Serialiserbarhed - Serializability

Denne artikel handler om seriabilitet af databasetransaktioner. For serialisering af objekter på objektorienterede sprog, se serialisering .

I concurrency kontrol af databaser , transaction processing (transaktionsstyring), og forskellige transaktionelle applikationer (fx transaktionsbeslutning hukommelse og software transaktionsbeslutning hukommelse ), både centraliseret og distribueret , en transaktion tidsplan er Serializable hvis dens udfald (fx den resulterende database tilstand) er svarende til resultatet af dets transaktioner, der udføres serielt, dvs. uden at overlappe i tide. Transaktioner udføres normalt samtidigt (de overlapper hinanden), da dette er den mest effektive måde. Serialiserbarhed er det største korrektionskriterium for samtidige transaktioner. Det betragtes som det højeste niveau af isolation mellem transaktioner og spiller en vigtig rolle i samtidighedskontrol . Som sådan understøttes det i alle generelle databasesystemer. Stærk streng tofaselåsning (SS2PL) er en populær serieiserbarhedsmekanisme, der er brugt i de fleste databasesystemer (i forskellige varianter) siden deres tidlige dage i 1970'erne.

Serialiserbarhedsteori giver den formelle ramme til at resonnere om og analysere serialiserbarhed og dens teknikker. Selvom det er matematisk , introduceres dets grundlæggende uformelt (uden matematiknotation) nedenfor.

Korrekthed

Serialiserbarhed

Serialiserbarhed bruges til at holde dataene i dataelementet i en ensartet tilstand. Serializability er en egenskab ved en transaktion tidsplan (historie). Det vedrører isolationsegenskaben for en databasetransaktion .

Serialiserbarhed af en tidsplan betyder ækvivalens (i resultatet, databasetilstand, dataværdier) til en seriel tidsplan (dvs. sekventiel uden transaktionsoverlappende tid) med de samme transaktioner. Det er det vigtigste kriterium for korrektheden af ​​samtidige transaktionsplan og understøttes således i alle databasesystemer til generelle formål.
Begrundelsen bag serialiserbarhed er følgende:
Hvis hver transaktion er korrekt i sig selv, dvs. opfylder visse integritetsbetingelser, er en tidsplan, der omfatter enhver seriel udførelse af disse transaktioner, korrekt (dens transaktioner opfylder stadig deres betingelser): "Seriel" betyder, at transaktioner ikke overlapper i tide og ikke kan interferere med hinanden, dvs. der findes fuldstændig isolation mellem hinanden. Enhver rækkefølge af transaktionerne er legitim, hvis der ikke er nogen afhængighed blandt dem, hvilket antages (se kommentar nedenfor). Som et resultat er en tidsplan, der omfatter enhver udførelse (ikke nødvendigvis seriel), der svarer (i resultatet) til enhver seriel udførelse af disse transaktioner, korrekt.

Tidsplaner, der ikke kan serialiseres, vil sandsynligvis generere fejlagtige resultater. Kendte eksempler er med transaktioner, der debiterer og krediterer konti med penge: Hvis de relaterede tidsplaner ikke kan serienummeres, bevares den samlede sum ikke muligvis. Penge kan forsvinde eller genereres fra ingen steder. Dette og overtrædelser af eventuelt nødvendige andre uforanderlige konserveringer er forårsaget af en transaktionsskrivning og "trædning på" og sletning af, hvad der er skrevet af en anden transaktion, før den er blevet permanent i databasen. Det sker ikke, hvis serialiserbarhed opretholdes.

Hvis der kræves en bestemt ordre mellem nogle transaktioner af en applikation, håndhæves den uafhængigt af de underliggende serieiserbarhedsmekanismer. Disse mekanismer er typisk ligeglade med nogen bestemt rækkefølge, og generere nogle uforudsigelige partiel orden , der er typisk kompatibel med flere serielle ordrer af disse transaktioner. Denne delordre er resultatet af planlægningsordrer for samtidige transaktions dataadgangsoperationer, som afhænger af mange faktorer.

