Question

我们用于监视事件的mongodb集合（版本3.6.1）有15列，包含大约10个列。一千万条记录。文档结构类似于以下内容：

{
    "_id" : ObjectId("5b56f26fa8b7ce5274deb72e"),
    "headers" : "",
    "message2Id" : "cdf6a0bd-0a48-47ed-9444-6a7d79864bc2",
    "activity" : "request_out",
    "originator" : "",
    "serviceName" : "myServiceA",
    "sequenceName" : "mySequenceA",
    "messageUnid" : "urn:uuid:934b3bda-0733-4702-aebe-0844ec72e43a",
    "node" : "INT_WRK1",
    "payload" : "",
    "details" : "messageDetails”
    "processType" : "typeA",
    "time" : NumberLong(1532424815712),
    "status" : "200",
    "timeDateFormat" : ISODate("2018-07-24T09:33:35.712Z")
}

大多数查询基于时间列（时间间隔）+一个或多个其他列（例如，服务名称，序列名称，状态等）的组合。这些“其他”列的组合取决于用户的选择。问题是这种查询的性能不佳。其中一些查询通常以超时结束。

查询实现分页（使用跳过和限制方法），并且应用程序还显示通过条件的记录数（使用聚合命令进行“计数”）。即使这个简单的“计数”也花费了很长时间，并且作为一种解决方法，我们必须在聚合命令中添加$ limit：100阶段（结果显示的精确值最大为100，然后显示“> 100”）

可用于mongodb实例的RAM数量约为。 12 GB。

问题是如何提高性能，这种情况下最佳的索引策略是什么？

1。）在各个列上分开索引，并在索引交集处中继？但是根据这篇文章Why doesn't MongoDB use index intersection?，在时间间隔内将无效

2。）每个组合时间的复合索引+ {另一列}？但是这些索引对于所有情况（例如“状态”列）是否具有足够的选择性？

3。）每个组合时间的复合索引+ {所有其他列的排列}-但是组合太多，我们很容易用完RAM

4。）还有其他想法吗？

谢谢瓦茨拉夫

基于时间的数据的MongoDB索引策略

0 个答案: