ACID Transactions are a must when you have strict data consistency requirements in your application. The costs of running transactions on distributed systems can rapidly create bottlenecks at scale. By Denis Rosa, Developer Advocate, Couchbase.
ACID transactions in NewSQL databases require more coordination than in NoSQL, as the data related to an entity is split into multiple tables which might live in different nodes. The relational model, as we use today, requires transactions for the majority of the writes, updates, and cascading deletes. The extra coordination that the NewSQL architecture requires comes at a cost of reduced throughput for applications requiring low latency operations.
The content of this guide:
- Relational vs NewSQL vs NoSQL Transactions
- Atomicity in RDBMS
- Atomicity in NewSQL
- Atomicity in Document Databases
- Multi-Document Distributed ACID Transactions in Couchbase
- Couchbase Architecture Review
- Distributed Transactions without a Central Coordinator
- Handling Isolation – Monotonic Atomic View
- Repeatable Reads and Monotonic Atomic Views
- Durability in a Distributed Database
… and more. Couchbase has support for the Read Committed/Monotonic Atomic View consistency models. But how good is that? Well, Read Committed is the default choice in Postgres, MySQL, MariaDB and many other databases out there; if you never changed that option, that’s what you are using right now. Yuo will also get charts explaining the concepts together with links to further reading. Very good!
[Read More]