Et væsentligt kendetegn ved en databasetransaktion er atomicitet , hvilket betyder, at den enten forpligter sig , dvs. at alle dens operationers resultater træder i kraft i databasen eller afbryder (tilbagekoblet), alle dens operationers resultater har ingen effekt på database ("alt eller intet" semantik ved en transaktion). I alle reelle systemer kan transaktioner afbrydes af mange grunde, og seriabilisering i sig selv er ikke tilstrækkelig til korrekthed. Tidsplaner skal også have ejendommen til genopretning (fra afbrudt). Gendannelighed betyder, at forpligtede transaktioner ikke har læst data skrevet af afbrudte transaktioner (hvis virkninger ikke findes i de resulterende databasetilstande). Mens serialiserbarhed i øjeblikket er kompromitteret med vilje i mange applikationer for bedre ydeevne (kun i tilfælde, hvor applikations korrekthed ikke skades), ville kompromittering af gendannelsesmuligheder hurtigt krænke databasens integritet såvel som for transaktionsresultater uden for databasen. En tidsplan med nyttiggørelse ejendom (en genindvindingsværdi tidsplan) "genopretter" fra Afbryder af sig selv, det vil sige, Afbryder ikke skader integriteten af dens engagerede transaktioner og deraf følgende database. Dette er forkert uden gendannelse, hvor de sandsynlige integritetsovertrædelser (resulterende forkerte databasedata) har brug for specielle, typisk manuelle, korrigerende handlinger i databasen.

Implementering af gendannelsesmuligheder i sin generelle form kan resultere i kaskadeafbrydelser : Afbrydelse af en transaktion kan resultere i et behov for at afbryde en anden transaktion og derefter en tredje osv. Dette resulterer i spild af allerede delvist udførte transaktioner og kan også resultere i en præstationsstraff. Undgå cascading aborts (ACA eller Cascadelessness) er et specielt tilfælde af genopretningsevne, der nøjagtigt forhindrer sådanne fænomener. Ofte anvendes i praksis et specielt tilfælde af ACA: Strenghed . Strenghed tillader effektiv databasegendannelse efter fejl.

Bemærk, at nyttiggørelse ejendommen er nødvendig, selv om ingen database svigt og ingen database opsving er nødvendig fra fiasko. Det er snarere nødvendigt for korrekt håndtering af afbrydelser korrekt, hvilket muligvis ikke er relateret til databasefejl og gendannelse efter fiasko.

Afslappende seriabilitet

I mange applikationer er det i modsætning til økonomi ikke nødvendigt med absolut korrekthed. For eksempel, når man henter en liste over produkter i henhold til specifikationen, betyder det i de fleste tilfælde ikke meget, hvis et produkt, hvis data blev opdateret for kort tid siden, ikke vises på listen, selvom det opfylder specifikationen. Det vises typisk på en sådan liste, når det forsøges igen kort tid senere. Kommercielle databaser giver samtidighedskontrol med en lang række isolationsniveauer, der faktisk er (kontrollerede) overtrædelser af serialiserbarhed for at opnå højere ydeevne. Højere ydeevne betyder bedre transaktionsudførelsesrate og kortere gennemsnitlig transaktionssvaretid (transaktionsvarighed). Snapshotisolering er et eksempel på en populær, bredt anvendt effektiv, afslappet serialiserbarhedsmetode med mange karakteristika for fuld seriabilitet, men stadig kort for nogle og uegnet i mange situationer.

