Serialiserbarhet

Den här artikeln handlar om serialisering av databastransaktioner. För serialisering av objekt i objektorienterade språk, se serialisering .

Vid samtidig kontroll av databaser , transaktionsbearbetning (transaktionshantering) och olika transaktionstillämpningar (t.ex. transaktionsminne och programvarans transaktionsminne ), både centraliserade och distribuerade , är ett transaktionsschema serialiserbart om dess resultat (t.ex. det resulterande databastillståndet) är lika med resultatet av dess transaktioner som utförs i serie, dvs utan överlappning i tid. Transaktioner utförs normalt samtidigt (de överlappar varandra), eftersom detta är det mest effektiva sättet. Serialiseringsbarhet är det viktigaste korrekthetskriteriet för samtidiga transaktioners exekveringar [ citat behövs ] . Det anses vara den högsta nivån av isolering mellan transaktioner och spelar en viktig roll vid samtidighetskontroll . Som sådan stöds den i alla allmänna databassystem. Stark strikt tvåfaslåsning (SS2PL) är en populär serialiseringsmekanism som används i de flesta databassystem (i olika varianter) sedan deras tidiga dagar på 1970-talet.

Serialiseringsteorin ger den formella ramen för att resonera kring och analysera serialiseringsbarhet och dess tekniker. Även om det är matematiskt till sin natur, introduceras dess grunder informellt (utan matematiknotation) nedan.

Rätthet

Serialiserbarhet

Serialiserbarhet används för att hålla data i dataobjektet i ett konsekvent tillstånd. Serialiserbarhet är en egenskap hos ett transaktionsschema ( historik). Det hänför sig till isoleringsegenskapen för en databastransaktion .

Serialisering av ett schema innebär likvärdighet (i resultatet, databastillståndet, datavärden) med ett seriellt schema (dvs. sekventiellt utan transaktionsöverlappning i tid) med samma transaktioner. Det är det viktigaste kriteriet för korrektheten av schemat för samtidiga transaktioner och stöds därför i alla databassystem för allmänna ändamål. [ citat behövs ]
Grunden bakom serialiserbarhet är följande:
Om varje transaktion är korrekt i sig själv, dvs. uppfyller vissa integritetsvillkor, är ett schema som omfattar varje seriell exekvering av dessa transaktioner korrekt (dess transaktioner uppfyller fortfarande sina villkor): " Serial" betyder att transaktioner inte överlappar varandra i tid och inte kan störa varandra, dvs. fullständig isolering mellan varandra existerar. Varje ordning av transaktionerna är legitim, om det inte finns några beroenden mellan dem, vilket antas (se kommentar nedan). Som ett resultat är ett schema som omfattar varje exekvering (inte nödvändigtvis seriellt) som är likvärdig (i sitt resultat) med varje seriell exekvering av dessa transaktioner, korrekt.

Schema som inte är serialiserbara kommer sannolikt att generera felaktiga resultat. Välkända exempel är med transaktioner som debiterar och krediterar pengar: Om de relaterade scheman inte kan serialiseras kanske den totala summan pengar inte bevaras. Pengar kan försvinna eller genereras från ingenstans. Detta och överträdelser av eventuellt nödvändiga andra oföränderliga bevaringar orsakas av att en transaktion skriver, och "trampar på" och raderar det som har skrivits av en annan transaktion innan det har blivit permanent i databasen. Det händer inte om serialiseringsbarheten bibehålls.

Om någon specifik ordning mellan vissa transaktioner begärs av en applikation, verkställs den oberoende av de underliggande serialiseringsmekanismerna. Dessa mekanismer är vanligtvis likgiltiga för någon specifik order och genererar en oförutsägbar delordning som vanligtvis är kompatibel med flera serieorder av dessa transaktioner. Denna delorder är resultatet av schemaläggningsorder för samtidiga transaktioners dataåtkomstoperationer, som beror på många faktorer.

