Relationele databases hanteren doorgaans strikte regels voor het invoeren, uitlezen en bijwerken van informatie. Ze werken volgens het acid-principe: atomicity, consistency, isolation en durability. Zulke databasesoftware zorgt ervoor dat bewerkingen op data niet in elkaars vaarwater zitten, dat alleen volledig afgeronde transacties worden doorgevoerd, dat data goed wordt opgeslagen en dat de database consistent wordt geüpdatet: deze moet altijd hetzelfde antwoord teruggeven.
Het acid-principe maakt relationele databases betrouwbaar, maar levert ook problemen op. Om het acid-principe te handhaven, kunnen entiteiten bijvoorbeeld exclusief door een opdracht worden geclaimd, zodat er niet tegelijkertijd meerdere bewerkingen op worden losgelaten. Dat locken levert echter wel schaalbaarheidsproblemen op. NoSQL-databases doen daarom vaak concessies op dit gebied. Eén of meer van de acid-eigenschappen worden dan geofferd voor betere prestaties.
De Cap-stelling
Het is een dilemma dat bekendstaat als de cap-stelling. Cap staat voor consistency, availability en partition tolerance. Consistency vereist dat een transactie overal wordt doorgevoerd, availability zegt dat een transactie altijd kan worden uitgevoerd, en met partition tolerance wordt bedoeld dat de database blijft doorwerken als de communicatie tussen servers wordt verstoord. Volgens de cap-stelling kan bij het ontwerp van de database maar met twee van deze eigenschappen goed rekening worden gehouden. Relationele databases scoren bijvoorbeeld slecht op het gebied van partition tolerance.
Veel NoSQL-databases doen op andere vlakken concessies. Zo is voor BigTable, MongoDB en HBase de beschikbaarheid het kind van de rekening. Cassandra en SimpleDB leveren weer in op het gebied van consistentie. Deze databases hanteren het principe van eventual consistency: uiteindelijk moeten databaserecords op alle locaties gelijk zijn, maar het kan tijdelijk zo zijn dat op één locatie afwijkende gegevens zijn opgeslagen.
Hoewel het gebrek aan consistentie een nadeel van veel NoSQL-databases is, maakt dat het wel makkelijker om vanuit verschillende locaties data te serveren, en daarmee horizontale schaalbaarheid te bieden. Er zijn overigens uitzonderingen: zo hebben Berkeley DB en het daarop gebaseerde Oracle NoSQL volledige acid-ondersteuning, maar deze zijn weer niet bedoeld om horizontaal te schalen.
/i/1363169968.png?f=fpa)
:strip_exif()/i/1317812597.gif?f=fpa)
/i/1245426289.png?f=fpa)
/i/1187250147.png?f=fpa)
/i/1313057134.png?f=fpa)
/i/1305060768.png?f=fpa)