Question

索引优化：

我们审查了昂贵收藏品[170M文件]的所有索引。

我们开始删除大部分索引;剩下2个主要指标[不包括主键]。这将总指数大小调整为其先前值的1/3。

在高层次我们采用了“复合指数”的策略;基于集合中查询中使用的文档中所有属性的共同点。

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

在线
  •这两个查询有两个专用索引，即   InfoId_1（等于）和Source_1_StatusId_1_SoundExWord12_1（等于，   等于，in）

离线 - 我们在这里使用[M-R]。   •有一种专用化合物   此用例中使用的所有查询的索引。所有查询都在使用   索引中设置的大多数字段。例如。索引名称   Source_1_StatusId_1_InfoIdHash_1_InfoUpdateDate_1_SoundExWord12_1   （等于，等于，范围，范围，用于排序）

到目前为止的结果：

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

到目前为止我们已经完成了更多研究/测试：一旦我们删除了在线索引的离线流程; M-R离线流程开始有良好的表现，因此我们确信在这里应用权利指标都是一件事。

问题/考虑：

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

向地图添加提示减少查询（/ 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}）提示（ “Source_1_StatusId_1_InfoIdHash_1_InfoUpdateDate_1_SoundExWord12_1”）解释（ “executionStats”）;   使用了正确的索引（在提示中定义）。



使用索引和在线查询中不同的字段顺序重新创建专用在线索引可防止脱机   使用此索引的过程，使在线过程能够使用它   但是，索引会降低在线流程的速度。我们   相信速度的下降是自我们搬迁的领域以来   索引的开头到索引的开头（未使用的那个   在离线查询中，仅在离线排序中）与contains一起使用   （$ 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
}

MongoDb - 索引优化

0 个答案: