WiredTiger 是一個(gè)開源的、高性能、可伸縮的 MongoDB 數(shù)據(jù)存儲(chǔ)引擎。

SSPL協(xié)議是只對(duì)使用云廠商提供的MongoDB存儲(chǔ)服務(wù)有要求，但是對(duì)于我們自己在云廠商主機(jī)上部署自己的MongoDB數(shù)據(jù)庫是沒有任何限制的，是吧？

按SSPL協(xié)議，最多也只能到MongoDB4.0版本。

這可能也是阿里云、百度云等云廠商上提供的MongoDB數(shù)據(jù)庫版本最多也是到MongoDB4.0的原因？

正解。這個(gè)只影響云廠商的MongoDB托管服務(wù)的部門。你自己在云上部署是不受SSPL限制的。

mongDB社區(qū)版使用的是 SSPL 協(xié)議，?和標(biāo)準(zhǔn)開源AGPL協(xié)議最大的差別就是 Mongo的不允許公有云廠商在云上賣MongoDB云服務(wù)。

阿里云已經(jīng)獲得商業(yè)授權(quán)所以他們接下來可以繼續(xù)提供更新版本。其他云暫時(shí)就只能到4.0，正如你已經(jīng)觀察到的。

?mongodb適合做數(shù)據(jù)倉庫嗎？

如果是傳統(tǒng)用來做星形schema或者雪花schema，不是太合適。

如果是用來做現(xiàn)代數(shù)倉，類似于大數(shù)據(jù)那樣做大寬表，mongodb可以作為一個(gè)選擇。

我在我自己的類似數(shù)倉的平臺(tái)產(chǎn)品里就用了mongodb。?

有一些比較不錯(cuò)的亮點(diǎn)是：橫向擴(kuò)展能力，多結(jié)構(gòu)化數(shù)據(jù)支持，檢索能力，元數(shù)據(jù)管理等

最近在java項(xiàng)目中嘗試將日志輸出到mongodb，發(fā)現(xiàn)效果挺不錯(cuò)，解決了日志集中存儲(chǔ)，分析排查問題方便了很多。

我想問的是 為什么現(xiàn)在微服務(wù)架構(gòu)中流行用elk方案處理日志，mongodb不是更方便 更簡(jiǎn)單嗎？ 由于我沒做過對(duì)比測(cè)試 不知mongodb存日志會(huì)不會(huì)有什么不足之處？

ELK 除了存儲(chǔ)日志之外，有一些另外的插件比如說Logstash 可以用來用工具方式收集一些日志文件，比如說Kibana可以用來做一些日志分析和可視化的工作。另外ELK在日志全文搜索方面也略勝一籌。

你的場(chǎng)景是從Java 里寫日志就沒有太大區(qū)別了，mongo 和ES都可以很好的解決。當(dāng)然，像我們公司一樣因?yàn)橐呀?jīng)用MongoDB 作為數(shù)據(jù)庫，那我們就不需要額外再去用另一個(gè)分布式系統(tǒng)了。架構(gòu)可以簡(jiǎn)單很多，這個(gè)可能是mongo能夠作為一個(gè)通用數(shù)據(jù)庫而不只是某些日志或搜索功能的優(yōu)勢(shì)了。

關(guān)于mongodb在loT領(lǐng)域的應(yīng)用，比如怎樣實(shí)現(xiàn)時(shí)序數(shù)據(jù)庫的功能？

MongoDB不是一個(gè)專門的IoT，但是可能在70%-80%的IoT場(chǎng)景下它可以是個(gè)不錯(cuò)的選擇。只有你在考慮有幾十億幾百億的量級(jí)，并且要做海量數(shù)據(jù)分析的時(shí)候，Mongo的行級(jí)存儲(chǔ)特性會(huì)使得它不是最優(yōu)的選擇。這個(gè)時(shí)候要考慮專門的IoT數(shù)據(jù)庫了。

Mongo的優(yōu)勢(shì)：

1）足夠好的擴(kuò)展能力來支撐大部分的IoT時(shí)序數(shù)據(jù)的存儲(chǔ)，特別是使用了分桶設(shè)計(jì)以后（第2章我會(huì)講）?

2）靈活的JSON模型，特別適合各種傳感器的不規(guī)則數(shù)據(jù)結(jié)構(gòu)。

國內(nèi)的某一大廠物聯(lián)網(wǎng)方案就是基于mongo的。西門子的工業(yè)物聯(lián)網(wǎng)Mindsphere也是用mongo。非常多的使用者。

http://mongoing.com上的MongoDB中文文檔是3.4的，現(xiàn)在MongoDB的版本已經(jīng)到4.2了，3.4的文檔跟4.2文檔的差別大嗎？mongoing.com后面會(huì)翻譯4.0版本的文檔嗎？現(xiàn)在看3.4的文檔翻譯是 2017年的了。

mongodb的官方文檔工具升級(jí)后就不支持非英語語言的合并，造成翻譯的文檔難以更新。

這個(gè)問題我們已經(jīng)反應(yīng)給官方，我們還在看有無機(jī)會(huì)等他們更新工具后重新啟動(dòng)新版翻譯。

看到很多書或者其他資料中說MongoDB是BSON數(shù)據(jù)模型，能解釋一下BSON嗎？

BSON 是MongoDB用來在落盤存儲(chǔ)時(shí)候或者網(wǎng)絡(luò)傳輸時(shí)候的底層物理數(shù)據(jù)模型。

如果你是存儲(chǔ)引擎開發(fā)者或者mongodb驅(qū)動(dòng)程序開發(fā)者，你需要從這個(gè)層面去了解。如果你是絕大部分的應(yīng)用開發(fā)者或者數(shù)據(jù)庫使用者，你只需要關(guān)心JSON。

BSON = Binary JSON， 是基于JSON基礎(chǔ)上加了一些類型及元數(shù)據(jù)描述的格式。

MongoDB 的特性是無Schema 設(shè)計(jì)，但在使用過程中通過 Java (Spring Boot)操作時(shí)需要先定義對(duì)象結(jié)構(gòu)，加上相應(yīng)的注解，與 MongoDB 的 Feild 對(duì)應(yīng)，這樣其實(shí) 沒有辦法利用 MongoDB 的這一特性了，有什么辦法嗎？

MongoDB是動(dòng)態(tài)Schema，不是無schema。

你定了一個(gè)schema以后，以后新增字段（在springboot）的時(shí)候，直接改就可以了，不需要去數(shù)據(jù)庫調(diào)整。這就是它的優(yōu)越性。

mongoDB這門課需要什么樣的基礎(chǔ)？需要懂開發(fā)語言么？

懂一些Javascript的話會(huì)比較有幫助一些。如果是只做管理的DBA，你可能也需要一些Javascript來維護(hù)下數(shù)據(jù)。

當(dāng)然，我不覺得用JS來做些腳本就一定要是像開發(fā)者那樣熟練，所以說不是100%需要懂開發(fā)語言。

您在課程中提到“介紹 MongoDB 的基本操作”這個(gè)任務(wù)，是留給“參考書”去做的。那么您能否推薦一些，這種用來給初學(xué)者入門的“參考書”，或者是網(wǎng)絡(luò)上的學(xué)習(xí)資源呢？

MongoDB: The Definitive Guide

有中文譯本：MongoDB權(quán)威指南

Mongodb 操作系統(tǒng)優(yōu)化這塊推薦的參數(shù)？

可以參考一下這里：

https://docs.mongodb.com/manual/administration/production-notes

MongoDB是一個(gè)基于json的數(shù)據(jù)庫，文檔模型靈活，很好橫向擴(kuò)展能力

2.x版本加入聚合的操作

3.x版本引入wiredtiger引擎

4.x版本引入事務(wù)acid的支持

為什么副本集說是5個(gè)9（99.999%）的高可用？

MongoDB復(fù)制集在從節(jié)點(diǎn)故障時(shí)候是不會(huì)影響到可用性。

在主節(jié)點(diǎn)故障，進(jìn)行選舉的時(shí)候需要數(shù)秒到十幾秒，這期間會(huì)影響寫入。

一年有365天x86640秒 ~= 3000多萬秒。假設(shè)你每個(gè)月發(fā)生一次主節(jié)點(diǎn)故障或者其他問題導(dǎo)致選舉，每次影響15秒，那么可用率就是：就是（3000w-12x15） / 3000w ~= 99.9994%

MongoDB這種復(fù)制集模式，在不同的數(shù)據(jù)中心，這中間的網(wǎng)絡(luò)延遲比較嚴(yán)重吧，不會(huì)影響做復(fù)制集的效果嗎？

數(shù)據(jù)規(guī)模達(dá)到多大級(jí)別需要使用分片機(jī)制？，我們現(xiàn)在數(shù)據(jù)有200多G，是不是復(fù)制集已經(jīng)足以應(yīng)對(duì)了？

在多中心部署的時(shí)候要考慮網(wǎng)絡(luò)延遲，所以一般多活中心只是建議能夠接受一定數(shù)據(jù)延遲的情況下才建議。

分片有3個(gè)觸發(fā)條件：數(shù)據(jù)量，并發(fā)量，以及熱數(shù)據(jù)大小（內(nèi)存需求）。理論上，任意一個(gè)都會(huì)觸發(fā)分片需求。如果只看數(shù)據(jù)量，單分片一般可以到1-2TB。

mongoDB和MySQL比寫入性能方面優(yōu)勢(shì)大嗎?

按照我個(gè)人經(jīng)驗(yàn)是有明顯的優(yōu)勢(shì)的。有好幾家大廠的兄弟，包括百度，網(wǎng)易，字節(jié)都有分享類似的經(jīng)驗(yàn)。?

