MongoDB分片可擴展性 - 查詢單個塊的性能？

Question

在做一些MongoDB分片的初步測試時，我希望並期望執行查詢的時間只會觸及一個分片/機器上的單個數據塊，因爲更多的數據被加載時會保持相對恆定。但我發現一個顯着的放緩。

一些細節：

對於我的簡單測試，我用兩臺機器分片，並試圖查詢類似的藏品有2萬行和700萬行。這些顯然非常小的集合，甚至不需要分片，但我很驚訝已經看到只有一個塊的查詢有顯着的一致性放緩。查詢包括分片鍵，用於從10s到100000s的結果集，我測量了滾動整個結果集所需的總時間。還有一件事：由於我的應用程序實際上需要的數據量遠遠超過RAM，因此所有查詢都基於冷藏緩存進行計時。

任何想法，爲什麼會這樣？其他人是否觀察到相同或矛盾的結果？

---

進一步細節（由Theo提示）：

對於這個測試，行太小（5列包括_id），和密鑰不是基於_id，而是基於一個多值文本列幾乎總是出現在查詢中。

db.printShardingStatus（）命令顯示了有多少個塊以及用於分塊的精確鍵值。該數據集的平均塊包含超過100,000行，並且對關鍵值分割的檢查可驗證測試查詢是否正在創建單個塊。

就本次測試而言，我只測量讀數。沒有插入或更新。

---

更新：

在一些額外的研究，我相信我確定了放緩的原因：MongoDB的塊是純粹的邏輯，以及其中的數據不是物理上位於一起（來源：「縮放的MongoDB 「由克里斯蒂娜Chodorow）。這與在Oracle和MySQL等傳統數據庫中進行分區相反。這似乎是一個重要的限制，因爲分片會隨着碎片/機器的增加而水平放大，但在垂直維度上不太好，因爲將數據添加到具有固定數量碎片的集合中。

如果我正確地理解了這一點，如果我有一個包含10個分片/機器的十億行的集合，那麼即使是隻有一個分片/機器的查詢仍然從包含1億行的大集合中查詢。如果分片密鑰的值恰好位於磁盤上，則可能是好的。但是，如果不是，並且我獲取的行數超過了幾行（例如1000），那麼這可能會導致很多I/O問題。

所以我的新問題是：爲什麼不在物理上組織MongoDB塊以實現垂直和水平可伸縮性？

Answer 1

是什麼讓你說查詢只觸及一個塊？如果結果高達100 000行，聽起來不太可能。塊是最大64 Mb，除非你的對象很小，許多不適合。 Mongo最有可能分割你的塊並分發它們。

我想你需要告訴我們更多關於你在做什麼和你的數據的形狀。您是否同時查詢和加載？你說大塊時是指碎片嗎？你的碎片關鍵是_id以外的東西嗎？你在查詢數據時做了什麼更新？

當涉及到Mongo的性能時，主要有兩個因素：全局寫入鎖定和內存映射文件的使用。內存映射文件意味着你必須考慮你的使用模式，全局寫鎖定會嚴重損壞頁面錯誤。

如果您查詢所有地方的內容，操作系統將努力將內容分頁和分頁，這可能會特別傷害您的對象很小，因爲必須加載整個頁面才能訪問小塊，大量的RAM將被浪費。如果你正在做大量寫操作來鎖定讀取操作（但通常不會那麼糟糕，因爲寫操作是按順序進行的），但是如果你正在進行更新，你可能會忘記任何類型的性能，更新會阻止整個數據庫服務器大量的時間。

運行mongostat當你運行你的測試，它可以告訴你很多（運行mongostat --discover | grep -v SEC看到所有你進行分片大師的指標，不要忘了包括--port，如果你的mongos沒有在27017上運行）。

---

解決您的更新問題：這將是非常好的，如果蒙戈沒有保持物理塊一起，但事實並非如此。其中一個原因是分片是mongod之上的一個圖層，並且mongod未完全意識到它是分片。這是配置服務器和mongos進程知道分片鍵和存在的塊。因此，在當前體系結構中，mongod甚至沒有將磁盤塊保存在一起所需的信息。問題更加深入：Mongo的磁盤格式不是很先進。它仍然（從v2.0開始）沒有在線壓縮（儘管壓縮在v2.0中變得更好），但它無法壓縮分段數據庫並仍然提供查詢。可悲的是，在能夠表達你所暗示的內容之前，Mongo還有很長的路要走。

您現在可以做的最好的事情是確保您按順序編寫數據，以便順序寫入數據塊。如果您事先創建所有塊，這可能會有所幫助，這樣數據就不會被平衡器移動。當然這隻有在您提前獲得所有數據的情況下才有可能，而且這似乎不大可能。

Answer 2

聲明：我在Tokutek

工作，所以我的新問題是：爲什麼不組織塊MongoDB中物理，使垂直和水平的可擴展性？

這正是在TokuMX，MongoDB的替代服務器中所做的。 TokuMX使用具有較高寫入吞吐量和壓縮率的分形樹索引，因此不是將數據存儲在堆中，而是數據爲clustered with the index。默認情況下，分片鍵是聚集的，所以它完全按照您的建議進行，它通過確保所有文檔由磁盤上的分片鍵進行排序來物理地組織塊。這可以快速地對分片鍵進行範圍查詢，就像在任何聚集索引上一樣。