En anden almindelig årsag til lempelse af distribueret seriabilitet i dag (se nedenfor) er kravet om tilgængelighed af internetprodukter og -tjenester . Dette krav besvares typisk ved datareplikering i stor skala . Den ligefremme løsning til synkronisering af replikers opdateringer af det samme databaseobjekt inkluderer alle disse opdateringer i en enkelt atomfordelt transaktion . Imidlertid er en sådan transaktion med mange replikaer meget stor og kan spænde nok af et antal adskillige computere og netværk, at nogle af dem sandsynligvis ikke vil være tilgængelige. Således vil en sådan transaktion sandsynligvis ende med at afbryde og gå glip af formålet. Derfor anvendes optimistisk replikering (Lazy replication) ofte (f.eks. I mange produkter og tjenester af Google , Amazon , Yahoo og lignende), mens serialiserbarhed er afslappet og kompromitteret for eventuel konsistens . I dette tilfælde sker afslapning kun i applikationer, der ikke forventes at blive skadet af denne teknik.

Klasser af tidsplaner defineret af afslappede serialiserbarhedsegenskaber indeholder enten serierbarhedsklassen eller er uforlignelige med den.

Se og konflikt seriabilitet

Mekanismer, der håndhæver serialiserbarhed, skal udføres i realtid eller næsten i realtid, mens transaktioner kører til høje priser. For at imødekomme dette krav anvendes specielle tilfælde af seriabilisering, tilstrækkelige betingelser for seriabilisering, som kan håndhæves effektivt.

Der findes to hovedtyper af serialiserbarhed: visningsserialiserbarhed og konfliktserialiserbarhed . View-serializability matcher den generelle definition af serializability, der er givet ovenfor. Konfliktserialiserbarhed er et bredt specielt tilfælde, dvs. enhver tidsplan, der kan konfliktserialiseres, kan også serieserialiseres, men ikke nødvendigvis det modsatte. Konfliktserialiserbarhed bruges i vid udstrækning, fordi det er lettere at bestemme og dækker en væsentlig del af tidsplanerne, der kan serier, der vises. Det er et NP-komplet problem at bestemme en tidsplaners serieafgrænsning (en klasse af problemer med kun vanskelige at beregne, alt for tidskrævende kendte løsninger).

Visningsserialiserbarhed af en tidsplan er defineret ved ækvivalens med en seriel tidsplan (ingen overlappende transaktioner) med de samme transaktioner, således at de respektive transaktioner i de to tidsplaner læser og skriver de samme dataværdier ("får vist" de samme dataværdier).
Konfliktserialiserbarhed af en tidsplan defineres ved ækvivalens med en seriel tidsplan (ingen overlappende transaktioner) med de samme transaktioner, således at begge tidsplaner har de samme sæt af respektive kronologisk ordnede par af modstridende operationer (samme forrangsrelationer for respektive modstridende operationer).

Operationer på data læses eller skrives (en skrivning: enten indsæt eller modificer eller slet ). To operationer er i modstrid med hinanden, hvis de er af forskellige transaktioner på samme dato (dataelement), og mindst en af ​​dem er skrivning . Hvert sådant par af modstridende operationer har en konflikttype : det er enten en læs-skriv eller skriv-læs eller en skriv-skriv- konflikt. Transaktionen med den anden operation i parret siges at være i konflikt med transaktionen med den første operation. En mere generel definition af modstridende operationer (også for komplekse operationer, som hver kan bestå af flere "enkle" læse / skrive-operationer) kræver, at de er ikke-kommutative (ændring af rækkefølgen ændrer også deres samlede resultat). Hver sådan operation skal være atomisk i sig selv (ved hjælp af korrekt systemunderstøttelse) for at blive betragtet som en operation til en kommutativitetskontrol. For eksempel er read-read-operationer kommutativ (i modsætning til read-write og de andre muligheder), og read-read er således ikke en konflikt. Et andet mere komplekst eksempel: operationens tilvækst og mindskelse af en tæller er begge skriveoperationer (begge ændrer tælleren), men behøver ikke at blive betragtet som modstridende (skriv-skriv-konflikttype), da de er kommutative (således er inkrement – ​​dekrementering ikke en konflikt, f.eks. er allerede understøttet i den gamle IBMs IMS "hurtige vej" ). Kun forrang (tidsordre) i par af modstridende (ikke-kommutative) operationer er vigtig, når man kontrollerer ækvivalens med en seriel tidsplan, da forskellige tidsplaner, der består af de samme transaktioner, kan omdannes fra en til en anden ved at ændre ordrer mellem forskellige transaktioners operationer forskellige transaktioners interleaving), og da ændring af ordrer på kommutative operationer (ikke-modstridende) ikke ændrer et samlet operationssekvensresultat, dvs. et tidsplanresultat (resultatet bevares ved ordreændring mellem ikke-modstridende operationer, men typisk ikke når modstridende operationer ændrer rækkefølge). Dette betyder, at hvis en tidsplan kan omdannes til en hvilken som helst seriel tidsplan uden at ændre ordrer på modstridende operationer (men ændre ordrer på ikke-modstridende, mens bevarelse af rækkefølgen inde i hver transaktion), så er resultatet af begge tidsplaner det samme, og tidsplanen kan pr. definition konfliktserialiseres.

