OceanBase

微博數據庫技術負責人楊尚剛將從技術選型、方案設計到落地實踐等維度，深度解析這場關乎億級用戶體驗的數據庫進化之路。

作者：楊尚剛，微博數據庫技術負責人

編者按： 作為中國最具影響力的社交媒體平臺之一，微博（舊稱新浪微博，股票代碼：09898）自2009年上線以來已發展成為集內容發布、社交互動、熱點傳播于一體的綜合性社交網絡。據公開數據顯示，2024年微博月活躍用戶規模突破5.83億。

面對龐大的用戶體量和日益復雜的業務場景，微博數據庫平臺面臨關鍵挑戰：如何在保障海量數據處理能力的同時，實現系統穩定性與成本效益的平衡。經過嚴謹的技術評估，團隊最終完成了核心數據庫系統的戰略升級。在本文中，微博數據庫技術負責人楊尚剛將從技術選型、方案設計到落地實踐等維度，深度解析這場關乎億級用戶體驗的數據庫進化之路。

微博數據庫平臺架構及現狀

微博的數據庫平臺主要分為三部分：常見的主流關系型數據庫、 NoSQL 數據庫托管，完整的 OLTP 和 OLAP 解決方案支撐，推動公司數據庫技術創新實踐和落地。

其中，數據庫實例規模總計數萬個，NoSQL 數據庫以 Redis 為主，每天的訪問量在萬億級別，十億級訪問峰值。自2011年開始，我們大量使用 Redis ，并基于 Redis 研發了多個內部分支，持久化存儲數據規模達 PB 級。

下圖為微博的數據庫架構圖：資源層包含早期的自建物理機、私有云和用于解決資源彈性擴縮容問題的公有云；調度層負責資源的管理和調度，包括內部自研的資源調度平臺和開源的 Kubernetes；服務層主要是關系型數據庫，包含MySQL、PostgreSQL、ClickHouse、Milvus、OceanBase、 MongoDB 等。當前產品種類繁多、導致平臺管理成本比較高，穩定性和易用性也存在問題。

由于近幾年經濟狀況較差，人力成本越來越高，而業務的正常發展、存儲資源的持續增長，以及架構升級，都需要更多的人力支撐，因此，為降本增效，我們需要更加簡單高效、低成本的技術架構。

架構升級，優先解決MySQL痛點

在成本控制和精細化風險把控的背景下，需要用有限的服務器資源支撐業務的平穩增長，并實現資源利用最大化和高效交付。 在關系型數據庫的應用中，MySQL使用范圍較廣，且存在的問題較為突出，所以在此次架構升級中，我們優先解決MySQL的應用痛點，比如：

• 長尾數據多。像微博評論這樣的數據每天都在大規模增長，且需要長期保存，導致長尾數據非常多，占用存儲空間。
• 分庫分表的不可持續性。當數據庫實例所需規格超過機器規格就需要擴容，通常我們只能考慮分庫分表方案，短暫滿足了業務要求，但帶來了更高的管理成本和業務成本。
• 高可用數據安全問題。 MySQL主要通過異步復制來同步數據，雖然也支持半同步，但會帶來一定的性能損耗。MySQL 5.7 支持的 MGR 集群方案相對完善，運維成本卻相對高。當進行主從切換后，存在數據一致性的風險。
• 存儲成本高。 MySQL 部署主要是一主兩從架構，相當于雙重備份。如下圖所示，從2013年到2020年，機械盤和 SSD 盤的成本越來越接近，機械盤在存儲成本的優勢沒有太大變化。

針對 MySQL 的痛點問題，我們計劃從如下幾個方面進行優化。

1.優化存儲成本，不同場景使用不用存儲模式。

2016年，為了解決延遲和性能問題，我們把數據從機械硬盤遷移到 QLC SSD。然而，隨著業務場景的變化，QLC SSD 的成本優勢并不明顯，某些情況下使用機械硬盤可能是一個更優的選擇，但在某些場景下，使用 QLC SSD 成本僅能降低約10%~20%，相比之下，機械硬盤由于其較高的單機存儲密度，成本降低幅度可能更大，因此需要針對不同的業務場景使用不同的存儲模式。

2.長尾數據歸檔到 S3。