En viktig egenskap hos en databastransaktion är atomicitet , vilket innebär att den antingen begår , dvs. alla dess operationers resultat träder i kraft i databasen, eller avbryter (rullas tillbaka), alla dess operationers resultat har ingen effekt på databas ("allt eller inget" semantik för en transaktion). I alla verkliga system kan transaktioner avbrytas av många skäl, och serialisering i sig är inte tillräcklig för korrekthet. Scheman måste också ha återvinning (från abort). Återvinningsbarhet innebär att begångna transaktioner inte har läst data som skrivits av avbrutna transaktioner (vars effekter inte finns i de resulterande databastillstånden). Även om serialiseringsförmågan för närvarande äventyras avsiktligt i många applikationer för bättre prestanda (endast i de fall då applikationens korrekthet inte skadas), skulle en äventyrande av återställningsbarheten snabbt bryta mot databasens integritet, såväl som för transaktionernas resultat utanför databasen. Ett schema med återställningsegenskapen (ett återställbart schema) "återhämtar sig" från avbrott av sig självt, dvs. avbryter skadar inte integriteten för dess genomförda transaktioner och den resulterande databasen. Detta är falskt utan återställningsbarhet, där de sannolika integritetsbrotten (som resulterar i felaktig databasdata) kräver speciella, vanligtvis manuella, korrigerande åtgärder i databasen.

Implementering av återvinningsbarhet i dess allmänna form kan resultera i kaskadavbrott : Att avbryta en transaktion kan resultera i ett behov av att avbryta en andra transaktion, och sedan en tredje, och så vidare. Detta resulterar i ett slöseri med redan delvis genomförda transaktioner och kan även resultera i en prestationsstraff. Att undvika kaskadavbrott (ACA eller Cascadelessness) är ett specialfall av återhämtning som exakt förhindrar sådana fenomen. I praktiken används ofta ett specialfall av ACA: Strikthet . Strikthet tillåter effektiv databasåterställning från fel.

Observera att återställningsegenskapen behövs även om inget databasfel inträffar och ingen databasåterställning från fel behövs. Det behövs snarare för att korrekt automatiskt hantera avbrott, som inte kan vara relaterade till databasfel och återställning från fel.

Avkopplande serialiserbarhet

I många applikationer, till skillnad från med ekonomi, behövs inte absolut korrekthet. När man till exempel hämtar en lista över produkter enligt specifikation spelar det i de flesta fall inte så stor roll om en produkt, vars data uppdaterades för en kort tid sedan, inte finns med i listan, även om den uppfyller specifikationen. Det kommer vanligtvis att visas i en sådan lista när du försöker igen en kort tid senare. Kommersiella databaser ger samtidighetskontroll med en hel rad isoleringsnivåer som i själva verket är (kontrollerade) serialiseringsbrott för att uppnå högre prestanda. Högre prestanda innebär bättre transaktionsexekveringshastighet och kortare genomsnittlig transaktionssvarstid (transaktionslängd). Snapshot-isolering är ett exempel på en populär, allmänt använd effektiv avslappnad serialiseringsmetod med många egenskaper för full serialiserbarhet, men fortfarande brist på några, och olämplig i många situationer.

En annan vanlig anledning numera för att lätta på distribuerad serialisering (se nedan) är kravet på tillgänglighet av internetprodukter och tjänster . Detta krav besvaras vanligtvis av storskalig datareplikering . Den enkla lösningen för att synkronisera replikas uppdateringar av samma databasobjekt är att inkludera alla dessa uppdateringar i en enda atomär distribuerad transaktion . Men med många repliker är en sådan transaktion mycket stor och kan sträcka sig över tillräckligt många av flera datorer och nätverk så att vissa av dem sannolikt inte är tillgängliga. En sådan transaktion kommer sannolikt att sluta med avbrytande och missa sitt syfte. Följaktligen används ofta Optimistisk replikering (lat replikering) (t.ex. i många produkter och tjänster av Google , Amazon , Yahoo och liknande), medan serialiseringsmöjligheten är avslappnad och äventyras för eventuell konsekvens . Återigen, i detta fall görs avslappning endast för applikationer som inte förväntas skadas av denna teknik.

Klasser av scheman definierade av avslappnade serialiseringsegenskaper innehåller antingen serialiseringsklassen eller är ojämförbara med den.

Serialiserbarhet och konflikter

Mekanismer som tvingar fram serialiserbarhet måste köras i realtid , eller nästan i realtid, medan transaktioner körs i höga takter. För att uppfylla detta krav utnyttjas särskilda fall av serialiseringsbarhet, tillräckliga villkor för serialisering som kan genomdrivas effektivt.

