MongoDB專案過程中的總結與建議

1.大小寫問題
mongodb 是預設區分大小寫的，但是這會不會衍生出跟mysql 一樣的問題？（mysql 區
分大小寫，導致windows 與linux 下的表名，欄位名不一致）。
如果無特別用途，建議表名，欄位名全部用小寫字母。

2.儘可能的縮短欄位名的長度
mongodb 的schema free 導致了每筆資料都要儲存他的key 以及屬性，這導致了這些數
據的大量冗餘。開發同事也許考慮到，從易讀性出發設計的key 基本比較長，基本都是按
照起字面意思去設計的。這導致key 很長。對應的資料儲存佔用了很大的空間。
必要的時候，可以考慮建立一個key 與實際意義的map 表，儘量降低key 的長度。
示例定義：
// 基本資訊
static final String _ID = "_id";
static final String STATUS_CODE = "sc";
// 緩衝
static final String DATE = "date";
static final String MAX_AGE = "age";
// 內容
static final String CONTENT = "content";
static final String CONTENT_TYPE = "ctype";
static final String CONTENT_LENGTH = "clen";
static final String ZIP = "zip";

3. mongodb 單表最大索引數為64
無索引排序的最大資料量為4M, 超過則報錯退出。
建議where 條件儘量落在索引欄位上，排序欄位需要建立索引，索引的使用原則與oracle
mysql 一致，儘量降低索引數量，索引長度。
mongodb 的查詢每次只能用到一個索引，對資料的查詢不會“併發”執行
例如： db.tab.find({'id'=1,'name'=2}) 如果‘id’，‘name' 列上分別有索引
對查詢效率提升意義不大，如果索引為（'id','name') 則大幅提升效率。

4.mongodb 新增欄位
如果新增欄位且帶有default 值，需要全部資料都要修改，這也是設計階段需要考慮的
事情，這個問題的另外一種解法是應用程式碼裡做一次判斷。

5.測試過程的密碼問題
對於用作資料庫使用的Mongodb，在程式碼測試階段都應加上密碼驗證，目前上線階段基
本都會在密碼驗證方面出現問題（做快取使用的可以不做密碼驗證)。

6.資料來源連線方式
使用連線池模式，儘量減少認證帶來的效能額外消耗
建議採用標準的uri 連線方式： mongodb://user:passwd@host:port,host:port/db

7.Mongodb日誌量
正常情況下不需要開啟-v 日誌選項。
Mongodb 的-v 日誌適合在開發環境的除錯線上部署不建議採用這個引數，目前線上
部署的情況，-v 日誌一天也會有幾個G 的日誌量，去掉這個引數，跟資料查詢相關的操作
就不會記日誌了，資料庫的內部的重要操作還是會寫日誌的。

8.連線數大小的設定
Mongodb 驅動程式採用的連線池的方式連線到資料庫，目前從觀察到的情況是應用一
開啟便根據變數的設定，建立全部連線，然後提供給程式使用，並且一旦其中某個連線
到資料庫的訪問失敗，則會清空整個連線池到這臺資料庫的連線，並重新建立連線。
而mongodb 對中斷連線的垃圾清理工作則是懶惰的被動清理方式，如果驅動程式端配
置的連線數過大，一旦發生重連，則會導致mongo 端堆積大量的垃圾連線資料，導致
主機資源耗盡。
建議： mongodb 驅動的連線池大小的設定一般應該控制100 以下，一般情況30-50 足
夠支撐應用訪問。

9.鎖的問題
Mongodb 對資料庫的訪問全部加鎖，如果是查詢請求則設定共享鎖，資料修改請求，
則設定全域性排他鎖，並且是例項級別的排他鎖。並且寫鎖會阻塞讀請求，如果長時間持有
寫鎖，會阻塞整個例項的讀請求。
部署建議：
1】一般情況下，建議不同的應用不要合用一套示例。
2】如果資源不滿足，需要合用，應該具有相同屬性的應用合用一套例項。
例如合同mongo 的應用都是讀多寫少，防止一臺寫多應用阻塞讀請求。

10.關於map/reduce問題
mongodb 對map/reduce 的支援是單執行緒的，我們不建議在前臺使用該功能， group by
是透過map/reduce 實現的，開發過程中，要慎用。

