17LIVE Next-Gen Database選型分析

Pink Yu

Published in

17LIVE Tech Insight

12 min readFeb 24, 2021

古語云 : 觀照古今 , 鑑往知來

在我們進入分析資料庫的選型前，先考古現今資料庫的發展，簡略的區分成下列四個階段。

1979年 Oracle 發佈第一款商業RDBMS
1984年 Teradata 發佈第一款無共享架構資料庫( Sharding 的概念誕生)
1989年 Kognitio 發佈第一款 In-Memory 資料庫
1991年第一款開源的文檔資料庫 Berkeley DB 問世
1992年 Arbor 發佈第一款多維度資料庫 Essbase
1995年 MySQL 開源資料庫問世
1996年第一款 Object Oriented 資料庫 illustra 發佈
1999年 Endeca 發佈第一款商用搜尋資料庫

在這段期間內，各類型的先驅資料庫相繼問世，且因原生架構上的限制，單機效能瓶頸逐漸浮現，後續解決問題大致發展成兩種主流模式，由業務層級的人工分庫分表，或是仰賴第三方 Middleware 協助的分片。

2009年左右，在各 DBMS 原生架構擴展遇上貧頸後，接著進入了宣揚 NoSQL (Not Only SQL) 的時代，針對業務上的實際需求，放棄了關聯性資料庫的 ACID 限制後，換取了彈性結構、強水平擴展等強項。

代表性資料庫：Redis、MongoDB、Cassandra、HBase

在 NoSQL 成功的崛起後，於2011年首度出現了 NewSQL 一詞，即是滿足了OLTP 需求同時保持 ACID 的規範，並多了 NoSQL 系統的可延展性，因不同於 SQL 及 NoSQL ，所以稱之為NewSQL ，可簡單區分成以下兩類。

Shared Nothing ( 純分佈式資料庫 )

代表性資料庫：Spanner 、CockroachDB

Shared Everything ( 將計算節點與資料存儲節點徹底分離，多半是 Cloud-Native Database)

代表性資料庫：Aurora、PolarDB

在 2013 年 Google 發表的 Spanner / F1 論文與 2014年分佈式一致性協議算法 Raft 論文，最終激發在2014誕生了 HTAP 一詞，終於想到將 OLTP 與 OLAP 之間的隔閡打破的可能性，不在區分成 SQL、NoSQL不同特性的資料庫存儲，而是以 “我全都要” 的想法，將之統整成新形態的 HTAP 資料庫 ( Hybrid Transactional and Analytical Processing ) ，HTAP 數據庫的優勢是可以像 NoSQL 一樣具備無限水平擴展能力，以及 NewSQL 一樣能夠去做 SQL 的查詢與事務的支持，更重要的是在混合業務等複雜的場景下，OLAP 不會影響到 OLTP 業務，並同時省去了 ETL 的步驟。

代表性資料庫：TiDB

宏觀上來看，各時期的資料庫並沒有強弱之分，都是為了滿足當前時代需求而演進的型態，只不過有些資料庫逐漸無法達成現今人們的需求，而慢慢被淘汰在時間的洪流裡，資料庫的選型如同上述一般，為了符合當前公司的業務需求及運維能力考量下，綜合評估得出的選擇，所以說以下文章並非只分析的資料庫優劣之分，而是針對該資料庫的原生設計，哪種更可能滿足我們業務上的需求而已。

不過市面上資料庫接近一百五十多種，以下初步篩選出來分析比較的資料庫，因為考量到運維能力方面，所以優先挑選知名度較高，除了官方文檔較齊全外，網上排錯及調優經驗等文章也容易取得。

表格資料來源 https://db-engines.com/en/ranking

MySQL、Mongo 兩款資料庫，分別是 SQL 與 NoSQL 其中的佼佼者，也是現今 17LIVE 採用的主力資料庫，以下簡單介紹內部架構狀況，及使用上的經驗痛點，乃至於需要研究往新世代的資料庫邁進的原因。

主要使用 ProxySQL 實作讀寫分離及負載平衡功能。

監控效能表現由 Grafana 為主，細部針對 Query 使用頻率及慢查詢的部分，則是由外部服務 Vividcortex 為輔。

備份作業由 Xtrabackup 及 Mydumper 分別對整庫及表做定時排程，除了本機保留一星期內的備份檔外，也將過期的備份檔同時上傳至 GCS 做三個月的留存。

Slave 除了作為線上業務 read 分流，額外區分給 Data-Team 做 ETL的源機及 DBA 分析語法工具 (SOAR) 。

比較特別的是 MHA (Master High Availability) 的做法，額外由 Orchestrator 獨立監控 MySQL 服務主從之間是否正常 sync ，當 Master 異常狀況發生時，Orchestrator 立即介入新舊主機切換，並同時透過內建切換的 hook 執行 script 聯絡 ProxySQL 變更 group id，進而達成全自動化主從切換。

似乎 MySQL 的架構透過搭配各式中間件協作已無破綻，非也非也！再怎麼透過工具補強 MySQL 的原生架構，也改善不了的弱點就是 OLAP 的語法一但進入 MySQL 執行，便會拖累整體的效能，即使透過讀寫分離加上負載平衡獨立一台 Slave 執行，也僅是隔離出一台 Slave 來跑緩慢的 OLAP 需求，對於語法本身的執行效能無實質上改善。

