即使使用索引，MongoDb 性能也很慢

Question

我们正在尝试使用 mongo 为我们的用户构建一个通知应用程序。我们在 10GB RAM、150GB SAS HDD 15K RPM、4 Core 2.9GHZ xeon intel XEN VM 上创建了 1 个 mongodb。

数据库架构:-

{
  "_id" : ObjectId("5178c458e4b0e2f3cee77d47"),
  "userId" : NumberLong(1574631),
  "type" : 2,
  "text" : "a user connected to B",
  "status" : 0,
  "createdDate" : ISODate("2013-04-25T05:51:19.995Z"),
  "modifiedDate" : ISODate("2013-04-25T05:51:19.995Z"),
  "metadata" : "{\"INVITEE_NAME\":\"2344\",\"INVITEE\":1232143,\"INVITE_SENDER\":1574476,\"INVITE_SENDER_NAME\":\"123213\"}",
  "opType" : 1,
  "actorId" : NumberLong(1574630),
  "actorName" : "2344"
}

DB stats :-
db.stats()
{
    "db" : "UserNotificationDev2",
    "collections" : 3,
    "objects" : 78597973,
    "avgObjSize" : 489.00035699393925,
    "dataSize" : 38434436856,
    "storageSize" : 41501835008,
    "numExtents" : 42,
    "indexes" : 2,
    "indexSize" : 4272393328,
    "fileSize" : 49301946368,
    "nsSizeMB" : 16,
    "dataFileVersion" : {
        "major" : 4,
        "minor" : 5
    },
    "ok" : 1
}

index :- userid 和 _id

我们正在尝试为一位用户选择最新的 21 条通知。

db.userNotification.find({ "userId" : 53 }).limit(21).sort({ "_id" : -1 });

但是这个查询花费了太多时间。4 月 26 日星期五 05:39:55.563 [conn156] query UserNotificationDev2.userNotification query: { query: { userId: 53 }, orderby: { _id: -1 } } cursorid:225321382318166794 ntoreturn:21 ntoskip:0 nscanned:266025 keyUpdates:0 numYields: 2 locks(micros) r:4224498 nreturned:21 reslen:10295 2581ms

即使计数也需要大量时间。

Fri Apr 26 05:47:46.005 [conn159] command UserNotificationDev2.$cmd command: { count: "userNotification", query: { userId: 53 } } ntoreturn:1 keyUpdates:0 numYields: 11 locks(micros) r:9753890 reslen:48 5022ms

我们是否在查询中做错了什么？

请帮忙!!!

如果我们的架构对于存储用户通知不正确，也会提出建议。我们尝试了像用户这样的嵌入式通知，然后在该文档下为该用户发送通知，但文档限制限制我们只能存储 ~50k 通知。所以我们改成了这个。

Answer 1

您正在通过 userId 进行查询，但没有在任何地方对其进行索引。我的建议是在 { "userId": 1, "_id": -1 } 上创建一个索引。这将创建一个以 userId 开头的索引树，然后是 _id，这几乎正是您的查询正在执行的操作。这是加快查询速度的最简单/最灵活的方法。

另一种内存效率更高的方法是将您的用户 ID 和时间戳作为字符串存储在 _id 中，例如 _id : "USER_ID:DATETIME。例如:

{_id : "12345:20120501123000"}
{_id : "15897:20120501124000"}
{_id : "15897:20120501125000"}

注意 _id 是字符串，不是 MongoId。然后你上面的查询变成一个正则表达式:

db.userNotification.find({ "_id" : /^53:/ }).limit(21).sort({ "_id" : -1 });

正如预期的那样，这将按降序返回 userId 53 的所有通知。内存效率部分有两个方面:

1. 您只需要一个索引字段。 (索引与数据竞争内存，通常大小为几千兆)
2. 如果您的查询通常是关于获取较新的数据，当索引太大而无法容纳整个索引时，右平衡索引可以让您最常在内存中工作。

回复:计数。计数确实需要时间，因为它会扫描整个集合。

回复:您的架构。我猜对于您的数据集，这是利用您的内存的最佳方式。当对象变大并且您的查询扫描多个对象时，它们将需要全部加载到内存中(当我在 2GB RAM 机器上对 2000 个 2MB 对象进行排序时，我让 OOM killer 杀死了我的 mongod 实例)。对于大型对象，您的 RAM 使用量会波动很大(更不用说它们在一定程度上受到限制)。使用您当前的模式，mongo 将更容易地只加载您正在查询的数据，从而减少交换和更一致的内存使用模式。