本文選自“字節跳動基礎架構實踐”系列文章。
“字節跳動基礎架構實踐”系列文章是由字節跳動基礎架構部門各技術團隊及專家傾力打造的技術乾貨內容，和大家分享團隊在基礎架構發展和演進過程中的實踐經驗與教訓，與各位技術同學一起交流成長。
字節跳動存在海量結構化與半結構化數據的諸多存儲需求。本文將對字節
概要
分佈式表格存儲系統在業界擁有廣泛的應用場景。Google 先後發佈了 Bigtable 和 Spanner 兩代分佈式表格存儲系統，承接了其公司內部和外部雲服務中的所有表格存儲需求。其中 Bigtable 的開源實現 HBase 在國內外公司中都得到了廣泛的使用，並且開源的圖數據庫 JanusGraph 、時序數據庫 OpenTSDB 、地理信息數據庫 GeoMesa、關係型數據庫 Phoenix 等底層都是基於 HBase 進行數據存儲的。字節跳動也大量使用 HBase 作爲表格存儲服務，HBase 在字節跳動的實踐過程中，在極大數據量和極高負載的場景下存在延時長尾較高和可用性不足的問題。爲此字節跳動表格存儲團隊經過大量開源系統調研並最終決定研發一套兼容 HBase 數據模型和語義的高可用、強一致、低延時、高吞吐、全局有序且對 SSD 和 HDD 盤同時友好的分佈式表格存儲系統，以應對字節跳動業務迅猛發展帶來的技術挑戰。目前第一代表格存儲系統 Bytable1.0 已作爲搜索和推薦的底層數據存儲穩定運行，我們團隊正在此基礎上演進第二代表格存儲系統 Bytable2.0。
1. 背景
隨着頭條全網搜索項目的啓動和發展，業務需要一個全局有序、容量巨大同時性能高效的表格存儲系統以存儲整個互聯網中所有鏈接和網頁，並保證互聯網上發生的所有變更都被能實時的更新到表格存儲系統中。在此之前，搜索引擎技術的領導者 Google 爲此構建了 Bigtable ，並在其搜索、地球和財經等多個項目中使用。其中搜索業務在其發表的論文中做了主要論述，因而之後很多運營搜索業務的公司都效仿其使用方式。我們團隊最初使用 Bigtable 的開源實現 HBase 爲搜索業務提供服務。在全網鏈接關係的實時更新需求下需要提供足夠高的可用性和足夠低的延時，由於其數據量極其龐大所以會創建極多的數據分片，集羣的整體尾延時和可用性會隨着數據分片實例數的增多而成指數級別的惡化，因此對每一個分片實例的延時和可用性提出了更高的要求。但由於 HBase 存在尾延時較高和可用性較低的問題，並不能滿足我們的需求，於是我們團隊開始了調研和技術選型。
2. Bytable1.0 應運而生的第一代表格存儲系統
2.1 技術選型
在我們的需求下，面對海量的網頁鏈接和網頁數據，數據量非常龐大，全部使用 SSD 盤將極大地增加存儲成本，所以我們面向的設備不能只考慮 SSD 盤，需要在 HDD 盤上也提供高效的支持。目前廣泛使用的全局有序的開源分佈式表格存儲系統有 HBase, TiDB, CockroachDB 等。經過驗證 HBase 由於其延時長尾和可用性問題滿足不了我們的需求。TiDB 和 CockroachDB 在我們的需求下存在：（1）數據遷移時需要多路歸併掃描數據；（2）寫數據時需要兩份日誌；這兩個引起磁頭搖擺對 HDD 盤的不友好的問題。由於這些系統都不能解決我們的問題，最終我們團隊決定結合目前公司提供的軟硬件資源水平和業務場景，獨立研發一套兼容 HBase 數據模型和語義的高可用、強一致、低延時、高吞吐、全局有序且對 SSD 和 HDD 盤同時友好的分佈式表格存儲系統 Bytable1.0。在設計方案時，我們團隊遵循的原則是在滿足業務需求的前提下，儘可能的簡化設計。業界的分佈式表格存儲系統往往使用共享存儲架構，但在當時公司內部的分佈式文件存儲系統不能提供足夠高的可用性和 SLA。爲了滿足業務的高可用需求，我們決定不依賴分佈式文件存儲系統直接管理本地磁盤。
2.2 系統架構
下面我們來介紹 Bytable1.0 的系統架構，如下圖所示主要由 Master, PlacementDriver 和 TabletServer 三個模塊組成。Client 會跟 Master 通信取得 Tablet (與 Bigtable 類似，使用 Tablet 表示表中的一個數據分片，表示表中的一個 KeyRange 對應的部分數據) 的元信息，以得到對應 Tablet 所在的 TabletServer 的地址，然後 Client 跟對應的 TabletServer 進行通信進行數據讀寫。類似於 HDFS 的 NameNode 和 DataNode 分別處理控制平面和數據平面的任務，我們將整個 Bytable1.0 劃分了控制平面（Master），決策平面（Placement Driver）和數據平面（TabletServer），我們將詳細介紹每一個平面的內部設計。
2.2.1 控制平面 Master
Master 控制了 Tablet 主動切主、被動選主、遷移、分裂與合併的具體流程控制，此外 Master 向 Client 暴露 Tablet 分佈的位置信息。這裏以被動切主爲例介紹下大致流程，當 Master 在指定時間內沒有收到某 TabletServer 的心跳消息，則將此 TabletServer 判定爲 Offline，然後對此 TabletServer 上爲 Leader 的 Tablet 發起一輪選主。選主的過程與 Raft 類似僅僅是將這部分邏輯上移到 Master 統一管理，首先收集 Tablet 各個副本的最新日誌號，然後選取足夠新的副本作爲選主目標，向 Tablet 各個副本發起投票，當投票成功後向選主目標發送當主請求。因爲 Master 接管了控制平面的所有工作，所以邏輯和 RPC 交互會非常複雜，並且因爲對性能沒有特別高的要求，所以選擇了 Go 語言進行開發，以降低研發成本，提升研發效率。
2.2.2 決策平面 Placement Driver
Master 控制了指定操作的具體流程，但是不對是否發起指定操作（除了被動選主）做決策，而這個決策的任務由 PlacementDriver 來負責。它會掃描 Master 獲得分區的負載信息，經過各種策略的計算生成決策信息，發送給 Master 實際執行。因爲策略的更新往往更頻繁，拆成兩個模塊的話策略的更新不需要滾動重啓 Master，對用戶來說可以做到完全無感知。爲了降低複雜策略的編寫成本，PD 也選擇了 Go 語言進行開發。
2.2.3 數據平面 TabletServer
TabletServer 承載了多個 Tablet 的數據存儲，並負責進行實際數據的讀寫操作。每一個 Tablet 都會與其他 TabletServer 上面的對應 Tablet 會組成一個複製組，複製組內的多個成員之間使用簡化的 Raft 複製協議進行數據複製。所謂簡化的 Raft 複製協議就是隻實現了 Log Replication 的功能，將 Leader Election 和 Member Change 的功能移到了 Master 端。這樣做分離了其數據平面和控制平面，實現了數據平面的邏輯簡化。與此同時將控制平面操作統一到 Master 中便於定製更復雜的選主策略，並藉此實現了多組 Raft 的心跳合併到 Master 減小了心跳的額外消耗。
數據路徑是這個系統關鍵路徑，需要更高的性能以提升吞吐和減低延時，在語言層面我們選用了 C++ 以便提供高效與可預測的性能，此外我們還在日誌引擎和數據引擎等方面進行了大量的優化。當前市面上大部分系統比如 MySQL, MongoDB, TiDB, CockroachDB 等，在寫日誌時都會寫入複製日誌和引擎日誌兩份日誌，在 HDD 盤的場景下往往會造成分別寫入兩份日誌時寫流量放大一倍並且使磁頭頻繁發生搖擺，制約寫入性能。因此在我們的實現中規避了引擎日誌僅使用了複製日誌，避免了磁頭的搖擺問題。此外在 TiDB 和 CockroachDB 的方案中，使用了 RocksDB 作爲多組複製日誌的合併存儲的方案，但其會引入其非必要的 MemTable 插入和 SST Flush & Compaction 開銷，不夠高效。因此我們團隊研發了一套 WAL 存儲引擎，進行多組複製日誌的合併，實現了僅一次的日誌寫入，不會造成 HDD 盤磁頭搖擺，不進行 Compaction 時也可以打滿 HDD 盤的寫入帶寬。
數據存儲引擎方面我們團隊採用了業界流行和廣泛驗證過的 RocksDB 作爲存儲引擎。與 TiDB, CockroachDB 不同的是，Bytable1.0 的每一個 Tablet 都對應一個 RocksDB 實例，在數據遷移的過程中可以直接進行 RocksDB 的文件讀取、傳輸與寫入，不需要額外的掃描、文件生成和文件注入，避免了掃描時多文件歸併引起的磁頭移動問題、RocksDB 文件注入操作誤入 L0 潛在的 Write Stall 問題和 RocksDB 文件注入操作不允許存在併發的普通寫入的卡頓問題，實現了快速輕量的數據遷移。此外還可以合理的控制一個 LSMTree 的大小，避免 LSMTree 大小變化後與 RocksDB 參數不匹配的問題。
Split 和 Merge 操作的高效實現則是一個 Tablet 對應一個 RocksDB 實例使用方式引入的難題。對於 Split 操作來說，需要將原先的一個 RocksDB 實例分裂爲兩個 RocksDB 實例，在我們的實現中利用了 LSMTree 的特性，首先會進行一輪全量的引擎文件硬鏈，然後停寫，再進行一輪增量的引擎文件硬鏈並打開寫入，不可用時間爲增量的少量硬鏈操作所需要的時間。對於 Merge 操作來說，我們對 RocksDB 進行了改造，在文件注入時將是否是注入進來的文件以及 GlobalSequence 都存儲在 Manifest 中以便允許直接注入另外一個 RocksDB 實例中文件。與 Split 的過程類似，Merge 的過程也使用了增量的策略進行注入以減少不可用時間。
對比多個 Tablet 公用一個 RocksDB 實例的實現方式，Bytable1.0 的方案在遷移的穩定性和效率與單個 LSMTree 的大小控制上都更有優勢，但在分裂與合併的引起的抖動上存在一定的劣勢。
下圖列舉了在相同機器環境下，讀寫混合場景（讀 50%，寫 50%）下，Bytable1.0 TabletServer 與 HBase RegionServer 的延時對比。可以看出，Bytable1.0 在平均延時和 p99 延時上均有大幅降低。
2.3 優化細節
2.3.1 點讀優化
因爲我們在 RocksDB 的 KV 模型之上封裝了 Table 數據模型，所以無法利用其內置的 BloomFilter 以優化點讀性能，我們爲每一個 SST 在 Flush 和 Compaction 的過程中手工生成一個 BloomFilter 存儲在其 TableProperty 中，並關閉了內置的 BloomFilter 以節省空間。在查詢時利用 TableFilter 功能，查找到 SST 對應的手工生成 BloomFilter 進行判斷，以優化點讀的性能。
2.3.2 熱點寫入優化
因爲我們使用了 Raft 作爲副本複製協議，而 Raft 的 Apply 流程是串行的，當出現寫入熱點時需要通過熱點 Tablet 分裂來擴展性能。因爲我們的分裂合併操作相對比較重，熱點分裂的決策並不適合過於實時和敏感，爲了擴展單個 Tablet 的寫入性能，我們實現了一種新型的 RocksDB MemTable，寫入時僅寫入隊列中實現了 O(1) 複雜度的在線寫入，靠後臺線程池將數據併發的寫入實際的 SkipList 中，在讀取的時候使用 ReadIndex 的機制進行等待。將單線程的最大承載能力擴展到單機的最大承載能力。
2.3.3 寫入反壓優化
當單個 Tablet 寫入過快時，由於硬件資源的略微差距總會有一個副本的速度趕不上其他副本，逐漸累積引起慢副本重裝快照。當出現這種情況的時候，如果速度快的兩個副本有一個副本機器 Down 機，就會出現這個 Tablet 的短期不可寫的情況（其中一個副本正在重裝快照）。爲了避免這種情況，我們會在一定的條件下進行慢節點反壓，限制整體的寫入速度，防止慢副本落後過多，實現了極限情況下的可用性提升。此外，我們會設定一定的限制避免磁盤降速故障引起的慢節點反壓。
2.4 分佈式事務
目前有些業務場景下存在分佈式事務的使用需求，我們團隊按照 Percolator 的事務模型，在 Bytable 上層實現了一套分佈式事務解決方案，相關內容將在後續專題文章中詳細描述。
3. Bytable2.0 追求極致的第二代表格存儲系統
隨着 Bytable1.0 的上線與穩定，業務對錶格存儲系統的成本、穩定性和性能都有了更高的要求。從成本角度來考慮，目前使用三副本方式來存儲數據相比分佈式文件系統的 EC(Erasure Code) 方案需要多消耗將近一倍的存儲空間，此外目前存在三副本獨立 Compaction 的情況多消耗了兩倍的 CPU。從資源利用率的角度來考慮，目前存在讀寫請求和磁盤空間佔用不匹配的情況，會出現 CPU 資源剩餘但磁盤空間用盡或者 CPU 資源用盡但磁盤空間剩餘的情況。從與離線 Hadoop 生態系統打通的角度來看，現在做備份、導出和數據加載都比較麻煩。從穩定性的角度來考慮，目前在分裂與合併的過程中仍然存在一定的延時抖動，我們也希望將尾延時優化到極致。從運維複雜度的角度來考慮，基於分佈式文件系統可以將我們的服務無狀態化，結合 K8S 的調度技術，我們不再需要考慮機器和磁盤的故障報修和重新上線，將極大地降低我們的運維成本。因此設計和實現基於共享存儲的分佈式表格存儲系統勢在必行。
3.1 技術選型
與 Bytable1.0 設計目標僅僅是希望滿足當前業務需求不同的是，我們希望可以在更大的範圍內尋求最優解，構建世界領先的分佈式表格存儲系統。隨着字節跳動分佈式文件存儲系統逐漸向在線模式演進，我們擁有了可供在線使用的分佈式文件存儲系統 ByteStore。此外字節跳動還研發了使用 Quorum 協議的分佈式日誌存儲系統 ByteJournal ，它擁有類似 Paxos 的日誌亂序複製和提交的特性以儘可能的降低延時。此外 ByteJournal 還能提供總共 5 副本寫入 2 副本成功即可提交，但需要 4 副本 Recover 的高級特性，以提供比 Paxos 協議更加極致的尾延時優化。這一次我們選擇站在巨人的肩膀上，使用 ByteStore 存儲引擎文件，使用 ByteJournal 管理複製日誌，依賴這兩個分佈式存儲系統實現基於共享存儲的第二代表格存儲系統 Bytable2.0。此外，國際化業務也擁有全球一致的表格存儲需求，並希望可以細粒度的設置和變更部分數據的複製配置，藉此控制對應數據在訪問時的讀寫延遲（通過訪問數據時的距離）。
3.2 系統架構
在 Bytable2.0 的系統設計中借鑑了 Google 第二代分佈式表格存儲系統 Spanner 的設計思路。在本節中我們將介紹 Bytable2.0 的系統架構，如下圖所示我們將 Bytable2.0 劃分爲數據讀寫層（TabletServer）、全局管理層（GlobalMaster），計算調度層（GroupMaster）和數據調度層（PlacementDriver）。
Bytable2.0 與 Bytable1.0 的主要不同有如下幾處：
- 與 Bytable1.0 中將 Tablet 分佈信息存儲在 Master 中不同，Bytable2.0 爲每一張表都會建立一個對應的 MetaTable 存儲在 TabletServer 中。這樣做一個好處是可以爲每一個表的 Tablet 分佈信息訪問做好隔離，另一個好處是如果 MetaTable 成爲瓶頸可以在以後的實現中加入 RootTable 使其可分裂。
- 與 Bytable1.0 中一個 Tablet 即對應一個複製組不同，Bytable2.0 中一個複製組中會包含多個 Tablet。最終表現爲一個 TabletServer 擁有多個 ReplicationGroup 的某一 Replica (Replica 是 ReplicationGroup 的一個副本)，一個 ReplicationGroup 擁有多個 Tablet。這樣做的好處是允許將多個不連續 KeyRange 的數據放置在同一個 ReplicationGroup 中，以方便極細粒度的分區，並允許不連續 KeyRange 的數據進行單 ReplicationGroup 的局部事務處理。將 ReplicationGroup 的複製能力和 KeyRange 的切分解耦，即使 KeyRange 的切分非常多依然可以使 ReplicationGroup 的數量保持收斂。
- 與 Bytable1.0 中僅有一個 Master 不同，Bytable2.0 引入了 GlobalMaster 和 GroupMaster 兩個組件。GlobalMaster 負責記錄所有 Table 和 ReplicationGroup 的元信息。GroupMaster 不斷同步 GlobalMaster 管理的元信息，在本地冗餘保存，它只管理自己對應 Region 內 TabletServer 實例的探活與 Replica 分配，實現了 Region 內部的自治，去除了 Region 間網絡狀況對 Region 內部可用性的影響。
Bytable2.0 與 HBase 的主要不同之處有如下幾處：
- HBase 僅支持同步或異步的主從複製，讀取時僅保證集羣內一致不保證集羣間一致。而 Bytable 2.0 可以支持跨 Region 的 Quorum 數據複製，保證全球一致。
- HBase 中 Region 和 KeyRange 的映射關係是一一映射，因此如果希望細粒度的設置 KeyRange 的複製關係則會創建大量的小 Region，而這對 HBase 則是不友好的。而 Bytable 2.0 可以支持細粒度的 Tablet 數據複製關係設置。
Client 讀寫數據的時候會首先跟 GroupMaster 通信獲得要訪問數據對應表的 MetaTable 對應的 ReplicationGroup 各個 Replica 的位置信息，然後請求對應的 MetaTable 從中定位對應的 Tablet 所屬 ReplicationGroupId，然後根據其去 GroupMaster 查詢對應 ReplicationGroup 各個 Replica 的位置信息，最終根據此位置信息找到對應的 TabletServer 進行讀寫。
在單機房部署的場景下，上面的架構就顯得過於臃腫，因爲我們實現時模塊化做的足夠好，所以可以將 GlobalMaster, GroupMaster 和 PlacementDriver 三個模塊編譯到同一個 Master 二進制文件中，以降低部署和維護的複雜度，如下圖所示，部署時一個集羣中可以僅擁有 Master 和 TabletServer 兩種服務。
3.2.1 數據讀寫層 TabletServer
與 Bytable1.0 中 ReplicationGroup 與 Tablet 的一一對應關係不同， Bytable2.0 的一個 TabletServer 中包含若干 ReplicationGroup 的 Replica，每一個 ReplicationGroup 中包含了若干 Tablet。這樣的設計可以使 Tablet 的分裂與合併變得非常輕量，僅僅是修改元數據，不需要任何停頓。在這種設計下遷移不再是將一個 Tablet 從一個 TabletServer 遷往另外一個 TabletServer，而是從一個 ReplicationGroup 將這個 Tablet 的對應數據導入另外一個 ReplicationGroup，我們使用 SST 文件 Range 抽取的方式輕量地完成對應的工作。
在寫入的流程中 Leader Replica 首先通過 ByteJournal 寫入 WAL，當日志寫入成功後寫入 MemTable。Follower Replica 從 ByteJournal 中讀取 WAL 並寫入 MemTable。Leader Replica 定期進行 Checkpoint 和 Compaction 操作，將 SST 文件寫入 ByteStore 中。在 Leader Replica 和 Follower Replica 共享分佈式文件系統的時候，僅僅 Leader Replica 進行 Checkpoint 和 Compaction 操作。當 Leader Replica 和 Follower Replica 不共享分佈式文件系統時，則在每一個分佈式文件系統上都會選出一個 Compaction Leader 分別進行 Checkpoint 和 Compaction 操作。這樣我們就解決了之前多副本分別 Compaction 引入的額外 CPU 損耗，於此同時我們也可以擁有 Follwer Replica 解決了早期 HBase 版本存在的沒有主從冗餘的問題。
在讀取流程中，Leader Replica 和 Follower Replica 都從對應的 ByteStore 中將 SST 數據讀取出來與內存中的 MemTable 歸併最後返回給用戶，其中 Follwer Replica 可以指定版本進行讀取，也可以使用 ReadIndex 的方式從 Leader Replica 獲取最新的日誌號並等待其在本地 Apply 後進行讀取。
3.2.2 全局管理層 GlobalMaster
GlobalMaster 是整個集羣全局的管理模塊，負責對運維人員暴露操作接口，主要負責表和 ColumnFamily 的創建和刪除。其中存儲了所有表和 ColumnFamily 的元信息，同時保存了每個表包含的所有 ReplicationGroup 的元信息。GroupMaster 從 GlobalMaster 同步這些元信息，以便獲取需要其調度的 Replica，以便管理 ReplicationGroup 在對應 Region 內的副本放置。
3.2.3 計算調度層 GroupMaster
GroupMaster 是某個 Region 內的管理模塊，管理 Region 內多個 TabletServer 實例和各個 ReplicationGroup 在本 Region 內分配的 Replica。除了註冊到這個 GroupMaster 的多個 TabletServer 的心跳與保活的工作，它還要根據從 GlobalMaster 同步的元信息中得出需要其調度的 Replica 信息，在註冊到這個 GroupMaster 的多個 TabletServer 上進行調度，告知 TabletServer 打開或關閉對應的 Replica。
3.2.4 數據調度層 PlacementDriver
PlacementDriver 是進行數據調度的決策模塊，其會和 TabletServer 通信，收集各個 TabletServer 的負載信息並掃描各個表對應的 MetaTablet，進行負載均衡計算，最終進行決策需要是否需要對某些 Tablet 進行分裂、合併或遷移操作。
3.3 未來展望
3.3.1 離線 Compaction
Compaction 操作和流式的數據讀寫相比，其實是一個 Batch 類型的離線操作，而這個離線作業跑在在線服務中，往往會降低在線服務的有效資源利用率和 Qos。所以，我們計劃允許將這個 Compaction 過程的執行遞交給 Yarn 或其他離線作業運行平臺，以降低其對在線服務 CPU 的消耗。Aliyun X-Engine 團隊使用的 FPGA 的方案，將本機的 Compaction CPU 負載 Offload 給 FPGA，也是利用類似的方式。不過其對特定機型和硬件依賴較重，可以考慮利用 Yarn 調度平臺對 FPGA 資源進行調度的方式更加合理與充分對其資源進行利用。
3.3.2 分析型列存引擎
在 Spanner: Becoming a SQL system 的論文中提到，目前 Spanner 提供了一套塊內列存的分析型引擎，在部分場景下取得了不錯的效果。TiDB 也通過爲 Raft 掛一個 ClickHouse (Yandex 開源的分析型數據) 從節點的方式提供了分析型查詢的解決方案。Bytable2.0 也有一些分析型的使用場景，我們計劃將來提供一套分析型列存的引擎，逐步發展爲一個 HTAP 的系統。
3.3.3 多模數據庫
目前數據庫市場上擁有多種多樣的 API 接口，比如 Redis， MongoDB，MySQL 等。與此同時，在開源市場中，圖數據庫 JanusGraph 、時序數據庫 OpenTSDB 、地理信息數據庫 GeoMesa、關係型數據庫 Phoenix 等數據庫底層都是基於 HBase 進行數據存儲的。這給我們帶來了一些啓示，Bytable2.0 將來也可以作爲通用的底層存儲服務，在上層實現各種各樣的 API 層，爲這些 API 的服務提供大容量低成本的解決方案。
3.3.4 新型分佈式事務機制探索
分佈式事務在業界的實現中，往往需要在吞吐和延時中進行權衡。在 Bytable 的分佈式事務解決方案中，使用了 Percolator 事務模型，其依賴了單點授時服務 TSO，在吞吐和延時之間做了一定權衡。在後續 Bytable2.0 的分佈式事務方案中，我們希望進一步優化 Bytable1.0 分佈式事務方案中 Percolator 模型的吞吐問題和跨 Region 延時問題，探索新的解決方案。
4. 總結
隨着字節跳動搜索和推薦場景的飛速發展和業務需求的不斷豐富，我們在前期快速的構建了第一代分佈式表格存儲系統 Bytable1.0，解決了大量的業務問題。但同時因爲一期系統的簡化和權衡，仍然存在一些需要優化的成本和擴展性等問題，我們在第二代類 Spanner 的表格存儲系統 Bytable2.0 中解決這些問題。歡迎感興趣的同學們加入表格存儲團隊打造極致的分佈式表格存儲解決方案，一起構建字節跳動堅實的基礎設施，爲公司的高速發展的保駕護航。
5. 參考文獻
[1] Chang, Fay, et al. “Bigtable: A distributed storage system for structured data.” ACM Transactions on Computer Systems (TOCS) 26.2 (2008): 1-26.
[2] Apache HBase: An open-source, distributed, versioned, column-oriented store modeled after Google’ Bigtable.
[3] TiDB: An open source distributed HTAP database compatible with the MySQL protocol.
[4] Taft, Rebecca, et al. “CockroachDB: The Resilient Geo-Distributed SQL Database.” Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. 2020.
[5] Dong, Siying, et al. “Optimizing Space Amplification in RocksDB.” CIDR. Vol. 3. 2017.
[6] Corbett, James C., et al. “Spanner: Google’s globally distributed database.” ACM Transactions on Computer Systems (TOCS) 31.3 (2013): 1-22.
[7] Bacon, David F., et al. “Spanner: Becoming a SQL system.” Proceedings of the 2017 ACM International Conference on Management of Data. 2017.
[8] Huang, Gui, et al. “X-Engine: An optimized storage engine for large-scale E-commerce transaction processing.” Proceedings of the 2019 International Conference on Management of Data. 2019.
本文轉載自公衆號字節跳動技術團隊（ID：toutiaotechblog）。
原文鏈接：