稍微網(wǎng)絡(luò)搜一下，都有十倍或者更多的數(shù)字。原因：

1）MongoDB默認(rèn)的事務(wù)級(jí)別比MySQL低

2）MongoDB支持的batch 寫入模式可以大幅度提升寫入速度

3）MongoDB默認(rèn)寫到內(nèi)存就返回，不等落盤

mongoDB是不是完爆MySQL呢？什么情況下該選用mysql而不是MongoDB呢？

實(shí)際情況是，很多同學(xué)在學(xué)校里學(xué)習(xí)的只是SQL。

很多開發(fā)團(tuán)隊(duì)，特別是有項(xiàng)目壓力的，沒有時(shí)間讓團(tuán)隊(duì)來學(xué)習(xí)，就會(huì)選擇大家比較熟悉的方式。

如果有額外的時(shí)間的話，我的幾個(gè)創(chuàng)業(yè)公司的朋友都說，想從MySQL 切換到MongoDB。

為什么MySQL不用一張表多個(gè)字段呢，而是拆分成幾個(gè)表？

MySQL一張表沒法做到一對(duì)多的關(guān)系，只能拆分表來做。

當(dāng)然，MySQL現(xiàn)在也支持json了，但是那個(gè)是非主流用法。對(duì)JSON的支持也是相對(duì)較弱，所以使用人并不多。

MongoDB 支持multi-master，所有節(jié)點(diǎn)可以同時(shí)讀寫數(shù)據(jù)庫嗎？

?在一個(gè)復(fù)制集群里沒有multi-master，但是一個(gè)分片集群可以有多個(gè)master (primary), 每個(gè)分片一個(gè)primary這種方式。

mongoDB性能優(yōu)勢(shì)大不大呢？

如果不說單節(jié)點(diǎn)性能比較，MongoDB最少是分布式架構(gòu)，可以通過橫向擴(kuò)容來克服性能瓶頸。

這個(gè)和同樣是用來作為應(yīng)用程序數(shù)據(jù)庫的RDBMS來比還是有很明顯的優(yōu)勢(shì)的。

Grafana不支持mongodb作為數(shù)據(jù)源，也沒有相關(guān)插件，有什么方案，使用grafana顯示mongodb的一些數(shù)據(jù)嗎?

https://grafana.com/grafana/dashboards/8339

mongoDB有什么推薦的客戶端軟件嗎？

MongoDB Compass（官方）

Studio3T

NoSQL Booster

navicat

mogodb安裝在linuc或windows上，運(yùn)行差別很大嗎？官方推薦是部署在什么系統(tǒng)上(難道大部分生產(chǎn)環(huán)境是部署在centos上)？

MongoDB生產(chǎn)環(huán)境絕大部分是Linux 系統(tǒng)。RedHat, CentOS, Ubuntu 等都有。

Windows 開發(fā)環(huán)境多一點(diǎn)，也有少數(shù)線上使用。但是確實(shí)不是主流。

差別：Linux版本上面用的最多，踩得坑也最多，相對(duì)更加穩(wěn)定。

mongodb在生產(chǎn)環(huán)境建議使用docker部署嗎？用docker部署副本集如何處理？

docker 在生產(chǎn)環(huán)境中不建議。

在開發(fā)測(cè)試環(huán)境中okay，需要注意的一點(diǎn)是要用服務(wù)名或者配置的域名進(jìn)行復(fù)制集的配置，否則可能會(huì)因?yàn)閐ocker 內(nèi)部ip無法互相通信而啟動(dòng)不了集群。

如果在docker容器中布署mongodb，一般容器內(nèi)存與heap內(nèi)存的比例大概是個(gè)什么比例？

?MongoDB 默認(rèn)會(huì)使用60%的系統(tǒng)內(nèi)存，一般至少也要用到1GB緩存，所以容器至少要給個(gè)2GB。

如果想對(duì)mongodb脫敏，非結(jié)構(gòu)型的數(shù)據(jù)結(jié)構(gòu)有什么好的解決方案推薦嗎？

可以采用一些ETL工具，如Kettle, Talend, Tapdata等。這些工具都對(duì)mongodb有一定程度的支持。

numa架構(gòu)下現(xiàn)在安裝mongodb還需要配置interleave=all，進(jìn)行交叉內(nèi)存分配么？

這個(gè)還是建議的。

看3.6的官方文檔，刪除是用deleteOne, deleteMany，這跟remove有什么區(qū)分嗎?

remove是mongo shell下的命令。deleteOne deleteMany是程序語言下的API。做的是類似的事情。

文件分布式的文件存儲(chǔ)也會(huì)選用MongoDB么？除了MongoDB還有其他的解決方案嗎？

可以嘗試 minio

請(qǐng)問分片集群的chunk分裂閾值有哪些？

shard key與chunk的分裂閾值是什么關(guān)系？

如何避免按shard key做chunk分裂時(shí)出現(xiàn)超出chunkSize的chunk塊？

這個(gè)閾值應(yīng)該是在80%（64MB * 80%）的時(shí)候，就會(huì)把塊一分為二。

mongodb刪除了數(shù)據(jù)、表、數(shù)據(jù)庫是沒法恢復(fù)的么，有沒有類似mysql有個(gè)日志記錄的機(jī)制去回滾的？

?mongodb有類似的oplog。但是那個(gè)要求你對(duì)全量的oplog都要保存，才能夠從oplog里完全恢復(fù)被誤刪的表。

在外分布式環(huán)境中，mongo如何做開機(jī)自啟？

將服務(wù)注冊(cè)成系統(tǒng)服務(wù)：

CentOS6.x? 寫啟動(dòng)腳本

CentOS7.x? 寫service文件

如果你是說希望有那種中央化的管控，那你可以使用OpsManager，可以通過GUI對(duì)全部節(jié)點(diǎn)進(jìn)行起?？刂?，并且是會(huì)在服務(wù)器宕機(jī)時(shí)候自動(dòng)重啟服務(wù)。

使用mongodump的時(shí)候會(huì)給collection加lock嗎?

不會(huì)加lock。所以mongodump出來的不是一個(gè)一致的backup。通?？梢约由?--oplog參數(shù)來獲取一個(gè)某個(gè)時(shí)間點(diǎn)的快照類的備份。

對(duì)于mongo副本集，如果有多個(gè)庫，由于單集群達(dá)到瓶頸了，我想把一個(gè)庫遷移出去，有什么方法嗎，能達(dá)到像mysql主從實(shí)現(xiàn)嗎？并且切換到新集群控制在切換ip的時(shí)間嗎？

如果可以停服務(wù)，可以用 mongodump -d xxx 方式如果不能停服，需要用一些工具：如果在阿里云，可以考慮mongoshake 工具M(jìn)ongoDB官方有mongomirror工具，我們Tapdata也有一個(gè)工具，有免費(fèi)3個(gè)月的使用期，如果只是一次性遷移夠用了。

我們系統(tǒng)一開始使用es, 但是我們的一個(gè)index包含2000多個(gè)field,經(jīng)常會(huì)出現(xiàn)寫性能問題，請(qǐng)問mongoDB對(duì)于寫入的文檔的字段，以及字段嵌套的深度由限制嗎？

那個(gè)沒有限制。限制就是最大不能超過16MB。ES的長處是查詢/搜索，寫入從來不是它優(yōu)勢(shì)。

MongoDB比較平衡點(diǎn)，增刪改查都還不錯(cuò)。

使用mongodump去備份db，備份過程中會(huì)阻塞insert寫入嗎？

是不是如果不想要一致性備份集，就不上鎖，如果想要一致性的備份集，加--oplog參數(shù)，也不阻塞insert寫入？

備份不阻塞，除非你用fsyncLock（）。

不上鎖的話，就用 --oplog

mongodb的動(dòng)態(tài)特性有缺點(diǎn)嘛？

有一些值得注意的地方。

schema 管理會(huì)復(fù)雜， 你不能一下確定這個(gè)集合到底是什么結(jié)構(gòu)。

解決方案是使用Schema Validation 或者 JSON Schema來定義這個(gè)集合的嚴(yán)格結(jié)構(gòu)。?

JSON Schema類似于關(guān)系數(shù)據(jù)庫的schema，但是不同的是如果你需要修改這個(gè)schema的話可以隨時(shí)更改，理論上也不需要對(duì)已有數(shù)據(jù)做更新或者遷移。

我以前用的MySQL，如果一個(gè)服務(wù)器上有多個(gè)數(shù)據(jù)庫，想遷移數(shù)據(jù)庫的時(shí)候直接考走對(duì)應(yīng)的數(shù)據(jù)庫文件就好。如果是mongodb，發(fā)現(xiàn)沒有對(duì)應(yīng)的文件，請(qǐng)問除了把數(shù)據(jù)導(dǎo)出還有別的辦法嗎？

?mongodb 不能這么玩，只能用mongodump 或者 mongoexport，或者用遷移工具。

比如在MySQL批量插入，一次3000條左右比較合適，性能也不錯(cuò)，如果是mongodb,一次插多少條比較高效？

這個(gè)沒有絕對(duì)值，通常和文檔大小有關(guān)。如果在1KB以內(nèi)的話，我會(huì)推薦用1000左右的batch size

想刪除多行數(shù)據(jù)，得對(duì)多行數(shù)據(jù)進(jìn)行備份，有什么工具可以生成反向語句insert進(jìn)行備份嗎?

換一個(gè)思路。

