0

Bigtable is listed as CP system below

NoSQL: What does it mean for MongoDB or BigTable to not always be "Available"

This means all read gets the latest write and the system functions during network partition, but how do you ensure all read gets the latest write if the network is partitioned?

Gourav B
  • 864
  • 5
  • 17
user16367669
  • 57
  • 1
  • 8
  • If my answer addressed your question, please consider accepting and up-voting it. If not, let me know so that I can improve my answer – Monali Ghotekar Feb 25 '22 at 09:58

2 Answers2

1

There are two different scenarios for this

  1. Single-cluster Bigtable instance
  2. Multi-cluster Bigtable instance

In (1) let's say you have 10 nodes in your cluster, each row will be assigned to one of those nodes (assume 1/10th on each for simplicity). This setup offers strong consistency but if one of the nodes dies, until another node picks up the rows it was managing, those 1/10th of the rows become unavailable. A new node spawns very quickly and takes ownership or the rows are redistributed across remaining nodes so this is hardly noticeable and there is no data loss since Bigtable writes to Google's Colossus distributed file system, not to attached disks on individual nodes.

In (2) there are multiple clusters which could be thousands of miles away and data is getting replicated between them. Bigtable supports multi-primary setups so they can all receive writes and replication is eventually consistent i.e. in this case Bigtable favors lower latency over consistency. In a failure case for this particular setup, with a multi-cluster routing policy, there will be automatic fail-over but it could be such that not all changes in cluster A made it to cluster B yet. However cluster B will remain available and continue serving data even though it is not consistent.

So trade-offs vary depending on the setup.

Bora
  • 66
  • 4
0
  • Bigtable treats each cluster in your instance as a primary cluster, so you can perform reads and writes in each cluster. You can also set up your instance so that requests from different types of applications are routed to different clusters.
  • By default, replication for Bigtable is eventually consistent. This term means that when you write a change to one cluster, you will eventually be able to read that change from the other clusters in the instance, but only after the change is replicated among the clusters. In a replicated cluster, there is not a guarantee of strong consistency, rather it is eventually consistent.
  • Below two posts Post 1 & Post 2 discuss in detail with regard to CAP theorem principles.
  • For more information you can refer to Doc for details.
Monali Ghotekar
  • 359
  • 1
  • 7