Question

在mongodb中，我们存储包含以下字段的平面数据（我们的事件对象）：

EventReceivedTimeStamp
EventStatus（SENT，FAILED，REJECTED）
唯一ID
系统（5个系统）
触发（20次触发）
的ErrorMessage

数据大小＆amp;更新

数据计数：2.7亿条
每天更新：300万（每天新增300万，每天删除300万）
文件大小：约2-3 kb

搜索条件：

EventReceivedTime范围和状态
EventReceived范围和系统以及触发器和状态
唯一标识

我们在上述字段中创建了复合索引/索引。

在对数据集执行搜索时，我们没有获得以毫秒为单位的响应时间。在我们的案例中，我们如何才能提高mongodb的性能？

SampleDocument

{
    "_id" : ObjectId("570cd8a55b66f3af1b4bd17e"),
    "_class" : "com.companyName.commons.dto.EventRecord",
    "uuid" : BinData(3,"10OXD+C51CEXS4E8jz0vnQ=="),
    "moc" : "APP_NOTIFICATION",
    "eventReceivedDateTime" : ISODate("2016-04-12T11:14:43.766Z"),
    "retryAttemptsMade" : 0,
    "retryAttemptDateTime" : ISODate("2016-04-12T11:14:43.766Z"),
    "eventStatus" : "FAILED",
    "systemName" : "OMS",
    "triggerName" : "COD_ORDER_NIGHT",
    "referenceId" : "39437515",
    "aggregatorBased" : true,
    "sentToDndQueue" : false,
    "lastProcessedDateTime" : ISODate("2016-04-12T11:14:44.294Z"),
    "errorMessage" : "Exception in validating attributes ",
    "suborderCodes" : [
        "39437515"
    ],
    "dndEvent" : false
}

**db.collection_name.getIndices()**

    [
        {
            "v" : 1,
            "key" : {
                "_id" : 1
            },
            "name" : "_id_",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "uuid" : 1
            },
            "name" : "uuid",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "moc" : 1
            },
            "name" : "moc",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "eventReceivedDateTime" : 1
            },
            "name" : "eventReceivedDateTime",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "retryAttemptsMade" : 1
            },
            "name" : "retryAttemptsMade",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "retryAttemptDateTime" : 1
            },
            "name" : "retryAttemptDateTime",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "eventStatus" : 1
            },
            "name" : "eventStatus",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "systemName" : 1
            },
            "name" : "systemName",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "triggerName" : 1
            },
            "name" : "triggerName",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "referenceId" : 1
            },
            "name" : "referenceId",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "aggregatorBased" : 1
            },
            "name" : "aggregatorBased",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "salesforceTagged" : 1
            },
            "name" : "salesforceTagged",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "sentToDndQueue" : 1
            },
            "name" : "sentToDndQueue",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "senderId" : 1
            },
            "name" : "senderId",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "lastProcessedDateTime" : 1
            },
            "name" : "lastProcessedDateTime",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "errorMessage" : 1
            },
            "name" : "errorMessage",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "suborderCodes" : 1
            },
            "name" : "suborderCodes",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "dndEvent" : 1
            },
            "name" : "dndEvent",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "eventStatus" : 1,
                "eventReceivedDateTime" : 1
            },
            "name" : "SDR",
            "ns" : "admin.event_record"
        },
        {
            "v" : 1,
            "key" : {
                "triggerName" : 1,
                "eventStatus" : 1,
                "systemName" : 1,
                "eventReceivedDateTime" : 1
            },
            "name" : "STSDR",
            "ns" : "admin.event_record"
        }
    ]

注意：将分享解释输出

Answer 1

1）。您可以使用批量操作进行读取，写入和更新。它大大减少了时间。

2）。创建模式，以便一起使用的字段位于一个集合中。

3）。即使写入数据需要搜索现有数据，您也必须快速进行搜索。所以勇敢地制作索引。如果创建更多索引，则数据写入操作会变慢。（另外需要更新索引）

4）。使用uniqeId作为_id

Answer 2

这一切都取决于你如何创建复合索引。在创建复合索引时，请确保检查查询将如何在集合上运行。定义复合索引，使索引的第一个键匹配（在查询中 - 等于语句），然后添加基于查询范围的键。请参阅https://docs.mongodb.org/manual/tutorial/create-queries-that-ensure-selectivity。

此外，请确保您有足够的内存（RAM）来处理数据集。您可以参考MongoDB官方文档 - https://docs.mongodb.org/manual/tutorial/ensure-indexes-fit-ram。

Answer 3

我们通过以下方式改进了查询的性能：

1）改变了分页逻辑。我们开始使用最后一个响应中发送的最后一个元素的id。而不是使用pageNumber / PageSize。

2）其次，我们开始给我们的查询提示，以便它应该使用适当的复合索引。

Mongo db读取性能改进

3 个答案: