在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中使用巨大的“文档”不好吗？

回答

相关问题