MongoDB 在評論中臺的實踐

vivo網際網路技術發表於2021-03-01
MongoDB

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

一、業務背景

隨著公司業務發展和使用者規模的增多，很多專案都在打造自己的評論功能，而評論的業務形態基本類似。當時各專案都是各自設計實現，存在較多重複的工作量；並且不同業務之間資料存在孤島，很難產生聯絡。因此我們決定打造一款公司級的評論業務中臺，為各業務方提供評論業務的快速接入能力。在經過對各大主流 APP 評論業務的競品分析，我們發現大部分評論的業務形態都具備評論、回覆、二次回覆、點贊等功能。

具體如下圖所示：

MongoDB 在評論中臺的實踐

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

 

  • 【主題 topic】評論的主題，商城的商品、應用商店的 APP、社群的帖子
  • 【評論 comment】使用者針對於主題發表的內容
  • 【回覆 reply】使用者針對於某條評論發表的內容，包括一級回覆和二級回覆

 

二、資料庫儲存的選擇

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

MongoDB 在評論中臺的實踐

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

  • 【欄位擴充套件】業務方不同評論模型儲存的欄位有一定差異，需要支援動態的自動擴充套件。
  • 【海量資料】作為公司中臺服務，資料量隨著業務方的增多成倍增長，需要具備快速便捷的水平擴充套件和遷移能力。
  • 【高可用】作為中颱產品，需要提供快速和穩定的讀寫能力，能夠讀寫分離和自動恢復。

而評論業務不涉及使用者資產，對事務的要求性不高。因此我們選用了 MongoDB 叢集 作為最底層的資料儲存方式。

三、深入瞭解 MongoDB

3.1 叢集架構

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

MongoDB 在評論中臺的實踐

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

  • mongos：路由伺服器，負責管理應用端的具體連結。應用端請求到mongos服務後，mongos把具體的讀寫請求轉發到對應的shard節點上執行。一個叢集可以有1~N個mongos節點。
  • config：配置伺服器，用於分儲存分片集合的後設資料和配置資訊，必須為 複製集(關於複製集概念戳我) 方式部署。mongos通過config配置伺服器合的後設資料資訊。
  • shard：用於儲存集合的分片資料的mongod服務，同樣必須以 複製集 方式部署。

3.2  片鍵

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

MongoDB 在評論中臺的實踐

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

  • hash分片：通過hash演算法進行雜湊，資料分佈的更加平均和分散。支援單列和多列hash。
  • 範圍分片：按照指定片鍵的值分佈，連續的key往往分佈在連續的區間，更加適用範圍查詢場景。單資料雜湊性由分片鍵本身保證。

3.3 評論中臺的實踐

3.3.1 叢集的擴充套件

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

  • 單個叢集，不能滿足部分業務資料物理隔離的需要。
  • 叢集調優(如split遷移時間)很難業務特性差異化設定。
  • 水平擴容帶來的單個業務方資料過於分散問題。

因此我們擴充套件了 MongoDB的叢集架構：

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 在評論中臺的實踐

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

MongoDB 在評論中臺的實踐

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細節上略有差異。

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

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

相關文章