Figure IV · Regions, splits, and RegionServers

HBase regions, on a row line.

HBase keeps rows sorted by key and chops the keyspace into contiguous regions. Each region lives on exactly one RegionServer at a time. That single fact is what makes HBase consistent — and what limits how it scales.

Why this matters

The database that powers things you'd never guess use a database

HBase is the open-source rebuild of Google's Bigtable paper, and Bigtable is the table behind much of Google itself. Where you find HBase or Bigtable, you find a sparse, sorted, infinite key-value table:

Facebook Messages — chat history rode on HBase for years
The Wayback Machine — older snapshots of every webpage are stored region-by-region
Google Search — the inverted index lives in Bigtable
Gmail — every message, every label, every search index, in one giant Bigtable
Spotify Cassandra → Bigtable migration — same workload, different cell of the CAP triangle

The pattern: billions of rows, billions of columns, mostly empty cells, random reads and writes by row key, and the need for strong per-row consistency. If Cassandra is for "always available", HBase is for "always right".

A region owns a contiguous range of row keys, like [d, j). When a region grows past a threshold, it splits in half — two new regions, each owning half the original keyspace. The cluster has a small set of RegionServers, and the master assigns each region to exactly one. If a RegionServer dies, its regions are reassigned to other RegionServers.

Add rows below to fill regions. Hit Split to force a split on the largest region. Kill a RegionServer to watch its regions migrate. Notice that the row line — the keyspace — never changes; only the partitioning of it does.

Figure IV.1 A keyspace partitioned into regions, mapped to RegionServers

Add a row

Action

Region splits

Kill RegionServer

Read this: each colored bar above the line is a region — a contiguous slice of the row keyspace, owning rows between the two letters that bound it. Each region drops a line down to the one RegionServer that owns it. A RegionServer can own many regions; a region is owned by exactly one RegionServer.

Rows 0

Regions 1

Live RegionServers 3

Last put landed in —

§ IV.1What just happened

Rows are sorted by key, always

Every row in HBase has a row key, and the keyspace is sorted lexicographically. “apple” comes before “banana”, no matter when they were inserted. This sortedness is what lets a region own a clean range; it’s also why monotonically-increasing row keys (think: timestamp_…) are a hot-spot risk — every new write goes to the same trailing region.

One region → one RegionServer

This is the rule that makes HBase simple. A region is owned by exactly one RegionServer at any moment — so all reads and writes for that range of rows go through a single machine, and they can be ordered, locked, and made consistent without coordination. A region cannot live on two RegionServers at once; if one dies, the master reassigns its regions before letting reads or writes through.

Single-row transactions only

Because a region is owned by one RegionServer and a row lives entirely in one region, HBase can offer ACID semantics across the columns of a single row. It cannot offer them across rows — even rows that happen to share a region — because users can trigger a split at any moment.

Storage rides on HDFS

The actual HFiles for each region sit in HDFS. So HBase inherits HDFS replication for free: the "region on one RegionServer" rule is about serving, not about durability. If a RegionServer dies, the data is still on HDFS, and a different RegionServer can take over reading from it.

The cloud equivalent is Bigtable

Google’s Bigtable was the original; HBase is the open-source reimplementation. The same row-sorted, region-on-one-server design lives inside Cloud Bigtable, just with Colossus standing in for HDFS.

§ IV.2The rules to remember

row order        : lexicographic by row key
region           : contiguous slice of the keyspace
ownership        : one region → one RegionServer (at a time)
transactions     : single-row only
storage          : HFiles on HDFS (so RF comes from HDFS)
cloud equivalent : Bigtable (Colossus instead of HDFS)

← previous figure: HDFS, by the byte · back to the atlas →