Inhoudsopgave:
De consistentie -eigenschap van een database betekent dat Zodra gegevens met succes in een database zijn geschreven, hebben de volgende query's toegang tot de gegevens en krijgen ze een consistent beeld van de gegevens. In de praktijk betekent dit dat als u een record naar een database schrijft en onmiddellijk die record aanvraagt, u dit zeker kunt zien. Het is vooral handig voor zaken als Amazon-bestellingen en bankoverschrijvingen.
Consistentie is echter een glijdende schaal en een onderwerp dat te diep is om hier te behandelen. In de NoSQL-wereld valt consistentie meestal in een van de twee kampen:
-
ACID Consistency (ACID staat voor Atomicity, Consistency, Isolation, Durability): ACID betekent dat zodra gegevens zijn geschreven, u volledige consistentie hebt in leest.
-
Eventuele consistentie (BASE): BASE betekent dat zodra gegevens zijn geschreven, deze uiteindelijk voor lezen zullen verschijnen.
Er is een strijd gaande tussen mensen die menen dat een sterke consistentie in een database niet vereist is en dat degenen die dit absoluut moeten doen, verplicht zijn (naar mensen van NoSQL naar mensen naar 'marketingafdelingen! ).
De realiteit zit ergens tussenin. Maakt het uit dat iemands Facebook-bericht vijf minuten lang niet door al zijn vrienden wordt gezien? Nee, waarschijnlijk niet. Verander "Facebook bericht" in "miljard-dollar-financiële transactie", en je houding verandert snel! Welke consistentiebenadering u kiest, hangt af van de situatie. In mijn ervaring is sterke consistentie echter altijd de keuze in bedrijfskritieke situaties van bedrijfssystemen.
ACID
ACID is een algemene set principes voor transactionele systemen, niet iets dat puur aan relationele systemen is gekoppeld, of zelfs maar aan databases, dus het is de moeite waard om te weten. ACID betekent in feite: " Deze database heeft voorzieningen om te voorkomen dat u corrumpeert of gegevens verliest ", wat niet geldt voor alle databases. Het overgrote deel van de NoSQL-databases biedt zelfs geen ACID-garantie.
Foundation DB, MarkLogic en Neo4j zijn opmerkelijke uitzonderingen. Sommige NoSQL-databases bieden een lagere garantie, Checken en instellen , die verifieert of iemand anders een document heeft gewijzigd voordat een transactie kan worden voltooid. Dit gedrag is meestal beperkt omdat het meestal wordt geïmplementeerd op basis van één record.
MongoDB is een opmerkelijke database die Check- en Set-mogelijkheden biedt. Met MongoDB kan een volledige knooppuntwaarde van gegevens worden vergrendeld tijdens een update, waardoor alle leesbewerkingen en alle schrijfbewerkingen worden voorkomen totdat de bewerking is voltooid.Het bedrijf werkt echter aan het verwijderen van deze beperking.
BASE
BASE betekent dat in plaats van ACID-garanties te maken, de database een afstembare balans tussen consistentie en beschikbaarheid van gegevens heeft. Dit is meestal het geval wanneer knooppunten in een gegeven databasecluster fungeren als primaire beheerders van een deel van de database en andere knooppunten read-only replica's bevatten.
Om ervoor te zorgen dat elke client alle updates ziet (dat wil zeggen, ze hebben een consistente weergave van de gegevens), moet een schrijven naar het primaire knooppunt dat de gegevens bevat, worden vergrendeld totdat alle leesreplica's up-to-date zijn. Dit wordt een twee - fase commit genoemd - de wijziging wordt lokaal aangebracht, maar alleen toegepast en bevestigd aan de client wanneer alle andere knooppunten worden bijgewerkt.
BASE versoepelt deze vereiste, waardoor alleen een subset van de knooppunten met dezelfde gegevens moet worden bijgewerkt om de transactie te laten slagen. Enige tijd nadat de transactie is vastgelegd, wordt de alleen-lezen replica bijgewerkt.
Het voordeel van deze aanpak is dat transacties sneller worden vastgelegd. Het hebben van leesbare live replica's betekent ook dat u uw dataleeslading kunt spreiden, waardoor u sneller kunt lezen.
Het nadeel is dat clients die verbinding maken met sommige van de leesreplica's, mogelijk gedurende een onbepaalde tijd verouderde informatie zien. In sommige scenario's is deze toestand prima. Als je een nieuw bericht plaatst op Facebook en sommige van je vrienden het een paar minuten niet zien, is dat geen groot verlies. Als u echter een betalingsopdracht naar uw bank verzendt, wilt u misschien meteen een transactie.
Een alternatieve benadering voor read-only replica's is het hebben van een gedeelde - niets cluster waarin slechts één knooppunt in een cluster altijd een bepaald deel van de database serveert.
Gedeeld-niets betekent nog niet dat u de replicatie kwijtraakt. Databases die deze methode gebruiken, repliceren hun gegevens doorgaans naar een secundair gebied op een ander primair knooppunt of knooppunten - maar slechts één knooppunt is de master voor het lezen en schrijven op elk gewenst moment.
Shared-nothing-clusters hebben het voordeel van een eenvoudiger consistentiemodel, maar vereisen een COMMIT in tweefasen voor replica's. Dit feit betekent dat de transactie wordt vergrendeld terwijl alle replica's worden bijgewerkt. (Een intern slot plus vergrendeling voor andere knooppunten geeft u twee fasen.)
Dit heeft doorgaans minder impact dan gedeelde gegevensclusters met alleen-lezen replica's, omdat gedeelde nihiet gerepliceerde gegevensgebieden geen leesverzoeken voor die delen ontvangen deel van de database. Daarom zijn tweefasige commits sneller op een shared-nothing cluster dan op een cluster met leesbare replica's.
Kiezen voor ACID of BASE?
Zoals je zou verwachten, is veel van het argument dat NoSQL-leveranciers zich kunnen onderscheiden van hun concurrenten door een andere, unieke aanpak te claimen. Het is echter interessant om het aantal NoSQL-leveranciers met ACID-compliance op hun routekaart te vermelden.
Sommige NoSQL-databases hebben ACID-conformiteit op hun routekaart, ook al zijn ze voorstanders van BASE, wat aantoont hoe relevant ACID-garanties zijn voor enterprise, mission - kritieke systemen.
Veel bedrijven gebruiken BASE-consistentieproducten bij het testen van ideeën, omdat ze gratis zijn, maar vervolgens migreren naar een ACID-compatibele betaalde database wanneer ze live willen gaan op een bedrijfskritisch systeem.
De eenvoudigste manier om te bepalen of u ACID nodig hebt, is door rekening te houden met de interacties die mensen en andere systemen hebben met uw gegevens. Als u bijvoorbeeld gegevens toevoegt of bijwerkt, is het dan belangrijk dat de volgende query de wijziging kan zien? Met andere woorden, hangen belangrijke beslissingen af van de huidige staat van de database? Zou het zien van enigszins verouderde gegevens betekenen dat die beslissingen fataal tekort kunnen schieten?
In financiële dienstverlening is de behoefte aan consistentie duidelijk. Denk aan handelaren die aandelen kopen. Ze moeten het kassaldo controleren voordat ze handelen, om er zeker van te zijn dat ze het geld hebben om de handel te dekken. Als ze het juiste saldo niet zien, zullen ze besluiten om geld uit te geven aan een andere transactie. Als de database die wordt opgevraagd pas uiteindelijk consistent is, wordt het gebrek aan voldoende geld mogelijk niet zichtbaar, waardoor hun organisatie wordt blootgesteld aan financieel risico.
Vergelijkbare gevallen kunnen worden gebouwd voor ACID over BASE in de gezondheidszorg, defensie, inlichtingendiensten en andere sectoren. Het komt echter allemaal neer op de gegevens en het belang van zowel tijdigheid als gegevensbeveiliging.