使用MongoDB Ops Manager可以實(shí)現(xiàn)任意時(shí)間點(diǎn)恢復(fù) - 比如你3：00執(zhí)行刪除動(dòng)作，4：00發(fā)現(xiàn)有問題想回滾，那么可以使用ops manager 把數(shù)據(jù)庫回到3：00的時(shí)候。

類似的事情可以用命令行方式做，但是就不是小項(xiàng)目了。反向生成insert的沒有見過，但是自己實(shí)現(xiàn)應(yīng)該很簡(jiǎn)單。

mongodb $in子句有長度限制嗎？另外mongodb的 findMany返回的游標(biāo)，會(huì)不會(huì)有內(nèi)存溢出的問題呢？

理論上沒有，只有bson 大小限制（16MB）。但實(shí)際上我用到1000的時(shí)候查詢就很慢了。

MongoDB官方好像是建議1主1從1arbiter。如果是1主2從，主節(jié)點(diǎn)掛掉后，兩個(gè)從節(jié)點(diǎn)都投票給自己，這樣僵持，不是會(huì)沒法產(chǎn)生新的master嗎？

“MongoDB官方好像是建議1主1從1arbiter” 請(qǐng)?zhí)峁┫鄳?yīng)的文章。

主節(jié)點(diǎn)掛了以后，兩個(gè)從節(jié)點(diǎn)的投票算法會(huì)防止你說的現(xiàn)象發(fā)生。

具體來說，如果兩個(gè)從節(jié)點(diǎn)條件完全一樣，那么第一個(gè)主張的節(jié)點(diǎn)就獲勝。如果兩個(gè)從節(jié)點(diǎn)同時(shí)主張自己，那么兩個(gè)人同時(shí)放棄，并用一個(gè)隨機(jī)值等待一小段時(shí)間（數(shù)秒），然后重試。所以總有一個(gè)節(jié)點(diǎn)會(huì)在另一個(gè)之前選為主節(jié)點(diǎn)。

通常怎樣提高寫性能？

?升級(jí)存儲(chǔ)是最直接的方案，如PCIE + SSD

- 注意索引的數(shù)量：索引越多寫入越慢

- 分片： 增加寫的節(jié)點(diǎn)來提供并發(fā)

如果是奇數(shù)節(jié)點(diǎn)，那么主節(jié)點(diǎn)掛掉，不就變成偶數(shù)節(jié)點(diǎn)了？

總數(shù)是看最初的配置，如你部署并配置了3個(gè)，雖然壞了一個(gè)，但是你的拓?fù)溥€是3節(jié)點(diǎn)， 按3節(jié)點(diǎn)的規(guī)則，剩下2個(gè)存活就可以正常工作。

1.建立3個(gè)獨(dú)立的單機(jī)庫，然后導(dǎo)入同一份數(shù)據(jù)，然后將3個(gè)節(jié)點(diǎn)設(shè)置為復(fù)制集模式，那么被設(shè)置為從節(jié)點(diǎn)的數(shù)據(jù)庫里面的數(shù)據(jù)會(huì)被清空，然后再從主節(jié)點(diǎn)再同步回來嗎？

2.如果3個(gè)節(jié)點(diǎn)通過公網(wǎng)ip地址互連，那么這中間的數(shù)據(jù)通信需要做安全防護(hù)嗎？也就是這個(gè)時(shí)候節(jié)點(diǎn)間的通信數(shù)據(jù)被竊取，是否有泄露數(shù)據(jù)的風(fēng)險(xiǎn)？

1）是的會(huì)重新同步。節(jié)點(diǎn)之間判斷是否需要同步是根據(jù)local庫里的元數(shù)據(jù)決定的。里面記錄了節(jié)點(diǎn)同步的狀態(tài)信息，并不是看你實(shí)際存儲(chǔ)的數(shù)據(jù)。

2）建議用SSL/TLS 加密鏈路就可以有效防止數(shù)據(jù)被竊取。

https://docs.mongodb.com/manual/tutorial/configure-ssl/index.html

太多的slave 數(shù)據(jù)節(jié)點(diǎn)，都從主節(jié)點(diǎn)拉oplog 是否反而增加了主節(jié)點(diǎn)的壓力？反而讓主節(jié)點(diǎn)性能變差了？

寫主 讀取從的這種配置是否還被推薦？什么場(chǎng)景適合這種？

太多從節(jié)點(diǎn)會(huì)增加主節(jié)點(diǎn)的壓力，大概是每增加一個(gè)節(jié)點(diǎn)會(huì)有10%左右的性能影響。

主從讀寫分離還是比較常見的。所有讀操作對(duì)數(shù)據(jù)時(shí)效（如報(bào)表型，或者歷史數(shù)據(jù)）不高的都可以用從節(jié)點(diǎn)。

增加副本集節(jié)點(diǎn)，只能提高并發(fā)訪問能力，單個(gè)查詢并不會(huì)變快。

那么有辦法通過水平擴(kuò)展的方式提高單個(gè)查詢的性能嗎？

?通過水平擴(kuò)展可以提高整體的吞吐量，但是單個(gè)（比如說，查詢 id=1234 這條記錄）查詢是不會(huì)得到改善的。因?yàn)檫@個(gè)查詢就是會(huì)在一個(gè)節(jié)點(diǎn)上發(fā)生。

提高單個(gè)查詢性能就是把數(shù)據(jù)放在內(nèi)存里，加上合適的索引可以來提升性能（降低讀取延遲）

選舉是發(fā)生在主節(jié)點(diǎn)故障時(shí)，那么它也會(huì)參與投票么？

主節(jié)點(diǎn)故障如果是進(jìn)程crash或者server crash，那么它當(dāng)然無法進(jìn)行選舉。

如果故障是因?yàn)楣?jié)點(diǎn)之間網(wǎng)絡(luò)不通，那失聯(lián)的主節(jié)點(diǎn)會(huì)自動(dòng)降級(jí)為從節(jié)點(diǎn)。

如果是短暫故障馬上回復(fù)后，主節(jié)點(diǎn)（這個(gè)時(shí)候已經(jīng)是從節(jié)點(diǎn)了）會(huì)重新加入選舉，但是有個(gè)30秒的等待期。

復(fù)制集主從讀寫分離看起來很美好，但是如果對(duì)主從同步延時(shí)要求高，使用就很受限。

比如某些業(yè)務(wù)會(huì)寫操作多，實(shí)時(shí)要求高的讀場(chǎng)景多，這樣主節(jié)點(diǎn)壓力就很大，而從節(jié)點(diǎn)可以分擔(dān)的業(yè)務(wù)場(chǎng)景非常有限。

老師如何看待復(fù)制集架構(gòu)在這種業(yè)務(wù)場(chǎng)景中的應(yīng)用和優(yōu)化呢？

對(duì)。

讀寫分離的讀一般指的是對(duì)時(shí)效性要求不高的讀場(chǎng)景。

如果要求高一般都建議讀主節(jié)點(diǎn)。如果主節(jié)點(diǎn)性能扛不住，這個(gè)時(shí)候就要采用分片集群來分擔(dān)壓力(讀和寫)。

我們想使用此方式來提高mongodb的查詢性能， 復(fù)制集采用一主兩從，主節(jié)點(diǎn)使用memeory，從節(jié)點(diǎn)wiredtiger。 這樣是否能夠提供查詢效率？

這樣做是OKAY的，當(dāng)然要注意InMemory Engine是商業(yè)版產(chǎn)品需要付費(fèi)。

之前有人用RAMDISK方式來模擬InMemory，但是由于代碼還是WT，所以和真正的InMemory Engine還是有些差別。

復(fù)制集，有沒有集群，就是分布式存儲(chǔ)?

?復(fù)制集也是集群，3個(gè)節(jié)點(diǎn)以上的高可用集群。

數(shù)據(jù)不做分布式存儲(chǔ)，只是主從熱備。

復(fù)制集能基于數(shù)據(jù)庫粒度嗎??

復(fù)制集只能同步所有數(shù)據(jù)庫嗎，能只同步選擇的數(shù)據(jù)庫嗎？

公司項(xiàng)目數(shù)據(jù)庫服務(wù)實(shí)例有多個(gè)數(shù)據(jù)庫,但是只想遷移部分?jǐn)?shù)據(jù)庫. dump oplog選項(xiàng)也不支持?jǐn)?shù)據(jù)庫粒度, 但是阿里云DTS和tapData又能基于oplog做數(shù)據(jù)庫粒度的毫秒級(jí)同步增量遷移,怎么做到的呢?

這個(gè)功能提了幾年了，但是還沒支持。

復(fù)制集的設(shè)計(jì)原理是基于3個(gè)節(jié)點(diǎn)是完全等同的基礎(chǔ)上（因?yàn)闀?huì)主從切換）。

當(dāng)然，對(duì)于某些指定的非主節(jié)點(diǎn)（第4個(gè)以上，priority為0)， 技術(shù)上實(shí)現(xiàn)庫級(jí)/選擇性同步是可以的的，只不過這個(gè)優(yōu)先級(jí)不高，沒有在mongo產(chǎn)品路線圖里實(shí)現(xiàn)而已。

1主2從的復(fù)制集節(jié)點(diǎn)，當(dāng)主掛掉了，怎么從2個(gè)從節(jié)點(diǎn)中選擇新的主節(jié)點(diǎn)呢？

主掛掉了，但是節(jié)點(diǎn)的架構(gòu)沒有變，還是3個(gè)節(jié)點(diǎn)（2個(gè)好的，1個(gè)壞的）。符合大多數(shù)原則，可以選舉主節(jié)點(diǎn)。

