Mongodb 写命令

Question

这篇文章会很长，如果你是mongo神，无论如何你都想帮助我，我从心底里感谢你。我尽量做到详尽，收集我收集的所有数据。

我在我的 MongoDD 数据库中遇到了一些奇怪的行为，我正在质疑 mongodb 的写入顺序。

我记录了仅在执行时发生的错误，这让我认为我们这里有时间问题，但是请求太慢了，我不明白它是如何在糟糕的情况下发生的

起点：

• 所有的 ObjectIds 都是 mongo 自动提供的，我从来没有设置它们在我身边
• 此 objectId 已编入索引（显然）且是唯一的
• 我使用这些请求 ID 中的时间戳来查询数据库，使用此请求：

    db.getCollection('eventStore').find({
      '_id': {
        '$gt': ObjectId("5d285c784460c502cc66ff9b"),
        '$lte': ObjectId("5d285cf7856cda0266215c77")
      }
    })

• 此请求的结果随后会使用基本的 Node.js 客户端可能性进行流式传输：

    collection.find({
        '_id': {
          ...(lower ? { '$gt': lower } : {}),
          '$lte': higher
        }
      }).sort({ _id: 1 }).stream({
        transform: (element) => {
          logger.info(`Exiting Get events by range::${JSON.stringify(lower)}::${JSON.stringify(higher)}`)
          logger.info(`Parse event::${JSON.stringify(element)}}`)
          return // PARSED EVENT
        }
      })

• 此时，我知道.sort({ _id: 1 }) 可能没用，但我还是把它留在这里，以防万一。
• 请求过程很慢：我查询上限以获取 eventStore 的偏移量，然后是视图的偏移量，然后查询存储以获取这些边界之间的所有事件。
• mongo 数据样本：

    /* 1 */
    {
        "_id" : ObjectId("5d285cf77f6482027108c15c"),
        "events" : [ 
            // Some events
        ]
    }

    /* 2 */
    {
        "_id" : ObjectId("5d285cf77f6482027108c15d"),
        "events" : [
            // Some events
        ]
    }

    /* 3 */
    {
        "_id" : ObjectId("5d285cf7856cda0266215c77"),
        "events" : [ 
            // Some events
        ]
    }

预期的 Mongo 行为：

• Mongo 是自行分配 ID，所以我希望当 ID ObjectId("5d285cf7856cda0266215c77") 存储在基础中，所有具有较旧时间戳的 ID 都已安全地存储在基础中。 ==> 无后退
• ObjectId 中编码的时间戳（当它由 mongo 自己给出时）是它写入并保存在数据库中的时间戳，而不是 Mongo 接收的时间戳。

实际行为（记录在记录器的函数中）：

• 在记录器的函数中只看到了第一个和最后一个 _id

    {"message":"Exiting Get events by range::\"5d285c784460c502cc66ff9b\"::\"5d285cf7856cda0266215c77\"","level":"info","timestamp":"2019-07-12 10:12:07"} 
    {"message":"Parse event::{\"_id\":\"5d285cf77f6482027108c15c\",\"events\":[ // Data ]}}","level":"info","timestamp":"2019-07-12 10:12:07"} 
    {"message":"Exiting Get events by range::\"5d285c784460c502cc66ff9b\"::\"5d285cf7856cda0266215c77\"","level":"info","timestamp":"2019-07-12 10:12:07"} 
    {"message":"Parse event::{\"_id\":\"5d285cf7856cda0266215c77\",\"events\":[ // Data ]}}","level":"info","timestamp":"2019-07-12 10:12:07"}

• 看起来：
  1. 或者事件 _id: ObjectId("5d285cf77f6482027108c15d") 在调用时不在基数中，但旧的 _id: ObjectId("5d285cf7856cda0266215c77") 是。
  2. 或者我的请求或流在调用时无效（但现在，返回正确答案）
  3. 还有别的吗？

Answer 1

Mongo 会自行分配 Id，因此我希望当 ID ObjectId("5d285cf7856cda0266215c77") 存储在 base 中时，所有具有较旧时间戳的 ID 都已安全地存储在 base 中。 ==> 无后退

Mongo _ids 是 ObjectIds 分别是：

• 一个 4 字节的值，表示自 Unix 纪元以来的秒数，
• 一个 5 字节的随机值，并且
• 一个 3 字节的计数器，从一个随机值开始。

这些通常在应用程序驱动程序代码中生成（在向 mongo 发送数据的服务器上）。

这意味着：

1. 网络延迟可能会产生乱序记录
2. 存在时钟漂移的应用服务器可能会创建乱序记录
3. 5 字节随机值不一定会在同一秒内向前移动（这可能会创建乱序记录，即使 mongo 正在分配 _ids）
4. NTP 更新可能会创建乱序记录（即使在 mongo 上——它在更新时钟时也不会造成任何拖尾）
5. 闰秒可以创建乱序记录

如果您查看共享的 _id，5d285cf77f6482027108c15d 和 5d285cf7856cda0266215c77 (5d285cf7) 的前 4 个字节（8 个字符）都共享相同的时间戳，因为它们发生在纪元。