朱曄的互聯網架構實踐心得S1E3：相輔相成的存儲五件套

10-12

來自專欄隨緣主人的園子1 人贊了文章

這裡所說的五件套是指關係型資料庫、索引型資料庫、時序型資料庫、文檔型資料庫和緩存型資料庫。

上圖顯示了一套讀寫服務搭配這五種類型資料庫的例子：

這裡只是說明了我們可以這麼來搭配這些類型的資料庫，不是說我們所有的應用都需要用到這些類型的資料庫。

同步寫服務負責第一時間把重要的數據落地和落緩存。

非同步寫服務通過監聽MQ來感知數據的變化，然後重新讀取最新的數據來把數據寫入其它次要數據源，比如文檔性資料庫和索引型資料庫，需要的話可以在緩存中回寫一個狀態。

由一個專門的數據查詢服務來根據需求做數據路由，根據需求和性能因素，從不同的數據源讀取數據。

數據聚合服務根據需求從次要數據源進一步讀取數據以時間維度進行聚合，聚合到時間序列資料庫，供監控查詢服務查詢。

下面我們來具體說說這些存儲系統。

關係型資料庫

毫無疑問，強事務性的數據寫入MySQL之類的關係型資料庫是最可靠的，搭配SSD盤的使用，關係型資料庫也很容易達到萬級的QPS。對於超大數據量加上超大並發的應用來說，單表的數據量過千萬伴隨著數萬的QPS很難以單體資料庫來支撐，我們需要對數據表進行Sharding分片處理，把數據按照一定的維度切分到比如128個數據表，然後分散在8套甚至16套數據集群，這樣每一台MySQL的實例只需要承受1/8或1/16的請求壓力而且數據量更小。隨之帶來的問題是，我們需要對應用進行改造，使之只能按照一定的查詢條件來查詢這個切片後的表，如果不帶條件或帶任意條件的話，我們是無法知道數據實際存儲在哪個表哪個實例上的。

這確實是一個比較麻煩的地方，我們的查詢條件可能有十幾個，只能按照一個維度來查詢滿足不了我們的需求。一個折中的方式是我們引入所謂的Index數據表，也就是在寫入實際的完整數據到Sharding的數據表的同時，我們把數據表裡需要查詢的欄位寫入一個專門的沒有經過Sharding處理的Index數據表，這個數據表裡存放的幾乎沒有varchar類型的數據，全部是各種bigint的各類業務ID或是tinyint類型的各種狀態，以及時間。由於這個表非常親，雖然數據條數多但是表空間幾乎可以在資料庫的緩存中容納，性能會高不少。對於實時性要求非常強的基於條件的查詢可以從這個數據表來進行查詢。而Sharding後的數據只能用於按ShardKey來進行查詢。

緩存資料庫

Redis是最常用的分散式緩存解決方案，幾乎在任何互聯網應用中都會用到，特點是：

能持久化數據，但是我的觀點是緩存資料庫還是僅僅作為緩存的好，要能夠承受丟失數據的風險，否則可能會死的比較難看。因為RDB或主從複製導致的一些事故也是層出不窮的。
豐富的數據結構是一定要利用的，豐富的數據結構代表了可以依賴豐富的API在服務端做複雜的運算，性能比反序列化取出後運算再序列化存入效率高的多。有的時候甚至可以把這些數據結構和API組合在一起碰撞出絕妙的方案以極高效的方式實現一個高性能的業務邏輯。可以看看《Redis實戰》一書。
超高的性能（當然了，配合一些集群方案比如codis就更上一層樓了）足以抵擋任何業務請求的直接訪問，很多時候緩存的方案掛是掛在因為各種各樣的原因穿透緩存而不是Redis檔不住。
豐富的集群和高可用方案以及各類各種實用的功能（管道、事務、Lua腳本），5.0的版本還推出了Stream特性來替代少有人關注的Disque值得關注。

所以Redis的應用也很廣泛：

數據緩存
分散式鎖
消息隊列
服務端運算

在上圖的架構中，我們通過同步寫服務對資料庫和緩存進行雙寫，目的也就是為了讓緩存中能有新鮮熱數據，不管是對內還是對外這種單條數據的查詢可以直接路由到緩存。

文檔型資料庫

文檔型資料庫的代表就是耕耘多年的Mongodb，我在一些非重要業務的場景使用過Mongodb幾次，我的評價如下（最近1年多沒有碰過Mongodb，也可能評價有失偏頗）：

