1. 從 MySql 到 Hbase (集群化方案)

4 人贊了文章

Mysql 應用的演化

Mysql 與 Hbase 說到最核心的點，是一種數據存儲方案。方案本身沒有對錯、沒有好壞，只有合適與否。 相信所有的公司都與 MySql 有著不解之緣，部分學校的課程甚至直接以 sql 語言作為資料庫講解。

只有 mysql

筆者呆的上家公司是一個 O2O 創業公司，所有的數據都存儲在同一個 MySql 里，而且沒有任何主備方案。相信這是一個很多初創公司典型的解決辦法。當時，這台 Mysql 為用戶、訂單、物流服務，同時也為線下分析服務

單實例的問題：

1. 一旦 mysql 掛了，服務全部停止了
2. 一旦 mysql 的磁碟壞了，公司的所有服務都沒有了 （一般會定時備份數據文件）

主從方案

隨著業務增加，單個 DB 是無法承載這麼多的請求的。於是就有了主從複製、讀寫分離的解決方案

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

1. 為了擴展讀能力可以增加多個 slave
2. 允許 slave 同步有一定的延遲
3. 一致性要求嚴格的，可以指定讀主庫

主從功能的問題：

1. 需要增加 管理 proxy 層，分配寫請求、讀請求
2. 節點故障：其它節點應該快速接管故障節點的功能

垂直拆分

業務繼續增長，master 甚至都無法承載所有的寫請求。資料庫需要按業務拆分。

垂直拆分的問題：

1. 線下分析，需要在業務代碼里 join 各個表，因為拆成多個庫，已經無法 join 了
2. 不容易做資料庫的事務性，用戶餘額減少，與下單成功無法使用 mysql 的事務功能

水平拆分

業務繼續增長，訂單表有大量的並發寫入，而且已經有了幾千萬行數據。

1. 單個庫無法承載大量的並發寫入
2. 上千萬行的大表，數據寫入可能需要調整一棵巨大的 B+ 樹
3. 上千萬行，B+ 樹過深，讀寫需要更多的磁碟 IO
4. 很多老數據訪問較少，B+ 樹上層緩存的部分信息無用
5. 。。。

參考：

大眾點評訂單系統分庫分表實踐

水平分庫/分錶帶來的問題

1. 維護 map 方案
2. 輔助索引只能局部有效
3. 由於分庫，無法使用 join 等函數；由於分表 count、order、group 等聚合函數也無法做了
4. 擴容：需要再次水平拆分的：修改 map，遷移數據。。。

Mysql 的問題

Mysql 的主要瓶頸，單機單進程。CPU 有限、內存/磁碟功能、連接數有限、網卡吞吐有限。。。

集群的限制點

• 關係型資料庫，縱向的外鍵相互 join (範式)
• 資料庫事務性，基於單機的鎖機制，無法擴展到集群中使用
• 全局有序列性，基於 B+ 樹，數據有序聚合存儲，集群化後無法保證
• 數據本地存儲，擴容需要遷移數據

集群的方案

放棄部分功能，輔助索引檢索、join、全局事務性、聚合函數等。當然有些牛逼的分散式資料庫，試圖解決這些問題（如 TIDB）。

• 水平拆分：存儲 KV 化，用機械的 map 思路實現集群
• 擴容方案：手動導數據，開發數據遷移腳本
• 事務性：兩階段事務、paxos、單庫事務。。。
• 備份容災：從節點同步主節點，但有一定的數據延遲
• 服務穩定性：主節點掛了，proxy 會將從節點升級為主節點；從節點掛了會被其它從節點替換

HBbse 集群化解決方案

水平拆分

• region: 拆分後的子表
• region server: 管理這些數據的 server，相當於一個 mysql 實例
• .META. 表存儲拆分信息 map<row, server>

單個 region 過大，RegionServer 將 region 會均分為兩個（自動、手工）。然後更新 .META. 表

擴容方案

RegionServer 向 HMaster 彙報狀態。HMaster 為 RegionServer 負載均衡，調整其負責的 region

增/刪 RegionServer 後，會為重新調整 region 的分配方式

服務穩定性

RegionServer 只是計算單元，掛掉後 Hmaster 可以隨便再找一個節點代替壞節點服務

事務性

HBase 只保證行級事務，單行數據肯定存在同一台機器 (單機事務很好做)

備份容災

數據使用 HDFS 存儲，多複本，任何一個複本掛掉都不影響功能

RegionServer 只是計算單元，掛掉後不影響服務