Konflikter er årsagen til at blokere transaktioner og forsinkelser (ikke-materialiserede konflikter) eller til afbrydelse af transaktioner på grund af forebyggelse af overtrædelse af seriabilitet. Begge muligheder reducerer ydeevnen. At reducere antallet af konflikter, f.eks. Ved kommutativitet (når det er muligt), er således en måde at øge ydeevnen på.

En transaktion kan udstede / anmode om en modstridende handling og være i konflikt med en anden transaktion, mens dens modstridende handling er forsinket og ikke udføres (f.eks. Blokeret af en lås ). Kun udførte ( materialiserede ) modstridende operationer er relevante for konfliktserialiserbarhed (se mere nedenfor).

Håndhævelse af konfliktserialisering

Test af konfliktserialiserbarhed

Tidsplanoverensstemmelse med konfliktserialiserbarhed kan testes med forrangsgrafen ( serialiserbarhedsgraf , serialiseringsgraf , konfliktgraf ) for forpligtede transaktioner i tidsplanen. Det er den rettede graf, der repræsenterer forrang for transaktioner i tidsplanen, hvilket afspejles i forrang for modstridende operationer i transaktionerne.

I forrangsgrafen er transaktioner noder, og forrangsrelationer er rettet mod kanter. Der findes en kant fra en første transaktion til en anden transaktion, hvis den anden transaktion er i konflikt med den første (se Konfliktserialiserbarhed ovenfor), og konflikten realiseres (dvs. hvis den anmodede modstridende handling faktisk udføres: i mange tilfælde en anmodet / udstedt modstridende handling ved en transaktion er forsinket og endda aldrig udført, typisk ved en lås på operationens objekt, der er indeholdt i en anden transaktion, eller når du skriver til en transaktions midlertidige private arbejdsområde og materialiserer, kopierer til selve databasen, når der er begået ; så længe en anmodet / udstedt modstridende handling ikke udføres på selve databasen, er konflikten ikke-materialiseret ; ikke-materialiserede konflikter er ikke repræsenteret ved en kant i forrangsgrafen).
Kommentar: I mange lærebøger er kun forpligtede transaktioner inkluderet i forrangsgrafen. Her er alle transaktioner inkluderet for nemheds skyld i senere diskussioner.

Følgende observation er en nøglekarakterisering af konfliktserialiserbarhed :

En tidsplan kan konfliktserieres, hvis og kun hvis dens forrangsgraf over forpligtede transaktioner (når kun forpligtede transaktioner betragtes) er cyklisk . Dette betyder, at en cyklus, der kun består af forpligtede transaktioner, genereres i den (generelle) forrangsgraf, hvis og kun hvis konfliktserialiserbarhed overtrædes.

