MongoDB 在評論中台的實踐

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

一、業務背景

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

具體如下圖所示:

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

 

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

 

二、資料庫存儲的選擇

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

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

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

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

三、深入了解 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的遷移,同樣會導致集群可用性降低,因此只能在業務低峰進行

四、寫在最後

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

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

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

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

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