mongodb - 是否应该为确定大小的小 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 毫秒。

Does that decision depend at all on the size of collection?

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

只有几百个元素，所有这些都无关紧要，因为 log n 和 n 之间的差异很小，并且因为更复杂的算法的运行时开销(即，常数因子通过 Landau-Notation 隐藏，因为它在很大程度上依赖于实现)在同一个联盟中播放。这同样适用于您的代码:将 200 个元素放在哈希表中没有意义，列表迭代甚至可能更快，因为它避免了分支。

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