1.主從這種配置實(shí)現(xiàn)了高可用和高并發(fā)，一主二從的配置其實(shí)就是一份數(shù)據(jù)最終落到了三臺(tái)機(jī)器，如果數(shù)據(jù)太多，導(dǎo)致磁盤不夠用，增加從節(jié)點(diǎn)是沒有用的對(duì)吧？是不是只能增加磁盤容量才可以？

2.對(duì)于mongo，究竟多大的數(shù)據(jù)量和并發(fā)量適合使用mongo，這個(gè)有什么評(píng)估標(biāo)準(zhǔn)嗎？

1. 你的理解是正確的。需要分片或者增加容量。

2. 如果不是為別的考量，只是數(shù)據(jù)量，通常我見的比較多的是億級(jí)以上的數(shù)據(jù)量，可以考慮mongodb。

主從復(fù)制是否會(huì)產(chǎn)生延遲，如果有延遲，那么常見有哪些因素會(huì)導(dǎo)致延遲，該如何避免或者降低延遲?

主從復(fù)制會(huì)有延遲。常見因素：

1） 網(wǎng)絡(luò)抖動(dòng) （沒辦法）

2）網(wǎng)絡(luò)擁擠 （評(píng)估數(shù)據(jù)增量需求，給予足夠的帶寬）

3）節(jié)點(diǎn)之間延遲太長

4）主節(jié)點(diǎn)壓力過大 （注意監(jiān)控，壓力過大要擴(kuò)容）

5）從節(jié)點(diǎn)配置不均衡，低于主節(jié)點(diǎn)配置（盡量均衡）

副本集提高讀性能，是指提高并發(fā)訪問的性能，還是指單個(gè)查詢會(huì)變快？或者二者兼有之？

通過增加節(jié)點(diǎn)，并且每個(gè)節(jié)點(diǎn)同時(shí)提供服務(wù)來提高并發(fā)訪問能力。

單個(gè)查詢的性能不受影響（不會(huì)變快）。

mongodb 的復(fù)制線程是主節(jié)點(diǎn)上的線程還是從節(jié)點(diǎn)上的線程？

復(fù)制是主節(jié)點(diǎn)通知從節(jié)點(diǎn)還是從節(jié)點(diǎn)定時(shí)拉取呢？

主從復(fù)制是由從節(jié)點(diǎn)的線程發(fā)起的。通過監(jiān)聽主節(jié)點(diǎn)的oplog表的變化，并把oplog的entries pull到從節(jié)點(diǎn)進(jìn)行回放。

oplog變化通知的方式類似于你在linux 下執(zhí)行一個(gè)tail -f 命令，一旦你tail的文件（oplog）有變化，馬上就會(huì)打印出來?；蛘咴趈ava里是類似于observable pattern。

1 投票節(jié)點(diǎn)疑問：

投票節(jié)點(diǎn)為什么不建議用？我看有的書上，如果是偶數(shù)的時(shí)候，又增加一個(gè)投票節(jié)點(diǎn)，這樣就變成奇數(shù)了，比如3個(gè)數(shù)據(jù)節(jié)點(diǎn)，2個(gè)投票節(jié)點(diǎn)。mongo為什么要設(shè)計(jì)投票節(jié)點(diǎn)？

2 集群部署問題：

1 從節(jié)點(diǎn)之間出現(xiàn)心跳不通，但是都和主節(jié)點(diǎn)是通的，這個(gè)會(huì)出現(xiàn)問題么？是不是網(wǎng)絡(luò)結(jié)構(gòu)部署有問題？

1）投票節(jié)點(diǎn)的最早設(shè)計(jì)初衷：需要奇數(shù)節(jié)點(diǎn)滿足一致性協(xié)議，但同時(shí)又想節(jié)省資源。為何不建議用？降低的可用性（丟一個(gè)數(shù)據(jù)節(jié)點(diǎn)后風(fēng)險(xiǎn)很高），無法使用更高的writeConcern（后續(xù)章節(jié)會(huì)講）來保證在主從切換的時(shí)候保證不丟失數(shù)據(jù)

2） 這種現(xiàn)象出現(xiàn)的可能性不大，你可以嘗試下畫下網(wǎng)絡(luò)拓?fù)洌唧w到物理層鏈路。如果真的出現(xiàn)了，應(yīng)該是可以繼續(xù)工作的。

選舉這塊，如果有三個(gè)節(jié)點(diǎn)，leader節(jié)點(diǎn)掛了，剩余的兩個(gè)節(jié)點(diǎn)能對(duì)外提供服務(wù)嗎？能完成選舉不？

可以 - 剩下兩個(gè)滿足大多數(shù)（2）就可以正常完成選舉并工作。

Mongodb2.4主從架構(gòu)，從庫復(fù)制從主庫復(fù)制數(shù)據(jù)時(shí)會(huì)清空本地所有數(shù)據(jù)，然后再同步？

如果是因?yàn)橥綔螅^oplog window大小，或者是數(shù)據(jù)庫損壞，或者是剛加入主庫，都需要執(zhí)行initial syn的操作，這個(gè)就會(huì)清空本地庫再同步。

請(qǐng)問下有關(guān)選舉過程：對(duì)于保證大多數(shù)選舉節(jié)點(diǎn)存活這一個(gè)條件。

舉例有7個(gè)選舉節(jié)點(diǎn)，是不是意味著必須有4個(gè)節(jié)點(diǎn)以上存活才可以進(jìn)行選舉？如果有4個(gè)節(jié)點(diǎn)存活，但是存活節(jié)點(diǎn)是偶數(shù)個(gè)，是否可以完成RAFT算法完成選舉。還是說選舉節(jié)點(diǎn)必須是奇數(shù)個(gè)？

選舉節(jié)點(diǎn)必須是奇數(shù)，過半數(shù)（4）才可以工作和選舉

第一個(gè)問題：關(guān)于復(fù)制集這塊的secondary是怎么從主庫來來取oplog的，實(shí)現(xiàn)的細(xì)節(jié)是什么？想了解這塊的出發(fā)點(diǎn)就是作為dba的話，會(huì)經(jīng)常遇到一些生產(chǎn)問題，需要從原理上解決問題？

第二個(gè)問題：在local下，有幾個(gè)關(guān)于副本集的集合，這幾個(gè)集合是干什么用的，排查問題的時(shí)候，這幾個(gè)表有什么作用？

第三個(gè)問題: 我有一個(gè)副本集，現(xiàn)在對(duì)一個(gè)secondary進(jìn)行了物理的熱備，之后，想把這個(gè)節(jié)點(diǎn)加入現(xiàn)有集群,是只需要配置參數(shù)文件，add加入副本集就可以嗎？如果可以加入副本集的話，他是通過哪個(gè)集合來判斷從哪個(gè)時(shí)間點(diǎn)開始來取oplog的？

第一個(gè)問題你可以先看下這篇博客：

https://www.cnblogs.com/Joans/p/7723554.html

如果進(jìn)一步了解的話，源碼也可以嘗試閱讀下

第二個(gè)問題也在上面的文章里有提及

第三個(gè)問題：可以的，但是要通過對(duì)local庫下面的一些表做個(gè)手腳。如果你用MongoDB的Ops Manager的話，它就提供這種方法來快速恢復(fù)一個(gè)從節(jié)點(diǎn)。

https://docs.opsmanager.mongodb.com/v1.4/tutorial/use-restore-to-seed-secondary/

其中關(guān)鍵的集合是system.replset 以及oplog.rs。 system.replset必須包含對(duì)應(yīng)的配置（和其他節(jié)點(diǎn)一致）和時(shí)間戳。oplog.rs必須包含至少一條和主節(jié)點(diǎn)oplog一樣的記錄用來匹配同步點(diǎn)。

請(qǐng)問下配置復(fù)制集的時(shí)候用IP+端口的方式可以嗎？

可以的 - 如果能用hostname最好

我們的生產(chǎn)環(huán)境只有一臺(tái)服務(wù)器，但有2個(gè)硬盤。做一主一從副本集，有意義嗎？

意義不是很大，你crash了一個(gè)進(jìn)程，另一個(gè)進(jìn)程也是沒法正常服務(wù)（需要3個(gè)節(jié)點(diǎn)才可以有HA）。硬盤的容錯(cuò)直接用RAID就可以。

請(qǐng)教一下采用多副本集后，主節(jié)點(diǎn)寫，其他復(fù)制集讀，但有時(shí)候主會(huì)切換成其他副節(jié)點(diǎn)，導(dǎo)致訪問mongodb的端口變化，調(diào)用程序無法連接上之前主節(jié)點(diǎn)進(jìn)行寫入操作，前端調(diào)用程序該如何處理？

“但有時(shí)候主會(huì)切換成其他副節(jié)點(diǎn)” 你是在同一臺(tái)服務(wù)器上起了幾個(gè)不同端口的實(shí)例？這樣的復(fù)制集/副本集是沒有意義的。

這種場(chǎng)景是常見的，在mongo世界里。你的連接串要同時(shí)包含3個(gè)節(jié)點(diǎn)的IP：PORT，這樣在切主的時(shí)候mongo的驅(qū)動(dòng)會(huì)自動(dòng)連到下一個(gè)主節(jié)點(diǎn)，你的應(yīng)用程序無需處理。

我有兩個(gè)問題：

1從節(jié)點(diǎn)是主動(dòng)監(jiān)聽主節(jié)點(diǎn)的op log并拉取嗎？?

mongo 選舉的時(shí)候，怎么知道集群中一共有多少節(jié)點(diǎn)？還有就是自己是和大多數(shù)節(jié)點(diǎn)互通的？

