本文主要分享騰訊智慧零售團(tuán)隊(duì)優(yōu)碼業(yè)務(wù)在MongoDB中的應(yīng)用，采用騰訊云MongoDB作為主存儲服務(wù)給業(yè)務(wù)帶來了較大收益，主要包括：高性能、快捷的DDL操作、低存儲成本、超大存儲容量等收益，極大的降低了業(yè)務(wù)存儲成本，并提高了業(yè)務(wù)迭代開發(fā)效率。

一、業(yè)務(wù)場景

騰訊優(yōu)碼從連接消費(fèi)者到連接渠道終端，實(shí)現(xiàn)以貨的數(shù)字化為基礎(chǔ)的企業(yè)數(shù)字化升級，包含營銷能力升級和動銷能力升級。騰訊優(yōu)碼由正品通、門店通和會員通三個子產(chǎn)品組成。

更多信息可以訪問騰訊優(yōu)碼官方網(wǎng)站獲得：

https://uma.qq.com/

騰訊優(yōu)碼整體視圖

1.1 正品通

騰訊優(yōu)碼正品通提供防偽鑒真能力，實(shí)現(xiàn)一物一碼全流程正品追溯，全鏈路數(shù)據(jù)存儲至區(qū)塊鏈，確保真實(shí)可信；更可直達(dá)品牌私域，實(shí)現(xiàn)流量進(jìn)一步轉(zhuǎn)化；同時(shí)正品通提供微信域內(nèi)的品牌保護(hù)能力，阻斷品牌偽冒網(wǎng)站傳播、幫助消費(fèi)者識別假冒商品。

產(chǎn)品主要包含如下核心特性：

1.2 門店通

騰訊優(yōu)碼門店通是服務(wù)品牌方、經(jīng)銷商、業(yè)代員以及終端門店四大零售鏈路核心角色實(shí)現(xiàn)基于終端銷售門店的銷售管理手段升級與銷售額提升。

產(chǎn)品主要包含如下核心特性：

1.3 會員通

騰訊優(yōu)碼會員通是面向零售品牌商提供的SaaS+定制化服務(wù)的產(chǎn)品，以掃碼為切入點(diǎn)，連接線上線下場景。提供豐富的掃碼/互動活動模型、活動評估體系助力品牌連接消費(fèi)者。

產(chǎn)品主要包含如下核心特性：

二、碼存儲選型

騰訊智慧零售優(yōu)碼業(yè)務(wù)存儲零售商品二維碼信息，該信息為智慧零售最核心的數(shù)據(jù)信息，提供“從連接消費(fèi)者到連接渠道終端，實(shí)現(xiàn)以貨的數(shù)字化為基礎(chǔ)的企業(yè)數(shù)字化升級”相關(guān)服務(wù)。因此碼數(shù)據(jù)存儲問題是項(xiàng)目最核心的問題。

2.1 需求和方案

要解決碼存儲問題，首先需要分析碼存儲的特征。經(jīng)過分析碼存儲問題的主要特征是：

海量數(shù)據(jù)：騰訊優(yōu)碼做的商品二維碼，隨著越來越多的商品使用騰訊優(yōu)碼業(yè)務(wù)，二維碼數(shù)據(jù)開始呈現(xiàn)指數(shù)級增長。

關(guān)聯(lián)存儲：碼與碼之間存在1：1和1：N：N的關(guān)聯(lián)關(guān)系，需要存儲這種關(guān)系，并且提供相應(yīng)的關(guān)聯(lián)查詢。

多維度查詢：針對不同的應(yīng)用場景需要提供不同維度的條件查詢。

在獲取到碼存儲特征之后，經(jīng)過多方調(diào)研和排查之后，初步選取了2種存儲方案：

1. MySQL?+ ES：MySQL 分庫分表存儲碼元數(shù)據(jù)，提供需要高性能的讀寫場景；然后根據(jù)需求將部分?jǐn)?shù)據(jù)同步 ES 以應(yīng)對各種復(fù)雜的查詢場景。

2. MongoDB：MongoDB 是全球排名最高的分布式NoSQL數(shù)據(jù)庫，其核心特性是 No Schema、高可用和分布式，非常適合分布式存儲。

2.2?方案分析

2.2.1 MySQL?+ ES方案分析

