談談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，感興趣的能夠自行研究。不出意外的話，我在這週會再寫一篇這個的系列的文章，若是喜歡就關注下面的公衆號吧！