1: 是的。

2: 配置。開始搭建集群時(shí)候就要配置一下（或者通過add方法增加節(jié)點(diǎn)）

在做復(fù)制架構(gòu)是在現(xiàn)有的環(huán)境做，這樣是會(huì)自動(dòng)將現(xiàn)有的節(jié)點(diǎn)設(shè)置為主嗎？

還是要將現(xiàn)有節(jié)點(diǎn)數(shù)據(jù)同步到新節(jié)點(diǎn)上。還是要在初始化的時(shí)候指定優(yōu)先級(jí)？

順序是：

1） 關(guān)掉mongo 服務(wù)

2）以復(fù)制集模式重新啟動(dòng)mongo（加replSet 參數(shù))

3) 初始化復(fù)制集

4）增加第二（三）個(gè)節(jié)點(diǎn)（新的節(jié)點(diǎn)）

5） 等待initialSync 完成

這個(gè)時(shí)候你的原來的節(jié)點(diǎn)會(huì)是主節(jié)點(diǎn)。

我有多個(gè)復(fù)制集，當(dāng)我想提升讀能力的時(shí)候。

是不是在讀的時(shí)候，要?jiǎng)討B(tài)切換這些復(fù)制集的地址？

如果可以接受從節(jié)點(diǎn)讀，那么可以使用 readPreference: secondary/nearest (后續(xù)有講如何使用）。這種方式可以使用更多的節(jié)點(diǎn)來支持讀操作。

復(fù)制集和分片機(jī)制有什么區(qū)別？

我們可以對(duì)數(shù)據(jù)分片到不同機(jī)器上的同時(shí)保留復(fù)制集嗎？部署配置方式有區(qū)別嗎？

復(fù)制集提供高可用，分片集在此基礎(chǔ)上橫向擴(kuò)充，增加系統(tǒng)對(duì)數(shù)據(jù)量/并發(fā)量的支持。分片集由2個(gè)或多個(gè)復(fù)制集組成。

我在搭建集群的過程中遇到一個(gè)問題。?

如果我集群中的所有節(jié)點(diǎn)都設(shè)置了密碼，在使用rs.add("host:port")時(shí)會(huì)報(bào)沒有權(quán)限。此時(shí)我該如何解決呢？

可能的問題：

1. 沒有為各個(gè)節(jié)點(diǎn)配置KeyFile，或者

2. 啟用認(rèn)證之后沒有創(chuàng)建管理員賬戶。rs.add()需要權(quán)限才能執(zhí)行。

3.不能用local 庫。那個(gè)是系統(tǒng)保留的。用任意其他庫都可以。如 use test

試過用mysql 做讀寫分離，開了binlog做主從同步。遇到一種情況，主庫寫太頻繁(load file操作，沒有事務(wù))，從庫同步延遲越來越大。

oplog的原理是否也是記錄成文件之后傳輸?shù)綇墓?jié)點(diǎn)，由專門線程回放，mongodb是否也會(huì)出現(xiàn)這種問題？

oplog 和 binlog類似。并且在壓力超大的時(shí)候，也有可能在從節(jié)點(diǎn)造成一些延遲。當(dāng)然mongodb可以用多線程同時(shí)來回放。

講到MongoDB Ops Manager 集群管理平臺(tái)時(shí)，說到該軟件支持 分片集群的備份。

請(qǐng)問分片集群的備份是什么意思？mongodump 做不了嗎？

mongodump 能做全量備份，但是做不到一致性備份。比如說，你想要一個(gè)半夜12點(diǎn)的備份，希望這個(gè)備份能夠還原那個(gè)時(shí)間點(diǎn)的分片數(shù)據(jù)庫的準(zhǔn)確狀態(tài)。事實(shí)上，當(dāng)你12點(diǎn)開始跑的時(shí)候，可能要跑幾十分鐘到數(shù)小時(shí)才能備份完。這個(gè)時(shí)候又有持續(xù)的寫入（可能會(huì)在備份里，可能不會(huì)在，取決于mongodump的讀取順序），所以你這個(gè)備份是屬于不一致狀態(tài)。

Ops Manager有自己獨(dú)特的機(jī)制來保證一個(gè)備份的多個(gè)分片之間數(shù)據(jù)是在一個(gè)時(shí)間點(diǎn)上一致的。

1 MongoDB鎖能否支持行級(jí)鎖？

2. 64G內(nèi)存的虛擬機(jī) 能否設(shè)置大于50%的wiredTiger cacheSizeGB?

?1）MongoDB采用的是MVCC機(jī)制，實(shí)際效果和行級(jí)鎖類似。

2）可以的，但是要考慮到mongodb除了緩存以外自身還需要額外內(nèi)存，所以要適當(dāng)給操作系統(tǒng)和mongo本身留一些。

從課程目錄里沒有看到有介紹MongoDB的數(shù)據(jù)庫引擎的內(nèi)容。在這個(gè)課程里是不會(huì)涉及這部分內(nèi)容嗎？

因?yàn)槟壳拔覀児臼褂玫膯喂?jié)點(diǎn)MongoDB數(shù)據(jù)庫，每隔一段時(shí)間就會(huì)被服務(wù)器的OOM殺掉，在網(wǎng)上搜索了下相關(guān)資料，設(shè)置了WiredTiger引擎可用的緩存大小，但并沒有起作用，從系統(tǒng)日志里還是能看到MongoDB在占用了5G左右的內(nèi)存后被OOM殺掉。

MongoDB不僅僅是WiredTiger 緩存占據(jù)內(nèi)存，除了緩存外，還有連接管理，聚合計(jì)算，排序等都會(huì)用到。

另外你可以注意下swap有無配置。配置swap可能可以緩解OOM的問題。

第三范式的理由是什么呢？是因?yàn)楣?jié)省數(shù)據(jù)庫空間嗎？

因?yàn)槲腋杏X只有一個(gè)group的表然后有name, description和一組contact_id的數(shù)組也可以把？中間抽離一個(gè)contactGroup的意義何在呢？

第三范式是關(guān)系設(shè)計(jì)的實(shí)踐。

節(jié)省空間是一個(gè)很大的驅(qū)動(dòng) - 關(guān)系型理論出來的時(shí)候，1GB硬盤需要10萬美元的價(jià)格。

數(shù)據(jù)一致性也是第三范式的一個(gè)目標(biāo)。

你說的那種方式就是MongoDB的設(shè)計(jì)模式了。內(nèi)嵌數(shù)組。

mongodb除了collection之外還有一個(gè)功能可以存附件，比如文件，視頻，音頻等。這個(gè)是和普通關(guān)系型數(shù)據(jù)庫有區(qū)別的地方吧，還有就是以前面試的時(shí)候，面試官也拿mongodb和fastdfs提問，兩者有什么區(qū)別，老師你可以用之前的項(xiàng)目經(jīng)驗(yàn)解答下么？

MongoDB的GridFS 不是一個(gè)真正的filesystem。

它其實(shí)是一個(gè)api sugarcoating。實(shí)現(xiàn)是在驅(qū)動(dòng)端（不是mongodb服務(wù)器），提供一個(gè)字節(jié)流的API， 允許你把二進(jìn)制文件通過這個(gè)接口提交給MongoDB 驅(qū)動(dòng)，或者從這個(gè)接口讀取二進(jìn)制文件流。然后驅(qū)動(dòng)會(huì)把這個(gè)文件分塊，每一塊作為一個(gè)mongodb的文檔插入到集合里。 當(dāng)你需要的時(shí)候，mongodb驅(qū)動(dòng)會(huì)把所有相關(guān)的切塊讀出來，拼成一整個(gè)文件，返回給應(yīng)用程序。

所以這個(gè)不是真的文件系統(tǒng)，只是提供了一個(gè)虛擬的文件接口供應(yīng)用進(jìn)行文件存儲(chǔ)和讀取。優(yōu)點(diǎn)是可以用到mongo的分布式能力，做海量的二進(jìn)制文件管理和高可用等。

在學(xué)習(xí)過程中遇到一個(gè)概念Tailable Cursor，這個(gè)應(yīng)該怎么理解呢？

Linux 有個(gè)命令叫tail，如果你理解那個(gè)的用法，就知道這個(gè)名詞的由來了。

tail -f debug.log

這個(gè)命令會(huì)打印debug.log 的內(nèi)容，然后不會(huì)退出，會(huì)在那里監(jiān)聽debug.log文件是否有新的日志寫入，一旦有新的，就會(huì)馬上在控制臺(tái)打印出來。

使用tailable cursor, 你的程序不會(huì)退出，讀完cursor最后一條以后會(huì)block，等待下一條數(shù)據(jù)過來后繼續(xù)。很多時(shí)候可以用來做一些類似Java里面 observer pattern的事情或者傳統(tǒng)數(shù)據(jù)庫里觸發(fā)器的事情。

使用的mongo是4.0.11版本的，架構(gòu)是分片集群，現(xiàn)在問題是，默認(rèn)的最大連接數(shù)不夠用的，819，怎么調(diào)優(yōu)最大連接數(shù)？

有可能是和ulimits相關(guān)。你看下這個(gè)

https://docs.mongodb.com/manual/reference/ulimit/

日志、journal、oplog 這三個(gè)有什么聯(lián)系與區(qū)別呢？

日志： 這個(gè)是一個(gè)比較通用的概念，可以包括你說的所有（journal,oplog,以及server日志）。