MySQL + ES 是一個比較常見的存儲解決方案，并且在很多領(lǐng)域內(nèi)被廣泛應(yīng)用，如會員或商品信息儲存領(lǐng)域。此方案的優(yōu)勢是能夠提供非常多的查詢方式和不同的性能保障，可以應(yīng)對各種各樣復(fù)雜的業(yè)務(wù)查詢需求。

MySQL + ES 的常見架構(gòu)是寫操作直接作用于MySQL，然后通過 canal + Kafka 的方式將數(shù)據(jù)變更同步到ES，然后再根據(jù)不同的查詢場景從MySQL或者ES查詢數(shù)據(jù)。下圖是在騰訊優(yōu)碼業(yè)務(wù)場景下可能的架構(gòu)圖：

從架構(gòu)圖可以看出，本方案存在幾個問題：

數(shù)據(jù)同步和一致性問題：這個問題在數(shù)據(jù)量不大的情況下不會有影響。但是如果數(shù)據(jù)量百億甚至千億時(shí)就是一個非常嚴(yán)重的問題。
數(shù)據(jù)容量問題：一般情況下 MySql 的單表數(shù)據(jù)最好維持在百萬級一下，如果單表數(shù)據(jù)量過大之后讀寫都是個問題。那么如果要存儲千億數(shù)據(jù)就要幾千上萬張表，如此多的分表需要業(yè)務(wù)自己維護(hù)時(shí)開發(fā)運(yùn)維都是幾乎不可行的。
成本問題：數(shù)據(jù)冗余存儲，會增加額外的存儲成本。同時(shí)ES 為了保證數(shù)據(jù)可靠性和查詢性能，需要更多的機(jī)器和內(nèi)存。而且 ES 存在數(shù)據(jù)膨脹問題，對于同樣的數(shù)據(jù)，需要相當(dāng)MySql來說更大的磁盤。
DDL運(yùn)維問題：MySql 在分庫分布之后，因?yàn)镈DL語句需要操作大量的庫表，因此非常耗時(shí)，同時(shí)也容易出錯。根據(jù)我們以前的項(xiàng)目經(jīng)驗(yàn)來說，當(dāng)有幾百張表，單表幾十萬數(shù)據(jù)時(shí)，一個簡單的增加字段的DDL語句也需要1小時(shí)甚至更久才能完成。
開發(fā)成本問題：此方案需要業(yè)務(wù)自己維護(hù)分庫分表、數(shù)據(jù)同步和根據(jù)需求選取不同的查詢引擎。不僅整個架構(gòu)復(fù)雜，同時(shí)在做業(yè)務(wù)需求時(shí)需要慎重考慮，稍不注意使用錯的存儲引擎就可能導(dǎo)致性能問題。
水平擴(kuò)容問題：MySql 分庫分表要擴(kuò)容需要業(yè)務(wù)手動 rehash 搬遷數(shù)據(jù)，成本非常高，而且很難處理擴(kuò)容過程中的數(shù)據(jù)讀寫問題。

2.2.2 MongoDB 方案分析

MongoDB 是非常出名的分布式存儲引擎，具備 No Schema、高可用、分布式、數(shù)據(jù)壓縮等多方面的優(yōu)勢。雖然MongoDB 是NoSQL 存儲引擎，但是其 Wired Tiger 存儲引擎和innerdb 一樣底層使用的是B+樹，因此MongoDB 在提供分布式存儲的前提下同時(shí)能夠提供大部分MySql 支持的查詢方式。因此，在使用 MongoDB 時(shí)，我們不需要MySql冗余表或者 ES 來支持大部分的分布式查詢。在騰訊優(yōu)碼的應(yīng)用場景下，基于MongoDB 的存儲架構(gòu)如下圖所示：

從圖中可以看出，MongoDB可以避免冗余存儲帶來的數(shù)據(jù)同步和一致性問題、存儲成本問題、資源/運(yùn)維/開發(fā)成本。而且在進(jìn)一步測試和分析MongoDB的功能和性能之后，我們發(fā)現(xiàn)MongoDB還具備如下優(yōu)勢：

無DDL問題：因?yàn)镸ongoDB 是No Schema 的，因此可以避免MySql的DDL問題。

數(shù)據(jù)自動均勻：MongoDB 有自動rebalance 功能，可以在數(shù)據(jù)分布不均勻的時(shí)候，自動搬遷數(shù)據(jù)，保證各個分片間的負(fù)載均勻。