Två huvudtyper av serialiserbarhet finns: view-serializability och konflikt-serialiserbarhet . View-serialiserbarhet matchar den allmänna definitionen av serialiserbarhet som ges ovan. Konfliktserialiserbarhet är ett brett specialfall, dvs varje schema som är konfliktserialiserbart är också visningsserialiserbart, men inte nödvändigtvis motsatsen. Konfliktserialiserbarhet används i stor utsträckning eftersom det är lättare att fastställa och täcker en betydande del av de visningsserialiserbara scheman. Att bestämma visningsserialisering av ett schema är ett NP-komplett problem (en klass av problem med endast svårberäknade, alltför tidskrävande kända lösningar).

View-serialiserbarhet av ett schema definieras av ekvivalens till ett seriellt schema (inga överlappande transaktioner) med samma transaktioner, så att respektive transaktioner i de två schemana läser och skriver samma datavärden ("visa" samma datavärden).
Konflikt-serialiserbarhet av ett schema definieras av ekvivalens till ett seriellt schema (inga överlappande transaktioner) med samma transaktioner, så att båda scheman har samma uppsättningar av respektive kronologiskt ordnade par av motstridiga operationer (samma prioritetsrelationer för respektive motstridiga operationer).

Operationer på data läses eller skrivas (en skrivning: infoga , uppdatera eller ta bort ). Två operationer är motstridiga om de är av olika transaktioner, på samma datum (datapost), och minst en av dem är skriv . Varje sådant par av motstridiga operationer har en konflikttyp : det är antingen en läs-skriv- eller skriv-läs- eller en skriv-skriv- konflikt. Transaktionen för den andra operationen i paret sägs vara i konflikt med transaktionen för den första operationen. En mer allmän definition av motstridiga operationer (även för komplexa operationer, som var och en kan bestå av flera "enkla" läs/skrivoperationer) kräver att de är icke-kommutativa (om du ändrar deras ordning ändras också deras kombinerade resultat). Varje sådan operation måste vara atomär i sig själv (med hjälp av rätt systemstöd) för att betraktas som en operation för en kommutativitetskontroll. Till exempel är läs-läs-operationer kommutativa (till skillnad från läs-skriv och de andra möjligheterna) och därför är läs-läs inte en konflikt. Ett annat mer komplext exempel: operationerna ökar och minskar en räknare är båda skrivoperationer (båda modifierar räknaren), men behöver inte betraktas som motstridiga (skriv-skriv-konflikttyp) eftersom de är kommutativa (ökning–minskning är alltså inte en konflikt, t.ex. redan har stötts i den gamla IBM:s IMS "snabba väg" ) . Endast företräde (tidsordning) i par av motstridiga (icke-kommutativa) operationer är viktigt när man kontrollerar ekvivalens till ett seriellt schema, eftersom olika scheman som består av samma transaktioner kan omvandlas från en till en annan genom att ändra order mellan olika transaktioners operationer ( olika transaktioners interfoliering), och eftersom ändring av ordningsföljd för kommutativa operationer (icke-konfliktiga) inte ändrar ett övergripande operationssekvensresultat, dvs ett schemaresultat (resultatet bevaras genom orderändring mellan icke-konfliktiga operationer, men vanligtvis inte när motstridiga operationer ändra ordning). Detta innebär att om ett schema kan omvandlas till vilket seriellt schema som helst utan att ändra order på motstridiga operationer (men att ändra order om icke-konflikt, samtidigt som operationsordningen bevaras i varje transaktion), då blir resultatet av båda scheman detsamma, och schemat är per definition konfliktserialiserbar.

Konflikter är anledningen till att blockera transaktioner och förseningar (icke-materialiserade konflikter), eller för att avbryta transaktioner på grund av att serialiseringsbrott förhindras. Båda möjligheterna minskar prestandan. Att således minska antalet konflikter, t.ex. genom kommutativitet (när det är möjligt), är ett sätt att öka prestandan.

En transaktion kan utfärda/begära en konfliktåtgärd och vara i konflikt med en annan transaktion medan dess motstridiga operation är försenad och inte körs (t.ex. blockerad av ett lås ). Endast utförda ( materialiserade ) motstridiga operationer är relevanta för konfliktens serialiseringsbarhet (se mer nedan).

Genomföra konflikter som kan serialiseras

Testar konflikt serialiserbarhet

Schemaöverensstämmelse med konfliktserialiseringsbarhet kan testas med prioritetsgrafen ( serialiseringsgraf , serialiseringsgraf , konfliktgraf ) för genomförda transaktioner i schemat. Det är den riktade grafen som representerar prioritet för transaktioner i schemat, vilket återspeglas av prioritet för motstridiga operationer i transaktionerna.

