目前很多系統隨著業務發展，數據量變多，併發變大。很多依賴數據庫的業務出現了響應慢，鎖表，甚至停止服務的問題。

目前比較流行的解決方案是 分庫分表 + ES 。分庫分表解決庫壓力，es解決搜索，複雜查詢和大數據量彙總問題（像分佈式數據庫）。

庫存，訂單中心等都採用了這種方案。

很多同學也心存疑問我們現在的數據量和併發量用這些手段是否合適，是否是過度優化？

我們對這幾個方案做個簡單總結：

ES:

主要功能是全文搜索。

支持多索引聚合，對過濾查詢也做了些優化。

適合無事物，數據質量和實時性要求不高的場景。

分佈式，支持大數據量的複雜查詢聚合操作。

按地理位置查詢（眾包搶單）

注意事項：

數據量增加性能下降，支持幾千萬問題不大。

減少索引量，只索引查詢字段，彙總字段，id。

使用內存緩存提高響應，但是需要設置內存佔比閥值。

不支持聯合查詢不支持事物，有延遲。

併發寫容易出現狀態不一致。

注：在我們的使用場景中，數據庫做數據的主要載體，es作為數據聚合查詢的輔助手段是可以的。

主站團購的三級類商品索引，幾億的數據量做查詢效果不錯。

分佈式數據庫：

維護成本高。

目前公司內沒有太好的使用案例。需要驗證。

有些框架只是優先保證寫，對聚合查詢的讀支持不太好。

Hbase:

分佈式，數據容量大。

列式數據庫，字段擴展靈活

只按rowkey查，查詢不靈活。

Rowkey模糊查詢，Scan,filter效率不高。

封裝二級索引可提高效率 單目前公司hbase不支持。

分庫分表：

在經過充分的數據庫，表結構，查詢優化後才考慮分庫分表。

分庫分表後會增加程序、維護複雜度。基本捨棄了關係數據庫關連，聚合等好用的特性。

分表為了應對數據量增長，分庫為了應對併發量增長。

一般場景應先考慮分表再分庫。

根據數據冷熱分表。熱數據達到百萬級需要分表。

冷數據（如流水錶）可超千萬級。

分佈式系統應該按業務領域做庫垂直拆分。

根據數據庫負載來。讀寫分庫，水平分庫。

注：

數據庫關連場景

保證強關聯不會分到兩個庫。

數據在程序中做關連，數據量小才允許庫中關連。

閱讀更多 從大數據說起 的文章

關鍵字: ElasticSearch 系統 HBase