Chose the right database from CAP Theorem Lenses
Uttam Kumar
Solution Architect at Royal London | 3x AWS Certified | Banking | FinTech | Wholesale Lending | Virtual Banking | Corporate Billing | Mortgages | Telecomm | Automotive Engineering
Today, as I sought to identify the most suitable database for various use cases, I contemplated creating a table that provides comprehensive information based on the CAP Theorem and is cloud-agnostic. The goal is to simplify decision-making. But before delving into that, let's first understand what the CAP Theorem is and how it facilitates the decision-making process for selecting databases:
The CAP Theorem outlines the trade-offs involved in designing distributed data stores, focusing on three key aspects:
Under normal conditions, a distributed data store can provide all three functionalities. However, the CAP theorem asserts that during a network failure, a choice must be made between consistency and availability. Partition tolerance is considered essential because network failures are inevitable in a distributed system.
The decision during a network failure involves a trade-off:
领英推荐
It's crucial to note that the definition of consistency in the CAP theorem is distinct from the consistency in ACID. In CAP, consistency means having the most up-to-date information, whereas in ACID, it refers to preventing the corruption of the database by any new transaction.
And here is the table which will help you to make the right choice while selecting a database:
I trust that this information will streamline your database selection process and guide you in making the optimal choice.
Learning Through Writing Evangelist | Making DevOps work for you
9 个月For anyone who doubts, there is a "Beating the CAP Theorem Checklist" ?? Here is why your idea will not work: ? you are assuming that software/network/hardware failures will not happen ? you pushed the actual problem to another layer of the system ? your solution is equivalent to an existing one that doesn't beat CAP ? you're actually building an AP system ? you're actually building a CP system ? you are not, in fact, designing a distributed system Specifically, your plan fails to account for: ? latency is a thing that exists ? high latency is indistinguishable from splits or unavailability ? network topology changes over time ? there might be more than 1 partition at the same time ? split nodes can vanish forever ? a split node cannot be differentiated from a crashed one by its peers ? clients are also part of the distributed system ? stable storage may become corrupt ? network failures will actually happen ? hardware failures will actually happen ? operator errors will actually happen ? deleted items will come back after synchronization with other nodes ? clocks drift across multiple parts of the system, forward and backwards in time Source with complete list here ? https://ferd.ca/beating-the-cap-theorem-checklist.html