超高的寫入性能，非常不錯的讀取性能（和Redis是不能比的，性質不同），數據量增多後可能會有很厲害的性能衰退，不是Hbase那種無底洞型的存儲，不維護就往裡面一直堆數據進去最後的性能可能比如MySQL。
因為存的是文檔，所以是弱結構的，存一些事先不能確定的數據非常非常合適，而且以後要查的時候可以任何加索引對需要的數據進行搜索查詢。一個很實用的場景就是作為爬蟲的數據源，數據變化多端而且不那麼重要，而且寫入性能很重要。
不太可靠和穩定，可能會丟數據，強烈不建議作為核心數據存儲，建議作為一個旁路資料庫用在非關鍵的業務。比如在上圖的架構圖中，我們可能會拿到核心數據後再從其它地方去補一些數據然後進行適當的加工，保存到Mongodb作為一個監控資料庫或者面向後台的資料庫來用（MEAN套件之一，可以想像對於簡單的應用來說配合腳本語言用起來多舒服了），掛了也就掛了，沒掛的話可以分擔很多MySQL的壓力。
玩法雖然多，什麼Sharding、複製、集群都有，但隨著數據量的增多運維可能是一個大坑，很可能遇到集群全軍覆沒無法啟動的情況，數據的恢復耗時很長。內存的使用相當瘋狂，對硬體的使用總感覺性價比不高。

索引型資料庫

ElasticSearch作為其代表是最近幾年的黑馬。ELK集群各大互聯網公司都有使用，只要集群配置得當，每秒幾十萬的寫入不是大問題，畢竟徹底的分散式化理論上可以有無限高的寫入能力。ES的特點如下：

非常豐富的查詢API，不僅僅是全文索引查詢，普通的查詢API豐富多樣，組合起來可以在服務端完成各種業務邏輯，基本上SQL+MySQL可以實現的，ES查詢都可以實現，而且還多了更強大的全文搜索。當然，查詢的語法稍顯晦澀肯定沒有SQL來的直掛。
類似於Mongodb的schema-free，無需實現定義表結構。
還算強大的寫入和讀取能力，當然，索引多的話寫入文檔的效率肯定會降低。這也是圖中對於ES的寫入由專門的非同步流程進行的原因。
ES天生的分散式配置決定了，在寫入億、十億的數據量之後，還能在相當可以接受的時間內（比如10秒）完成一個多條件複雜查詢，對於MySQL這個量級下這樣的查詢可能需要10分鐘甚至100分鐘的時間來執行，完全不能接受。
ES對嵌套型數據的查詢支持不錯，經過測試我們傾向於把多標關聯的數據作為一個大的嵌套的JSON拍扁了直接存入ES，比如我們可以把用戶個人唯獨的基本信息+充值訂單+提現訂單+投資訂單，一人一個JSON存進去，然後對於嵌套的下層JSON數據也是可以方便的利用查詢API進行查詢。

因為這些特點，在這個架構圖上，我們把ES也作為了查詢服務的數據源，對於滿足下面這些條件的查詢，我們可以走ES：

對數據延遲不敏感，可以接受一段時間查不到新鮮數據
查詢特別複雜，或是全文搜索，不能走Sharding後的RouteKey，Index表也無法滿足需求
查詢的結果也不僅僅是單表的數據而是比較豐富的數據，查詢資料庫需要查詢多個表多次

索引型資料庫和文檔型資料庫的底層存儲結構是截然不同的，雖然現在有很多人使用ES來完全替代Mongodb，但是個人覺得ES適合存比Mongodb更大的一個數據量，分散式不利用起來發揮不了ES，Mongodb還是適合中型數據非Sharding的存儲。

時序型資料庫

InfluxDb是時序型資料庫的代表。對於按照時間段進行Group By查詢的話，不管是ES還是MySQL還是Mongodb在API層面當然都是支持的，但是查詢效率不堪入目。因此對於諸如下面的需求首當其中可以考慮時序型資料庫：

監控圖表
按時間維度聚合
查詢的時間維度可以跨度很長
需要定期歸檔

如果使用傳統方案的話，我們往往會以固定的時間維度來聚合保存數據，如果我們要查1小時和1年的維度，都使用5秒的聚合粒度顯然不合適，我們需要在寫入數據到時候針對不同的粒度進行聚合，需要一定的工作量，使用時間序列資料庫可以少一些這樣的煩惱。而且InfluxDb之類的資料庫的性能是非常高的，寫入數據的性能堪比Redis，單節點甚至可以承受十萬指標的寫入，基本可以滿足大部分應用場景的需求。對於一些業務指標的監控，業務事件的打點，業務數據的時間維度聚合，我們完全可以考慮引入專門的時序型資料庫。

綜上所述，這裡的架構圖只是體現了幾個重要思想：

使用專門的服務來做數據的寫入和讀取，方便進行路由。
合理規劃好Sharding的方式，以及想好RDBMS在Sharding後的全套查詢方案。
數據的寫入區分主要數據源的同步寫入和次要數據源的非同步寫入，讓主流程更快。
合理利用不同數據源的特性，組合使用發揮所長，避免所短。
數據的加工可以是一個層級的關係，可以由專門業務中間件來進行數據加工。
RDBMS以外的資料庫如果打算作為主核心存儲引擎的話千萬慎重思考。
採用豐富的數據源意味著維護成本的增多，數據不同步的問題在所難免，需要考慮一下我們是否可以接受一定層度的數據不一致。