MongoDB 在評論中臺的實踐

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

1、業務背景

隨着公司業務發展和用戶規模的增多，不少項目都在打造本身的評論功能，而評論的業務形態基本相似。當時各項目都是各自設計實現，存在較多重複的工做量；而且不一樣業務之間數據存在孤島，很難產生聯繫。所以咱們決定打造一款公司級的評論業務中臺，爲各業務方提供評論業務的快速接入能力。在通過對各大主流 APP 評論業務的競品分析，咱們發現大部分評論的業務形態都具有評論、回覆、二次回覆、點贊等功能。

具體以下圖所示：

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

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

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

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

2、數據庫存儲的選擇

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

因爲評論業務的特殊性，它須要以下能力：

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

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

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

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

3、深刻了解 MongoDB

3.1 集羣架構

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

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

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

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

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

3.2  片鍵

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

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

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

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

3.3 評論中臺的實踐

3.3.1 集羣的擴展

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

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

• 集羣調優(如split遷移時間)很難業務特性差別化設置。

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

所以咱們擴展了 MongoDB的集羣架構：

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

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

3. 不一樣的MongoDB分片集羣，實現了物理隔離和差別調優的可能。

3.3.2 片鍵的選擇

MongoDB集羣中，一個集合的數據部署是分散在多個shard分片和chunk中的，而咱們但願一個評論列表的查詢最好只訪問到一個shard分片，所以肯定了 範圍分片 的方式。

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

• jumbo chunk問題

• 惟一鍵問題

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的限制，也解決了惟一性問題。

3.4 遷移和擴容

隨着數據的寫入，當單個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的遷移，一樣會致使集羣可用性下降，所以只能在業務低峯進行

4、寫在最後

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

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

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

參考資料：https://docs.mongodb.com/manual/introduction/

做者：vivo 官網商城開發團隊