更低的成本：MongoDB 自帶數(shù)據(jù)壓縮，在同等數(shù)據(jù)下，MongoDB 需求的磁盤更少。

更高的性能：MongoDB 最大化的利用了內(nèi)存，在大部分場景下?lián)碛薪咏鼉?nèi)存數(shù)據(jù)庫的性能。經(jīng)過測試MongoDB的單分片讀性能約為3萬QPS。

更多的讀寫方式：雖然MongoDB沒有ES的倒排索引，其支持的查詢方式略遜于ES。但是，MongoDB在擁有大部分ES的查詢能力的同時(shí)，其性能遠(yuǎn)高與ES；而且相對MySql 來說MongoDB 的字段類型支持內(nèi)嵌對象和數(shù)組對象，因此能滿足跟多的讀寫需求。

2.3 方案對比

通過前面的分析，我們初步判斷MongoDB擁有更好的表現(xiàn)。因此為了進(jìn)一步確定MongoDB的優(yōu)勢，我們深入對比了MySQL + ES 與MongoDB在各方面的表現(xiàn)。

2.3.1 存儲成本對比

MongoDB 在存儲上的優(yōu)勢主要體現(xiàn)在兩個方面：數(shù)據(jù)壓縮和無冗余存儲。

為了更加直觀的看出磁盤使用情況，我們模擬了在騰訊優(yōu)碼業(yè)務(wù)場景下，MySQL + ES和MongoDB下的實(shí)際存儲情況。

一方面，在MySQL+ES的方案下，為了滿足需要我們需要將冗余一份ES數(shù)據(jù)和MySQL的冗余表。其中碼的核心數(shù)據(jù)存儲在MySQL中，其磁盤總量僅占總的38.1%。前面說過 MongoDB的方案是不需要冗余存儲的，因此使用MongoDB可以減少這61.9%的總數(shù)據(jù)容量。

另一方面，經(jīng)過測試同樣的碼數(shù)據(jù)，MongoDB snappy壓縮算法的壓縮率約3倍，zlib 壓縮算法的壓縮率約6倍。因此，雖然業(yè)務(wù)為了保證系統(tǒng)的穩(wěn)定性而選擇 snappy 壓縮算法，但MongoDB 仍然只需要 MySQL 三分之一的磁盤消耗。

2.3.2 開發(fā)運(yùn)維成本

無數(shù)據(jù)同步鏈路：使用MongoDB不需要數(shù)據(jù)同步，因此就不需要維護(hù)canal服務(wù)和kafka隊(duì)列，大大減少開發(fā)和運(yùn)維難度。
人力成本收益：在MySQL+ES架構(gòu)下每次對MySQL集群做添加字段變更，都需運(yùn)維一定的人日投入，并且存在業(yè)務(wù)抖動風(fēng)險(xiǎn)，同時(shí)影響業(yè)務(wù)迭代發(fā)布進(jìn)度，迭代發(fā)布耗時(shí)且風(fēng)險(xiǎn)大。
開發(fā)維護(hù)成本：MongoDB存儲架構(gòu)簡單，一份存儲，無數(shù)據(jù)一致性壓力。
動態(tài)擴(kuò)容：MongoDB 支持隨時(shí)動態(tài)擴(kuò)容，基本不存在容量上限問題，而MySQL在擴(kuò)容時(shí)需要業(yè)務(wù)手動rehash變遷數(shù)據(jù)，并自己保證數(shù)據(jù)一致性和完整性。

2.3.3 性能對比

經(jīng)過壓測，同樣的4C8G的機(jī)器配置下，MySQL和MongoDB在大數(shù)據(jù)量下寫性能基本一致。MySQL的讀性單分片約6000QPS左右，ES的性能只有800QPS左右。而 MongoDB 單分片地讀性能在3萬QPS左右，遠(yuǎn)高于MySQL和 ES 的性能。

2.3.4 總結(jié)

經(jīng)過上面的分析和對比之后，可以明顯看出 MongoDB 在各方面都有優(yōu)勢。為了更加直觀的看出不同方案的差異，這里列出了從功能、性能、成本、可擴(kuò)展性和可維護(hù)性等5個方面的對比數(shù)據(jù)：