11.安全問題
1】Mongodb 執行在mongodb 使用者之上，並禁止mongodb 使用者登入
2】使用Mongodb 自帶的認證方法（adduser、auth）限制使用者訪問行為
3】將Mongodb 置於內網環境中
4】Mongodb 必須暴露在外網環境中的時候，使用IPTABLES 等網路層技術進行防護
5】網路層面內容為明文傳輸，可以考慮儲存加密文件，應用端，加解密。

12.效能監控
Mongodb 自帶有效能資料收集系統
Mongostat 實時採集資料庫的多項指標,提供http console 埠號為應用埠號+1000。
關注的主要效能指標：
1】Faults：顯示Mongodb 每秒頁面故障的數量，這個是mongoDB 對映到虛擬地址空間，
而不是實體記憶體，這個值如果飆高的話，可能意味著機器沒有足夠的記憶體來
儲存資料和索引。
2】Flushes：每秒做了多少次fsync，顯示多少次資料被重新整理進了磁碟
3】locked：寫鎖
4】idx miss：索引未命中比例
5】qr | qw：讀寫鎖的請求佇列長度。
6】conn： 當前已經建立的連線數。
其他命令：
Db.stat()
db.serverStatuse()
Db.collection.stats()

13.碎片問題
Mongodb 資料庫如果資料修改很頻繁，會出現比較嚴重的空間碎片問題，表現在磁碟
檔案擴張與實際資料量不相符，記憶體不夠用，索引命中率低，查詢效率降低。
碎片整理，目前我們採用的版本沒有太有效的方法。
可以用db.repaireDatabase() 來整理資料庫，這個過程非常的慢
如果是Master-slave 模式則相當於執行一次主從切換，然後從新建立從庫。
如果是replSet 架構可以停掉資料庫，然後刪除資料目錄，從新從複製複製組中全同步資料，
這個時候要考慮oplog 的尺寸。
一個大體的步驟：
1.】先呼叫rs.freeze(1200),將每個不想讓它成為primary 的機器讓它在1200 秒內無法成為
primary(這步也可以不做)
2. 】將primary stepDown,不出意外新的primary 會起來.
3. 】將原primary kill 掉.
4. 】刪掉所有data 資料(呼叫repair 很慢,真不如干掉重新來)
5. 】再重啟動原primary 的程式
6. 】以此迴圈完成整個複製組的全部重建。

14.系統備份：
Mongodb 目前不支援線上備份，只能離線備份。
我們採用的架構為replSet 和Master-slave .
基於我們目前的架構以及資料一致性要求，我們沒有安排相關的備份系統。

15.應用程式碼中Mongodb連線問題
在有些應用在使用Mongodb 過程中會存在以下兩個小問題：
1. 在應用啟動過程中，應用存在要求連線池中所有的連線都建立成功才讓應用正
常啟動，這種做法不可取，因為存在網路問題、Mongodb 拒絕連線或Mongodb 假死情況，如
果沒加外部try catch 做防護，則Resin 不斷重啟也不能正常啟動埠。
2.有些應用在使用Mongodb 中連線池配置了safe=true，w=1；這種配置意味著客戶端在
插入資料或更新資料的時候，要求mongodb 必須將所更新的資料寫入磁碟並返回更新成功
的資訊給程式。如果碰上應用程式訪問壓力大，mongodb 就會反應遲鈍，並會發生假死可能，
針對此情況，需要評估資料的一致性需求，做出合適調整。我們一般建議關閉此選項。

16.補充開發方面的一些問題
1】skip+limit翻頁，越往後面越慢，有資料說用陣列元素的分頁可以解決，目前還沒
試過，比較靠譜的做法是，先找出上次的id，翻頁的時候不用skip：
last_row_id = ObjectId(‘....’);
db.activity_stream->find({_id:{$lt: last_row_id },
user_id:20 } ).sort( {_id:-1} ).limit(10);
2】.只有真正需要的欄位才select出來
3】.更新的某條資料的時候，先查出來再更新會減小鎖的時間
4】.只有返回很少結果的查詢才用索引，否則會載入太多資料，比沒有用索引還慢
5】.屬性比較多的時候，建立分層的關係能夠提高查詢效率，否則每個記錄都要過一遍
才能找到要的屬性

17.關於硬體資源的選擇：
虛擬機器可以很好的隔離資源，並可動態的擴充套件。
我們建議mongodb 的部署採用虛擬機器的方式，每個虛擬機器部署一個例項，使各節點分
散在不同的物理機上,根據應用的前期預測，平衡虛擬機器的之間的i/o。