Cykler af forpligtede transaktioner kan forhindres ved at afbryde en uafgjort (hverken begået eller afbrudt) transaktion i hver cyklus i forrangsgrafen over alle transaktionerne, som ellers kan blive til en cyklus af forpligtede transaktioner (og en forpligtet transaktion kan ikke afbrydes) . En transaktion, der afbrydes pr. Cyklus, er både påkrævet og tilstrækkelig i antal til at bryde og eliminere cyklussen (flere afbrydelser er mulige og kan ske under nogle mekanismer, men er unødvendige for serieiserbarhed). Sandsynligheden for cyklusgenerering er typisk lav, men alligevel håndteres en sådan situation omhyggeligt, typisk med en betydelig overhead, da korrekthed er involveret. Transaktioner, der er afbrudt på grund af forebyggelse af overtrædelse af seriabilitet genstartes og udføres straks igen.

Mekanismer til håndhævelse af serialiserbarhed opretholder typisk ikke en forrangsgraf som datastruktur, men snarere forhindrer eller bryder cykler implicit (f.eks. SS2PL nedenfor).

Fælles mekanisme - SS2PL

Hovedartikel: To-faselåsning

Stærk streng tofaselåsning (SS2PL) er en almindelig mekanisme, der er brugt i databasesystemer siden deres tidlige dage i 1970'erne ("SS" i navnet SS2PL er dog nyere) for at håndhæve både konfliktserialisering og strenghed (et specielt tilfælde af gendannelsesmulighed, som muliggør effektiv databasegendannelse efter svigt) af en tidsplan. Under denne mekanisme er hvert nulpunkt låst af en transaktion, inden den får adgang til det (i enhver læse- eller skriveoperation): varen er markeret med og forbundet med en lås af en bestemt type afhængigt af den operation, der udføres (og den specifikke transaktionsimplementering ; forskellige modeller med forskellige låsetyper findes; i nogle modeller kan låse ændre type i transaktionens levetid). Som et resultat kan adgang fra en anden transaktion blive blokeret, typisk ved en konflikt (låsen forsinker eller forhindrer fuldstændigt konflikten i at blive materialiseret og afspejles i forrangsgrafen ved at blokere den modstridende operation) afhængigt af låsetype og den anden transaktion adgangstype. Anvendelse af en SS2PL-mekanisme betyder, at alle låse på data på vegne af en transaktion kun frigives, efter at transaktionen er afsluttet (enten begået eller afbrudt).

SS2PL er også navnet på den resulterende tidsplanegenskab, som også kaldes strenghed . SS2PL er et specielt tilfælde ( korrekt delmængde ) af to- faselåsning (2PL)

Gensidig blokering mellem transaktioner resulterer i en blokering , hvor udførelsen af ​​disse transaktioner er stoppet, og der ikke kan opnås nogen gennemførelse. Således skal blokeringer løses for at afslutte disse transaktioners udførelse og frigive relaterede computerressourcer. En blokering er en afspejling af en potentiel cyklus i forrangsgrafen, der ville opstå uden blokering, når konflikter materialiseres. En blokering løses ved at afbryde en transaktion involveret i en sådan potentiel cyklus og bryde cyklussen. Det detekteres ofte ved hjælp af en ventetidsgraf (en graf over konflikter, der er blokeret af låse fra materialisering; det kan også defineres som grafen for ikke-materialiserede konflikter; konflikter, der ikke materialiseres, reflekteres ikke i forrangsgrafen og påvirker ikke serializability), som angiver, hvilken transaktion der "venter på" frigivelsen af ​​en af ​​flere låse, hvormed andre transaktioner eller transaktioner, og en cyklus i denne graf betyder en blokering. Afbrydelse af en transaktion pr. Cyklus er tilstrækkelig til at bryde cyklussen. Transaktioner afbrudt på grund af deadlock-opløsning genstartes og udføres straks igen.

Andre håndhævelsesteknikker

Andre kendte mekanismer inkluderer:

