在MongoDB中使用巨大的「文檔」不好嗎？

既然我們可以構建一個MongoDB的任何我們想要的方式，我們可以做這樣在MongoDB中使用巨大的「文檔」不好嗎？

{ products: 
    [ 
    { date: "2010-09-08", data: { pageviews: 23, timeOnPage: 178 }}, 
    { date: "2010-09-09", data: { pageviews: 36, timeOnPage: 202 }} 
    ], 
    brands: 
    [ 
    { date: "2010-09-08", data: { pageviews: 123, timeOnPage: 210 }}, 
    { date: "2010-09-09", data: { pageviews: 61, timeOnPage: 876 }} 
    ] 
}

使我們日復一日添加數據，該文件products和brands文件會變得越來越大。 3年後，products和brands將有千元。對MongoDB不好嗎？我們是否應該把它分成4份以上的文件：

{ type: 'products', date: "2010-09-08", data: { pageviews: 23, timeOnPage: 178 }} 
{ type: 'products', date: "2010-09-09", data: { pageviews: 36, timeOnPage: 202 }} 
{ type: 'brands', date: "2010-09-08", data: { pageviews: 123, timeOnPage: 210 }} 
{ type: 'brands', date: "2010-09-08", data: { pageviews: 61, timeOnPage: 876 }}

這樣3年後，會有2000個「文件」？

來源

2010-09-11 太極者無極而生

+1：我對這個問題的答案感興趣。它似乎*像你的第二種方法會更好，但我不知道。當然，您可以生成一堆測試產品和品牌，並構建兩個不同的數據庫。然後進行一些性能測試，看看在哪些條件下哪一個獲勝。現在是晚上11點，你知道你的DB *在哪裏嗎？ – 2010-09-11 00:22:32

AFAIK MongoDB將文檔限制爲每個4 MB。 – 2010-09-11 00:45:49

那麼做一些模擬，製作一個填滿10年數據的對象，它有多大，限制爲4mb。什麼對你的軟件模型更好？ – Amala 2010-09-11 13:30:22

我不是MongoDB的專家，但1000不是「巨大的」。另外，我會認真地懷疑1個包含4000個子元素的頂層文檔和4個包含1000個子元素的頂層文檔之間的區別 - 其中一個是六個一個，另一個是另一個問題。

現在，如果您正在討論1個具有1,000,000個元素的文檔，而其中每個文檔有1000個元素，這是不同的數量級+，可能存在一個與另一個的優點，無論是存儲時間還是查詢時間。

來源

2010-09-11 00:40:01

假設你使用Mongoid（你標記了它），你不想使用你的第一個模式的想法。對於Mongoid來說，每次你想查找一個小小的值時，就會把這些大文件抽出來。

什麼可能會是你一個更好的模式是：

class Log 
    include Mongoid::Document 

    field :type 
    field :date 
    field :pageviews, :type => Integer 
    field :time_on_page, :type => Integer 
end

這將使你看起來像文件：

{_id: ..., date: '2010-09-08', type: 'products', pageviews: 23, time_on_page: 178}

不用擔心文件的數量 - 蒙戈可以處理數十億這些。你可以通過索引類型和日期來輕鬆找到你想要的數字。

此外，這種方式通過驅動程序更新記錄更容易，甚至不需要從數據庫中提取記錄。例如，在每個網頁瀏覽中，您可以執行以下操作：

Log.collection.update({'type' => 'products', 'date' => '2010-09-08'}, {'$inc' => {'pageview' => 1}})

來源

2010-09-11 02:18:46 PreciousBodilyFluids

您已經討論瞭如何更新數據，但您打算如何查詢它？這可能會影響您如何構建文檔。

在數組中使用嵌入元素的問題是，每次添加時都可能無法適應爲文檔分配的當前空間。這將導致（新）文檔被重新分配和移動（該移動將需要重新編寫文檔的任何索引）。

我通常會建議您建議的第二種形式，但它取決於上述問題。

注意：4MB是一個任意的限制，並會很快提出;您實際上可以重新編譯服務器以獲得您想要的任何限制。

來源

2010-09-12 20:37:49

看起來你的設計非常類似於關係表模式。

alt text

所以每天補充文件將是具有自己的標識集合中的一個單獨的條目。雖然mongo文檔大小限制爲4 MB，但其大部分足以容納純文本文檔。而且您不必擔心mongo中不斷增長的文檔數量，這就是基於文檔的數據庫的本質。

你只需要擔心的是db集合的大小。其限於32位系統的2GB。因爲MongoDB使用內存映射文件，因爲它們與可用的內存尋址有關。這對64位系統不是問題。

希望這有助於

來源

2010-09-14 13:30:10 RameshVel

這又取決於您的查詢用例。如果你真的關心單個項目，如每天的產品：

{類型： '產品'，日期：「2010-09-08」，數據：{瀏覽量：23，timeOnPage：178}}

然後你可以在一個日期中包含多天。

{類型： '產品'，{日期：「2010-09-08」，數據：{瀏覽量：23，timeOnPage：178}}}

我們使用這樣的事情：

{類型：'products'，「2010」：{「09」：{「08」：data：{pageviews：23，timeOnPage：178}}}}}

所以我們可以每天遞增：{「$ inc 「：{」2010.09.08.data.pageviews「：1}}

也許看起來很複雜，但好處是您可以在1條記錄中存儲有關」類型「的所有數據。因此，您可以檢索單個記錄並獲取所有信息。

來源

2010-09-15 19:17:45 Amala

在MongoDB中使用巨大的「文檔」不好嗎？

回答

相關問題