I prioritetsgrafen är transaktioner noder och prioritetsrelationer är riktade kanter. Det finns en fördel från en första transaktion till en andra transaktion, om den andra transaktionen är i konflikt med den första (se Konflikt serialiserbarhet ovan), och konflikten materialiseras ( dvs. om den begärda konfliktåtgärden faktiskt utförs: i många fall en begärd/utfärdad motstridig operation av en transaktion försenas och till och med aldrig exekveras, vanligtvis av ett lås på operationens objekt, som hålls av en annan transaktion, eller när du skriver till en transaktions tillfälliga privata arbetsyta och materialiserar, kopiering till själva databasen, vid commit ; så länge som en begärd/utfärdad motstridig operation inte exekveras på själva databasen, är konflikten icke-materialiserad ; icke-materialiserade konflikter representeras inte av en kant i prioritetsdiagrammet).
Kommentar: I många läroböcker ingår endast genomförda transaktioner i prioritetsdiagrammet. Här ingår alla transaktioner för bekvämlighet i senare diskussioner.

Följande observation är en nyckelkarakterisering av konfliktserialiserbarhet :

Ett schema är konfliktserialiserbart om och endast om dess prioritetsgraf över begångna transaktioner (när endast begångna transaktioner beaktas) är acyklisk . Detta innebär att en cykel som endast består av genomförda transaktioner genereras i den (allmänna) prioritetsgrafen, om och endast om konfliktserialiserbarheten kränks.

Cykler av begångna transaktioner kan förhindras genom att avbryta en obestämd (varken genomförd eller avbruten) transaktion på varje cykel i prioritetsdiagrammet för alla transaktioner, som annars kan förvandlas till en cykel av begångna transaktioner (och en begången transaktion kan inte avbrytas) . En transaktion avbruten per cykel är både nödvändig och tillräckligt till antal för att bryta och eliminera cykeln (fler avbrott är möjliga och kan ske under vissa mekanismer, men är onödiga för att kunna serialiseras). Sannolikheten för cykelgenerering är typiskt låg, men ändå hanteras en sådan situation noggrant, vanligtvis med en avsevärd mängd omkostnader, eftersom korrekthet är inblandat. Transaktioner som avbrutits på grund av förhindrande av serialiseringsbrott startas om och körs omedelbart igen.

Serialiseringsförstärkande mekanismer upprätthåller vanligtvis inte en prioritetsgraf som en datastruktur, utan snarare förhindrar eller bryter cykler implicit (t.ex. SS2PL nedan).

Vanlig mekanism — SS2PL

Huvudartikel: Tvåfaslåsning

Stark strikt tvåfaslåsning (SS2PL) är en vanlig mekanism som använts i databassystem sedan deras tidiga dagar på 1970-talet ("SS" i namnet SS2PL är dock nyare) för att upprätthålla både serialisering av konflikter och strikthet (ett specialfall av återställbarhet som möjliggör effektiv databasåterställning från fel) av ett schema. Enligt denna mekanism låses varje datum av en transaktion innan den kommer åt den (i valfri läs- eller skrivoperation): objektet är markerat med och associerat med ett lås av en viss typ beroende på den operation som utförs (och den specifika transaktionsimplementeringen ; olika modeller med olika låstyper finns; i vissa modeller kan lås byta typ under transaktionens livstid). Som ett resultat kan åtkomst av en annan transaktion blockeras, vanligtvis vid en konflikt (låset fördröjer eller förhindrar helt att konflikten förverkligas och återspeglas i prioritetsdiagrammet genom att blockera den motstridiga operationen), beroende på låstyp och den andra transaktionens åtkomstoperationstyp. Att använda en SS2PL-mekanism innebär att alla lås på data för en transaktions räkning släpps först efter att transaktionen har avslutats (antingen genomförd eller avbruten).

SS2PL är också namnet på den resulterande schemaegenskapen, som också kallas rigorousness . SS2PL är ett specialfall ( korrekt delmängd ) av tvåfaslåsning (2PL)

