HBase and NoSQL Basics
This domain tests the HBase data model, architecture, read/write path, and row-key design, plus the NoSQL family classifications. You must be able to choose HBase for random access rather than analytical scans.
Data model and architecture
- HBase is a sparse, distributed, sorted map: table → row key → column family → qualifier → versioned cell. Rows are sorted lexicographically by row key.
- HMaster manages metadata and regions; RegionServers host regions; ZooKeeper coordinates and holds bootstrap information; data files live on HDFS.
- Writes go to the write-ahead log and MemStore, then flush to HFiles. Minor and major compactions merge files and remove deleted data.
- NoSQL types: key-value, column-family (HBase, Cassandra), document (MongoDB), and graph (Neo4j). CAP trade-offs explain availability versus consistency choices.
Worked example
A message table uses row key = reversed(senderID) + reversed(timestamp). Reversing the sender ID spreads sequential IDs across regions, avoiding a write hotspot; reversing the timestamp puts the newest messages first for a prefix scan. A get by full row key is fast; a scan needs a start/stop row or prefix, otherwise it reads the whole table.
Traps
- Row keys cannot be edited in place; changing one means delete plus reinsert. Design them up front.
- Column families are declared at table creation and should stay few; qualifiers can be added dynamically.
- HBase does not natively do joins or multi-row transactions like a relational database; SQL layers such as Phoenix or Spark are add-ons.