綜上所述，MongoDB 不僅能完全滿足業(yè)務(wù)需求，同時(shí)在性能、成本、可維護(hù)性等各方面都優(yōu)于其它兩種方案，因此騰訊優(yōu)碼最終選用的是MongoDB 作為業(yè)務(wù)核心數(shù)據(jù)碼的存儲方案。

三、MongoDB分片

集群優(yōu)化過程

零售優(yōu)碼業(yè)務(wù)對成本要求較高、數(shù)據(jù)量較大，線上真實(shí)讀寫流量不是太高(讀3W QPS要求)，因此采用低規(guī)格4C8G規(guī)格(單節(jié)點(diǎn)規(guī)格)分片模式集群部署。

3.1 分片集群片建選擇+預(yù)分片

零售優(yōu)碼數(shù)據(jù)查詢都是通過碼id查詢，因此選擇碼id作為片建，這樣可以最大化查詢性能，索引查詢都可以通過同一個分片獲取數(shù)據(jù)。此外，為了避免分片間數(shù)據(jù)不均衡引起的moveChunk操作，因此選擇hashed分片方式，同時(shí)提前進(jìn)行預(yù)分片，MongoDB默認(rèn)支持hashed預(yù)分片，以優(yōu)碼詳情表為例，預(yù)分片方式如下：

use?db_code_xx??sh.enableSharding("db_code_xx")??//n為實(shí)際分片數(shù)??sh.shardCollection("db_code_xx.t_code_xx",?{"id":?"hashed"},?false,{numInitialChunks:8192*n})??

3.2 低峰期滑動窗口設(shè)置

由于MongoDB實(shí)例節(jié)點(diǎn)規(guī)格低(4C8G)，當(dāng)分片間chunks數(shù)據(jù)不均衡的情況下，會觸發(fā)自動balance均衡，由于實(shí)例規(guī)格低，balance過程存在如下問題：

CPU消耗過高，遷移過程甚至消耗90%左右CPU
業(yè)務(wù)訪問抖動，耗時(shí)增加
慢日志增加
異常告警增多

以上問題都是由于balance過程進(jìn)行moveChunk數(shù)據(jù)搬遷過程引起，為了快速實(shí)現(xiàn)數(shù)據(jù)從一個分片遷移到另一個分片，MongoDB內(nèi)部會不停的把數(shù)據(jù)從一個分片挪動到另一個分片，這時(shí)候就會消耗大量CPU，從而引起業(yè)務(wù)抖動。

MongoDB內(nèi)核也考慮到了balance過程對業(yè)務(wù)有一定影響，因此默認(rèn)支持了balance窗口設(shè)置，這樣就可以把balance過程和業(yè)務(wù)高峰期進(jìn)行錯峰，這樣來最大化規(guī)避數(shù)據(jù)遷移引起的業(yè)務(wù)抖動。例如設(shè)置凌晨0-6點(diǎn)低峰期進(jìn)行balance窗口設(shè)置，對應(yīng)命令如下：

use?config??db.settings.update({"_id":"balancer"},{"$set":{"activeWindow":{"start":"00:00","stop":"06:00"}}},true)?

3.3 寫多數(shù)派優(yōu)化

由于優(yōu)碼二維碼數(shù)據(jù)非常核心，為了避免極端情況下的數(shù)據(jù)丟失和數(shù)據(jù)回歸等風(fēng)險(xiǎn)，因此客戶端采用writeConcern={w: “majority”}配置，確保數(shù)據(jù)寫入到副本集大多數(shù)成員后才向客戶端發(fā)送確認(rèn)。

鏈?zhǔn)綇?fù)制的概念：假設(shè)節(jié)點(diǎn)A(primary)、B節(jié)點(diǎn)(secondary)、C節(jié)點(diǎn)(secondary)，如果B節(jié)點(diǎn)從A節(jié)點(diǎn)同步數(shù)據(jù)，C節(jié)點(diǎn)從B節(jié)點(diǎn)同步數(shù)據(jù)，這樣A->B->C之間就形成了一個鏈?zhǔn)降耐浇Y(jié)構(gòu)，如下圖所示：

? ? ??

MongoDB多節(jié)點(diǎn)副本集可以支持鏈?zhǔn)綇?fù)制，可以通過如下命令獲取當(dāng)前副本集是否支持鏈?zhǔn)綇?fù)制：

