從MySQL到HBase：數據存儲方案轉型的演進

1、集羣化方案

一、MySQL應用的演化

MySQL與HBase說到最核心的點，是一種數據存儲方案。方案自己沒有對錯、沒有好壞，只有合適與否。相信多數公司都與MySQL有着不解之緣，部分學校的課程甚至直接以SQL語言做爲數據庫講解。我想借自身經歷，先來談談MySQL應用的演化。

只有MySQL

筆者以前曾在一家O2O創業公司工做，公司全部數據都存儲在同一個MySQL裏，並且沒有任何主備方案。相信這是不少初創公司會用到的一個典型解決辦法，當時這臺MySQL爲用戶、訂單、物流服務，同時也爲線下分析服務。

單實例的問題：

一旦MySQL掛了，服務所有中止；
一旦MySQL的磁盤壞了，公司的全部服務都沒有了 （通常會定時備份數據文件）。

主從方案

隨着業務增長，單個DB是沒法承載這麼多請求的。因而就有了主從複製、讀寫分離的解決方案。

master只負責寫請求，slave同步master用來服務讀請求：

爲了擴展讀能力能夠增長多個slave；
容許slave同步有必定的延遲；
一致性要求嚴格的，能夠指定讀主庫。

主從功能的問題：

須要增長管理Proxy層，分配寫請求、讀請求；
節點故障：其它節點應該快速接管故障節點的功能。

垂直拆分

業務繼續增加，master甚至沒法承載全部的寫請求，數據庫須要按業務拆分。

垂直拆分的問題：

線下分析，須要在業務代碼裏join各個表。由於拆成多個庫，已經沒法join了。
不容易作數據庫的事務性，用戶餘額減小與下單成功的狀況下沒法使用MySQL的事務功能。