1.linux 系統(tǒng)：
1】關閉文件系統(tǒng)/分區(qū)的atime 選項
Vi /etc/fstab
在對應的分區(qū)項后面添加noatime ,nodiratime
LABEL=/1 / ext3 defaults 1 1
LABEL=/data1 /data ext4 defaults,noatime,nodiratime 1 2
2】設置文件句柄４ｋ＋，目前該配置已經(jīng)集成到啟動腳本中。
Vi /etc/security/limit.conf
* soft nproc 65536
* hard nproc 65536
* soft nofile 65536
* hard nofile 65536
3】不要使用large vm page （不要使用大內(nèi)存頁選項）
Linux 大內(nèi)存頁參考：http://linuxgazette.net/155/krishnakumar.html
4】用dmesg 查看主機的信息。
2.linux 文件系統(tǒng)的選擇：
Mongodb 采用預分配的大文件來存儲數(shù)據(jù),我們推薦
1】ext4
2】xfs
3.內(nèi)核版本：
網(wǎng)絡上對2.6.33-31 以及2.6.32 的表現(xiàn)持懷疑度， 而強力推薦2.6.36
4.線程堆棧的尺寸
默認的線程堆棧尺寸為10m ，調(diào)整為1m ，已經(jīng)集成在啟動腳本中。
項目過程中的總結與建議
1.大小寫問題
mongodb 是默認區(qū)分大小寫的，但是這會不會衍生出跟mysql 一樣的問題？（mysql 區(qū)
分大小寫，導致windows 與linux 下的表名，字段名不一致）。
如果無特別用途，建議表名，字段名全部用小寫字母。
2.盡可能的縮短字段名的長度
mongodb 的schema free 導致了每筆數(shù)據(jù)都要存儲他的key 以及屬性，這導致了這些數(shù)
據(jù)的大量冗余。開發(fā)同事也許考慮到，從易讀性出發(fā)設計的key 基本比較長，基本都是按
照起字面意思去設計的。這導致key 很長。對應的數(shù)據(jù)存儲占用了很大的空間。
必要的時候，可以考慮建立一個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";
// 內(nèi)容
static final String CONTENT = "content";
static final String CONTENT_TYPE = "ctype";
static final String CONTENT_LENGTH = "clen";
static final String ZIP = "zip";
3. mongodb 單表最大索引數(shù)為64
無索引排序的最大數(shù)據(jù)量為4M, 超過則報錯退出。
建議where 條件盡量落在索引字段上，排序字段需要建立索引，索引的使用原則與oracle
mysql 一致，盡量降低索引數(shù)量，索引長度。
mongodb 的查詢每次只能用到一個索引，對數(shù)據(jù)的查詢不會“并發(fā)”執(zhí)行
例如： db.tab.find({'id'=1,'name'=2}) 如果‘id’，‘name' 列上分別有索引
對查詢效率提升意義不大，如果索引為（'id','name') 則大幅提升效率。
4.mongodb 添加字段
如果添加字段且?guī)в衐efault 值，需要全部數(shù)據(jù)都要修改，這也是設計階段需要考慮的
事情，這個問題的另外一種解法是應用代碼里做一次判斷。
5.測試過程的密碼問題
對于用作數(shù)據(jù)庫使用的Mongodb，在代碼測試階段都應加上密碼驗證，目前上線階段基
本都會在密碼驗證方面出現(xiàn)問題（做緩存使用的可以不做密碼驗證)。
6.數(shù)據(jù)源連接方式
使用連接池模式，盡量減少認證帶來的性能額外消耗
建議采用標準的uri 連接方式： mongodb://user:passwd@host:port,host:port/db
7.Mongodb日志量
正常情況下不需要開啟-v 日志選項。
Mongodb 的-v 日志適合在開發(fā)環(huán)境的調(diào)試線上部署不建議采用這個參數(shù)，目前線上
部署的情況，-v 日志一天也會有幾個G 的日志量，去掉這個參數(shù)，跟數(shù)據(jù)查詢相關的操作
就不會記日志了，數(shù)據(jù)庫的內(nèi)部的重要操作還是會寫日志的。
8.連接數(shù)大小的設置
Mongodb 驅動程序采用的連接池的方式連接到數(shù)據(jù)庫，目前從觀察到的情況是應用一
開啟便根據(jù)變量的設置，建立全部連接，然后提供給程序使用，并且一旦其中某個連接
到數(shù)據(jù)庫的訪問失敗，則會清空整個連接池到這臺數(shù)據(jù)庫的連接，并重新建立連接。
而mongodb 對中斷連接的垃圾清理工作則是懶惰的被動清理方式，如果驅動程序端配
置的連接數(shù)過大，一旦發(fā)生重連，則會導致mongo 端堆積大量的垃圾連接數(shù)據(jù)，導致
主機資源耗盡。
建議： mongodb 驅動的連接池大小的設置一般應該控制100 以下，一般情況30-50 足
夠支撐應用訪問。
9.鎖的問題
Mongodb 對數(shù)據(jù)庫的訪問全部加鎖，如果是查詢請求則設置共享鎖，數(shù)據(jù)修改請求，
則設置全局排他鎖，并且是實例級別的排他鎖。并且寫鎖會阻塞讀請求，如果長時間持有
寫鎖，會阻塞整個實例的讀請求。
部署建議：
1】一般情況下，建議不同的應用不要合用一套示例。
2】如果資源不滿足，需要合用，應該具有相同屬性的應用合用一套實例。
例如合同mongo 的應用都是讀多寫少，防止一臺寫多應用阻塞讀請求。
10.關于map/reduce問題
mongodb 對map/reduce 的支持是單線程的，我們不建議在前臺使用該功能， group by
是通過map/reduce 實現(xiàn)的，開發(fā)過程中，要慎用。
11.安全問題
1】Mongodb 運行在mongodb 用戶之上，并禁止mongodb 用戶登錄
2】使用Mongodb 自帶的認證方法（adduser、auth）限制用戶訪問行為
3】將Mongodb 置于內(nèi)網(wǎng)環(huán)境中
4】Mongodb 必須暴露在外網(wǎng)環(huán)境中的時候，使用IPTABLES 等網(wǎng)絡層技術進行防護
5】網(wǎng)絡層面內(nèi)容為明文傳輸，可以考慮存儲加密文檔，應用端，加解密。
12.性能監(jiān)控
Mongodb 自帶有性能數(shù)據(jù)收集系統(tǒng)
Mongostat 實時采集數(shù)據(jù)庫的多項指標,提供http console 端口號為應用端口號+1000。
關注的主要性能指標：
1】Faults：顯示Mongodb 每秒頁面故障的數(shù)量，這個是mongoDB 映射到虛擬地址空間，
而不是物理內(nèi)存，這個值如果飆高的話，可能意味著機器沒有足夠的內(nèi)存來
存儲數(shù)據(jù)和索引。
2】Flushes：每秒做了多少次fsync，顯示多少次數(shù)據(jù)被刷新進了磁盤
3】locked：寫鎖
4】idx miss：索引未命中比例
5】qr | qw：讀寫鎖的請求隊列長度。
6】conn： 當前已經(jīng)建立的連接數(shù)。
其他命令：
Db.stat()
db.serverStatuse()
Db.collection.stats()
13.碎片問題
Mongodb 數(shù)據(jù)庫如果數(shù)據(jù)修改很頻繁，會出現(xiàn)比較嚴重的空間碎片問題，表現(xiàn)在磁盤
文件擴張與實際數(shù)據(jù)量不相符，內(nèi)存不夠用，索引命中率低，查詢效率降低。
碎片整理，目前我們采用的版本沒有太有效的方法。
可以用db.repaireDatabase() 來整理數(shù)據(jù)庫，這個過程非常的慢
如果是Master-slave 模式則相當于執(zhí)行一次主從切換，然后從新建立從庫。
如果是replSet 架構可以停掉數(shù)據(jù)庫，然后刪除數(shù)據(jù)目錄，從新從復制復制組中全同步數(shù)據(jù)，
這個時候要考慮oplog 的尺寸。
一個大體的步驟：
1.】先調(diào)用rs.freeze(1200),將每個不想讓它成為primary 的機器讓它在1200 秒內(nèi)無法成為
primary(這步也可以不做)
2. 】將primary stepDown,不出意外新的primary 會起來.
3. 】將原primary kill 掉.
4. 】刪掉所有data 數(shù)據(jù)(調(diào)用repair 很慢,真不如干掉重新來)
5. 】再重啟動原primary 的進程
6. 】以此循環(huán)完成整個復制組的全部重建。
14.系統(tǒng)備份：
Mongodb 目前不支持在線備份，只能離線備份。
我們采用的架構為replSet 和Master-slave .
基于我們目前的架構以及數(shù)據(jù)一致性要求，我們沒有安排相關的備份系統(tǒng)。
15.應用代碼中Mongodb連接問題
在有些應用在使用Mongodb 過程中會存在以下兩個小問題：
1. 在應用啟動過程中，應用存在要求連接池中所有的連接都建立成功才讓應用正
常啟動，這種做法不可取，因為存在網(wǎng)絡問題、Mongodb 拒絕連接或Mongodb 假死情況，如
果沒加外部try catch 做防護，則Resin 不斷重啟也不能正常啟動端口。
2.有些應用在使用Mongodb 中連接池配置了safe=true，w=1；這種配置意味著客戶端在
插入數(shù)據(jù)或更新數(shù)據(jù)的時候，要求mongodb 必須將所更新的數(shù)據(jù)寫入磁盤并返回更新成功
的信息給程序。如果碰上應用程序訪問壓力大，mongodb 就會反應遲鈍，并會發(fā)生假死可能，
針對此情況，需要評估數(shù)據(jù)的一致性需求，做出合適調(diào)整。我們一般建議關閉此選項。
16.補充開發(fā)方面的一些問題
1】skip+limit翻頁，越往后面越慢，有資料說用數(shù)組元素的分頁可以解決，目前還沒
試過，比較靠譜的做法是，先找出上次的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】.更新的某條數(shù)據(jù)的時候，先查出來再更新會減小鎖的時間
4】.只有返回很少結果的查詢才用索引，否則會加載太多數(shù)據(jù)，比沒有用索引還慢
5】.屬性比較多的時候，建立分層的關系能夠提高查詢效率，否則每個記錄都要過一遍
才能找到要的屬性
17.關于硬件資源的選擇：
虛擬機可以很好的隔離資源，并可動態(tài)的擴展。
我們建議mongodb 的部署采用虛擬機的方式，每個虛擬機部署一個實例，使各節(jié)點分
散在不同的物理機上,根據(jù)應用的前期預測，平衡虛擬機的之間的i/o。