在 http://www.rethinkdb.com/docs/data-modeling/，指出：
由于前面的限制，最好保持 帖子阵列不超过几百个文档。
如果我打算保留 90 天(3 个月(的统计数据，并且每个日期可能都有一个大约 10 个区域的嵌入式数组。这意味着 90*10=900。900 并不完全是几百。
然而，MongoDB关系中的一个相关问题：嵌入还是引用？表明MongoDB的限制为16mb，这意味着能够托管3000万条推文或大约25万个典型的Stackoverflow问题作为嵌入式文档。好多啊！
然而，那是MongoDB。RethinkDB每个文档的限制为10mb。这应该还是相当高的。RethinkDB的文档可能存在缺陷。或者还有另一个具体的原因(没有解释(，为什么Rethinkdb建议只将其减少到几百个嵌入式阵列，即使10mb显然可以容纳更多。
我所指的架构的粗略想法：
DailyStat::Campaign
[
{
id: '32141241dkfjhjksdlf',
days_remaining: 26,
status: 'running',
dates: [
{
date: 20130926,
delivered: 1,
failed: 1,
clicked: 1,
top_regions: [
{ region_name: 'Asia', views: 10 },
{ region_name: 'America', views: 10 },
{ region_name: 'Europe', views: 10 },
{ region_name: 'Africa', views: 10 },
{ region_name: 'South East Asia', views: 10 },
{ region_name: 'South America', views: 10 },
{ region_name: 'Northern Europe', views: 10 },
{ region_name: 'Middle East', views: 10 }
]
},
{
date: 20130927,
delivered: 1,
failed: 1,
clicked: 1,
top_regions: [
{ region_name: 'Asia', views: 10 },
{ region_name: 'America', views: 10 },
{ region_name: 'Europe', views: 10 },
{ region_name: 'Africa', views: 10 },
{ region_name: 'South East Asia', views: 10 },
{ region_name: 'South America', views: 10 },
{ region_name: 'Northern Europe', views: 10 },
{ region_name: 'Middle East', views: 10 }
]
},
...
]
}
]
简短回答：
这篇文章指的是每个嵌入式阵列的大小，而不是它们的大小之和。所以在您的情况下，大小只有 10，这肯定会很好。
更长的安瑟：
在文档中有一个大型嵌套数组(实际上只是一个大型文档，数组没有什么特别之处(的问题在于，如果您需要更新它，它会变慢。RethinkDB现在不进行部分更新，因此每当您想要更新文档时，都需要读取整个磁盘并将整个内容写入磁盘。同样，如果您经常阅读文档但只关心其中的一小部分，这可能是一个问题。例如，如果你在一个文档中有一个非常大的数组，但还有一个小字段，你需要经常从中读取，每次你尝试读取小字段时，你都会付出读取大数组的代价。
这里提到的"以前的限制"是指以下内容：
使用嵌入式数组的缺点：对作者文档的任何操作都需要将所有帖子加载到内存中。对文档的任何更新都需要将整个阵列重写到磁盘。
这与其说是限制，不如说是性能权衡。
例如，如果你在用户表中嵌入每个用户的推文，你可能会遇到性能问题，因为：
- 推文的嵌入使用户文档变大
- 每次插入推文时，都必须更新整个用户文档(很大(
- 每个用户每天可能插入许多推文
- 将其乘以用户总数
另一方面，如果您将推文存储在单独的表中，则每次插入都很小且便宜。
在您的实例中，您每天都在存储统计信息。每天更新一个文档几次应该不会导致任何性能问题，即使它只有几 MB。