具體一點(diǎn)來說， journal日志是數(shù)據(jù)庫的crash recovery手段。通常的做法是把數(shù)據(jù)庫內(nèi)的數(shù)據(jù)塊修改，提前用文件順序?qū)懛绞剿⒌奖P上，然后再去真正的提交數(shù)據(jù)的修改。這樣的目的是在服務(wù)器宕機(jī)的時(shí)候，內(nèi)存中被丟失的數(shù)據(jù)可以在恢復(fù)過程中從journal 日志文件中讀回來。

Oplog也是記錄的數(shù)據(jù)庫的操作日志，但是記的是邏輯操作命令。主要的目的是用于節(jié)點(diǎn)之間復(fù)制數(shù)據(jù)，而不是上面journal主要是用來recover crash。

還有一種就是mongod.log，這個(gè)就是一個(gè)文本文件，記錄數(shù)據(jù)庫系統(tǒng)的正常運(yùn)行和錯(cuò)誤信息等等。

Mongo 落盤的時(shí)候，有用到文件系統(tǒng)的 Page Cache 機(jī)制嗎？

當(dāng)有一條數(shù)據(jù)更新的時(shí)候是先寫到內(nèi)存，然后是Page Cache 最后是 硬盤嗎？

j 這個(gè)參數(shù)是代表寫到 Page Cache 還是硬盤呢？

j:1 表示Journal 日志刷盤，所以就是要寫文件到硬盤。

正常數(shù)據(jù)只是寫到內(nèi)存的Cache（不是操作系統(tǒng)的cache，而是WiredTiger自己管理的Cache），然后異步刷盤。

mongodb事務(wù)的默認(rèn)隔離級(jí)別是什么？

默認(rèn)是read uncommitted。

正常情況都不會(huì)有問題，除了發(fā)生宕機(jī)的時(shí)候，這個(gè)可能會(huì)有問題 - 你讀到的一條數(shù)據(jù)可能會(huì)在宕機(jī)的時(shí)候被回滾掉。這種事情概率很小，發(fā)生了可能問題也不算特別嚴(yán)重，很多場(chǎng)景可以接受。如果要求比較高，那么需要用 readConcern: majority 來提高隔離級(jí)別。

按照mongodb復(fù)制集選舉規(guī)則，有最新數(shù)據(jù)的會(huì)第一優(yōu)先被選為主節(jié)點(diǎn)

mongo是否可以在服務(wù)器端配置 majority write concern ，跟 j : true ？

服務(wù)器端無法配置。

你可以在Connection String上設(shè)置，這個(gè)一般是全局統(tǒng)一的設(shè)置。

例子：mongodb://db0.example.com,db1.example.com,db2.example.com/?replicaSet=myRepl&w=majority&wtimeoutMS=5000

詳細(xì)文檔：

https://docs.mongodb.com/manual/reference/connection-string/

oplog是在內(nèi)存中還是在磁盤上呢？?

每一次寫操作都會(huì)事務(wù)的記錄oplog?

oplog和就是一個(gè)MongoDB的collection ，都是存儲(chǔ)在磁盤上的。 對(duì)oplog的操作只是順序追加寫入，所以效率相對(duì)來說會(huì)高不少，相比于普通collection 的隨機(jī)讀寫。

每一次增刪改都會(huì)記錄相應(yīng)的oplog，并且對(duì)oplog的操作和數(shù)據(jù)表的寫入是同一個(gè)原子事務(wù)的。

為什么說寫入多數(shù)集群才算安全呢？

寫入多數(shù)節(jié)點(diǎn)后，即時(shí)一個(gè)節(jié)點(diǎn)數(shù)據(jù)失效/不可用，你的數(shù)據(jù)還在另外一個(gè)節(jié)點(diǎn)上。是從這個(gè)角度。

請(qǐng)問怎樣限制 MongoDB 使用的總內(nèi)存大??？

32GB只是控制數(shù)據(jù)的緩存空間大小。MongoDB服務(wù)器本身還需要內(nèi)存來進(jìn)行工作，如管理TCP連接，聚合、排序運(yùn)算等。

chunk過程中各個(gè)分片上的oplog是會(huì)變化的嗎？這時(shí)候oplog跟分片上的數(shù)據(jù)能對(duì)應(yīng)起來嗎？

會(huì)產(chǎn)生日志。日志里有個(gè)特殊字段會(huì)標(biāo)記出來是來自于chunk migration

change stream是如何觸發(fā)微服務(wù)的？比如庫存低于一定閾值后，觸發(fā)Java服務(wù)發(fā)送郵件

可以看這個(gè)例子：

https://github.com/spring-projects/spring-data-examples/tree/master/mongodb/change-streams

MongoDB適合存儲(chǔ)車輛GPS信息嗎？比如十萬輛車，每輛車每十秒上傳一次GPS信息（時(shí)間，坐標(biāo)，方向，位置，速度等），MongoDB可以支持這種量級(jí)的數(shù)據(jù)嗎？還要考慮車輛位置實(shí)時(shí)監(jiān)控，歷史時(shí)間段軌跡查詢等應(yīng)用。

這個(gè)有非常多的案例。比較著名的是有最大的一個(gè)共享單車，國內(nèi)最大的汽車制造廠之一，以及最著名的電動(dòng)車廠都是用mongo來記錄車輛GPS位置。放心去用吧。

請(qǐng)問MongoDB復(fù)制集的連接數(shù) 和機(jī)器的配置應(yīng)該怎么換算？怎么樣達(dá)到合理的連接數(shù)？

可以參考下這個(gè)文檔：

https://docs.atlas.mongodb.com/connection-limits/index.html

mongodb atlas云服務(wù)里面的規(guī)格和AWS機(jī)器規(guī)格對(duì)應(yīng)：

M30 m4.large

M40 m4.xlarge

M50 m4.2xlarge

M60 m4.4xlarge

請(qǐng)問MongoDB的用戶是在庫上來配置的嗎，還是只是在admin庫里配置的？

?理論上都可以 - 用戶可以在admin庫里，也可以在用戶庫里。我們一般建議建在admin庫里方便統(tǒng)一管理

在MongoDB中怎么設(shè)置本地時(shí)間，在查詢時(shí)間，顯示的時(shí)間比本地時(shí)間慢8個(gè)小時(shí)？

?目前只支持格林威治時(shí)間。。。沒法設(shè)置。

MongoDB集群分片數(shù)據(jù)分配不均衡，怎么辦 ？

少數(shù)不均衡不是問題（比如說5-10% 的差別）。多了不均衡，要看看是不是有下面問題？

1） Jumbo chunk

2） balancer 是不是停了？ sh.getBalancerState()

3) 寫入太頻繁，超過IO能力

數(shù)據(jù)量不是很大，如果要支撐百萬并發(fā)，一般要如何設(shè)計(jì)，大概要多少個(gè)節(jié)點(diǎn)，用復(fù)制集還是分片集？

官方的建議不管讀還是寫，都用分片來解決。百萬級(jí)的并發(fā)算是很大了，如果是以查為主的讀操作占絕大多數(shù)，那么一個(gè)節(jié)點(diǎn)理論上支撐10萬以上并發(fā)是可以的，當(dāng)然必須是那種32/64 核高CPU的物理服務(wù)器。 Oppo的同學(xué)分享過單集群支撐100萬+并發(fā)，該集群由14個(gè)分片組成，14x3共42臺(tái)機(jī)器

看視頻得知configsrv節(jié)點(diǎn)很重要，它保存了分片集群的元數(shù)據(jù)。

如果這個(gè)節(jié)點(diǎn)的數(shù)據(jù)因?yàn)橐恍┰驌p壞、丟失了，那集群里的各個(gè)分片還能重新組成一個(gè)新的分片集群?jiǎn)幔?br>

各個(gè)分片的數(shù)據(jù)理論上是互不重疊的，所以如果配置服務(wù)器壞的話，你將無法組成一個(gè)新的分片集群，但是你的數(shù)據(jù)可以合并起來組成非分片的集群。

當(dāng)然，考慮到分片集群某一時(shí)間點(diǎn)會(huì)有正在分片之間遷移的數(shù)據(jù)，這個(gè)數(shù)據(jù)合并還是有點(diǎn)風(fēng)險(xiǎn)。

所以你的配置服務(wù)器，也是需要3個(gè)節(jié)點(diǎn)來保證數(shù)據(jù)的可靠性。

mongodb還需要考慮分庫分表嗎，如果要考慮一般是在什么數(shù)量級(jí)別才分呢？

一般原則是不需要。

如果你的應(yīng)用場(chǎng)景用不到數(shù)據(jù)合并（連統(tǒng)一報(bào)表都不需要），并且數(shù)據(jù)量級(jí)在10億級(jí)以上，可以考慮作為一個(gè)特殊優(yōu)化手段做分表。

數(shù)據(jù)大小與機(jī)器配置有沒有經(jīng)驗(yàn)換算方式，比如1TB數(shù)據(jù)，1主2從復(fù)制集，單臺(tái)服務(wù)器需要多大的配置，CPU、內(nèi)存，還是需要模擬壓測(cè)？

官方?jīng)]有標(biāo)準(zhǔn)算法 - 根據(jù)workload的不同，硬件配置可以差別很大。

你可以參考MongoDB Atlas上面有個(gè)機(jī)器大小可以支持的Connections，所以從應(yīng)用要支持的連接數(shù)，可以做一個(gè)反推。但是并不考慮你的數(shù)據(jù)量，所以只是個(gè)概括估計(jì)。

https://docs.atlas.mongodb.com/connection-limits/index.html

mongo分片集群如何實(shí)現(xiàn)讀寫分離？需要配置哪些？可以提供一些資料查看嗎？

