2

索引优化：

我们审查了我们在昂贵的集合 [170M 文档] 上的所有索引。

我们开始删除大部分索引；剩下 2 个主要索引 [不包括主键]。这将总索引大小缩减为之前值的 1/3。

在高层我们采用“复合索引”的策略；基于集合查询中使用的文档中所有属性的共同点。

有两个主要用例用于查询此集合。

在线
• 这两个查询有两个专用索引，即 InfoId_1 (equals) 和 Source_1_StatusId_1_SoundExWord12_1 (equals, equals, in)

离线——我们在这里使用 [MR]。• 此用例中使用的所有查询都有一个专用复合索引。所有查询都使用索引中设置的大部分字段。例如索引名称 Source_1_StatusId_1_InfoIdHash_1_InfoUpdateDate_1_SoundExWord12_1（等于、等于、范围、范围、用于排序）

到目前为止的结果：

在检查 MongoDB 中的执行计划后，似乎离线操作的专用索引在生产中被拒绝用于在线操作的专用索引，导致 270M 结果扫描而不是 130K 结果扫描（在 QA 中，大多数情况下选择了正确的索引）。由于某种原因，它没有使用正确的索引，目前还不清楚为什么。

到目前为止我们已经完成的更多研究/测试：一旦我们删除了在线索引，离线过程；MR 离线进程开始以良好的性能工作，因此我们确信在这里应用权限索引完全是问题。

问题/考虑：

这里有两种选择：在这里我需要你帮助实现第一个 alertnative 或优化第二个：

  1. 向 map reduce 查询 (/query+sort) 添加提示（通过 C# 2.0 旧版驱动程序）以让 MongoDB 选择正确的索引 - 找不到任何方法来做到这一点。一旦使用命令 db.infosoundexpair.find({$and: [ { "Source": { $eq: "XXX" } }, { "StatusId": { $eq: 0 } }, { "InfoIdHash": { $ gte: -2147483648 } }, {"InfoIdHash": { $lte: -2143862259 } }, { "InfoUpdateDate": { $lt: ISODate("2015-06-04T00:00:00.000Z") } } ]}) .sort({"SoundExWord12": 1}).hint("Source_1_StatusId_1_InfoIdHash_1_InfoUpdateDate_1_SoundExWord12_1").explain("executionStats"); 使用了正确的索引（在提示中定义）。

  2. 在索引和在线查询中使用不同的字段顺序重新创建专用在线索引会阻止离线进程使用该索引，使在线进程能够使用该索引，但是会降低在线进程的速度。我们认为速度的下降是因为我们从索引末尾移动到索引开头的字段（离线查询中没有使用的字段，只是在离线排序中使用）而不是使用包含（$in）的等于 ($eq) 具有约 25 个潜在值，而其他两个字段是相等比较。

样本文件：

{
    "_id" : "766574b0-0f3d-4e0a-b979-a6024bf6fbbb/cemcdeomc/vodemer",
    "InfoId" : LUUID("b0746576-3d0f-0a4e-b979-a6024bf6fbbb"),
    "Source" : "OFAC",
    "StatusId" : 0,
    "InfoUpdateDate" : ISODate("2015-06-09T13:55:25.863Z"),
    "SoundExWord12" : "cemcdeomc/vodemer",
    "InfoIdHash" : -547866111
}
4

0 回答 0