是否应该为小确定大小的 mongo 集合创建索引？答案

【问题标题】：Should indexes be created for small definite size mongo collections?是否应该为小确定大小的 mongo 集合创建索引？
【发布时间】：2015-04-16 05:21:46
【问题描述】：

假设我有一个 mongo 集合，它具有固定数量的条目，永远不会超过 300-400 的计数。示例：

User{
String name;
String phoneNumber;
String address;
String dob;
Integer noOfCars;
}

在这些字段中，我想索引姓名和电话号码。

为如此小的集合创建索引是否可取？该决定是否完全取决于收藏的规模？是否取决于我要创建的索引数量？

【问题讨论】：

当我们避免在我们不会经常查询的字段上创建额外的索引时，我们会做出这种选择，因为创建索引的成本超过了提供的好处。在类似的方面，我试图询问为小型静态集合支付创建索引的成本是否有意义。

标签： mongodb indexing mongodb-indexes

【解决方案1】：

没关系。我刚刚在一个包含 384 个条目的样本集合上尝试了这个。根据explain() 的说法，索引扫描耗时 0 毫秒，而 第一次 集合扫描耗时 2 毫秒 - 之后的每个集合扫描也耗时 0 毫秒。

这个决定是否完全取决于集合的大小？

是的，索引的想法是它增加了创建和更新数据的成本，这些成本通过加快查询速度来摊销。特别是，一个简单的列表具有 O(1) 的渐近插入性能和 O(N) 的搜索时间，而 B-Tree 两者都有 O(log n)，即我们接受较慢的插入，因为我们假设我们读取比我们写的更频繁，或者数据太大以至于即使是几次 O(N) 读取也会影响性能，即如果 N >> log N。

只有几百个元素，这一切都无关紧要，因为 log n 和 n 之间的差异很小，而且更复杂的算法的运行时开销（即 constant 因素通过Landau-Notation 隐藏，因为它在很大程度上取决于实施）在同一个联赛中的比赛。这同样适用于您的代码：将 200 个元素放在哈希表中没有意义，列表迭代甚至可能更快，因为它避免了分支。

但是，如果文档很大，则集合扫描将不得不处理更多数据（而不仅仅是查看索引）。

【讨论】：

这个答案信息量如此之大，以至于引发了一系列衍生问题。这是一个很好的答案。

【解决方案2】：

为这么小的集合创建索引是否可取？

这可能是一种观点，因为集合是如此之小，数据库可能对如此小的集合进行了优化。我的意见是这样做，但有利有弊。

con：增加了系统复杂性。这类似于您拥有的 LOC 越多，您可能拥有的错误就越多。

pro：如果使用量增加或集合大小增加，将来会证明集合。

这个决定是否完全取决于集合的大小？

是的。并且除非在如此小的集合上可能发生任何数据库优化，它还取决于使用情况。

是否取决于我要创建的索引数量？

更多索引会增加写入时间，但这需要针对您的特定设置进行测试。没有什么比真正的测试更好的了，因为有很多因素在起作用。我知道，在之前的项目中，我们使用 TokuMX for MongoDB 并且看到了惊人的写入性能...... Toko 用 2 分钟，而普通 mongo 用 12 分钟用 19 个索引写入 500k 条目。

【讨论】：

【解决方案3】：

我认为你应该这样做。持久性存储几乎不是问题。小收藏的索引也很小。它还取决于查询量。如果查询量很大，那么即使是对单个查询的微小改进也将聚合成巨大的性能改进。

【讨论】：