Adatgazdák, helyi tranzakció és konzisztenciamodellek
Célok
A lecke végére el tudod magyarázni, mit garantál egy helyi tranzakció, miért nem terjeszthető ki automatikusan több adatgazdára, miben különbözik az erős és a végső konzisztencia, és mit mond a CAP-tétel.
Miért kell?
A monolitban a készlet ellenőrzése és a rendelés mentése egy tranzakcióban történhet. Amint az adatok külön gazdához kerülnek (1.3, 3.3), ez a kényelem megszűnik. Az elosztott adatkezelés minden további minta kiindulópontja.
Helyi tranzakció és ACID
Az adatbázis tranzakciója műveletek olyan csoportja, amelyet az adatbázis egységként kezel. A klasszikus garanciák az ACID (Atomicity, Consistency, Isolation, Durability): atomicitás (vagy mind megtörténik, vagy semmi), konzisztencia (az adatbázis szabályai nem sérülnek), izoláció (a párhuzamos tranzakciók nem látják egymás félkész állapotát), tartósság (a sikeres eredmény megmarad). Ez helyi tranzakció: egy adatbázis határán belül érvényes. Az „ACID adatbázist használnak” állítás ezért az egyes adatbázisok helyi tranzakcióira vonatkozik, nem terjed ki a másik szolgáltatás commitjára vagy egy külső API hívására.
Adatgazda és adatmásolat
A microservices.io „database per service” mintája szerint a szolgáltatás tartós adata privát, és csak a szolgáltatás API-ján át érhető el. Ennek megvalósítása lehet saját tábla, saját séma vagy saját adatbázisszerver; a lényeg a tulajdonosi határ. A közös gép működési függés, a közös tábla módosítása adatmodellbeli csatolás — a kettő külön probléma.
A mintának ára van: a több szolgáltatást érintő üzleti tranzakciók nehezen valósíthatók meg, a több adatbázist összekapcsoló lekérdezések nehezek, és több adatbázist kell üzemeltetni.
A fogyasztó tárolhat helyi másolatot olvasásra, de tudni kell, honnan frissül és mennyit késhet. A másolat nem kapja meg az eredeti módosításának jogát. Egy üzleti dokumentum gyakran történeti tényt őriz (például az árat a vásárlás pillanatában); a kérdés, hogy a másolat aktuális állapotot vagy adott időpontban érvényes tényt jelent-e.
Erős és végső konzisztencia
Az erős konzisztencia többféle modellt takarhat; a követelményben meg kell mondani, milyen olvasási és sorrendi garanciát várnak (például: sikeres írás után az olvasás már az új állapotot lássa).
A végső konzisztencia (eventual consistency) azt jelenti, hogy ha nem érkezik új írás, minden olvasás végül a legfrissebb értéket adja. A Wikipedia leírása szerint ez gyenge garancia: csak azt mondja ki, hogy az eredmény „idővel” egységes lesz, a köztes értékek visszaadhatók. Nem jelent korlátlan, követhetetlen késést, és nem oldja meg magától az ellentmondásokat. Felhasználói oldalról fontos lehet, hogy a saját most végrehajtott módosítása ne tűnjön el egy késő olvasási nézetben (ezt a gyakorlat „read-your-writes” garanciának nevezi; ennek külön forrását nem vizsgáltuk).
A döntésnek az üzleti jelentésből kell következnie: egy keresési találatban a „van készlet” állítás késő lehet, de a tényleges foglalásról a készlet gazdája dönt, atomi módon.
A CAP-tétel
A CAP a Consistency, Availability, Partition tolerance (konzisztencia, rendelkezésre állás, partíciótűrés) rövidítése. Eric Brewer sejtését (2000) Seth Gilbert és Nancy Lynch bizonyította (2002). A tétel szerint hálózati szétválás (partition) esetén egy elosztott rendszernek választania kell: vagy megszakítja a műveletet (a konzisztenciát választva), vagy folytatja (a rendelkezésre állást választva, az inkonzisztencia kockázatával); szétválás nélkül mindkettő teljesülhet. A „három közül kettő” megfogalmazás félrevezető lehet, ahogy maga Brewer is jelezte 2012-ben. A PACELC kiterjesztés (Partition – Availability or Consistency, Else – Latency or Consistency) szerint szétválás nélkül is van kompromisszum a késleltetés és a konzisztencia között.
A gyakorlatban nem a szlogent, hanem a konkrét műveletet kell eldönteni: elfogadható-e módosítás bizonytalan kapcsolat mellett, és hogyan rendeződik az állapot utána.
flowchart LR
P["Hálózati szétválás"] --> C["Művelet megszakítása<br/>(konzisztencia)"]
P --> A["Művelet folytatása<br/>(rendelkezésre állás,<br/>inkonzisztencia kockázata)"]
Gyakori tévhitek
| Állítás |
Pontosítás |
| „Ha ACID adatbázist használ a rendszer, akkor atomi.” |
Csak a helyi tranzakció az; szolgáltatások között nem. |
| „A közös adatbázisszerver = közös adatgazda.” |
A szerver működési függés, az adatgazda felelősségi kérdés. |
| „A CAP szerint mindig kettőt kell választani háromból.” |
Szétválás esetén kell választani; különben mindkettő teljesülhet. |
| „A végső konzisztencia azt jelenti, hogy tetszőleges ideig eltérhet.” |
Gyenge garancia, de a késést a követelmények korlátozzák. |
Röviden
- A helyi tranzakció egy adatbázison belül ad ACID-garanciát.
- Több adatgazdánál nincs automatikus közös tranzakció.
- Az erős konzisztenciát konkrét garanciaként kell megadni; a végső konzisztencia gyenge, idővel egységesedő garancia.
- A CAP szétválás esetén a konzisztencia és a rendelkezésre állás közti választásról szól.
Ellenőrző kérdések
- Miért nem terjed ki az ACID a másik szolgáltatás adatbázisára?
- Melyik adat lehet késő egy termékoldalon, és melyik döntés nem támaszkodhat rá?
- Hogyan fogalmaznád meg egy konkrét művelet CAP-szerinti választását?
Források
Adatgazdák, helyi tranzakció és konzisztenciamodellek
Célok
A lecke végére el tudod magyarázni, mit garantál egy helyi tranzakció, miért nem terjeszthető ki automatikusan több adatgazdára, miben különbözik az erős és a végső konzisztencia, és mit mond a CAP-tétel.
Miért kell?
A monolitban a készlet ellenőrzése és a rendelés mentése egy tranzakcióban történhet. Amint az adatok külön gazdához kerülnek (1.3, 3.3), ez a kényelem megszűnik. Az elosztott adatkezelés minden további minta kiindulópontja.
Helyi tranzakció és ACID
Az adatbázis tranzakciója műveletek olyan csoportja, amelyet az adatbázis egységként kezel. A klasszikus garanciák az ACID (Atomicity, Consistency, Isolation, Durability): atomicitás (vagy mind megtörténik, vagy semmi), konzisztencia (az adatbázis szabályai nem sérülnek), izoláció (a párhuzamos tranzakciók nem látják egymás félkész állapotát), tartósság (a sikeres eredmény megmarad). Ez helyi tranzakció: egy adatbázis határán belül érvényes. Az „ACID adatbázist használnak” állítás ezért az egyes adatbázisok helyi tranzakcióira vonatkozik, nem terjed ki a másik szolgáltatás commitjára vagy egy külső API hívására.
Adatgazda és adatmásolat
A microservices.io „database per service” mintája szerint a szolgáltatás tartós adata privát, és csak a szolgáltatás API-ján át érhető el. Ennek megvalósítása lehet saját tábla, saját séma vagy saját adatbázisszerver; a lényeg a tulajdonosi határ. A közös gép működési függés, a közös tábla módosítása adatmodellbeli csatolás — a kettő külön probléma.
A mintának ára van: a több szolgáltatást érintő üzleti tranzakciók nehezen valósíthatók meg, a több adatbázist összekapcsoló lekérdezések nehezek, és több adatbázist kell üzemeltetni.
A fogyasztó tárolhat helyi másolatot olvasásra, de tudni kell, honnan frissül és mennyit késhet. A másolat nem kapja meg az eredeti módosításának jogát. Egy üzleti dokumentum gyakran történeti tényt őriz (például az árat a vásárlás pillanatában); a kérdés, hogy a másolat aktuális állapotot vagy adott időpontban érvényes tényt jelent-e.
Erős és végső konzisztencia
Az erős konzisztencia többféle modellt takarhat; a követelményben meg kell mondani, milyen olvasási és sorrendi garanciát várnak (például: sikeres írás után az olvasás már az új állapotot lássa).
A végső konzisztencia (eventual consistency) azt jelenti, hogy ha nem érkezik új írás, minden olvasás végül a legfrissebb értéket adja. A Wikipedia leírása szerint ez gyenge garancia: csak azt mondja ki, hogy az eredmény „idővel” egységes lesz, a köztes értékek visszaadhatók. Nem jelent korlátlan, követhetetlen késést, és nem oldja meg magától az ellentmondásokat. Felhasználói oldalról fontos lehet, hogy a saját most végrehajtott módosítása ne tűnjön el egy késő olvasási nézetben (ezt a gyakorlat „read-your-writes” garanciának nevezi; ennek külön forrását nem vizsgáltuk).
A döntésnek az üzleti jelentésből kell következnie: egy keresési találatban a „van készlet” állítás késő lehet, de a tényleges foglalásról a készlet gazdája dönt, atomi módon.
A CAP-tétel
A CAP a Consistency, Availability, Partition tolerance (konzisztencia, rendelkezésre állás, partíciótűrés) rövidítése. Eric Brewer sejtését (2000) Seth Gilbert és Nancy Lynch bizonyította (2002). A tétel szerint hálózati szétválás (partition) esetén egy elosztott rendszernek választania kell: vagy megszakítja a műveletet (a konzisztenciát választva), vagy folytatja (a rendelkezésre állást választva, az inkonzisztencia kockázatával); szétválás nélkül mindkettő teljesülhet. A „három közül kettő” megfogalmazás félrevezető lehet, ahogy maga Brewer is jelezte 2012-ben. A PACELC kiterjesztés (Partition – Availability or Consistency, Else – Latency or Consistency) szerint szétválás nélkül is van kompromisszum a késleltetés és a konzisztencia között.
A gyakorlatban nem a szlogent, hanem a konkrét műveletet kell eldönteni: elfogadható-e módosítás bizonytalan kapcsolat mellett, és hogyan rendeződik az állapot utána.
Gyakori tévhitek
Röviden
Ellenőrző kérdések
Források