【问题标题】:Is mongoDB inefficient for storing many arrays of integers?mongoDB 存储许多整数数组效率低吗?
【发布时间】:2013-02-15 21:48:47
【问题描述】:

我的 mongoDB 集合中的所有文档都有一个整数数组。对于每个整数,我不需要超过 32 位,并且整数数组的长度对于每个文档都是相同的。

我的应用程序的客户端会经常更新数组中的各个字段。

如果我有 5000 到 10000 个包含 256 个整数的数组的文档,mongo db 是否会浪费空间,因为我需要准备好将数组的内容更改为非整数数据类型,或者更改数组的长度?

与传统的关系数据库相比,mongoDB 的设计是否会使更新我的数组中的单个整数非常低效?

假设我正在使用此处描述的更新数组语法: http://docs.mongodb.org/manual/applications/update/#update-arrays

【问题讨论】:

  • 您的文档在修改后是否会增长,以至于它们必须从之前的连续空间中移出?
  • @Sammaye 没有。每个数组的长度总是与其他数组的长度完全相同。对于此问题中的示例,假设每个数组的长度为 256。包含数组和其他字段的文档的总大小也不会改变。
  • 更新的最大问题是移动,考虑到你不会有这个问题,我认为你可以很好地将它们拍打到子文档中,并且应该在这里看到良好的性能,特别是因为它是数组中的 256 个元素,它们应该非常快地加载到 $pull 等内存运算符中
  • 附带说明:will mongo db waste space because it needs to be prepared for me to change the contents of my arrays to non-integer datatypes 大多数时候 MongoDB 只会分配一个刚刚超过 1 的填充因子,通常可能是 1.1 左右,这意味着它只会给您的实际应用带来非常小的开销对象,比如小,当然取决于对象的大小

标签: mongodb non-relational-database


【解决方案1】:

mongo db 是否会浪费空间,因为我需要准备好将数组的内容更改为非整数数据类型或更改数组的长度?

不,它不会浪费空间。与其考虑更改数据类型或更改数组长度的能力,我会专注于 MongoDB 的padding factor,它可以自适应地了解文档是否倾向于增长。由于您的文档大小非常相似,因此您的填充因子将趋向于 1(即几乎没有在文档大小上添加额外的填充)。

与传统的关系数据库相比,mongoDB 的设计是否会使更新我的数组中的单个整数非常低效?

由于嵌入式数组没有精确的关系等价物,因此比较并不明显。您可能会假设关系等价物是JOIN。在这种情况下,我相信 MongoDB 会运行得更快,因为 JOIN 有它自己的成本。


另外说明,考虑到 MongoDB 可以处理的数据量,5,000 到 10,000 个文档是微不足道的。只要您在更新中指定索引标准(例如_id),您就不必担心任何空间或性能问题。但是,由于您的文档并不小,我要注意的一件事是尝试在查找查询中一次加载整个文档,您可能更喜欢 project find queries 仅用于特定字段;在查询数组时,您可能需要考虑$slice

【讨论】:

  • 由于数组操作在内存中,而 JOIN 操作在索引上,因此在性能方面略有可比。
  • @Sammaye 谢谢,我已经更新了我的答案。尽管就效率而言,我认为这不是一个明显的比较。但是,我认为根据所描述的特定场景,它必须比关系更快?
  • 确实我同意,这个特定的场景应该比在磁盘上就地更新上的 JOIN 上的范围索引更快地将数组加载到工作集中并对其进行操作