cmgo-xx:SECONDARY> rs.conf().settings.chainingAllowed  true??cmgo-xx:SECONDARY>???

此外，可以通過查看副本集中每個節(jié)點(diǎn)的同步源來判斷當(dāng)前副本集節(jié)點(diǎn)中是否存在有鏈?zhǔn)綇?fù)制情況，如果同步源為secondary從節(jié)點(diǎn)，則說明副本集中存在鏈?zhǔn)綇?fù)制，具體查看如下副本集參數(shù)：

cmgo-xx:SECONDARY> rs.status().syncSourceHost  xx.xx.xx.xx:7021??cmgo-xx:SECONDARY>???

由于業(yè)務(wù)配置為寫多數(shù)派，鑒于性能考慮可以關(guān)閉鏈?zhǔn)綇?fù)制功能，MongoDB可以通過如下命令操作進(jìn)行關(guān)閉：

cfg?=?rs.config()??cfg.settings.chainingAllowed?=?falsers.reconfig(cfg)??

鏈?zhǔn)綇?fù)制好處：可以大大減輕主節(jié)點(diǎn)同步oplog的壓力。

鏈?zhǔn)綇?fù)制不足：當(dāng)寫策略為majority時(shí)，寫請求的耗時(shí)變大

基于寫性能考慮，當(dāng)業(yè)務(wù)采用“寫大多數(shù)”策略時(shí)，直接關(guān)閉鏈?zhǔn)綇?fù)制功能，確保寫鏈路過長引起的寫性能下降。

關(guān)于作者

騰訊優(yōu)碼團(tuán)隊(duì)：

騰訊優(yōu)碼團(tuán)隊(duì)深耕零售行業(yè)多年，致力于從連接消費(fèi)者到連接渠道終端，實(shí)現(xiàn)以貨的數(shù)字化為基礎(chǔ)的企業(yè)數(shù)字化升級。騰訊優(yōu)碼構(gòu)建會員通、門店通、正品通、碼中臺，三通一碼平臺。目前已在水飲、酒水和食品行業(yè)具備較為完善的數(shù)字化解決方案，并服務(wù)于70+企業(yè)，連接150億+商品，掃碼人次60億+。

騰訊云MongoDB團(tuán)隊(duì)：

騰訊云MongoDB當(dāng)前服務(wù)于游戲、電商、社交、教育、新聞資訊、金融、物聯(lián)網(wǎng)、軟件服務(wù)等多個行業(yè)；MongoDB團(tuán)隊(duì)(簡稱CMongo)致力于對開源MongoDB內(nèi)核進(jìn)行深度研究及持續(xù)性優(yōu)化(如百萬庫表、物理備份、免密、審計(jì)等)，為用戶提供高性能、低成本、高可用性的安全數(shù)據(jù)庫存儲服務(wù)。后續(xù)持續(xù)分享MongoDB在騰訊內(nèi)部及外部的典型應(yīng)用場景、踩坑案例、性能優(yōu)化、內(nèi)核模塊化分析。

﹀

-- 更多精彩 --

云上MongoDB常見索引問題及最優(yōu)索引規(guī)則大全

騰訊云與MongoDB達(dá)成戰(zhàn)略合作，為全球用戶提供最新MongoDB服務(wù)

↓↓點(diǎn)擊閱讀原文，了解更多優(yōu)惠

MongoDB請求出戰(zhàn)！助力騰訊零售優(yōu)碼降本增效

1.1 正品通

1.2 門店通

1.3 會員通

2.1 需求和方案

2.3 方案對比

通過前面的分析，我們初步判斷MongoDB擁有更好的表現(xiàn)。因此為了進(jìn)一步確定MongoDB的優(yōu)勢，我們深入對比了MySQL + ES 與MongoDB在各方面的表現(xiàn)。

2.3.1 存儲成本對比

3.1 分片集群片建選擇+預(yù)分片

3.2 低峰期滑動窗口設(shè)置

3.3 寫多數(shù)派優(yōu)化

關(guān)于作者

MongoDB請求出戰(zhàn)！助力騰訊零售優(yōu)碼降本增效

通過前面的分析，我們初步判斷MongoDB擁有更好的表現(xiàn)。因此為了進(jìn)一步確定MongoDB的優(yōu)勢，我們深入對比了MySQL + ES 與MongoDB在各方面的表現(xiàn)。