Column-Family Databases
Column-family databases store data in column groups rather than rows, optimizing for read-heavy analytical queries that access a few columns across many records. They suit workloads like time-series data, event logging, and wide-table patterns at scale.
itDatabases and data storage | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Column-Family Databases
A column-family database stores a very large amount of structured data when the important question is already known: which key do you have? It looks like a table, because databases enjoy familiar furniture, but it behaves more like a sparse map spread across many machines.
The useful picture is a row key, then a column family, then a qualifier, timestamp, and value. A family is a durable group such as profile, metric, or audit. A qualifier is the flexible field name inside that group. Rows can omit qualifiers they do not need, so an absent battery reading does not require a ceremonial empty cell.
This arrangement exists because fixed rectangular tables and broad joins are not the only way to organize data. Device measurements, web data, and time-series records often arrive in large volumes and are read through known keys. A row key can keep related data together for a bounded range read. It also influences where the work lands. That second job is where the furniture starts charging rent.
A key with a timestamp first can send fresh writes into one narrow ordered range. A key with too much hash can distribute those writes but scatter every read. A time bucket can bound growth but adds more buckets to visit. The correct key is the one that makes the important read direct while keeping traffic and growth distributed.
The category name is not a lifetime warranty for identical behavior. Bigtable and HBase use ordered row keys, families, qualifiers, and timestamped cells. Cassandra uses a partition key to choose a partition and clustering columns to order rows inside it. Its tables are built around planned queries, often with deliberate duplication. The shared vocabulary is helpful. It is not a substitute for checking consistency, transaction boundaries, and operations in the selected product.
Start with the Intro for the full map of rows, families, keys, distribution, and fit. Use Slides when you want the relationships in one glance. Keep the Cheatsheet nearby while reviewing a key or partition. The practice reference and exercise turn a device-measurement workload into a schema decision, which is where this subject stops being a vocabulary quiz and begins making requests go somewhere very specific.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://research.google/pubs/bigtable-a-distributed-storage-system-for-structured-data/
Supports
- Bigtable as a distributed storage system designed for very large structured datasets
- Original Bigtable data model and historical foundation
- Research-paper link rationale
- https://cloud.google.com/bigtable/docs/overview
Supports
- Sorted key-value map, rows, row keys, column families, qualifiers, and timestamped cells
- Sparse storage and multiple cell versions
- Bigtable service and tablet orientation
- Bigtable overview link rationale
- https://cloud.google.com/bigtable/docs/schema-design
Supports
- Query-driven schema and efficient key, prefix, and range reads
- Lexicographic row order, row-level atomicity, and lack of joins
- Column-family grouping and family-level garbage-collection policies
- Hotspot causes, timestamp-first key risk, row growth, and time-based keys
- Bigtable schema-design link rationale
- https://hbase.apache.org/
Supports
- HBase as an open-source distributed store modeled after Google Bigtable
- Bigtable-like capabilities on Hadoop and HDFS
- HBase project link rationale
- https://hbase.apache.org/docs/datamodel/
Supports
- HBase row keys, column families, qualifiers, cells, timestamps, and versions
- Column families as physical storage groups with shared properties
- Flexible qualifiers and sparse row view
- Get, Put, Scan, Delete, and separately documented ACID semantics
- HBase data-model link rationale
- https://cassandra.apache.org/doc/stable/cassandra/architecture/overview.html
Supports
- Cassandra as a distributed database with a partitioned wide-column model
- Bigtable and Dynamo design influences
- Cassandra keyspaces, tables, partitions, rows, and columns
- Multi-primary replication goals and key-oriented queries
- Cassandra architecture link rationale
- https://cassandra.apache.org/doc/latest/cassandra/developing/data-modeling/intro.html
Supports
- Query-driven Cassandra tables and denormalization
- Partition keys and clustering keys
- Lack of foreign keys and relational integrity
- Partition growth, redundancy, and consistency as analysis concerns
- Cassandra data-modeling link rationale
- https://hbase.apache.org/1.4/book.pdf
Supports
- HBase development began in late 2006
- HBase became a Hadoop subproject in 2008 and an Apache top-level project in 2010
- HBase timeline milestones
- https://engineering.fb.com/2010/11/15/core-infra/the-underlying-technology-of-messages/
Supports
- Cassandra was open-sourced in 2008 after serving Inbox Search traffic
- Cassandra open-source timeline milestone
- https://cloud.google.com/blog/products/gcp/cloud-bigtable-now-supports-hdd-storage-for-big-analytics-workloads-at-lower-cost
Supports
- Cloud Bigtable launched in 2015 as a managed service with an HBase-compatible API
- Cloud Bigtable launch timeline milestone
- https://cloud.google.com/blog/products/gcp/google-cloud-bigtable-is-generally-available-for-petabyte-scale-nosql-workloads
Supports
- Cloud Bigtable reached general availability in 2016
- Cloud Bigtable general-availability timeline milestone
- https://cloud.google.com/blog/products/databases/cloud-bigtable-regional-replication-now-generally-available
Supports
- Cloud Bigtable regional replication reached general availability in 2018
- Regional replication timeline milestone
- https://cloud.google.com/blog/products/databases/scale-globally-get-four-nines-availability-with-new-cloud-bigtable-capabilities
Supports
- Cloud Bigtable global replication reached general availability in 2019
- Global replication timeline milestone
- https://cassandra.apache.org/_/blog/Apache-Cassandra-4.0-is-Here.html
Supports
- Apache Cassandra 3.0 released in November 2015
- Apache Cassandra 4.0 released in July 2021
- Cassandra release timeline milestones
- https://cassandra.apache.org/_/blog/Apache-Cassandra-5.0-Announcement.html
Supports
- Apache Cassandra 5.0 reached general availability in September 2024
- Cassandra 5.0 timeline milestone
- https://www.datastax.com/blog/leveled-compaction-apache-cassandra
Supports
- Cassandra immutable SSTables and compaction tradeoffs
- Compaction field note
- https://docs.datastax.com/en/luna-cassandra/planning/data-model.html
Supports
- Large and imbalanced partitions create hotspots and compaction work
- Partition field note
- https://docs.scylladb.com/stable/get-started/data-modeling/
Supports
- ScyllaDB query-first data modeling
- ScyllaDB product landscape placement
- https://www.scylladb.com/product/scylla-drivers/
Supports
- ScyllaDB supports Cassandra CQL drivers and APIs
- ScyllaDB product landscape placement
- https://docs.aws.amazon.com/keyspaces/latest/devguide/how-it-works.html
Supports
- Amazon Keyspaces implements the CQL API and removes node management
- Amazon Keyspaces product landscape placement
