mongod（v2.6.5）分片羣集查詢延遲問題？

Question

我正在運行使用mongo分片羣集的節點（0.10.26）應用程序。我正在使用三個副本集作爲分片。這裏是我的其他配置細節

硬件和操作系統設置

1. EC2：m3.large（RAM：7.5G）
2. Linux操作系統Ubuntu 12.04（內核：3.2.0-69虛擬64位）
3. 磁盤：400g的SSD（EBS）（安裝有noatime的和的32預讀設定）

應用的負載模式

1. 插入率= 20-30 /秒 大多數刀片是日誌收集和他們發生 所有的時間。
2. 查詢率= 50-100 /秒
3. 更新=〜30 /第二

蒙戈

1. 存儲引擎：默認（mmapv1）
2. 指數大小：3.5G
3. 工作組：270 MB
4. 貓鼬版本：3.8.25
5. 蒙戈版本：2.6.5

我的應用程序提供下載日誌記錄爲具有一定過濾CSV文件的接口。當我嘗試csv下載時，應用程序變得非常慢。

經過一番調查後，我得出結論說，查詢日誌需要很長時間（> 2分鐘，有時長達10分鐘） 由於數據庫響應速度慢，應用程序也很慢

問題

1. 爲什麼是需要長時間的日誌查詢。

   如果我做了解釋（），我看到它碰到了索引。

   mongostat（當以1秒的延遲運行時）表示有 有許多頁面錯誤發生（〜800 - 1100）/秒。查詢返回後頁面 故障消退。隨後的查詢在幾秒鐘內返回 。

   工作集+索引大小= 3.7 G

   RAM = 7.5 G.

   大小日誌收集= 50g的

2. 是否頻繁寫入日誌收集影響在同一採集讀取操作 。這種擔心是否適用於我的工作負荷？

Answer 1

根據我很多事情，我們需要考慮在這裏解決問題。我不確定Mongo端到底發生了什麼，但這裏有一些我會看到的東西，

1. 你說你允許用戶提供日誌過濾器並創建它的csv然後下載。 在這種情況下，csv文件的平均大小是多少？

----如果太大，則可能我認爲你正在使用遊標來獲取數據，然後將其寫入可以是IO密集型文件（頁面錯誤可以證明）。代替這個，你可以檢查MongoExport和MongoDump選項，這些選項是專爲高效批量操作而設計的。

1. 你說你正在過濾記錄，然後你正在使用什麼過濾器？這是最佳嗎？你有正確的索引嗎？

----檢查過濾效率。雖然你說你正在使用索引，並且查詢正在使用索引。仍然可以添加更高效的新索引嗎？如果是，請添加它。

1. 將記錄與過濾器進行匹配後，您是否獲取該文檔的所有屬性（日誌記錄）？

----如果答案是肯定的，那麼他們真的需要嗎？如果答案是否定的，則嘗試僅獲取所需的數據。避免不必要的處理。

1. 我能想到的另一種技術是，如何完成分片？

----對於日誌，什麼是常規搜索過濾器（日期，錯誤等）？在NoSQL Dbs中，首先應確定需求/查詢/過濾器，然後決定模式/集合等。如果您還沒有考慮過，那麼現在是因爲您的數據庫規模很小。一旦它增長，你不能以後再做。

希望這有助於:)