Work out how many Bigtable nodes your QPS, row size and stored data need, and what the cluster costs per month.
Bigtable sizing is the maximum of three independent limits: request rate, bytes per second and stored data. Row size decides which one binds — at 1 KB the QPS figure rules, but at 10 KB the same request rate is throughput bound and needs several times more nodes. Bigtable degrades ungracefully when it is short a node, showing up as latency spikes rather than errors, and replication doubles or triples the whole bill rather than just the compute. Confirm node-hour and per-GB prices for your region in the Google Cloud pricing calculator.
Bigtable Capacity
nodes = max(QPS ÷ (QPS per node × target CPU), MB/s ÷ (MB/s per node × target CPU), TB ÷ per-node capacity), rounded up and multiplied by the cluster count.
nodes = max(QPS ÷ (QPS per node × target CPU), MB/s ÷ (MB/s per node × target CPU), TB ÷ per-node capacity), rounded up and multiplied by the cluster count. Bigtable sizing is the maximum of three independent limits: request rate, bytes per second and stored data. Row size decides which one binds — at 1 KB the QPS figure rules, but at 10 KB the same request rate is throughput bound and needs several times more nodes.
Bigtable degrades ungracefully when it is short a node, showing up as latency spikes rather than errors, and replication doubles or triples the whole bill rather than just the compute. Confirm node-hour and per-GB prices for your region in the Google Cloud pricing calculator.
This calculator takes 13 inputs: Peak read QPS, Peak write QPS, Average row size, Data stored, Storage type, QPS per node at 1 KB rows, Throughput per node, Target CPU utilisation, Price per node-hour, Hours in the billing month, SSD storage price per GB, HDD storage price per GB, Clusters in the instance. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Because a replicated instance must be able to absorb the traffic of a failed cluster. Sizing each cluster to about 35% CPU leaves enough headroom for one cluster to take the whole load during a failover.