爲什麼我們要在評論系統中用 MongoDB？

本文主要講述 vivo 評論中臺在數據庫設計上的技術探索和實踐。

業務背景

隨着公司業務發展和用戶規模的增多，很多項目都在打造自己的評論功能，而評論的業務形態基本類似。當時各項目都是各自設計實現，存在較多重複的工作量；並且不同業務之間數據存在孤島，很難產生聯繫。

因此我們決定打造一款公司級的評論業務中臺，爲各業務方提供評論業務的快速接入能力。在經過對各大主流 APP 評論業務的競品分析，我們發現大部分評論的業務形態都具備評論、回覆、二次回覆、點贊等功能。

具體如下圖所示：

涉及到的核心業務概念有：

• 【主題 topic】評論的主題，商城的商品、應用商店的 APP、社區的帖子

• 【評論 comment】用戶針對於主題發表的內容

• 【回覆 reply】用戶針對於某條評論發表的內容，包括一級回覆和二級回覆

數據庫存儲的選擇

團隊在數據庫選型設計時，對比了多種主流的數據庫，最終在 MySQL 和 MongoDB 兩種存儲之進行抉擇。

cMmuCj

由於評論業務的特殊性，它需要如下能力：

• 【字段擴展】業務方不同評論模型存儲的字段有一定差異，需要支持動態的自動擴展。

• 【海量數據】作爲公司中臺服務，數據量隨着業務方的增多成倍增長，需要具備快速便捷的水平擴展和遷移能力。

• 【高可用】作爲中颱產品，需要提供快速和穩定的讀寫能力，能夠讀寫分離和自動恢復。

而評論業務不涉及用戶資產，對事務的要求性不高。因此我們選用了MongoDB 集羣作爲最底層的數據存儲方式。

深入瞭解 MongoDB

集羣架構

由於單臺機器存在磁盤 /IO/CPU 等各方面的瓶頸，因此以 MongoDB 提供集羣方式的部署架構，如圖所示:

主要由以下三個部分組成：

• mongos：路由服務器，負責管理應用端的具體鏈接。應用端請求到 mongos 服務後，mongos 把具體的讀寫請求轉發到對應的 shard 節點上執行。一個集羣可以有 1~N 個 mongos 節點。

• config：配置服務器，用於分存儲分片集合的元數據和配置信息，必須爲 複製集方式部署。mongos 通過 config 配置服務器合的元數據信息。

• shard：用於存儲集合的分片數據的 mongod 服務，同樣必須以 複製集 方式部署。

片鍵

MongoDB 數據是存在 collection（對應 MySQL 表）中。集羣模式下，collection 按照片鍵（shard key）拆分成多個區間，每個區間組成一個 chunk，按照規則分佈在不同的 shard 中。並形成元數據註冊到 config 服務中管理。

分片鍵只能在分片集合創建時指定，指定後不能修改。分片鍵主要有兩大類型：

• hash 分片：通過 hash 算法進行散列，數據分佈的更加平均和分散。支持單列和多列 hash。

• 範圍分片：按照指定片鍵的值分佈，連續的 key 往往分佈在連續的區間，更加適用範圍查詢場景。單數據散列性由分片鍵本身保證。

評論中臺的實踐

1、集羣的擴展

作爲中颱服務，對於不同的接入業務方，通過表隔離來區分數據。以 comment 評論表舉例，每個接入業務方都單獨創建一張表，業務方 A 表爲 comment_clientA，業務方 B 表爲 comment_clientB，均在接入時創建表和相應索引信息。但只是這樣設計存在幾個問題：

• 單個集羣，不能滿足部分業務數據物理隔離的需要。

• 集羣調優（如 split 遷移時間）很難業務特性差異化設置。

• 水平擴容帶來的單個業務方數據過於分散問題。

因此我們擴展了 MongoDB 的集羣架構：

擴展後的評論 MongoDB 集羣增加了【邏輯集羣】和【物理集羣】的概念。一個業務方屬於一個邏輯集羣，一個物理集羣包含多個邏輯集羣。

增加了路由層設計，由應用負責擴展 Spring 的 MongoTemplate 和連接池管理，實現了業務到 MongoDB 集羣之間的切換選擇服務。

不同的 MongoDB 分片集羣，實現了物理隔離和差異調優的可能。