Ömsesidig blockering mellan transaktioner resulterar i ett dödläge , där exekveringen av dessa transaktioner stannar och inget slutförande kan nås. Sålunda måste låsningar lösas för att slutföra dessa transaktioners exekvering och frigöra relaterade datorresurser. Ett dödläge är en återspegling av en potentiell cykel i prioritetsgrafen som skulle inträffa utan blockeringen när konflikter materialiseras. Ett dödläge löses genom att avbryta en transaktion involverad i en sådan potentiell cykel och bryta cykeln. Det upptäcks ofta med hjälp av en väntan-på-graf (en graf över konflikter som blockeras av lås från att materialiseras; den kan också definieras som grafen över icke-materialiserade konflikter; konflikter som inte har materialiserats återspeglas inte i prioritetsgrafen och påverkar inte serialiserbarhet), som indikerar vilken transaktion som "väntar på" frisläppandet av ett eller flera lås genom vilka andra transaktioner eller transaktioner, och en cykel i denna graf innebär ett dödläge. Att avbryta en transaktion per cykel är tillräckligt för att bryta cykeln. Transaktioner som avbrutits på grund av dödlägeslösning startas om och körs omedelbart igen.

Andra verkställighetstekniker

Andra kända mekanismer inkluderar:

Ovanstående (konflikt) serialiseringstekniker i sin allmänna form ger inte återvinningsbarhet. Särskilda förbättringar behövs för att lägga till återställningsbarhet.

Optimistisk kontra pessimistisk teknik

Samtidighetskontrolltekniker är av tre huvudtyper:

  1. Pessimistisk : I pessimistisk samtidighetskontroll blockerar en transaktion dataåtkomstoperationerna för andra transaktioner vid konflikter, och konflikter är icke-materialiserade tills blockeringen tas bort. Detta görs för att säkerställa att operationer som kan bryta mot serialiseringsbarheten (och i praktiken även återvinningsbarheten) inte inträffar.
  2. Optimistisk : I Optimistisk samtidighetskontroll blockeras inte dataåtkomstoperationerna för andra transaktioner vid konflikter, och konflikter uppstår omedelbart . När transaktionen når redo -tillståndet, dvs. dess körtillstånd har slutförts, kontrolleras eventuell serialiserbarhet (och i praktiken även återvinningsbarhet) av transaktionens operationer (i förhållande till andra pågående transaktioner): om överträdelse har inträffat, är transaktionen vanligtvis avbruten (ibland är det att föredra att avbryta en annan transaktion för att hantera brott mot serialisering). Annars är det engagerat .
  3. Semi-optimistisk : Mekanismer som blandar blockering i vissa situationer med inte blockering i andra situationer och använder både materialiserade och icke-materialiserade konflikter.

De huvudsakliga skillnaderna mellan tekniktyperna är konflikttyperna som genereras av dem. En pessimistisk metod blockerar en transaktionsoperation vid konflikt och genererar en icke-materialiserad konflikt, medan en optimistisk metod inte blockerar och genererar en materialiserad konflikt. En semi-optimistisk metod genererar båda konflikttyperna. Båda konflikttyperna genereras av de kronologiska ordningarna i vilka transaktionsoperationer anropas, oberoende av typen av konflikt. En cykel av begångna transaktioner (med materialiserade konflikter) i prioritetsdiagrammet ( konfliktdiagram ) representerar en serialiseringsöverträdelse och bör undvikas för att upprätthålla serialiseringsbarheten. En cykel av (icke-materialiserade) konflikter i väntan-på-grafen representerar en dödlägessituation, som bör lösas genom att bryta cykeln. Båda cykeltyperna är resultatet av konflikter och bör brytas. Under alla typer av teknik bör konflikter upptäckas och övervägas, med liknande omkostnader för både materialiserade och icke-materialiserade konflikter (vanligtvis genom att använda mekanismer som låsning, medan antingen blockering för lås eller inte blockering men konflikt för materialiserade konflikter registreras). I en blockeringsmetod sker typiskt en kontextväxling vid konflikt, med (ytterligare) uppkomna overhead. Annars förblir blockerade transaktioners relaterade datorresurser inaktiva, outnyttjade, vilket kan vara ett sämre alternativ. När konflikter inte förekommer ofta har optimistiska metoder vanligtvis en fördel. Med olika transaktionsbelastningar (blandningar av transaktionstyper) kan en tekniktyp (dvs. antingen optimistisk eller pessimistisk) ge bättre prestanda än den andra.

Såvida inte schemaklasser i sig är blockerande (dvs. de kan inte implementeras utan blockering av dataåtkomstoperationer; t.ex. 2PL, SS2PL och SCO ovan; se diagrammet), kan de också implementeras med optimistiska tekniker (t.ex. Serialiserbarhet, Återställningsbarhet).

