565
表格存儲在QCon2017的分享
在QCon2017的基礎設施專場，筆者以表格存儲為基礎分享了分布式係統設計的幾點考慮，主要是擴展性、可用性和性能。每個點都舉了一個具體的例子來闡述。這裏對這次分享做一次簡單的總結。
首先，說到了表格存儲產生的背景，大規模、弱關係數據，對靈活schema變動的需求，傳統數據庫無法很好的滿足，NOSQL的出現是一個很好的補充。NOSQL不是為了取代SQL，也無法取代SQL，是已有數據庫生態的很好補充。我認為未來會出現更多種類的數據庫，麵向不同的業務，使用不同的硬件，數據庫市場將迎來更多的成員。
然後介紹了表格存儲的功能、生態、架構以及數據模型，有了這些基礎才能更好的理解後麵的內容。
在論述擴展能力的時候，筆者舉了個例子。HBase在一次分裂之後，需要做Compaction才能繼續分裂，Compaction時間可能數個小時，而表格存儲支持連續分裂。那麼，為什麼表格存儲要支持連續分裂呢？主要原因在於多租戶服務和企業內產品的不同。對於表格存儲而言，用戶點點鼠標就可以開通，業務訪問隨時可能大幅上漲，用戶不會提前告訴我們，即使告訴了也人力也沒那麼多。而訪問量上漲有很大的可能導致分區內訪問熱點，這些熱點需要係統能夠快速的處理，1個分裂成2個，2個分裂成4個...。而在企業內部，業務一般可以預期的，很難出現運維不期望的巨量上升，所以對於HBase而言，連續分裂的必要性就降低了。這個不同，看似技術的不同，實際則是用戶不同、產品形態不同帶來的的不同選擇。
在論述可用性的時候，特別講了一個例子，就是穀歌BigTable和開源HBase都采用的在worker層聚合日誌以提高性能。這個思路很好理解，就是將多個分區的日誌聚合在一起，寫入文件係統中，這樣就能減少文件係統的IOPS，提高性能。但是，這對可用性是個很大的傷害，因為一旦機器發生failover，意味著日誌文件需要被讀出來按照分區進行分割，這些分割完的日誌文件再被相應的分區replay，然後相應分區才能提供服務。顯然，上麵這個過程會使得機器failover時候分區不可用的時間變長（想想看誰來分割日誌呢？這是否會成為瓶頸？）。如果考慮到全集群重啟，或者交換機down導致較多機器失聯，那麼其對可用性的影響將十分可觀。這裏是一個可用性和性能的權衡，表格存儲在設計之初，是選擇了可用性的，也就是每個分區有獨立的日誌文件，以降低在機器failover場景下不可服務時間。但是這是否意味著性能的下降？是的，但是我們相信可用性優先級更高，而性能總會被解決，後來我們也找到了非常不錯的辦法，見下。
上麵說到可用性和性能的權衡，表格存儲選擇了可用性，而放棄了性能。但是性能顯然十分重要，於是我們重新思考了這個問題。BigTable和HBase的核心思想是聚合以減少IOPS，從而提高性能；那麼聚合是否一定要做在table這一層呢？是否可以下推做到分布式文件係統層？結論當然是可以，而且效果更好，受益方更多。具體架構見附件裏麵的說明，我們通過將聚合下推到文件係統、RPC層小包聚合、Pipeline傳輸等大幅改進了性能，在可用性和性能之間取得了很好的平衡。
繼續向下，我們說到了，作為一個平台，如何向用戶學習。附件中給出了PK自增列用於消息推送係統的例子，這方麵我們寫過不少文章，見[2][3]。
[1]. QCon 2017資料: https://ppt.geekbang.org/qconsh2017
[2]. 高並發IM架構：https://yq.aliyun.com/articles/66461
[3]. 打造千萬級Feed流係統：https://yq.aliyun.com/articles/224132
[4]. 演講PPT下載：https://ppt.geekbang.org/slide/show/1122
最後更新：2017-10-26 13:34:30