分片的讀寫分離和復(fù)制集的是一樣機(jī)制?？梢圆殚喴幌翸ongoDB read preference。參數(shù)可以直接給到mongos連接串。

視頻課程相關(guān)內(nèi)容在這里

https://time.geekbang.org/course/detail/100040001-176897

我們生產(chǎn)使用的是分片模式，但是有一個(gè)集合沒有建片鍵，這個(gè)集合現(xiàn)在太大了占了7.4TB

1：現(xiàn)在怎么建片鍵，可以建嗎？

2：建了片鍵之后會(huì)不會(huì)影響之前的數(shù)據(jù)查詢

1）可以，直接用shardCollection就可以

2）不會(huì)。

數(shù)據(jù)均衡可能會(huì)花很長時(shí)間（數(shù)天），這是正常的。

沒有分片的集合是會(huì)隨機(jī)找個(gè)shard 復(fù)制集存嗎？

mongos在你新建庫的時(shí)候會(huì)為你的庫挑一個(gè)“primary shard”，所有未分片的集合都會(huì)在這個(gè)shard里面。挑選的規(guī)則就是看哪個(gè)分片相對(duì)數(shù)據(jù)量小一點(diǎn)。

mongos configsvr 是否需要高內(nèi)存 多核心的服務(wù)器，這2個(gè)服務(wù)能部署在同一個(gè)服務(wù)器上面么？

config server通常有1~2c就可以,內(nèi)存也不用大，通常4G就可以。

mongos 因?yàn)橐薪雍芏噙B接處理，一般建議CPU還是有給夠，可以和mongod參考。因?yàn)樗痪彺鏀?shù)據(jù)，所以內(nèi)存也可以不用太大?？梢詤⒖糾ongod的一半。

有一套環(huán)境config改完端口shard不能啟動(dòng)了，還去連修改之前的端口。

為什么shard啟動(dòng)的時(shí)候會(huì)去連config？shard從哪里讀取config的信息？如何修改？

config上面存著分片的重要元數(shù)據(jù)（如chunk分布），沒有config server 分片集群無法工作的。shard server會(huì)建立到configserver的連接(正常端口）來獲取并緩存配置數(shù)據(jù)。

改完端口以后，config 復(fù)制集是否正常？你有重新啟動(dòng)mongos 和 shard mongod 實(shí)例嗎？

所有操作必須要使用mongos。不能直接使用分片主節(jié)點(diǎn)。直接操作主節(jié)點(diǎn)僅僅限于數(shù)據(jù)庫故障恢復(fù)

有的庫我不分片，目前我有2個(gè)分片集(A和B)，然后我創(chuàng)建一個(gè)新數(shù)據(jù)庫，怎么指定其在分片集B上面？

db.adminCommand( { movePrimary : "your_dbname", to : "shard0001" } )

https://docs.mongodb.com/manual/reference/command/movePrimary/

?集群如何啟用驗(yàn)證？

:集群如果啟用驗(yàn)證的話，需要用一個(gè)shared key文件，或者使用 X509 公鑰機(jī)制來進(jìn)行集群間的互相認(rèn)證。

可以先看下這個(gè)英文文檔，有問題再提。

https://docs.mongodb.com/manual/core/security-internal-authentication

1、如果兩個(gè)分片服務(wù)器性能不一樣，訪問和存儲(chǔ)可以權(quán)重類的設(shè)置嗎？

2、加入新的分片后，集群里的分片數(shù)據(jù)會(huì)自動(dòng)均衡到各分片嗎？比如首先只有第一個(gè)分片有30G數(shù)據(jù)，后面新增兩個(gè)分片，各分片會(huì)遷移10G數(shù)據(jù)嗎？

1）可以使用zone sharding方式來自己控制數(shù)據(jù)的分布。比如說分片1是16Core SSD，那你可以給它更多的數(shù)據(jù)。

2）是的，最后3個(gè)分片會(huì)各有10G左右

MongoDB備份只備份某一時(shí)刻的數(shù)據(jù)。

如果發(fā)生宕機(jī)時(shí)用備份進(jìn)行數(shù)據(jù)恢復(fù)也只能回復(fù)到備份的那一時(shí)刻。那豈不是備完成到宕機(jī)這段時(shí)間的數(shù)據(jù)不就丟失了嗎？

這個(gè)就是RPO指標(biāo)決定的。Recovery Point Objective. 如果是定期備份，你的RPO就是你的備份間隔時(shí)間，比如說24小時(shí)。這樣的話你由可能丟失24小時(shí)的數(shù)據(jù)。

如果你希望RPO最小化，就要啟用實(shí)時(shí)備份oplog的方式。MongoDB官方提供OpsManager可以實(shí)現(xiàn)，數(shù)據(jù)可以恢復(fù)到故障之前一分鐘。

然后，一般需要恢復(fù)的場(chǎng)景不是宕機(jī)。宕機(jī)這種比較常見的場(chǎng)景在MongoDB里面是通過復(fù)制集來解決的。一個(gè)節(jié)點(diǎn)宕機(jī)不影響業(yè)務(wù)，重啟就好了。

備份恢復(fù)通常是出現(xiàn)一些數(shù)據(jù)問題，比如說，有人刪庫跑路。

mongo的全量備份的時(shí)候，如果有插入或刪除數(shù)據(jù)呢，比如我在t0開始全量備份，t1時(shí)插入了一條數(shù)據(jù)，t2時(shí)備份到剛插入的數(shù)據(jù)，t3時(shí)完成備份，事后我用全量的備份數(shù)據(jù)加上期間的oplog的話，不就多插入一條數(shù)據(jù)了嗎？

oplog是有冪等性的?；胤诺臅r(shí)候，t1 的數(shù)據(jù)+oplog的一條，合在一起，還是一條。

請(qǐng)問mysql中的數(shù)據(jù)怎么遷移到mongodb呢？

對(duì)于少量數(shù)據(jù)(100M內(nèi)) 和 大量數(shù)據(jù)(幾個(gè)T) 的處理方式分別是什么呢？

如果是一次性遷移，直接導(dǎo)出到CSV文件然后使用mongoimport命令。100MB或者幾個(gè)T都是這樣。

如果是持續(xù)遷移，那需要一些專門的工具，比如說我們公司的tapdata產(chǎn)品。

為什么需要分片集備份？

不是可以用mongodump進(jìn)行全量備份嘛？

這個(gè)方法可以做備份，但是不是最嚴(yán)格的。

嚴(yán)格的備份能夠提供指定時(shí)間點(diǎn)的恢復(fù)。比如說，如果你發(fā)現(xiàn)13：01分的時(shí)候有個(gè)誤刪操作，使用好的分片備份機(jī)制，可以恢復(fù)到13：00的準(zhǔn)確狀態(tài)。而通過mongodump是沒有這種保障機(jī)制的。

我們的生產(chǎn)環(huán)境近幾日有些數(shù)據(jù)刪掉了，看還在oplog的覆蓋范圍內(nèi)，但是我們之前沒做過全量備份，這個(gè)有什么辦法可以恢復(fù)嗎？

可以通過歷史數(shù)據(jù)備份+oplog 重放來恢復(fù)，抱歉恢復(fù)不了。

副本集集群有通過物理備份+oplog實(shí)現(xiàn)任意點(diǎn)的恢復(fù)嗎，就是類似mysql的innobackupex+binlog的方式，有可參照的案例嗎？

可以的，大致步驟是：

1）用snapshot或者關(guān)機(jī)復(fù)制文件方式進(jìn)行全量備份

2）使用mongodump 備份 oplog 庫

3）恢復(fù)全量備份

4） 使用 mongorestore 的 --oplogFile --oplogLimit 參數(shù)來恢復(fù)指定的oplog 時(shí)間點(diǎn)

可以參考下面這個(gè)英文博客

https://alexmarquardt.com/2017/01/25/mongodb-point-in-time-restore

分片集群具體如何實(shí)施備份？

?停掉均衡器之后，各個(gè)節(jié)點(diǎn)通過定時(shí)任務(wù)備份（各個(gè)機(jī)器啟動(dòng)備份時(shí)間點(diǎn)是否能夠絕對(duì)一致，如果備份時(shí)間點(diǎn)存在幾秒的差別，是否有致命風(fēng)險(xiǎn)？）

停掉均衡以后，備份可以保證每個(gè)節(jié)點(diǎn)各自是準(zhǔn)確的。但是各個(gè)節(jié)點(diǎn)之間時(shí)間點(diǎn)很難保證在同一點(diǎn)上，所以每個(gè)節(jié)點(diǎn)恢復(fù)以后那個(gè)狀態(tài)不是完全同步的。這個(gè)沒有致命風(fēng)險(xiǎn)，但是確實(shí)有數(shù)據(jù)不一致的可能性。如果要做到完全一致，需要使用MongoDB 企業(yè)版 Ops Manager的分片備份功能。

mongodb啟動(dòng)參數(shù)中的logpath指的是mongo系統(tǒng)日志文件路徑， 相當(dāng)于mongodb配置文件中的systemLog.path

你可以配置MongoDB寫日志到以下目的地：

1） 本地文件 （命令行參數(shù)--logpath，或者配置文件 systemLog.path)

2) syslog （命令行參數(shù) --syslog，或者配置文件內(nèi)的systemLog.syslog)

3) 標(biāo)準(zhǔn)輸出（不用任何參數(shù)，默認(rèn)）

參見： https://docs.mongodb.com/manual/reference/configuration-options/#systemLog.path

分片的集群通過mongos連接建立的用戶是保存在哪里，config集群上面還是每個(gè)shard里面也保存？