Serialiserbar multi-version samtidighetskontroll

Se även Multiversion samtidighetskontroll (delvis täckning) och Serialiserbar Snapshot Isolation i Snapshot-isolering

Multi-version concurrency control (MVCC) är ett vanligt sätt idag att öka samtidighet och prestanda genom att generera en ny version av ett databasobjekt varje gång objektet skrivs och tillåta transaktioners läsoperationer av flera senaste relevanta versioner (av varje objekt), beroende på schemaläggningsmetod. MVCC kan kombineras med alla serialiseringstekniker som anges ovan (förutom SerializableSI, som ursprungligen är MVCC-baserad). Det används i de flesta allmänna DBMS-produkter.

MVCC är särskilt populärt numera genom den avslappnade serialiseringsmetoden (se ovan) Snapshot isolation (SI) som ger bättre prestanda än de flesta kända serialiseringsmekanismer (till priset av eventuella serialiserbarhetsbrott i vissa fall). SerializableSI , som är en effektiv förbättring av SI för att göra den serialiserbar, är avsedd att tillhandahålla en effektiv serialiserbar lösning. SerializableSI har analyserats via en allmän teori om MVCC.

Distribuerad serialiserbarhet

Översikt

Distribuerad serialiserbarhet är serialiserbarheten av ett schema för ett transaktionsdistribuerat system (t.ex. ett distribuerat databassystem) . Ett sådant system kännetecknas av distribuerade transaktioner (även kallade globala transaktioner ), dvs transaktioner som sträcker sig över datorprocesser (en processabstraktion i allmän mening, beroende på datormiljö; t.ex. operativsystemets tråd ) och möjligen nätverksnoder. En distribuerad transaktion omfattar mer än en av flera lokala deltransaktioner som var och en har tillstånd enligt beskrivningen ovan för en databastransaktion . En lokal deltransaktion omfattar en enda process, eller flera processer som vanligtvis misslyckas tillsammans (t.ex. i en enda processorkärna ). Distribuerade transaktioner innebär ett behov av ett atomärt åtagandeprotokoll för att nå konsensus bland dess lokala deltransaktioner om huruvida det ska begås eller avbrytas. Sådana protokoll kan variera från en enkel (enfas) handskakning bland processer som misslyckas tillsammans till mer sofistikerade protokoll, som tvåfas commit , för att hantera mer komplicerade fall av fel (t.ex. process, nod, kommunikation, etc. fel). Distribuerad serialiserbarhet är ett viktigt mål för distribuerad samtidighetskontroll för korrekthet. Med spridningen av Internet , cloud computing , grid computing och små, bärbara, kraftfulla datorenheter (t.ex. smartphones ) verkar behovet av effektiva distribuerade serialiseringstekniker för att säkerställa korrekthet i och bland distribuerade applikationer öka.

Distribuerad serialiserbarhet uppnås genom att implementera distribuerade versioner av de kända centraliserade teknikerna. Vanligtvis kräver alla sådana distribuerade versioner användning av konfliktinformation (av antingen materialiserade eller icke-materialiserade konflikter, eller, på motsvarande sätt, transaktionsföreträde eller blockeringsinformation; konfliktserialiserbarhet används vanligtvis) som inte genereras lokalt, utan snarare i olika processer, och på distans platser. Därför behövs informationsdistribution (t.ex. prioritetsrelationer, låsinformation, tidsstämplar eller biljetter). När det distribuerade systemet är av en relativt liten skala och meddelandefördröjningarna över systemet är små, kan de centraliserade samtidighetskontrollmetoderna användas oförändrade medan vissa processer eller noder i systemet hanterar de relaterade algoritmerna. Men i ett storskaligt system (t.ex. rutnät och moln ), på grund av distributionen av sådan information, uppstår vanligtvis en betydande prestationsstraff, även när distribuerade versioner av metoderna (mot de centraliserade) används, i första hand på grund av dator- och kommunikationslatens . Dessutom, när sådan information distribueras, är relaterade tekniker vanligtvis inte skala bra. Ett välkänt exempel med avseende på skalbarhetsproblem är en distribuerad låshanterare , som distribuerar låsinformation (icke-materialiserad konflikt) över det distribuerade systemet för att implementera låstekniker.

Se även

Anteckningar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Serializability&oldid=1134256108 "