Bigtable
Bigtable is Google's wide-column NoSQL database — data is organized by row key, with many sparse columns per row, optimized for very high throughput and low latency on massive datasets. It powers Google Search, Gmail, Google Maps, and Google Analytics internally, and is the system that inspired Apache HBase and Apache Cassandra.
Data Model
Each row has a row key — a byte string up to 4 KB that is the sole identifier for that row. Values within a row are grouped into column families. Rows are stored in sorted order by row key. Efficient reads are row-key lookups, prefix scans, or bounded range scans — filtering on arbitrary column values forces scanning far more data. Bigtable now speaks SQL (GoogleSQL for Bigtable) and offers continuous materialized views as its mechanism for secondary indexes, but neither changes the physics: performance still comes from designing around the row key.
Row Key Design
100% CPUnode 2
idlenode 3
idle
~33%node 2
~33%node 3
~33%
Row key design is the most critical decision in a Bigtable schema. Changing it later means rewriting every row — there is no relational-style schema migration for it. The key must both distribute writes evenly to avoid hot spots and keep data read together contiguous, which can be in tension. Sequential timestamps as a prefix cause all recent writes to hit the same tablet server. A pure hash prefix spreads writes but destroys range-scan locality, so use it only for point-lookup reads; combining a high-cardinality field (device or user ID) with a timestamp spreads load while keeping each entity's rows contiguous for scans.
Column Families
Bigtable performs best with a small number of column families — typically one to three. Many column families degrade performance. Many columns within a family is the correct pattern.
Monitoring and Hotspot Detection
A single hot tablet can saturate one node while the rest of the cluster sits idle, so cluster-average CPU is the wrong signal for capacity planning. Always monitor per-node CPU and keep the highest-loaded node below 70% under sustained load.
Key Visualizer renders a heatmap of read and write traffic across the row key range over time. It surfaces hot spots, large scans, and sudden access pattern shifts — issues that aggregate metrics hide. Open it any time latency rises or one node's CPU diverges from the rest.
If hot spots appear in Key Visualizer, adding nodes will not help — the load is concentrated, not spread. Fix the row key design first; scale capacity second.
Scaling
Adding nodes linearly increases throughput until key distribution becomes a bottleneck. A single Bigtable cluster handles millions of reads and writes per second. Cluster replication provides higher read throughput, lower read latency for distributed users, and high availability.
- Sequential timestamps as the primary row key prefix — creates write hot spots.
- Too many column families — degrades performance.
- Not monitoring per-node CPU distribution — total CPU can look healthy while key skew exists.
- Choosing Bigtable for workloads Firestore or Cloud SQL would serve adequately.
- Treating a single-cluster instance as highly available — single-cluster has no failover. Enable cluster replication for production HA.
- Design row keys for even write distribution before loading any data.
- Use one to three column families.
- Enable cluster replication for production workloads.
- Monitor per-node CPU, not just cluster-level averages.
- Set garbage collection policies on column families to control storage growth.
Knowledge Check
When is Bigtable the right choice over Firestore or Cloud SQL?
- When you need very high throughput with single-digit millisecond latency, and access is through row key lookups or range scans
- When the application needs SQL queries with complex joins across many normalized relational tables
- When the application needs real-time listeners that push live updates straight to connected mobile and web clients as data changes
- When the application needs strong-consistency ACID transactions across globally distributed regions
Where do efficient reads in Bigtable come from?
- SQL queries that filter on any column value perform equally well thanks to the query optimizer
- Secondary indexes that Bigtable maintains automatically on every column a query touches
- Row key lookups or contiguous range scans — filtering on other columns forces scanning far more data
- Through full table scans that Bigtable parallelizes and optimizes automatically behind the scenes on every read
Why do sequential timestamps as a row key prefix cause problems in Bigtable?
- Timestamps push the key past the 4 KB row key size limit when combined with other prefix fields
- Bigtable cannot sort rows that carry timestamp prefixes in the correct order
- All recent writes hit the same tablet server — concentrating load and creating a write hot spot
- Timestamps change frequently, forcing the row key to be updated and every affected row rewritten
What is the recommended number of column families in a Bigtable table?
- As many as your schema needs — column families carry no performance impact at all
- One column family per logical data category, which is typically around 10 to 20
- Typically one to three — many column families degrade performance
- Exactly one — multiple column families are not supported
What happens to throughput as you add nodes to a Bigtable cluster?
- Throughput is fixed — adding nodes only improves availability
- Throughput doubles with each node added regardless of key distribution
- Throughput increases linearly with added nodes, until key distribution becomes a bottleneck
- Throughput improves only for reads — write throughput is determined by primary key design alone
You got correct