MongoDB?在評論中臺的實踐
[導讀]本文主要講述vivo評論中臺在數(shù)據庫設計上的技術探索和實踐。一、業(yè)務背景隨著公司業(yè)務發(fā)展和用戶規(guī)模的增多，很多項目都在打造自己的評論功能，而評論的業(yè)務形態(tài)基本類似。當時各項目都是各自設計實現(xiàn)，存在較多重復的工作量；并且不同業(yè)務之間數(shù)據存在孤島，很難產生聯(lián)系。因此我們決定打造一款公...
本文主要講述 vivo 評論中臺在數(shù)據庫設計上的技術探索和實踐。
一、業(yè)務背景
隨著公司業(yè)務發(fā)展和用戶規(guī)模的增多，很多項目都在打造自己的評論功能，而評論的業(yè)務形態(tài)基本類似。當時各項目都是各自設計實現(xiàn)，存在較多重復的工作量；并且不同業(yè)務之間數(shù)據存在孤島，很難產生聯(lián)系。因此我們決定打造一款公司級的評論業(yè)務中臺，為各業(yè)務方提供評論業(yè)務的快速接入能力。在經過對各大主流 APP 評論業(yè)務的競品分析，我們發(fā)現(xiàn)大部分評論的業(yè)務形態(tài)都具備評論、回復、二次回復、點贊等功能。
具體如下圖所示：
涉及到的核心業(yè)務概念有：
二、數(shù)據庫存儲的選擇
團隊在數(shù)據庫選型設計時，對比了多種主流的數(shù)據庫，最終在? MySQL ?和? MongoDB ?兩種存儲之進行抉擇。
由于評論業(yè)務的特殊性，它需要如下能力：
而評論業(yè)務不涉及用戶資產，對事務的要求性不高。因此我們選用了?MongoDB 集群?作為最底層的數(shù)據存儲方式。
三、深入了解 MongoDB
3.1 集群架構
由于單臺機器存在磁盤/IO/CPU等各方面的瓶頸，因此以 MongoDB 提供集群方式的部署架構，如圖所示:
主要由以下三個部分組成：
3.2? 片鍵
MongoDB 數(shù)據是存在collection(對應 MySQL表)中。集群模式下，collection按照?片鍵（shard key）拆分成多個區(qū)間，每個區(qū)間組成一個chunk，按照規(guī)則分布在不同的shard中。并形成元數(shù)據注冊到config服務中管理。
分片鍵只能在分片集合創(chuàng)建時指定，指定后不能修改。分片鍵主要有兩大類型：
3.3 評論中臺的實踐
3.3.1?集群的擴展
作為中臺服務，對于不同的接入業(yè)務方，通過表隔離來區(qū)分數(shù)據。以comment評論表舉例，每個接入業(yè)務方都單獨創(chuàng)建一張表，業(yè)務方A表為? comment_clientA ，業(yè)務方B表為 comment_clientB，均在接入時創(chuàng)建表和相應索引信息。但只是這樣設計存在幾個問題：
因此我們擴展了 MongoDB的集群架構：
3.3.2?片鍵的選擇
MongoDB集群中，一個集合的數(shù)據部署是分散在多個shard分片和chunk中的，而我們希望一個評論列表的查詢最好只訪問到一個shard分片，因此確定了?范圍分片?的方式。
起初設置只使用單個key作為分片鍵，以comment評論表舉例，主要字段有{"_id":唯一id,"topicId":主題id,"text":文本內容,"createDate":時間} ,考慮到一個主題id的評論盡可能連續(xù)分布，我們設置的分片鍵為???topicId。隨著性能測試的介入，我們發(fā)現(xiàn)了有兩個非常致命的問題：
jumbo chunk：
官方文檔中，MongoDB中的chunk大小被限制在了1M-1024M。分片鍵的值是chunk劃分的唯一依據，在數(shù)據量持續(xù)寫入超過chunk size設定值時，MongoDB 集群就會自動的進行分裂或遷移。而對于同一個片鍵的寫入是屬于一個chunk，無法被分裂，就會造成? jumbo chunk 問題。
舉例，若我們設置1024M為一個chunk的大小，單個document 5KB計算，那么單個chunk能夠存儲21W左右document?？紤]熱點的主題評論(如微信評論)，評論數(shù)可能達到40W ，因此單個chunk很容易超過1024M。超過最大size的chunk依然能夠提供讀寫服務，只是不會再進行分裂和遷移，長久以往會造成集群之間數(shù)據的不平衡.
唯一鍵問題：
MongoDB 集群的唯一鍵設置增加了限制，必須是包含分片鍵的；如果_id不是分片鍵，_id索引只能保證單個shard上的唯一性。
因此我們刪除了數(shù)據和集合，調整? ? topicId 和 _id 為聯(lián)合分片鍵 重新創(chuàng)建了集合。這樣即打破了chunk size的限制，也解決了唯一性問題。
3.4 遷移和擴容
隨著數(shù)據的寫入，當單個chunk中數(shù)據大小超過指定大小時(或chunk中的文件數(shù)量超過指定值)。MongoDB集群會在插入或更新時，自動觸發(fā)chunk的拆分。
拆分會導致集合中的數(shù)據塊分布不均勻，在這種情況下，MongoDB balancer組件會觸發(fā)集群之間的數(shù)據塊遷移。balancer組件是一個管理數(shù)據遷移的后臺進程，如果各個shard分片之間的chunk數(shù)差異超過閾值，balancer會進行自動的數(shù)據遷移。
balancer是可以在線對數(shù)據遷移的，但是遷移的過程中對于集群的負載會有較大影響。一般建議可以通過如下設置，在業(yè)務低峰時進行（更多見官網）
MongoDB的擴容也非常簡單，只需要準備好新的shard復制集后，在 Mongos節(jié)點中執(zhí)行：
擴容期間因為chunk的遷移，同樣會導致集群可用性降低，因此只能在業(yè)務低峰進行
四、寫在最后
MongoDB集群在評論中臺項目中已上線運行了一年多，過程中完成了約10個業(yè)務方接入，承載了1億 評論回復數(shù)據的存儲，表現(xiàn)較為穩(wěn)定。BSON非結構化的數(shù)據，也支撐了我們多個版本業(yè)務的快速升級。而熱門數(shù)據內存化存儲引擎，較大的提高了數(shù)據讀取的效率。
但對于MongoDB來說，集群化部署是一個不可逆的過程，集群化后也帶來了索引，分片策略等較多的限制。因此一般業(yè)務在使用MongoDB時，副本集方式就能支撐TB級別的存儲和查詢，并非一定需要使用集群化方式。
以上內容基于MongoDB 4.0.9版本特性，和最新版本的MongoDB細節(jié)上略有差異。
參考資料：https://docs.mongodb.com/manual/introduction/
一、業(yè)務背景
隨著公司業(yè)務發(fā)展和用戶規(guī)模的增多，很多項目都在打造自己的評論功能，而評論的業(yè)務形態(tài)基本類似。當時各項目都是各自設計實現(xiàn)，存在較多重復的工作量；并且不同業(yè)務之間數(shù)據存在孤島，很難產生聯(lián)系。因此我們決定打造一款公司級的評論業(yè)務中臺，為各業(yè)務方提供評論業(yè)務的快速接入能力。在經過對各大主流 APP 評論業(yè)務的競品分析，我們發(fā)現(xiàn)大部分評論的業(yè)務形態(tài)都具備評論、回復、二次回復、點贊等功能。
具體如下圖所示：
涉及到的核心業(yè)務概念有：
- 【主題 topic】評論的主題，商城的商品、應用商店的?APP、社區(qū)的帖子
- 【評論 comment】用戶針對于主題發(fā)表的內容
- 【回復 reply】用戶針對于某條評論發(fā)表的內容，包括一級回復和二級回復
二、數(shù)據庫存儲的選擇
團隊在數(shù)據庫選型設計時，對比了多種主流的數(shù)據庫，最終在? MySQL ?和? MongoDB ?兩種存儲之進行抉擇。
由于評論業(yè)務的特殊性，它需要如下能力：
- 【字段擴展】業(yè)務方不同評論模型存儲的字段有一定差異，需要支持動態(tài)的自動擴展。
- 【海量數(shù)據】作為公司中臺服務，數(shù)據量隨著業(yè)務方的增多成倍增長，需要具備快速便捷的水平擴展和遷移能力。
- 【高可用】作為中臺產品，需要提供快速和穩(wěn)定的讀寫能力，能夠讀寫分離和自動恢復。
而評論業(yè)務不涉及用戶資產，對事務的要求性不高。因此我們選用了?MongoDB 集群?作為最底層的數(shù)據存儲方式。
三、深入了解 MongoDB
3.1 集群架構
由于單臺機器存在磁盤/IO/CPU等各方面的瓶頸，因此以 MongoDB 提供集群方式的部署架構，如圖所示:
主要由以下三個部分組成：
- mongos：路由服務器，負責管理應用端的具體鏈接。應用端請求到mongos服務后，mongos把具體的讀寫請求轉發(fā)到對應的shard節(jié)點上執(zhí)行。一個集群可以有1~N個mongos節(jié)點。
- config：配置服務器，用于分存儲分片集合的元數(shù)據和配置信息，必須為 復制集(關于復制集概念戳我) 方式部署。mongos通過config配置服務器合的元數(shù)據信息。
- shard：用于存儲集合的分片數(shù)據的mongod服務，同樣必須以 復制集 方式部署。
3.2? 片鍵
MongoDB 數(shù)據是存在collection(對應 MySQL表)中。集群模式下，collection按照?片鍵（shard key）拆分成多個區(qū)間，每個區(qū)間組成一個chunk，按照規(guī)則分布在不同的shard中。并形成元數(shù)據注冊到config服務中管理。
分片鍵只能在分片集合創(chuàng)建時指定，指定后不能修改。分片鍵主要有兩大類型：
- hash分片：通過hash算法進行散列，數(shù)據分布的更加平均和分散。支持單列和多列hash。
- 范圍分片：按照指定片鍵的值分布，連續(xù)的key往往分布在連續(xù)的區(qū)間，更加適用范圍查詢場景。單數(shù)據散列性由分片鍵本身保證。
3.3 評論中臺的實踐
3.3.1?集群的擴展
作為中臺服務，對于不同的接入業(yè)務方，通過表隔離來區(qū)分數(shù)據。以comment評論表舉例，每個接入業(yè)務方都單獨創(chuàng)建一張表，業(yè)務方A表為? comment_clientA ，業(yè)務方B表為 comment_clientB，均在接入時創(chuàng)建表和相應索引信息。但只是這樣設計存在幾個問題：
- 單個集群，不能滿足部分業(yè)務數(shù)據物理隔離的需要。
- 集群調優(yōu)(如split遷移時間)很難業(yè)務特性差異化設置。
- 水平擴容帶來的單個業(yè)務方數(shù)據過于分散問題。
因此我們擴展了 MongoDB的集群架構：
- 擴展后的評論MongoDB集群 增加了 【邏輯集群】和【物理集群】的概念。一個業(yè)務方屬于一個邏輯集群，一個物理集群包含多個邏輯集群。
- 增加了路由層設計，由應用負責擴展Spring的MongoTemplate和連接池管理，實現(xiàn)了業(yè)務到MongoDB集群之間的切換選擇服務。
- 不同的MongoDB分片集群，實現(xiàn)了物理隔離和差異調優(yōu)的可能。
3.3.2?片鍵的選擇
MongoDB集群中，一個集合的數(shù)據部署是分散在多個shard分片和chunk中的，而我們希望一個評論列表的查詢最好只訪問到一個shard分片，因此確定了?范圍分片?的方式。
起初設置只使用單個key作為分片鍵，以comment評論表舉例，主要字段有{"_id":唯一id,"topicId":主題id,"text":文本內容,"createDate":時間} ,考慮到一個主題id的評論盡可能連續(xù)分布，我們設置的分片鍵為???topicId。隨著性能測試的介入，我們發(fā)現(xiàn)了有兩個非常致命的問題：
- jumbo chunk問題
- 唯一鍵問題
jumbo chunk：
官方文檔中，MongoDB中的chunk大小被限制在了1M-1024M。分片鍵的值是chunk劃分的唯一依據，在數(shù)據量持續(xù)寫入超過chunk size設定值時，MongoDB 集群就會自動的進行分裂或遷移。而對于同一個片鍵的寫入是屬于一個chunk，無法被分裂，就會造成? jumbo chunk 問題。
舉例，若我們設置1024M為一個chunk的大小，單個document 5KB計算，那么單個chunk能夠存儲21W左右document?？紤]熱點的主題評論(如微信評論)，評論數(shù)可能達到40W ，因此單個chunk很容易超過1024M。超過最大size的chunk依然能夠提供讀寫服務，只是不會再進行分裂和遷移，長久以往會造成集群之間數(shù)據的不平衡.
唯一鍵問題：
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
因此我們刪除了數(shù)據和集合，調整? ? topicId 和 _id 為聯(lián)合分片鍵 重新創(chuàng)建了集合。這樣即打破了chunk size的限制，也解決了唯一性問題。
3.4 遷移和擴容
隨著數(shù)據的寫入，當單個chunk中數(shù)據大小超過指定大小時(或chunk中的文件數(shù)量超過指定值)。MongoDB集群會在插入或更新時，自動觸發(fā)chunk的拆分。
拆分會導致集合中的數(shù)據塊分布不均勻，在這種情況下，MongoDB balancer組件會觸發(fā)集群之間的數(shù)據塊遷移。balancer組件是一個管理數(shù)據遷移的后臺進程，如果各個shard分片之間的chunk數(shù)差異超過閾值，balancer會進行自動的數(shù)據遷移。
balancer是可以在線對數(shù)據遷移的，但是遷移的過程中對于集群的負載會有較大影響。一般建議可以通過如下設置，在業(yè)務低峰時進行（更多見官網）
db.settings.update({ _id: "balancer" },{ $set: { activeWindow : { start : "" , stop : "" } } },{ upsert: true })MongoDB的擴容也非常簡單，只需要準備好新的shard復制集后，在 Mongos節(jié)點中執(zhí)行：
sh.addShard("<replica_set>/<hostname><:port>")擴容期間因為chunk的遷移，同樣會導致集群可用性降低，因此只能在業(yè)務低峰進行
四、寫在最后
MongoDB集群在評論中臺項目中已上線運行了一年多，過程中完成了約10個業(yè)務方接入，承載了1億 評論回復數(shù)據的存儲，表現(xiàn)較為穩(wěn)定。BSON非結構化的數(shù)據，也支撐了我們多個版本業(yè)務的快速升級。而熱門數(shù)據內存化存儲引擎，較大的提高了數(shù)據讀取的效率。
但對于MongoDB來說，集群化部署是一個不可逆的過程，集群化后也帶來了索引，分片策略等較多的限制。因此一般業(yè)務在使用MongoDB時，副本集方式就能支撐TB級別的存儲和查詢，并非一定需要使用集群化方式。
以上內容基于MongoDB 4.0.9版本特性，和最新版本的MongoDB細節(jié)上略有差異。
參考資料：https://docs.mongodb.com/manual/introduction/
下載文檔