Ovenstående (konflikt) serialiseringsteknikker i deres generelle form giver ikke gendannelse. Specielle forbedringer er nødvendige for at tilføje gendannelsesmuligheder.

Optimistiske versus pessimistiske teknikker

Teknikker for samtidighedskontrol er af tre hovedtyper:

  1. Pessimistisk : I pessimistisk samtidighedskontrol blokerer en transaktion dataadgangsoperationer for andre transaktioner ved konflikter, og konflikter bliver ikke materialiseret, indtil blokering er fjernet. Dette gøres for at sikre, at operationer, der kan krænke serieiserbarhed (og i praksis også gendannelse), ikke finder sted.
  2. Optimistisk : I optimistisk samtidighedskontrol blokeres dataadgangsoperationer for andre transaktioner ikke ved konflikter, og konflikter materialiseres straks . Når transaktionen når den klar tilstand, dvs. dens kørende tilstand er afsluttet, kontrolleres mulig seriabiliserbar (og i praksis også gendannelsesmæssig) krænkelse af transaktionens operationer (i forhold til andre kørende transaktioner): hvis overtrædelse har fundet sted, er transaktionen typisk afbrudt (undertiden foretrækkes det at afbryde en anden transaktion for at håndtere overtrædelse af seriabilitet). Ellers er det begået .
  3. Semi-optimistisk : Mekanismer, der blander blokering i bestemte situationer med ikke blokering i andre situationer og anvender både materialiserede og ikke-materialiserede konflikter

De væsentligste forskelle mellem tekniktyperne er de konflikttyper, der genereres af dem. En pessimistisk metode blokerer en transaktionshandling ved konflikt og genererer en ikke-materialiseret konflikt, mens en optimistisk metode ikke blokerer og genererer en materialiseret konflikt. En semi-optimistisk metode genererer begge konflikttyper. Begge konflikttyper genereres af de kronologiske ordrer, hvor transaktionshandlinger påberåbes uafhængigt af typen af ​​konflikt. En cyklus af begåede transaktioner (med materialiserede konflikter) i forrangsgrafen (konfliktgraf) repræsenterer en overtrædelse af seriabilitet og bør undgås for at opretholde seriabilitet. En cyklus af (ikke-materialiserede) konflikter i ventetidsgrafen repræsenterer en dødvandssituation, som skal løses ved at bryde cyklussen. Begge cyklustyper skyldes konflikter og skal brydes. Under enhver tekniktype skal konflikter opdages og overvejes med lignende omkostninger for både materialiserede og ikke-materialiserede konflikter (typisk ved hjælp af mekanismer som låsning, mens de enten blokerer for låse eller ikke blokerer, men registrerer konflikt for materialiserede konflikter). I en blokeringsmetode opstår der typisk en kontekstskift ved konflikt med (yderligere) afholdt overhead. Ellers forbliver blokerede transaktioners relaterede databehandlingsressourcer inaktive, uudnyttede, hvilket kan være et værre alternativ. Når konflikter ikke opstår hyppigt, har optimistiske metoder typisk en fordel. Med forskellige transaktionsbelastninger (blandinger af transaktionstyper) kan en tekniktype (dvs. enten optimistisk eller pessimistisk) give bedre ydeevne end den anden.

Medmindre planlægningsklasser i sig selv blokerer (dvs. de kan ikke implementeres uden dataadgangsoperationer, der blokerer f.eks. 2PL, SS2PL og SCO ovenfor; se diagram), kan de også implementeres ved hjælp af optimistiske teknikker (f.eks. Serializability, Recovery).

Serialiserbar samtidskontrol med flere versioner

Se også Multiversion samtidighedskontrol (delvis dækning) og Serializable Snapshot Isolation i Snapshot isolation

