Grafiekdatabases voor Beginners: ACID vs. BASE Explained
wanneer het gaat om NoSQL-databases, kunnen gegevensconsistentiemodellen soms opvallend anders zijn dan die gebruikt worden door relationele databases (evenals heel anders dan andere NoSQL-stores).
De twee meest voorkomende consistentiemodellen zijn bekend onder de acroniemen zuur en BASE. Hoewel ze vaak tegenover elkaar staan in een strijd om de ultieme overwinning (maak daar alsjeblieft een video van), hebben beide consistentiemodellen voordelen – en nadelen – en geen van beide is altijd een perfecte pasvorm.
laten we eens een kijkje nemen op de trade-offs van beide database consistentiemodellen.
in deze Graph Databases voor Beginners blog serie, zal ik je door de basisprincipes van graph technologie nemen, ervan uitgaande dat je weinig (of geen) achtergrond in de ruimte hebt. In de afgelopen weken hebben we aangepakt waarom grafiektechnologie de toekomst is, waarom connected data belangrijk is, de basis (en valkuilen) van datamodellering, waarom een database query taal belangrijk is, de verschillen tussen imperatieve en declaratieve query talen, voorspellende modellering met behulp van graftheorie, de basisprincipes van grafiekzoekalgoritmen en waarom we NoSQL databases nodig hebben.
Deze week zullen we de belangrijkste verschillen tussen consistentiemodellen voor zuur-en BASE-databases nader bekijken en wat hun trade-offs betekenen voor uw gegevenstransacties.
het Acid consistence Model
veel ontwikkelaars zijn vertrouwd met ACID transacties door het werken met relationele databases. Als zodanig is het zuurconsistentiemodel al enige tijd de norm.
De belangrijkste ZUURGARANTIE is dat het een veilige omgeving biedt waarin uw gegevens kunnen worden gebruikt. Het acroniem ACID staat voor:
Atomic
- alle operaties in een transactie slagen of elke operatie wordt teruggedraaid.
Consistent
- na voltooiing van een transactie is de database structureel gezond.
geïsoleerde
- transacties kampen niet met elkaar. Contentieuze toegang tot gegevens wordt gemodereerd door de database, zodat transacties sequentieel lijken te lopen.
duurzaam
- de resultaten van de toepassing van een transactie zijn permanent, zelfs bij storingen.
ZUUREIGENSCHAPPEN betekenen dat zodra een transactie voltooid is, de gegevens consistent zijn (tech lingo: schrijfconsistentie) en stabiel zijn op de schijf, wat meerdere verschillende geheugenlocaties kan omvatten.
schrijfconsistentie is een prachtig ding voor applicatieontwikkelaars, maar het vereist ook geavanceerde vergrendeling, wat meestal een zwaargewicht patroon is voor de meeste use cases.
als het gaat om NoSQL-technologieën, gebruiken de meeste grafiekdatabases(inclusief Neo4j) een ZUURCONSISTENTIEMODEL om ervoor te zorgen dat gegevens veilig en consistent worden opgeslagen.
het BASISCONSISTENTIEMODEL
voor veel domeinen en use cases zijn ZUURTRANSACTIES veel pessimistischer (d.w.z. Ze maken zich meer zorgen over gegevensveiligheid) dan het domein eigenlijk vereist.
in de NoSQL-databasewereld zijn ACID-transacties minder modieus omdat sommige databases de vereisten voor onmiddellijke consistentie, versheid en nauwkeurigheid hebben versoepeld om andere voordelen te behalen, zoals schaalbaarheid en veerkracht.
(Met name de op. NET gebaseerde RavenDB heeft de trend onder geaggregeerde winkels in het ondersteunen van zuur transacties tegengewerkt.)
hier is hoe het basis acroniem afbreekt:
Basic Availability
- de database lijkt meestal te werken.
Soft-state
- Stores hoeven niet schrijfconsistent te zijn, noch moeten verschillende replica ‘ s altijd wederzijds consistent zijn.
uiteindelijke consistentie
- opslagplaatsen vertonen consistentie op een later moment (bijvoorbeeld lui tijdens het lezen).
basiseigenschappen zijn veel losser dan ZUURGARANTIES, maar er is geen directe één-voor-één mapping tussen de twee consistentiemodellen (een punt dat waarschijnlijk niet kan worden overschat).
Een BASE data store waarden beschikbaarheid (omdat dat belangrijk is voor schaal), maar het biedt geen gegarandeerde consistentie van gerepliceerde data op schrijftijd. Over het algemeen biedt het basisconsistentiemodel een minder strikte zekerheid dan zuur: gegevens zullen in de toekomst consistent zijn, hetzij op leestijd (bijv. Riak) of het zal altijd consistent zijn, maar alleen voor bepaalde verwerkte momentopnamen uit het verleden (bijv. Datomic).
Het basisconsistentiemodel wordt voornamelijk gebruikt door geaggregeerde opslagplaatsen, inclusief kolomfamilie, sleutelwaarde en documentopslag.
navigeren met zuur vs. Base Trade-offs
er is geen juist antwoord op de vraag of uw applicatie een zuur versus BASE consistentiemodel nodig heeft. Ontwikkelaars en data architects moeten hun data consistentie trade-offs selecteren op een case-by-case basis – niet alleen gebaseerd op wat is trending of welk model eerder werd gebruikt.
gezien de losse consistentie van BASE, moeten ontwikkelaars beter geïnformeerd en rigoureus zijn over consistente data als ze een BASE-winkel kiezen voor hun toepassing. Het is essentieel om vertrouwd te zijn met het basisgedrag van uw gekozen aggregaat winkel en werken binnen deze beperkingen.aan de andere kant kan planning rond BASISBEPERKINGEN soms een groot nadeel zijn in vergelijking met de eenvoud van ZUURTRANSACTIES. Een volledig zure database is de perfecte pasvorm voor use cases waar betrouwbaarheid en consistentie van gegevens essentieel zijn (bankieren, iedereen?).in de komende weken zullen we dieper ingaan op meer zuur/BASE-details als het gaat om aggregaatopslag en andere grafiektechnologieën.
Haal uw exemplaar van het O ‘ Reilly Graph Databases book op en begin grafische technologie te gebruiken om echte problemen op te lossen.
haal het Boek op
haal de rest van de Graph Databases voor Beginnersreeks in:
- waarom Grafiektechnologie de toekomst is
- waarom Connected Data Matters
- de basisprincipes van Data Modeling
- valkuilen van Data Modeling om
- te vermijden waarom een Database Query taal belangrijk is (meer dan je denkt)
- imperatief vs. declaratieve Query talen: Wat is het verschil?
- Grafiektheorie & Predictive Modeling
- Graph Search Algorithm Basics
- waarom we NoSQL Databases
- een Tour van geaggregeerde Stores
- andere Grafiektechnologieën
- Native vs. Non-Native Graph Technology