From 4c9644d31d640e0a09cc34c0ea5292a07b16ca96 Mon Sep 17 00:00:00 2001 From: Mahdi Azarboon <21277296+azarboon@users.noreply.github.com> Date: Thu, 13 Jun 2024 20:01:28 +0800 Subject: [PATCH 1/2] Update relational-vs-nosql-data.md --- docs/architecture/cloud-native/relational-vs-nosql-data.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/architecture/cloud-native/relational-vs-nosql-data.md b/docs/architecture/cloud-native/relational-vs-nosql-data.md index cd468a8d8c274..9daa9605216e8 100644 --- a/docs/architecture/cloud-native/relational-vs-nosql-data.md +++ b/docs/architecture/cloud-native/relational-vs-nosql-data.md @@ -42,12 +42,15 @@ The theorem states that distributed data systems will offer a trade-off between - *Consistency.* Every node in the cluster responds with the most recent data, even if the system must block the request until all replicas update. If you query a "consistent system" for an item that is currently updating, you'll wait for that response until all replicas successfully update. However, you'll receive the most current data. -- *Availability.* Every node returns an immediate response, even if that response isn't the most recent data. If you query an "available system" for an item that is updating, you'll get the best possible answer the service can provide at that moment. +- *Availability.* "Every request received by a non-failing node in the system must result in a response". Put it simply, if you query an "available system" for an item that is updating, you'll get the best possible answer the service can provide at that moment. But note that "availability" as defined by CAP theorem is technically different from "high availability" as it's conventionally known for distributed systems. - *Partition Tolerance.* Guarantees the system continues to operate even if a replicated data node fails or loses connectivity with other replicated data nodes. CAP theorem explains the tradeoffs associated with managing consistency and availability during a network partition; however tradeoffs with respect to consistency and performance also exist with the absence of a network partition. CAP theorem is often further extended to [PACELC](http://www.cs.umd.edu/~abadi/papers/abadi-pacelc.pdf) to explain the tradeoffs more comprehensively. +> [!NOTE] +> Even if you choose availability over consistency, in times of network partition, availability will suffer. CAP available system is more available to some of its clients but it's not necessarily "highly available" to all its clients. + Relational databases typically provide consistency and availability, but not partition tolerance. They're typically provisioned to a single server and scale vertically by adding more resources to the machine. Many relational database systems support built-in replication features where copies of the primary database can be made to other secondary server instances. Write operations are made to the primary instance and replicated to each of the secondaries. Upon a failure, the primary instance can fail over to a secondary to provide high availability. Secondaries can also be used to distribute read operations. While writes operations always go against the primary replica, read operations can be routed to any of the secondaries to reduce system load. From 73bccab386e702fcee5e508e1f28026c57b537c9 Mon Sep 17 00:00:00 2001 From: Mahdi Azarboon <21277296+azarboon@users.noreply.github.com> Date: Thu, 27 Jun 2024 07:10:17 +0800 Subject: [PATCH 2/2] Update docs/architecture/cloud-native/relational-vs-nosql-data.md Co-authored-by: David Pine --- docs/architecture/cloud-native/relational-vs-nosql-data.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/cloud-native/relational-vs-nosql-data.md b/docs/architecture/cloud-native/relational-vs-nosql-data.md index 9daa9605216e8..009bcd6d5dbaa 100644 --- a/docs/architecture/cloud-native/relational-vs-nosql-data.md +++ b/docs/architecture/cloud-native/relational-vs-nosql-data.md @@ -42,7 +42,7 @@ The theorem states that distributed data systems will offer a trade-off between - *Consistency.* Every node in the cluster responds with the most recent data, even if the system must block the request until all replicas update. If you query a "consistent system" for an item that is currently updating, you'll wait for that response until all replicas successfully update. However, you'll receive the most current data. -- *Availability.* "Every request received by a non-failing node in the system must result in a response". Put it simply, if you query an "available system" for an item that is updating, you'll get the best possible answer the service can provide at that moment. But note that "availability" as defined by CAP theorem is technically different from "high availability" as it's conventionally known for distributed systems. +- *Availability.* Every request received by a non-failing node in the system must result in a response. Put it simply, if you query an "available system" for an item that is updating, you'll get the best possible answer the service can provide at that moment. But note that "availability" as defined by CAP theorem is technically different from "high availability" as it's conventionally known for distributed systems. - *Partition Tolerance.* Guarantees the system continues to operate even if a replicated data node fails or loses connectivity with other replicated data nodes.