Multi-version concurrency control (MVCC) er en almindelig måde i dag at øge samtidighed og ydeevne ved at generere en ny version af et databaseobjekt hver gang objektet skrives og tillade transaktioners læseoperationer af flere sidst relevante versioner (af hvert objekt), afhængigt af planlægningsmetoden. MVCC kan kombineres med alle ovennævnte serialiserbarhedsteknikker (undtagen SerializableSI, som oprindeligt er MVCC-baseret). Det bruges i de fleste generelle DBMS-produkter.

MVCC er især populært i dag gennem den afslappede serialiserbarhedsmetode (se ovenfor) Snapshot-isolation (SI), som giver bedre ydeevne end de fleste kendte serialiserbarhedsmekanismer (på bekostning af mulig serialiserbarhedsovertrædelse i visse tilfælde). SerializableSI , som er en effektiv forbedring af SI for at gøre det serialiserbart, er beregnet til at give en effektiv serieiserbar løsning. SerializableSI er blevet analyseret via en generel teori om MVCC

Distribueret seriabilitet

Oversigt

Distribueret serialiserbarhed er serialiserbarheden af ​​en tidsplan for et transaktionsdistribueret system (f.eks. Et distribueret databasesystem ). Et sådant system er kendetegnet ved distribuerede transaktioner (også kaldet globale transaktioner ), dvs. transaktioner, span computerprocesser (en proces abstraktion i generel forstand, afhængigt computing miljøet fx operativsystem 's tråd ) og muligvis netværksknudepunkter. En distribueret transaktion omfatter mere end en af ​​flere lokale undertransaktioner, som hver har tilstande som beskrevet ovenfor for en databasetransaktion . En lokal undertransaktion omfatter en enkelt proces eller flere processer, der typisk mislykkes sammen (f.eks. I en enkelt processorkerne ). Distribuerede transaktioner indebærer et behov for en atomforpligtelsesprotokol for at nå til enighed blandt dens lokale undertransaktioner om, hvorvidt de skal begå eller afbryde. Sådanne protokoller kan variere fra et simpelt (en-faset) håndtryk blandt processer, der fejler sammen til mere sofistikerede protokoller, som tofasetag , til at håndtere mere komplicerede tilfælde af fiasko (fx proces, node, kommunikation osv. Fiasko). Distribueret seriabilitet er et hovedmål for distribueret samtidighedskontrol for korrekthed. Med udbredelsen af Internettet , cloud computing , grid computing og små, bærbare, kraftfulde computerenheder (f.eks. Smartphones ) synes behovet for effektive distribuerede serierbarhedsteknikker for at sikre korrekthed i og blandt distribuerede applikationer at stige.

Distribueret seriabilitet opnås ved at implementere distribuerede versioner af de kendte centraliserede teknikker. Typisk kræver alle sådanne distribuerede versioner anvendelse af konfliktoplysninger (af enten materialiserede eller ikke-materialiserede konflikter eller, ækvivalent, transaktionsprioritet eller blokerende information; konfliktserialiserbarhed bruges normalt), der ikke genereres lokalt, men snarere i forskellige processer og fjerntliggende placeringer. Således er informationsdistribution nødvendig (f.eks. Forrangsrelationer, låsinformation, tidsstempler eller billetter). Når det distribuerede system er af relativt lille skala, og beskedforsinkelser på tværs af systemet er små, kan de centraliserede samtidige kontrolmetoder anvendes uændret, mens visse processer eller noder i systemet styrer de relaterede algoritmer. I et stort system (f.eks. Gitter og sky ) på grund af distributionen af ​​sådan information opstår der typisk en betydelig præstationsstraff, selv når distribuerede versioner af metoderne (vs. de centraliserede) anvendes, primært grundet computer og kommunikation latens . Når sådanne oplysninger distribueres, skalerer relaterede teknikker typisk ikke godt. Et velkendt eksempel med hensyn til skalerbarhedsproblemer er en distribueret låsemanager , som distribuerer låsinformation (ikke-materialiseret konflikt) på tværs af det distribuerede system for at implementere låseteknikker.

Se også

Bemærkninger

Referencer