我們計劃將長尾數據歸檔到 S3，且正在調研適合的方案。已知MariaDB 插件支持 S3 存儲，其本質是通過底層 S3 實現數據同步，而非傳統意義上的集群數據同步。這種方案可顯著降低存儲成本，甚至可能低于使用硬盤的成本。但需要注意的是，該方案對業務場景有一定要求，例如對于數據更新頻繁的表，可能會受到限制，更適合存儲很少更新或基本不更新的數據。此外，OceanBase 也支持 S3 方案，其方案可行性正在調研中。

3.通過壓縮軟件、硬件降低成本。

軟件壓縮和硬件壓縮技術也是我們整體測試的方面。MySQL 從5.5版本開始支持壓縮，到5.7和8.0版本引入了新的壓縮方式。不過MySQL自帶的 壓縮的性能損耗較大，例如使用 MySQL 壓縮可以節省約40%的存儲空間，但性能可能會下降約66%。由于我們了解到OceanBase具備較強的降本能力，因此，我們后續考慮通過OceanBase來降低硬件成本與存儲成本，同時減少性能損耗。

4.資源池化以實現彈性擴展。

資源池化是解決彈性擴展能力的重要方向，但其實現需要較強的研發實力。我們暫不具備實施資源池化的條件，但可以參考業界的先進方案，如 AWS 或 PolarDB，再或者引入OceanBase時利用其資源池化能力。資源池化的主要目標是解決 MySQL 擴展困難的問題，尤其是數據存儲和擴容的難點。

通過多方面的優化措施，我們希望能夠有效解決 MySQL 的痛點問題，提升系統性能和成本效益。而在調研數據庫方案時，發現OceanBase比較符合我們的預期，便在業務中進行嘗試。

分區表替代分庫分表，又穩又省

OceanBase 是一款完全自主研發的原生分布式數據庫，支持平滑擴展與彈性擴縮容、高度兼容 MySQL，能夠平滑、快速、小成本搬遷應用與數據，且具備高可用（RPO=0，RTO小于8s）能力，還有非常活躍的開源社區，因此我們開始嘗試在某些場景引入 OceanBase。

舉個例子，某個系統此前面臨分庫分表拆分復雜、數據不一致、多實例導致的機器資源浪費、運維成本高等問題。我們嘗試將該系統的數據庫替換為 OceanBase，前期測試和部署過程都比較順利，解決了該系統使用 MySQL 時問題。

采用 OceanBase 后，主要收益如下：

1. 我們摒棄了原有的 MySQL 分庫分表策略，轉而使用 OceanBase 分區表。從業務層面來看，相當于一張大表，從而簡化了業務讀寫邏輯，完全解決了數據一致性問題。
2. OceanBase 底層存儲使用通用壓縮和數據編碼壓縮，數據壓縮比高于 MySQL，且性能不受影響。在系統遷移到 OceanBase 后，存儲占用從 50TB 下降到 27TB，成本節省46%。
3. 系統已穩定運行半年多，證明了 OceanBase 的強穩定性。
4. OceanBase 分布式數據庫天然具備高可用能力，集群部署完成后，不需要額外花大量工作維護數據的多副本，少數節點出現故障不影響業務使用；無需像 MySQL 那樣引入額外的組件來保證集群切換，進一步降低了運維復雜性和 DBA 運維成本。

選對技術策略，降本增效

在引入 OceanBase 的過程中，我們收獲了很多實踐經驗，供大家做參考。

實踐1：分區表設計

分區表是數據庫設計中常見的優化手段，尤其在處理大規模數據時。對于MySQL用戶來說，分區表的設計和使用已有諸多規范、文檔供閱讀。然而，MySQL早期版本的分區表存在一些問題，因此在實際應用中，通常建議使用分表而非分區表。MySQL 單表通常為N千萬行，大于此數量需要分庫分表。

OceanBase 分區表設計理念與 MySQL 有顯著區別，主要通過分區表設計來實現大規模數據的高效管理，不存在單表數據量上限，對于大數據量表建議使用分區表，且單個分區表可以控制在100GB以下（對應MySQL 600GB~800GB）。同時，分區數量建議在服務器臺數的2-3倍，以及 CPU邏輯核數的2倍范圍之間，以確保數據分布均衡，避免因分區過少導致的數據不均衡問題。

