应该为确定大小的小 mongo 集合创建索引吗？

Question

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

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

在这些字段中，我想索引 name 和 phoneNumber。

建议为这样的小集合创建索引吗？这个决定是否完全取决于收藏的规模？它是否取决于我要创建的索引数量？

Answer 1

没关系。我刚刚在一个有 384 个条目的样本集合上尝试了这个。根据explain()，索引扫描用了 0毫秒，而第一次收集扫描用了 2 毫秒——接下来的每次收集扫描也用了 0 毫秒。

这个决定是否完全取决于收藏的规模？

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

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

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

Answer 2

我想你应该。持久性存储几乎不是问题。而且小集合的索引也很小。它还取决于查询量。如果查询量很大，那么即使单个查询的微小改进也会聚合成巨大的性能改进。