Distribuerade datastrukturer

Fluid Framework ger utvecklare distribuerade datastrukturer (DDSe) som automatiskt säkerställer att varje ansluten klient har åtkomst till samma tillstånd. API:erna som tillhandahålls av DDSes är utformade för att vara bekanta för programmerare som har använt vanliga datastrukturer tidigare.

En distribuerad datastruktur fungerar som en lokal datastruktur. Koden kan lägga till data i den, ta bort data, uppdatera dem osv. En DDS är dock inte ett lokalt objekt. En DDS kan också ändras av andra klienter som exponerar samma överordnade container för DDS. Eftersom användare kan ändra samma DDS samtidigt måste du överväga vilken DDS som ska användas för att modellera dina data.

Om du väljer rätt datastruktur för ditt scenario kan du förbättra programmets prestanda och kodstruktur.

DDSes varierar från varandra med tre egenskaper:

• Grundläggande datastruktur: Till exempel nyckel/värde-par, en sekvens eller en kö.
• Klientautonomi: En optimistisk DDS gör det möjligt för alla klienter att ensidigt ändra ett värde och det nya värdet vidarebefordras till alla andra klienter. Men en konsensus-DDS tillåter bara en ändring om den accepteras av andra klienter genom en konsensusprocess.
• Sammanslagningsprincip: Den princip som avgör hur motstridiga ändringar från klienter löses.

Nedan har vi räknat upp datastrukturerna och beskrivit när de kan vara mest användbara.

Nyckel/värde-data

Dessa DDS:er används för att lagra nyckel/värde-data. De är optimistiska och använder en sammanslagningsprincip för de senaste skrivarna. Även om värdet för ett par kan vara ett komplext objekt kan inte värdet för ett givet par redigeras direkt. hela värdet måste ersättas med ett nytt värde som innehåller önskade ändringar, helt för hela.

• SharedMap: en grundläggande nyckel/värde-datastruktur.

Scenarier med nyckelvärde

Nyckelvärdesdatastrukturer är det vanligaste valet för många scenarier.

• Användarinställningsdata.
• Aktuellt tillstånd för en undersökning.
• Konfigurationen av en vy.

Vanliga problem och metodtips för nyckelvärdes-DDS:er

• Att lagra en räknare i en SharedMap kommer att ha ett oväntat beteende. Använd SharedCounter i stället.
• Lagring av matriser, listor eller loggar i en nyckel/värde-post kan leda till oväntat beteende eftersom användarna inte kan ändra delar av en post gemensamt. Prova att lagra matrisen eller listdata i en SharedSequence eller SharedInk.
• Lagring av mycket data i en nyckel/värde-post kan orsaka prestanda- eller sammanslagningsproblem. Varje uppdatering uppdaterar hela värdet i stället för att slå samman två uppdateringar. Prova att dela upp data mellan flera nycklar.

Sekvenser

Dessa DDS:er används för att lagra sekventiella data. De är optimistiska. Sekvensdatastrukturer är användbara när du behöver lägga till eller ta bort data i ett angivet index i en lista eller matris. Till skillnad från nyckel/värde-datastrukturerna har sekvenser sekventiell ordning och kan hantera samtidiga infogningar från flera användare.

• SharedNumberSequence: en sekvens med tal.
• SharedObjectSequence: en sekvens med oformaterade objekt.

Sekvensscenarier

• Listor
• Tidslinjer

Vanliga problem och metodtips för sekvens-DDS:er

• Lagra endast oföränderliga data som ett objekt i en sekvens. Det enda sättet att ändra värdet för ett objekt är att först ta bort det från sekvensen och sedan infoga ett nytt värde på den position där det gamla värdet fanns. Men eftersom andra klienter kan infoga och ta bort finns det inget tillförlitligt sätt att få det nya värdet i önskad position.

Strängar

SharedString DDS används för ostrukturerade textdata som kan redigeras tillsammans. Det är optimistiskt.

• SharedString – en datastruktur för att hantera samarbetstext.

Strängscenarier

• Textredigerare

Se även

Mer information om DDSes och hur du använder dem finns i följande avsnitt i fluidframework.com:

• Introduktion till distribuerade datastrukturer.
• Typer av distribuerade datastrukturer.