OceanBase支持一級分區和二級分區。一級分區是常見的分區方式，包括 HASH、KEY、LIST、RANGE、RANGE COLOMNS、LISTCOLOMNS 等常用的分區類型，具體選擇需根據業務場景和數據特點確定。例如，如果數據具有時間維度特征，范圍分區可能更為合適；如果數據需要根據特定值進行分區，列表分區可能是更好的選擇。

二級分區相當于在一級分區的基礎上，又從第二個維度進行了拆分。如果在設計初期選擇了一級分區，后續需要擴展分區，直接修改分區鍵可能較為困難，此時可以通過引入二級分區來解決這一問題。二級分區的設計需要謹慎考慮，以確保分區的合理性和擴展性。

創建分區的目的是在特定的SQL操作中減少數據讀寫的總量，以減少響應時間，同時提升了可擴展性能力、可管理性、提高性能等能力。

分區表設計的主要目的是優化數據量和響應時間，降低系統負擔。通過合理分區，可以有效控制并發度，確保數據規模和性能的平衡。在設計分區表時，還需要注意以下幾點。

1. 分區鍵選擇。分區鍵應根據業務形態（熱點數據打散、歷史數據維護便利性、業務SQL的條件形態、分區裁剪）謹慎選擇，盡量將數據均勻分布，避免數據熱點問題。
2. 分區類型選擇。根據業務需求選擇合適的分區類型，如哈希分區、范圍分區或列表分區。
3. 分區鍵與主鍵的關系。在 OceanBase 中，分區鍵必須是主鍵的子集，即主鍵中必須包含分區鍵。
4. Range分區。考慮是否使用maxvalue，如果使用了maxvalue，后續會沒辦法再添加分區。
5. 寫放大問題。為了避免寫入放大問題，選擇表的自定義主鍵時，不要使用隨機生成的值，盡量有序，比如時序遞增等。
6. 考慮分區裁剪優化。 分區表設計是數據庫優化的重要環節，尤其在處理大規模數據時。OceanBase 的分區表設計比較靈活性，在實際應用中，需要根據業務需求和數據特點選擇合適的分區策略，優化系統性能和數據管理效率。

實踐2：統計信息收集

統計信息收集是數據庫 SQL 優化的重要組成部分，尤其是在處理慢查詢時比較依賴統計信息。無論是MySQL 還是 OceanBase，其查詢優化器的執行路徑都依賴于統計信息的準確性。當表的數量較多時，統計信息的收集成本較高，耗時也較長。統計信息中，直方圖是較為重要的一部分，直方圖收集涉及復雜的計算，帶來額外成本的耗時。大分區表默認收集二級分區、一級分區、全表的統計信息和直方圖，代價為：3 * {cost(全表掃)+cost(直方圖)}。

統計信息收集需要注意五個方面。

其一，設置合適的默認收集并行度。

• 統計信息收集的并發度需要控制，因為其對機器性能有一定影響。建議在業務低峰期（如凌晨）進行收集，以減少對業務的影響。
• 建議并行度控制 8 個以內，業務可控的情況下，可以調大并發通過犧牲資源保證了統計信息的收集效率
• 業務租戶執行：

