1.linux 系統：
1】關閉文件系統/分區的atime 選項
Vi /etc/fstab
在對應的分區項后面添加noatime ,nodiratime
LABEL=/1 / ext3 defaults 1 1
LABEL=/data1 /data ext4 defaults,noatime,nodiratime 1 2
2】設置文件句柄４ｋ＋，目前該配置已經集成到啟動腳本中。
Vi /etc/security/limit.conf
* soft nproc 65536
* hard nproc 65536
* soft nofile 65536
* hard nofile 65536
3】不要使用large vm page （不要使用大內存頁選項）
Linux 大內存頁參考：http://linuxgazette.net/155/krishnakumar.html
4】用dmesg 查看主機的信息。
2.linux 文件系統的選擇：
Mongodb 采用預分配的大文件來存儲數據,我們推薦
1】ext4
2】xfs
3.內核版本：
網絡上對2.6.33-31 以及2.6.32 的表現持懷疑度， 而強力推薦2.6.36
4.線程堆棧的尺寸
默認的線程堆棧尺寸為10m ，調整為1m ，已經集成在啟動腳本中。
項目過程中的總結與建議
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。