Bigtable

Bigtable is a wide-column store. Data is organised as rows identified by a single row key, with columns grouped into column families. It is designed for datasets measured in terabytes or petabytes, with consistently low latency for reads and writes at very high volume.

It offers no SQL, no joins and no multi-row transactions. Those omissions are the point: removing them is what allows predictable single-digit millisecond latency at enormous scale.

Certain workloads have a shape no general-purpose database serves well: enormous volume, very high write rates, simple access patterns and a strict latency requirement. Time series data, IoT telemetry, financial market data and large-scale personalisation all fit that description.

For these, Bigtable is frequently the only option that meets the requirement at acceptable cost. For anything else, it is usually the wrong choice, and exams test whether you recognise the difference.

Bigtable sorts rows lexicographically by row key and distributes contiguous ranges across servers. Every performance characteristic follows from that single fact.

• Sequential keys create hotspots. A key beginning with a timestamp sends all current writes to one server while the rest sit idle.
• Field promotion. Put a high-cardinality identifier first, then the timestamp — sensor123#20260907T1204 distributes writes across sensors while keeping each sensor's readings together.
• Salting. Prefixing a hash spreads writes evenly, at the cost of making range scans harder.
• Design for your read pattern. Rows you read together should sort together, because a range scan over adjacent rows is dramatically faster than many individual lookups.
• Reversed timestamps put the newest data first when you usually want the most recent readings.

• Instance and cluster — the provisioned capacity. Clusters in multiple zones or regions can serve the same data for availability.
• Node — a unit of serving capacity. Throughput scales roughly linearly with node count.
• Column family — a group of related columns configured together, including their retention policy.
• Cell — the value at a row, column and timestamp. Bigtable can retain multiple versions over time.
• Garbage collection policy — automatically expires old versions or old data, controlling storage growth.
• Application profile — controls routing between clusters and whether single-cluster or multi-cluster routing is used.

• Time series data from sensors, devices and infrastructure monitoring.
• Financial market data with very high ingest rates.
• User behaviour and personalisation data read at low latency during a request.
• Ad technology platforms requiring lookups within tight latency budgets.
• Graph-shaped and adjacency data at very large scale.

It is the wrong answer for transactional application data, anything needing joins or ad-hoc SQL, and anything small enough to fit comfortably in a relational database.