HAPPO
ACID ( englannin sanasta atomicity, consistency, isolation, Durability ) on joukko vaatimuksia transaktiojärjestelmälle, joka varmistaa sen luotettavimman ja ennustettavimman toiminnan - atomiteetti , johdonmukaisuus , eristys , vakaus ; muotoili Jim Gray 1970-luvun lopulla [1] .
Vaatimusjoukkoa pidetään de facto standardina erittäin luotettaville järjestelmille, ensisijaisesti relaatiotietokantajärjestelmille , kun taas 2000-luvun puolivälissä hajautettujen DBMS-järjestelmien rakentamisessa oletettiin, että osa ACID-vaatimuksista hylätään (mikä on perusteltua CAP :n avulla lause , PACELC - lause ) tai vaatimusten ankaruuden vähentäminen ( BASE ) .
Atomicity
Atomicity varmistaa, että mikään tapahtuma ei ole osittain sitoutunut järjestelmään. Joko kaikki sen alioperaatiot suoritetaan tai mitään niistä ei suoriteta. Koska käytännössä on mahdotonta suorittaa samanaikaisesti ja atomisesti koko toimintosarjaa tapahtuman sisällä, otetaan käyttöön "palautuksen" ( rollback ) käsite: jos tapahtumaa ei voida saada kokonaan päätökseen, kaikkien sen tähän mennessä suoritettujen toimien tulokset peruutetaan ja järjestelmä palaa "ulkoisesti alkutilaan" - ulkopuolelta näyttää siltä, että tapahtumaa ei ollut (luonnollisesti laskurit, indeksit ja muut sisäiset rakenteet voivat muuttua, mutta jos DBMS on ohjelmoitu ilman virheitä, tämä ei vaikuta sen ulkoiseen käyttäytymiseen).
Johdonmukaisuus
Tapahtuma, joka saavuttaa normaalin tapahtuman päättymisen (EOT) ja sitoutuu siten tuloksensa, säilyttää tietokannan johdonmukaisuuden. Toisin sanoen jokainen onnistunut tapahtuma, määritelmän mukaan, sitoutuu vain kelvollisiin tuloksiin. Tämä ehto on välttämätön neljännen ominaisuuden tukemiseksi.
Johdonmukaisuus on laajempi käsite. Esimerkiksi pankkijärjestelmässä voi olla vaatimus, että yhdeltä tililtä veloitettava summa on sama kuin toiselle tilille hyvitetty summa. Tämä on liiketoimintasääntö, eikä sitä voida taata pelkillä eheystarkastuksilla, vaan ohjelmoijien on otettava se huomioon tapahtumakoodia kirjoittaessaan. Jos jokin tapahtuma veloittaa, mutta ei hyvitä, järjestelmä pysyy väärässä tilassa ja johdonmukaisuusominaisuus rikotaan.
Lopuksi vielä yksi huomautus koskee sitä tosiasiaa, että mitään johdonmukaisuutta ei vaadita tapahtuman suorittamisen aikana . Esimerkissämme veloitus ja hyvitys ovat todennäköisesti kaksi eri alioperaatiota, ja niiden suorittamisen välissä tapahtuman sisällä näkyy järjestelmän epäjohdonmukainen tila. Emme kuitenkaan saa unohtaa, että jos eristysvaatimus (katso alla) täyttyy, tämä epäjohdonmukaisuus ei näy muissa tapahtumissa. Ja atomicity takaa, että tapahtuma joko suoritetaan kokonaan tai mitään tapahtuman toiminnoista ei suoriteta. Siten tämä välin epäjohdonmukaisuus on piilotettu.
Eristäminen
Tapahtuman toteuttamisen aikana rinnakkaiset tapahtumat eivät saa vaikuttaa sen lopputulokseen. Eristäminen on kallis vaatimus, joten todellisissa tietokannoissa on tiloja, jotka eivät täysin eristä tapahtumaa ( eristystasot, jotka mahdollistavat phantom-lukemisen ja alhaisemmat).
Kestävyys
Huolimatta alempien tasojen ongelmista (esimerkiksi järjestelmän sähkökatkos tai laitteistohäiriöt), onnistuneesti suoritetun tapahtuman tekemien muutosten tulisi pysyä tallennettuina järjestelmän palattua työhön. Toisin sanoen, jos käyttäjä sai järjestelmästä vahvistuksen, että tapahtuma on suoritettu, hän voi olla varma, että hänen tekemänsä muutokset eivät peruunnu jonkinlaisen vian vuoksi.
Muistiinpanot
- ↑ Jim Grey. Tapahtumakonsepti: Hyveet ja rajoitukset . - 1981. - kesäkuuta. Arkistoitu alkuperäisestä 4.7.2020.
Kirjallisuus
- P. A. Bernstein, N. Goodman, V. Hadzilacos. Samanaikaisuuden valvonta ja palautus tietokantajärjestelmissä. - Addison-Wesley, 1986.
| Käsitteet |
|
|---|---|
| Objektit |
|
| Avaimet | |
| SQL | |
| Komponentit | |