2、片鍵的選擇

MongoDB 集羣中，一個集合的數據部署是分散在多個 shard 分片和 chunk 中的，而我們希望一個評論列表的查詢最好只訪問到一個 shard 分片，因此確定了範圍分片的方式。

起初設置只使用單個 key 作爲分片鍵，以 comment 評論表舉例，主要字段有 {"_id": 唯一 id,"topicId": 主題 id,"text": 文本內容,"createDate": 時間}，考慮到一個主題 id 的評論儘可能連續分佈，我們設置的分片鍵爲 topicId。隨着性能測試的介入，我們發現了有兩個非常致命的問題：

jumbo chunk 問題：

官方文檔中，MongoDB 中的 chunk 大小被限制在了 1M-1024M。分片鍵的值是 chunk 劃分的唯一依據，在數據量持續寫入超過 chunk size 設定值時，MongoDB 集羣就會自動的進行分裂或遷移。而對於同一個片鍵的寫入是屬於一個 chunk，無法被分裂，就會造成 jumbo chunk 問題。

舉例，若我們設置 1024M 爲一個 chunk 的大小，單個 document 5KB 計算，那麼單個 chunk 能夠存儲 21W 左右 document。考慮熱點的主題評論（如微信評論），評論數可能達到 40W+，因此單個 chunk 很容易超過 1024M。超過最大 size 的 chunk 依然能夠提供讀寫服務，只是不會再進行分裂和遷移，長久以往會造成集羣之間數據的不平衡。

唯一鍵問題：

MongoDB 集羣的唯一鍵設置增加了限制，必須是包含分片鍵的；如果 _id 不是分片鍵，_id 索引只能保證單個 shard 上的唯一性。

• You cannot specify a unique constraint on a hashed index

• For a to-be-sharded collection, you cannot shard the collection if the collection has other unique indexes

• For an already-sharded collection, you cannot create unique indexes on other fields

因此我們刪除了數據和集合，調整 topicId 和 _id 爲聯合分片鍵，重新創建了集合。這樣即打破了 chunk size 的限制，也解決了唯一性問題。

遷移和擴容

隨着數據的寫入，當單個 chunk 中數據大小超過指定大小時（或 chunk 中的文件數量超過指定值）。MongoDB 集羣會在插入或更新時，自動觸發 chunk 的拆分。

拆分會導致集合中的數據塊分佈不均勻，在這種情況下，MongoDB balancer 組件會觸發集羣之間的數據塊遷移。balancer 組件是一個管理數據遷移的後臺進程，如果各個 shard 分片之間的 chunk 數差異超過閾值，balancer 會進行自動的數據遷移。

balancer 是可以在線對數據遷移的，但是遷移的過程中對於集羣的負載會有較大影響。一般建議可以通過如下設置，在業務低峯時進行：

db.settings.update(
{ _id: "balancer" },
{ $set: { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } },
{ upsert: true }
)

MongoDB 的擴容也非常簡單，只需要準備好新的 shard 複製集後，在 Mongos 節點中執行：

sh.addShard("<replica_set>/<hostname><:port>")

擴容期間因爲 chunk 的遷移，同樣會導致集羣可用性降低，因此只能在業務低峯進行。

寫在最後

MongoDB 集羣在評論中臺項目中已上線運行了一年多，過程中完成了約 10 個業務方接入，承載了 1 億 + 評論回覆數據的存儲，表現較爲穩定。BSON 非結構化的數據，也支撐了我們多個版本業務的快速升級。而熱門數據內存化存儲引擎，較大的提高了數據讀取的效率。

但對於 MongoDB 來說，集羣化部署是一個不可逆的過程，集羣化後也帶來了索引，分片策略等較多的限制。因此一般業務在使用 MongoDB 時，副本集方式就能支撐 TB 級別的存儲和查詢，並非一定需要使用集羣化方式。

以上內容基於 MongoDB 4.0.9 版本特性，和最新版本的 MongoDB 細節上略有差異。

本文源自公衆號 vivo 互聯網技術，分佈式實驗室已獲完整授權。

分佈式實驗室 關注分佈式相關的開源項目和基礎架構，致力於分析並報道這些新技術是如何以及將會怎樣影響企業的軟件構建方式。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/wQ0BS-GRZ_UBpRDt4Zni-g