config 集群

$? mongo -u reader -p "Reader@123"? --authenticationDatabase? admin?

上面的命令中, 一定要加上 --authenticationDatabase admin 否則會(huì)導(dǎo)致 Authentication failed。

如果黑客mongo連接進(jìn)去然后創(chuàng)建個(gè)超級(jí)用戶再登錄這種情況怎么辦?

啟動(dòng)鑒權(quán)后，你可以無密碼登錄進(jìn)去，但是只能做一件事：創(chuàng)建超級(jí)用戶。

這個(gè)事情也只能做一次（無密碼創(chuàng)建超級(jí)用戶），以后“黑客”再來，他就必須要登錄才能做創(chuàng)建用戶的事情。

所以你要做的事情，就是盡快創(chuàng)建那個(gè)超級(jí)用戶。

mongoDB 可以定義類似 MySQL 的 create_time 和 update_time 字段嗎？

可以參考 $currentDate

https://docs.mongodb.com/manual/reference/operator/update/currentDate

這個(gè)ticket默認(rèn)是128，一般調(diào)高這個(gè)值的時(shí)候需要參考哪些指標(biāo)？比如物理機(jī)內(nèi)存？cpu核數(shù)？節(jié)點(diǎn)數(shù)？有沒有相關(guān)經(jīng)驗(yàn)的最佳實(shí)踐分享下？

ticket一般只是個(gè)標(biāo)志，如果發(fā)現(xiàn)用光，是因?yàn)槟愕奈锢碣Y源不夠，主要是IOPS，少數(shù)時(shí)候CPU。這個(gè)時(shí)候不是調(diào)高tickt，而是優(yōu)化硬件資源。

最近做了個(gè)前端監(jiān)控分析的系統(tǒng)，使用了MongoDB作為數(shù)據(jù)庫，現(xiàn)在每天的存儲(chǔ)記錄達(dá)到300W+條，查詢返回百萬級(jí)數(shù)據(jù)這塊不知道怎么優(yōu)化，老師有什么建議嗎？

你需要對(duì)這些數(shù)據(jù)做pre-aggregation，按照時(shí)間顆粒度，獲得分鐘級(jí)平均數(shù)，小時(shí)級(jí)平均數(shù)，把他們事先存到庫里，給前段展現(xiàn)用。這樣的話你就不需要返回大量的原始數(shù)據(jù)再在應(yīng)用里做計(jì)算了。

聽完寫入操作的過程，有點(diǎn)好奇，oplog和journal日志能不能合并呢，我的理解的話就是oplog是個(gè)定容的集合，存放的記錄都是冪等操作，用于mongodb的復(fù)制集模式，從主節(jié)點(diǎn)復(fù)制到其他slave節(jié)點(diǎn)保證數(shù)據(jù)的一致，journal日志是用于mongodb crash之后恢復(fù)的一個(gè)日志。那crash恢復(fù)能不能也用oplog呢？

oplog記錄的是對(duì)數(shù)據(jù)庫的邏輯操作， 在MongoDB里面用一個(gè)固定大小的普通集合來記錄，和其他的數(shù)據(jù)一樣，默認(rèn)增刪都是在內(nèi)存里發(fā)生。

journal 和其他數(shù)據(jù)庫類似，采用WriteAheadLog機(jī)制，用來提供對(duì)數(shù)據(jù)庫寫入操作的一致性和持久性保證。它記錄的是要對(duì)數(shù)據(jù)物理區(qū)塊修改的一些動(dòng)作。

Journal 日志和Oplog理論上都可以用來恢復(fù)，但是journal比較底層，直接操作存儲(chǔ)區(qū)，寫入和恢復(fù)效率要比oplog 日志高，所以通常數(shù)據(jù)庫都會(huì)采用專門的journal來做crash recovery.

如果剛開始只有一臺(tái)單體，后面想擴(kuò)容，做分片，搭復(fù)制集，但是這臺(tái)單體上已經(jīng)有相當(dāng)?shù)臄?shù)據(jù)，那搭建復(fù)制集的時(shí)候是不是要先用dump等工具備份恢復(fù)一下數(shù)據(jù)？

對(duì)。使用dump/restore 可以加速這個(gè)過程。如果不用dump也是可以，時(shí)間需要更多點(diǎn)，但是也是可以完成的。

對(duì)于分片集群來說，應(yīng)用端怎樣去配置連接串呢？

只需要指定對(duì)應(yīng)的幾個(gè)分片路由節(jié)點(diǎn)連接信息就可以了么，后面的副本集發(fā)生切換對(duì)路由節(jié)點(diǎn)或應(yīng)用有沒有感知或者影響呢？

默認(rèn)只需要配路由節(jié)點(diǎn)就可以。副本集切換是透明的。

Retrywrite 只會(huì)重試一次嗎？如果重試第二次時(shí)新的primary還沒被選舉出來，是不是會(huì)寫失敗？

只會(huì)重試一次， 會(huì)一直等到primary選舉成功才會(huì)試。如果30秒還沒選出來，這個(gè)寫操作就失敗了。

30秒選不出來，這個(gè)大概率集群出故障了。

請(qǐng)問這一系列的課程，其中有一個(gè)課程(04 | MongoDB特色及優(yōu)勢(shì))，有描述到有一個(gè)企業(yè)從1.x升級(jí)到4.X，影片時(shí)間落在9:48的位置，透過滾動(dòng)服務(wù)升級(jí)，透過replica set升級(jí)的升級(jí)。未來是否有課程會(huì)討論到這一塊，我想嘗試不下線的方式，從4.2升級(jí)到4.22，不知道是否有該實(shí)作的教學(xué)？

其實(shí)比較簡(jiǎn)單的，假設(shè)ABC三個(gè)節(jié)點(diǎn)，A是當(dāng)前主節(jié)點(diǎn)，大致可以按照以下步驟：

- 停止C的mongo服務(wù)，升級(jí)C的mongodb binary文件

- 重啟C服務(wù)，等待集群穩(wěn)定

- 停止B的mongo服務(wù)，升級(jí)B的mongodb binary文件

- 重啟B服務(wù)，等待集群穩(wěn)定

- 停止A，升級(jí)A的mongodb binary文件

- 重啟A，等待集群穩(wěn)定

這里有個(gè)中文翻譯

http://www.mongoing.com/docs/release-notes/3.0-upgrade.html

切換FCV是在所有節(jié)點(diǎn)上都切換還是只在主節(jié)點(diǎn)上切換？

主節(jié)點(diǎn)上操作，會(huì)被復(fù)制到從節(jié)點(diǎn)。

MongoDB 壓測(cè)有什么好的工具和方法實(shí)踐嗎？

我們一般用 POCDriver / YCSB來做壓測(cè)。監(jiān)控的話用Ops Manager，可以整體看壓測(cè)過程中系統(tǒng)性能表現(xiàn)。

mongo是內(nèi)存數(shù)據(jù)庫嗎？ 它的數(shù)據(jù)應(yīng)該在保存到硬盤吧？

MongoDB 會(huì)在內(nèi)存里操作數(shù)據(jù)，用異步刷盤方式。所以你內(nèi)存足夠大的話，可以近似的認(rèn)為它有內(nèi)存數(shù)據(jù)庫的性能。

?事實(shí)上它有一種存儲(chǔ)引擎InMemory就是完全的內(nèi)存數(shù)據(jù)庫了。

電商網(wǎng)站的oracle部分不能用mongo替代嗎？

?完全可以。 你可以搜一下 MongoDB Cisco關(guān)鍵詞。 幾百億的訂單都在MongoDB上處理，特別是4.0以后mongo支持了多文檔事務(wù)以后。

mongodb為什么這么快，適用于秒級(jí)別的數(shù)據(jù)庫訪問（物聯(lián)網(wǎng)場(chǎng)景等）？

比如說redis雖然是單線程，但是它基于了I/O多路復(fù)用的機(jī)制。

那mongodb呢？因?yàn)樗烊坏闹С至朔植际矫矗?br>

它的數(shù)據(jù)默認(rèn)只是寫到內(nèi)存就返回。數(shù)據(jù)的安全性通過同步到其他節(jié)點(diǎn)上和journal日志來保證。

沒有IO在里面，響應(yīng)時(shí)間自然就快。

怎么在mongo shell中修改MongoDB的配置參數(shù)？

db.adminCommand( { setParameter: 1, <parameter>: <value> } )

https://docs.mongodb.com/manual/reference/command/setParameter

mongoDB 數(shù)據(jù)庫存儲(chǔ)的時(shí)間相差八小時(shí)，有什么設(shè)置可以調(diào)整嗎？還是必須要代碼轉(zhuǎn)一下？

?by design，沒法調(diào)整。這樣其實(shí)減少很多有bug的機(jī)會(huì)，就是要麻煩一點(diǎn)點(diǎn)轉(zhuǎn)一下

mongodb存儲(chǔ)文件，比如圖片和視頻，有什么方案嗎？

大視頻不太適合放mongodb。圖片可以考慮。

如果真的存，直接用GridFS API就可以。還是挺方便的。

MongoDB 專家之路的 3 個(gè)建議：

1、去 MongoDB 網(wǎng)絡(luò)大學(xué)注冊(cè)學(xué)習(xí)，并通過認(rèn)證考試。（https://university.mongodb.com）

2、通過官方文檔學(xué)習(xí)。（https://docs.mongodb.com）

3、MongoDB 中文社區(qū)收集了很多 MongoDB 專家的精華文章和案例分享。（http://www.mongoing.com）