谈谈HBase中的Transaction

起初是由于看了PingCAP的几篇博客，而后知道了所谓的NewSQL。后来发现本身对于OLTP中的一些技术点并非特别了解，就决定从本身稍微熟悉一点的技术栈开始作一些探究。因此，这是数据库系列中的第一篇 :)。

ACID

评价一个数据库的事务性每每会从ACID四个方面来考虑，咱们先简单看看ACID具体表明着什么含义：

• A -> Atomicity: 原子性。一个事务每每会包括多个操做，那么这些操做只能同时成功或者同时失败。
• C -> Consistency: 一致性。一致性保证了数据库一直处于一个有效状态，若是出现了非法事务，能够及时回滚，保持一致性。
• I -> Isolation: 隔离性。在实际业务中，容易出现读写同时发生的状况，这时候，读写应该如何隔离。
• D -> Durability: 持久化。事务成功后，不会由于数据库宕掉而丢失此事务。

---

HBase + ACID

知道了ACID的概念以后，就很容易地去阐述HBase的事务性。

• Atomicity: 只在同一个Region下具备原子性，没法实现跨Region/Table。
• Consistency: 不存在回滚策略，也就是没法实现一致性。
• Isolation: 因为HBase采用LSM结构，更新数据经过Compaction来实现，因此必定程度上，不存在对已有数据同时读写的状况。
• Durability: 知足持久化的概念。

---

If HBase + ACID

HBase性能高，适合OLAP查询/计算。传统数据库MySQL支持事务性，可是没法方便地支撑海量数据的存储和查询。若是HBase可以彻底地支持ACID的话，而且稳定性有所保障的 状况下，相信有很多人会选择弃用RDBMS吧。那么咱们能够看看，单纯以ACID来说，HBase还须要作什么才能弥补完整事务性的空缺。

Atomicity

若是要实现跨表、跨节点的事务保证，必需要想一个机制来保证，全部节点的事务同时成功或者同时失败。比较经典的是2PC（2-Phase-Commit）机制，这个我在以前Flink的博客中提到过，将不一样节点的提交分为两步骤，第一步为Pre-Commit，待全部节点完成Pre-Commit以后，再真正的触发事务。
来实现这个流程，首先须要有一个Manager和全部节点保持通讯，这样才能保证你们的commit流程处于一致的状态。固然，这个机制也不是万能的，若是在真正触发事务时gg了，那也没辙了。目前没有看到更好的算法或机制，也多是我见识太少？

Consistency

重点是在不一致时实现回滚。这意味着在写以前，必需要先读取数据。其实在我看了一两篇数据库论文以后，发现大部分数据库都是这样作的...。因而一个写事务的时间线就变成了这样：

Isolation

Durability

至于这两部分，HBase目前倒也能够达到标准。

---

固然，已经有若干个线程的框架支持HBase的事务性，如Apache Tephra，感兴趣的能够自行研究。不出意外的话，我在这周会再写一篇这个的系列的文章，若是喜欢就关注下面的公众号吧！