mongodb索引用户定义的模式

Question

我们目前正在使用MongoDB来允许SaaS应用程序中的租户定义他们可以在应用程序中使用的实体。我们不知道每个租户如何为他们正在创建的实体定义字段。每个实体都将在属于租户的单独数据库中为其动态创建一个集合。

例如，一个租户可能会将客户定义为名字，姓氏，电子邮件。另一个租户可能会将货件定义为货件参考，发货日期，所有者等......每个租户将在其租户数据库中拥有许多实体/集合。

我们有一个字段（ID），我们将始终强制用户包含在每个实体/集合中。我们将在创建集合时预先为此字段编制索引。

但是，当数据集变得过大时，我们如何处理我们希望允许租户快速排序/搜索/订购/查询大型集合/实体 的情况？

也就是说，由于我们不知道用户将在哪些字段中进行排序/过滤/排序，因此在Mongo中使用的索引策略是什么？

Answer 1

首先，Mongo要求您为每个文档设置_id，并自动为其编制索引。您应该利用这一点，而不是创建另一个ID字段，以防您需要客户拥有ID字段。我不确定你的申请是否属实。

你所要求的不是一个完美的解决方案，甚至是最优的解决方案，但我可以建议几个选择：

• 为文档中的每个字段创建单个字段索引。让Mongo查询优化器根据查询决定使用哪个索引。缺点 - 在磁盘和内存中占用大量空间。使插入更慢。 Mongo在条件子句中只能使用1个索引，因此无法使用复合索引。您可以使用this等工具轻松提取架构。我写了这个分析和打印Mongo架构的小原型。
• 让您的应用程序了解要创建的索引。从Mongo profiler（在Mongo日志中）获取慢查询，分析常见部分（自动？）并在最常用的字段上创建索引。如果您的客户更改查询或数据，那么实施起来并不容易，效率可能会随时间而变化。应用程序在开始时会很慢，直到它了解自己：）。

Answer 2

您是否只想强调选择您的设计时，您提到的ID和非_id字段实际上是一些唯一的实体标识符，那么您最好将其放在_id中。

这里的原因是，在所需的_id上使用另一个唯一索引的性能权衡是一个相当大的开销。考虑到这一点，因为_id是必需的，所以MongoDB在确定使用哪个索引时首先要查找它。否则，请考虑包含实体信息和其他一些有用唯一性的复合_id字段。

至于用户定义的字段，这是mongo文档的本质，为了我的钱，我会把它作为API的一部分来设置索引。根据正在发生的搜索类型，您可能希望复合索引和生成的查询对这些有意义。

简单地为每个字段编制索引可能会限制使用，因为无论如何只会为查找选择一个索引，并且查询优化器将尝试所有这些索引。如前所述，长期选项可以是根据使用模式设置索引。但这可能需要做一些工作。