另外關於金流的 Log Table ，因時間累積逐漸趨於肥大，雖然初步透過水平分割 ( Horizontal Partitioning ) 的方式來改善整體效能，但這種因時間不斷積累的大表，一遇上任何 DDL 的需求，相信絕對是 DBA 的夢魘，即使目前使用了 Percona 的 pt-online-schema-change ，但執行時間仍是會久到一個令人厭世，不過這痛點在 MySQL 8.0.12 引入了 Instant Add Column 快速加列的功能，得到部分的緩解( 沒有改善 index 的部分 ) 。

上圖為一座 Cluster 的架構圖，17LIVE 在2020年底根據業務拆分成六座Cluster 分散流量壓力，日常運維如前述正常運作的情況下幾乎不需要投入太多人力介入，但痛點的部分則是 Mongo 分片仍需要仰賴管理者的經驗設計，網上及目前使用經驗都常遇到使用錯誤的 Index 而導致拖累整體效能，更甚會在單 shard 瞬間流量過高，無法負荷出現 OOM 的狀況，導致切上來的新 Primary 也瞬間崩潰，然後不斷重複主從切換的狀況。

做為 MySQL 的熱門替代方案，擁有搬遷容易加上 SQL 高度相容，且社群資源取得容易，對入門學習者友善，且 Secondary database models 為 Document store，故 Mongo內 data 搬遷雖然步驟繁多，但並非不能達成，是未來有機會可以將17LIVE內部 OLTP及 Data Team OLAP需求合併的選擇。

筆者身為 MySQL 擁護者，但是平心而論 PostgresSQL 整體性能與支援度都高於 MySQL ， MySQL對我而言比較像 ”土炮” 的萬用資料庫，需要用中間件來支持 MySQL 缺陷，網路上多數比較兩者的文章，將 MySQL列入中間件資源較少，沒有熱備份工具(注一)，及 MyISAM 引擎的缺點等等，諸如此類的資訊落差。
在幾年前將 MySQL 搬遷至 PostgresSQL ，應該遠高於 PostgresSQL到 MySQL，但是近年有更多的 NewSQL崛起，我個人覺得 PostgresSQL 仍會是個選擇，但優先度不會很高，因為追求更新的技術總是比較香。
注一：MySQL 的熱備份工具除了 Xtrabackup 也有 Enterprise backup。
注二：MyISAM 在 5.7版後，逐漸被淘汰。

與 TIDB同樣設計靈感來自 Google 的 Spanner 和 F1，底層同樣使用RockDB(LSM樹)，與 TiDB 的差別主要是對 SQL 解析協議是基於 PostgreSQL，效能表現稍差的原因可能使用全同步機制預設序列化隔離等級，及分散式事務提交仰賴網路 IO 的開銷等等。
在 2020 年的 20.2 版本預設引擎改為更適合 Cockroach的原生引擎 Pebble ，效能改善方面可以期待後續發展。

藉由對比 MongoDB 架構圖， Create DB 的架構能自動分區分片及重新平衡數據，如果在效能表現比 Mongo 內部實現的 move chunk 更好，加上 Create DB 節點能達成高可用，拋棄任何故障的節點，並不影響整體群集的運作，加上原本業務上的確有不需要頻繁 update 的場景，評估的確有取代 Mongo DB 服務的潛力。

ClickHouse 屬於 share nothing的分佈式架構，同步數據在多個 replicate 之間互相發送，需要用到 zookeeper 介入管理，所以 shard 在單點錯誤的情況下，是可能會發生資料丟失，及需要手動介入修復的情況。
ClickHouse 適合做一次一千筆以上的批次寫入，因為本身善於並行處理機制，即使一個簡單的查詢，也會用一半以上的CPU，因此不適合高並發使用，官方建議單台 QPS 在100左右，所以如果需求改成高並發的小量頻繁寫入，則會嚴重影響查詢效能，基本上 ClickHouse 的效能表現非常依賴 CPU。
再次研究查詢下來的優點還有，查詢可以不需要滿足索引靠左原則，只要過濾條件有包含在索引內即可，以及列存儲的真正優勢在於順序ＩＯ。

從早期稱作 MemSQL 針對於 row data 能完全存放在 memory 的前提下進行高度優化設計的資料庫，但隨著 RAM 成本越來越低，多數資料庫也能達到將大多數的資料存放進 memory，加上 OLAP 的需求逐漸增加，故放棄了純記憶體資料庫系統的主張，併入了 on-disk 存放 column data 來滿足 OLAP 的需求，最終更名為 SingleStote，從以上發展歷史可以了解，SingleStote 專為設計適用於需要高速的 OLTP 需求並同時要滿足能查找 OLAP 的使用場景，但由於其閉源且已有不少能滿足相關訴求，同時也免費開源的資料庫系統，故取代現有需求優先度不高。

對比 CockroachDB 與 YugabyteDB ，在實作分片、複製、事務架構高度相似，底層皆採用 RockDB 以及使用 Raft 作為分佈式共識算法，而 YugabyteDB 查詢層的多 API設計，提供了以下三種 API
YCQL：與 Cassandra兼容的API，具有擴展功能，包括分佈式 ACID 事務，高度一致的輔助索引和本機 JSON數據類型
YEDIS：支持 Redis的命令和數據類型，用新的本地時間序列數據類型提供的Redis兼容的API
YSQL： PostgreSQL 的兼容的API
最後是否能在目前 NewSQL 與 HATP 快速發展的時代，走出自己特性的路，可以期待其後續發展。