2015-02-23 53 views
3

我們的應用程序使用物化路徑方法來存儲樹。我們使用這種方法,因爲插入速度很快,並且允許我們很容易地查詢子樹。在這種方法中,我們將路徑存儲到mongo中稱爲'路徑'的字段中的樹中每個節點。我們正在面對即將發生的mongo問題,在那裏我們的樹將不能再被構建到mongo中,因爲路徑不能超過1024字節b/c它是一個索引字段。mongodb 3.0是否增加了主鍵索引限制?

mongo 3.0是否將這個任意限制增加到高於1024bytes的東西?

回答

2

關於索引關鍵字長度的1024 byte limit仍然適用於MongoDB 3.0。

如果您的樹的materialized paths接近密鑰大小限制,或許您應該考慮限制樹中每個節點的樹深度或描述長度。

在MongoDB文檔中描述的modelling tree structures有幾種替代方法,但是提到了與您當前的方法相比的顯而易見的權衡。

僅供參考,您可以在MongoDB問題跟蹤器中看到/ upvote:SERVER-3372: Allow indexing fields of arbitrary length

+0

注意:SERVER-3372當前的fixVersion爲「3.1 Desired」。這表明它是在3.1開發週期中進行審查的候選問題,但不能保證該功能將實施。在MongoDB 3.0中添加可插拔存儲API後,我認爲將考慮如何將公開的索引鍵限制映射到底層存儲引擎的任何限制(可能大於或小於1024字節)。 – Stennie 2015-02-24 01:46:48

+0

我已經審查了很多建模樹結構文檔。對於這種尺寸的樹,唯一的另一個可行的選擇是嵌套設置模式,它只是插入時的一隻狗。物化路徑確實是最好的選擇。我也通過使用npm shortid模塊與mongo對象ID來使用更短的描述符。我可能必須遷移到TokuMX,因爲它們的字段可以有32k索引字段。 – 2015-02-25 04:29:16

+0

這個問題有沒有什麼動作?我真的很困難。在我們的應用程序中,樹中有數百萬個節點,查詢樹和子樹是非常關鍵的。我們還在樹上執行了數十億數據庫事務,並且我們發現物化路徑方法是我們需要的最佳機制。是否有可能至少增加允許的長度?即使加倍允許的密鑰長度也能幫助我們。 – 2016-08-19 02:32:55