Graph adatbázisok kezdőknek: ACID vs. BASE magyarázata

amikor a NoSQL adatbázisokról van szó, az adatkonzisztencia modellek néha feltűnően különböznek a relációs adatbázisok által használtaktól (valamint egészen más, mint a többi NoSQL áruház).
a két leggyakoribb konzisztencia modell az ACID és a BASE rövidítésekkel ismert. Bár gyakran egymás ellen küzdenek a végső győzelemért folytatott csatában (kérjük, valaki készítsen erről videót), mindkét konzisztencia modell előnyökkel – és hátrányokkal – jár, és egyik sem mindig tökéletes illeszkedés.
vessünk egy közelebbi pillantást a kompromisszumok mindkét adatbázis konzisztencia modellek.

ebben a graph Databases for Beginners blog sorozatban végigvezetem a graph technológia alapjait, feltéve, hogy kevés (vagy nincs) háttér a térben. Az elmúlt hetekben foglalkoztunk azzal, hogy miért a gráftechnológia a jövő, miért számítanak az összekapcsolt adatok, az adatmodellezés alapjai (és buktatói), miért fontos az adatbázis-lekérdezési nyelv, az imperatív és deklaratív lekérdezési nyelvek közötti különbségek, a gráfelméletet használó prediktív modellezés, a gráfkeresési algoritmusok alapjai és miért van szükségünk NoSQL adatbázisokra.
ezen a héten közelebbről megvizsgáljuk az ACID és a BASE adatbázis-konzisztencia modellek közötti legfontosabb különbségeket, valamint azt, hogy ezek milyen kompromisszumokat jelentenek az adattranzakciókra.

A savas konzisztencia modell

sok fejlesztő ismeri az ACID tranzakciókat a relációs adatbázisokkal való együttműködésből. Mint ilyen, a savas konzisztencia modell egy ideje a norma.
a legfontosabb savas garancia az, hogy biztonságos környezetet biztosít az adatok működtetéséhez. Az ACID rövidítés jelentése:
Atomic

• a tranzakció minden művelete sikeres, vagy minden művelet visszahúzódik.

következetes

• a tranzakció befejezésekor az adatbázis szerkezetileg megfelelő.

az elszigetelt

• tranzakciók nem versenyeznek egymással. Az adatokhoz való vitatott hozzáférést az adatbázis moderálja, így úgy tűnik, hogy a tranzakciók egymás után futnak.

tartós

• a tranzakció alkalmazásának eredményei állandóak, még hibák jelenlétében is.

az ACID tulajdonságok azt jelentik, hogy a tranzakció befejezése után az adatok konzisztensek (tech lingo: írási konzisztencia) és stabilak a lemezen, ami több különálló memóriahelyet is magában foglalhat.
Az írási konzisztencia csodálatos dolog az alkalmazásfejlesztők számára, de kifinomult zárolást is igényel, amely általában nehézsúlyú minta a legtöbb felhasználási esetben.
amikor a NoSQL technológiákról van szó, a legtöbb gráf adatbázis(beleértve a Neo4j-t is) savas konzisztencia modellt használ, hogy biztosítsa az adatok biztonságát és következetes tárolását.

az ALAPKONZISZTENCIA modell

sok domain és felhasználási eset esetében az ACID tranzakciók sokkal pesszimistábbak (azaz jobban aggódnak az adatbiztonság miatt), mint amit a domain ténylegesen megkövetel.
a NoSQL adatbázis világában az ACID tranzakciók kevésbé divatosak, mivel egyes adatbázisok lazították az azonnali konzisztencia, az adatok frissessége és pontossága követelményeit, hogy más előnyöket szerezzenek, mint például a skála és a rugalmasság.
(nevezetesen, a. net-alapú RavenDB már bucked a trend között aggregált üzletek támogatása savas tranzakciók.)
itt van, hogy az alap betűszó lebontja:
alapvető elérhetőség

• az adatbázis úgy tűnik, hogy a munka a legtöbb időt.

Soft-state

• a tárolóknak nem kell íráskonzisztensnek lenniük, és a különböző másolatoknak sem kell állandóan kölcsönösen konzisztensnek lenniük.

az esetleges konzisztencia

• az üzletek valamilyen későbbi időpontban (pl.

az alaptulajdonságok sokkal lazábbak, mint az ACID garanciák, de a két konzisztencia modell között nincs közvetlen egy-egy leképezés (ezt a pontot valószínűleg nem lehet túlbecsülni).
az alap adattároló értékeli a rendelkezésre állást (mivel ez fontos a skála szempontjából), de nem garantálja a replikált adatok garantált konzisztenciáját írási időben. Összességében az ALAPKONZISZTENCIA modell kevésbé szigorú biztosítékot nyújt, mint az ACID: az adatok a jövőben konzisztensek lesznek, akár olvasási időben (pl. Riak), vagy mindig konzisztensek lesznek, de csak bizonyos feldolgozott múltbeli pillanatképeknél (pl.
az ALAPKONZISZTENCIA modellt elsősorban az aggregált áruházak használják, beleértve az oszlopcsaládot, a kulcsértéket és a dokumentumtárakat.

Navigálás ACID vs. Alap kompromisszumok

nincs helyes válasz arra, hogy az alkalmazásnak szüksége van-e ACID versus BASE konzisztencia modellre. A fejlesztőknek és az adatépítészeknek eseti alapon kell kiválasztaniuk adatkonzisztencia-kompromisszumaikat – nem csak a trend vagy a korábban használt modell alapján.
tekintettel a BASE laza konzisztenciájára, a fejlesztőknek tájékozottabbnak és szigorúbbnak kell lenniük a következetes adatokkal kapcsolatban, ha BÁZISTÁROLÓT választanak alkalmazásukhoz. Alapvető fontosságú, hogy ismerje a választott aggregátum-áruház alapvető viselkedését, és dolgozzon ezeken a korlátokon belül.
másrészt a BÁZISKORLÁTOZÁSOK körüli tervezés néha jelentős hátrányt jelenthet az ACID tranzakciók egyszerűségéhez képest. A teljesen savas adatbázis tökéletesen illeszkedik olyan felhasználási esetekhez, ahol az adatok megbízhatósága és következetessége elengedhetetlen (banki, bárki?).
az elkövetkező hetekben több ACID / BASE specifikációba merülünk, amikor az aggregált áruházakról és más graph technológiákról van szó.

felzárkózni a többi gráf adatbázisok kezdőknek sorozat:

• miért gráf technológia a jövő
• miért kapcsolódó adatok ügyek
• az alapok az adatmodellezés
• adatmodellezés buktatókat, hogy elkerüljék
• miért adatbázis lekérdezés nyelv számít (több, mint gondolnád)
• imperatív vs. deklaratív lekérdezés Nyelvek: mi a különbség?
• Gráfelmélet & prediktív modellezés
• Gráfkeresési algoritmus alapjai
• miért van szükségünk NoSQL adatbázisokra
• Az aggregált üzletek bejárása
• Egyéb Gráfadat-technológiák
• natív vs. Nem natív gráf technológia