Database (1) - HBase Transactions

It started with a few PingCAP blog posts that introduced me to NewSQL. I then realized that I did not understand some OLTP techniques particularly well, so I decided to explore the subject through a technology stack I knew a little better. This is the first post in my database series :).

ACID

Database transactions are usually evaluated along the four ACID dimensions. Let’s briefly review what ACID means:

• A -> Atomicity: A transaction often includes multiple operations, which must either all succeed or all fail.
• C -> Consistency: The database must remain in a valid state. An invalid transaction should be rolled back promptly to preserve consistency.
• I -> Isolation: Reads and writes often occur simultaneously in real applications. How should they be isolated from each other?
• D -> Durability: Once a transaction succeeds, a database crash must not cause it to be lost.

HBase + ACID

With the ACID concepts in mind, HBase’s transaction properties are straightforward to describe.

• Atomicity: Only provided within a single Region, not across Regions or Tables.
• Consistency: There is no rollback strategy, so consistency cannot be achieved.
• Isolation: HBase uses an LSM structure and updates data through compaction, so to some extent existing data is not read and written simultaneously.
• Durability: Satisfies the durability requirement.

If HBase + ACID

HBase offers high performance and suits OLAP queries and computation. Traditional databases such as MySQL support transactions but cannot conveniently accommodate massive-scale storage and queries. If HBase fully supported ACID with reliable stability, I suspect many people would abandon their RDBMS. Looking purely at ACID, what does HBase still need to provide complete transactions?

Atomicity

Transactions across tables and nodes require a mechanism ensuring that transactions on all nodes succeed or fail together. A classic approach is 2PC (two-phase commit), which I discussed in an earlier Flink post. Each node’s commit is split into two steps: first pre-commit, then actually trigger the transaction once all nodes have completed pre-commit. This requires a manager that communicates with every node to keep their commit processes coordinated. Of course, it is not a cure-all: if things fail while the transaction is actually being triggered, there is little it can do. I have not yet seen a better algorithm or mechanism; perhaps I just have not read enough?

Consistency

The key is to roll back when inconsistency occurs. This means reading data before writing it. After reading a couple of database papers, I found that most databases do exactly this… The timeline for a write transaction therefore becomes:

Isolation

Durability

HBase can currently meet the requirements for these two aspects.