SQL>call dbms_stats.set_table_prefs('database_name', 'table_name', 'degree', '8’);

其二，配置采樣比例。

配置塊采樣，可以通過塊采樣的方式減少統計信息收集時要處理的數據量，也達到到快速收集的效果。但會犧牲一定的統計信息的準確性。可使用如下方式設置。

配置開啟塊采樣：

SQL>call dbms_stats.set_table_prefs('databse_name','table_name','block_sample','True');

配置采樣比例，可根據表的數量級進行配置，通常情況下，采集千萬級的數據即可充分反應一個表的數據特征：

SQL> call dbms_stats.set_table_prefs('databse_name','table_name','estimate_percent','0.1');

其三，設置默認列的直方圖收集方式，考慮給數據分布均勻的列設置不收集直方圖。

如果該表所有列的數據分布都是均勻的，可以使用如下方式設置所有列都不收集直方圖

SQL>call dbms_stats.set_table_prefs('database_name', 'table_name', 'method_opt', 'for all columns size 1');

如果該表僅極少數列數據分布不均勻，需要收集直方圖，其他列都不需要，則可以使用如下方式設置(c1,c2收集直方圖，c3不收集直方圖)：

SQL>call dbms_stats.set_table_prefs('database_name', 'table_name', 'method_opt', 'for columns c1 size 254, c2 size 254, c3 size 1);

跳過大對象字段，如果列中保存的都是大對象，可能會導致收集特別慢，因此，收集除大對象外的所有列：

SQL>call dbms_stats.set_table_prefs('databse_name','table_name','method_opt','for columns col1,col2,col3,... size auto');

其四，不同場景收集統計信息的方式。

慎用設置大表采樣的方式收集統計信息，設置大表采樣收集時，直方圖的樣本數量也會變得很大，存在適得其反的效果，設置采樣的方式收集統計信息僅適合只收集基礎統計信息，不收集直方圖的場景。業務租戶執行如下。 設置所有列都不收集直方圖：

call dbms_stats.set_table_prefs('database_name', 'table_name', 'method_opt', 'for all columns size 1');

設置采樣比例為10%：

call dbms_stats.set_table_prefs('database_name', 'table_name', 'estimate_percent', '10');

其五，鎖定統計信息。

考慮能否手動收集大表統計信息后，鎖定相關的統計信息。需要注意的是當表的統計信息鎖定后，自動收集將不會更新，適用于一些對數據特征變化不太大、數據值不敏感的場景，如果需要重新收集鎖定的統計信息，需要先將其解鎖。

鎖定表的統計信息：

call dbms_stats.lock_table_stats('database_name', 'table_name');

解鎖表的統計信息：

call dbms_stats.unlock_table_stats('database_name', 'table_name');

統計信息收集需要綜合考慮并發度、采樣比例、收集方式以及表的使用場景等因素，以確保優化器能夠基于準確的統計信息生成高效的查詢計劃，同時避免對系統性能造成過大影響。

在KV場景、向量場景進一步探索OceanBase

由于 OceanBase 在已上線的業務中表現優秀，因此，我們計劃在其他業務場景中繼續進行嘗試和探索。目前，我們的業務數據量較大，但讀寫量相對較低。未來，我們將嘗試應用于讀寫量更大、對耗時更為敏感的業務場景，以進一步驗證 OceanBase 的性能和適用性。

場景1：KV 存儲優化

除了 TP 場景，微博內部的 KV 場景也面臨一些挑戰。以 Pika 為例，目前存在4個問題。

1. 混部影響 Pika 穩定性：Pika 與 MySQL 混布，且 Pika 實例較多。如果調度不均衡，可能導致單機 Pika 實例過多，進而影響其穩定性，尤其是在遇到熱點數據或機器負載不均衡時。
2. 長尾數據：與 MySQL 類似，Pika 作為基于磁盤的 KV 存儲，部分 Pika 實例存在長尾數據問題。這些數據需要長期存儲，但又不能清理，給存儲管理帶來較大壓力。
3. 擴展性問題：Pika 本質上是單機數據庫，其數據規模和擴展性面臨挑戰，與 MySQL 類似，單機擴展性是當前較為棘手的問題之一。
4. 成本優化：成本主要分為兩部分，一是 Redis 遷移到 Pika 等的遷移成本，二是引入新的平臺 ARM 平臺帶來的成本。

優化措施分為以下兩個維度。一是優化擴展性優化， 針對 Pika 的擴展性問題，我們調研了相關方案，目前考慮通過 Proxy + Pika 的方式進行管理；二是適配ARM 架構， 我們已對 Pika、Redis 服務及 Memcached 進行了 ARM 架構適配。從測試結果來看，ARM 架構在單實例性能上較同配置的x86架構有顯著提升，且成本更低。但適配過程存在一定成本，尤其是在ARM架構上，編譯指令和JCC（Just-In-Time Compiler）支持等方面與 x86 架構有所不同。此外，MySQL 后續也可能進行 ARM 架構適配，但其適配難度可能較 Redis 更大，因為MySQL 代碼復雜度更高。

場景2：向量數據庫痛點

近年來，向量數據庫發展迅速，種類繁多，如主流的 Milvus、Redis、Elasticsearch、PG Vector、OceanBase 等，均支持向量索引和標量索引，功能較為全面。 目前，微博線上主要使用 Milvus 和 Elasticsearch，但使用成本、存儲成本、學習成本，以及管理復雜度都比較高，在處理高維向量數據時也存在性能和擴展的瓶頸。 基于微博向量數據庫的應用現狀，我們將評估當前技術架構、細化業務應用場景，并探索OceanBase 向量能力在內部業務場景的落地應用。

首先，細化業務應用場景。未來，線上業務可能會繼續沿用目前的多種數據庫，包括 MySQL、Elasticsearch 、 OceanBase 等，我們將根據業務場景和數據規模進行細化選型，以優化成本和性能。

其次，評估磁盤索引升級 Milvus 版本持續升級與優化。對于當前使用的向量數據庫，需繼續升級以解決其成本和性能問題。

最后，測試 OceanBase 向量功能。 OceanBase在向量數據庫方面具有一定優勢，表現在：

• 索引種類豐富。支持向量索引、標量索引、半結構化索引（多值索引、空間索引）、全文索引等。
• 應用集成豐富。采用 SQL 訪問，復用 MySQL 生態各個語言的客戶端；提供 Python API、提供SDK, 類似Milvus SDK。
• 索引創建語法豐富。索引類型包括HNSW、IVFFlat、DiskANN(on processing)；距離算法包括L2、IP、COSINE、Jaccard( on processing)。
• 向量查詢豐富。支持 TOP N 排序的相似度計算；支持向量和標量混合查詢；
• 部署運維方便。功能集成在數據庫內核中，可以使用和 OceanBase 社區版相同的部署、運維、監控、數據遷移工具。

隨著 AI 技術的發展，數據庫將與 AI 結合更加深入，尤其是自然語言和SQL的結合如SQL 改寫方向。同時，AI Agent 也將成為我們在 OceanBase 向量能力的探索方向，例如數據庫助手、知識庫等。希望利用 AI 提高內部人員的工作便捷性，降低運維復雜度，提高工作效率。

其他場景

除KV場景和向量場景計劃探索OceanBase外，我們在OceanBase應用過程中還將執行以下5個計劃。

1. OCP平臺和自建運維管理平臺融合。

我們將推進OCP平臺與自建運營管理平臺的整合。如果要大規模使用OceanBase，必須將其與現有的數據庫管理平臺進行有效整合，從而降低使用成本并提高管理效率。

2. 資源隔離。

目前，我們的資源調度方式包括Kubernetes（K8s）和自研調度系統，在實現CPU和內存資源隔離方面存在一定的局限性。OceanBase的多租戶架構可以更好地實現資源隔離。

3. 數據遷移自動化。

數據遷移是將MySQL或其他數據庫遷移到OceanBase的關鍵環節。目前，數據遷移和校驗工作尚未完全自動化，仍需逐步完善。我們將致力于提高數據遷移的自動化程度，確保遷移過程的高效性和數據的準確性。

4. 集群性能調優。

隨著OceanBase在微博的應用范圍擴大，集群規模也越來越大，性能調優將成為一項持續性的工作。我們將根據實際使用情況，逐步積累經驗，優化集群性能，以滿足業務需求。

5. 多可用區容災。

容災能力是后續需要重點建設的領域。隨著云服務和自建虛擬化環境的普及，MySQL或其他數據庫的部署規模和密度不斷增加，對容災和大規模故障處理能力的需求也日益迫切。未來，我們計劃將OceanBase集群部署在多個數據中心，以提高容災能力。雖然這種部署方式可能會因網絡問題對性能產生一定影響，但我們將逐步評估和優化，以確保系統的高可用性和穩定性。

總結

經過本次數據庫架構的成功升級，我們持續探索更優的架構和更便捷的開發、運維方式。OceanBase 作為一款日益流行的數據庫產品，在微博的應用場景中具有廣闊前景，我們將積極探索更多降本增效策略，以應對未來挑戰。在此過程中，我們將堅持兩個原則：

• One size does not fit all。對于互聯網企業而言，數據庫選型至關重要，需綜合考慮技術穩定性、人員技能、運營體系和業務場景等因素。
• 適合自己的才是最好的。我們將保持開放思維，持續關注 OceanBase 的發展，爭取應用更多和我們業務場景適配的產品能力，助力業務發展。

最后為大家推薦這個 OceanBase 開源負責人老紀的公眾號「老紀的技術嘮嗑局」，會持續更新和 #數據庫、#AI、#技術架構 相關的各種技術內容。歡迎感興趣的朋友們關注！

「老紀的技術嘮嗑局」不僅希望能持續給大家帶來有價值的技術分享，也希望能和大家一起為開源社區貢獻一份力量。如果你對 OceanBase 開源社區認可，點亮一顆小星星?吧！你的每一個Star，都是我們努力的動力。