假设我有一个 mongo 集合，它具有固定数量的条目，永远不会超过 300-400 的计数。例子：
User{
String name;
String phoneNumber;
String address;
String dob;
Integer noOfCars;
}
在这些字段中，我想索引姓名和电话号码。
为这么小的集合创建索引是否可取？该决定是否完全取决于收藏的规模？这是否取决于我要创建的索引数量？
问问题
621 次
3 回答
6
没关系。我刚刚在一个包含 384 个条目的示例集合上尝试了这个。根据explain()，索引扫描花费了 0 毫秒，而第一次收集扫描花费了 2 毫秒 - 每个后续收集扫描也花费了 0 毫秒。
该决定是否完全取决于收藏的规模？
是的，索引的想法是它增加了创建和更新数据的成本，这些成本通过加快查询速度来摊销。特别是，一个简单的列表具有 O(1) 的渐近插入性能和 O(N) 的搜索时间，而 B-Tree 两者都有 O(log n)，即我们接受较慢的插入，因为我们假设我们读取比我们写的更频繁，或者数据太大以至于即使是几次 O(N) 读取也会影响性能，即如果 N >> log N。
只有几百个元素，所有这些都无关紧要，因为 log n 和 n 之间的差异很小，并且因为更复杂的算法的运行时开销（即，通过朗道符号隐藏的常数因子，因为它在很大程度上是实施依赖）在同一个联赛中比赛。这同样适用于您的代码：将 200 个元素放在哈希表中是没有意义的，列表迭代甚至可能更快，因为它避免了分支。
但是，如果文档很大，则集合扫描将不得不处理更多数据（而不仅仅是查看索引）。
于 2015-02-15T17:40:15.807 回答
3
为这么小的集合创建索引是否可取？
这可能是一种观点，因为集合是如此之小，数据库可能对如此小的集合进行了优化。我的意见是这样做，但有利也有弊。
缺点：增加系统复杂性。这类似于您拥有的 LOC 越多，您可能拥有的错误就越多。
亲：如果使用量增加或集合大小增加，将来会证明集合。
该决定是否完全取决于收藏的规模？
是的，它确实。并且除非在如此小的集合上可能发生任何数据库优化，它还取决于使用情况。
这是否取决于我要创建的索引数量？
更多索引会增加写入时间，但这需要针对您的特定设置进行测试。没有什么比真正的测试更好的了，因为有很多因素在起作用。我知道在之前的项目中，我们使用 TokuMX for MongoDB 并且看到了惊人的写入性能……使用 Toko 2 分钟 vs 12 分钟使用常规 mongo 编写具有 19 个索引的 500k 条目。
于 2015-02-15T17:53:50.203 回答
0
我觉得你应该。持久性存储几乎不是问题。小收藏的索引也很小。它还取决于查询量。如果查询量很大，那么即使是对单个查询的轻微改进也会聚合到巨大的性能改进。
于 2015-02-15T17:39:34.737 回答