【问题标题】:Is it OK to store Mongo _id as a string, instead of ObjectId是否可以将 Mongo _id 存储为字符串,而不是 ObjectId
【发布时间】:2021-03-27 15:01:57
【问题描述】:

这个问题已被问过几次,但使用 ObjectId 的“优点”似乎都不适用于我的案例,而且这些问题都已经很老了。我想知道我是否缺少任何东西。

具体来说,我在这两个选项之间做出决定:

  1. _id 存储为数据库中的ObjectId
  2. _id 存储为 DB 中 ObjectId 的字符串表示形式。

我对倾向于存储 ObjectId 对象而不是其字符串表示的原因的理解:

  • 它们是 12 字节而不是 24 字节。这只是每百万条记录 12 MB,文档大小的一小部分,以及几美分的额外基础设施,因此不保证增加我的应用程序代码的复杂性。
  • 它们“更快”。我一直听到这个,但没有人说 多少 快,这让我想知道是否没有区别,每个人都只是重复他们从其他人那里听到的内容。我找到了these benchmarks,其中单个项目的读取时间是相同的。写一百万条记录时会有所不同,但我不会那样做。像这样的基准测试也没有考虑到每次写入操作将对象(通过网络)从字符串 ID 转换为 ObjectId 对象所花费的额外时间。我怀疑必须在应用服务器上添加一个循环来解析传入数据并将字符串转换为 new ObjectId(item._id) 以获取百万条记录会平衡结果。
  • 使用ObjectId 是“正常”的方式。我对这个论点有些动摇,我不喜欢以奇怪的方式做事。但由于它会导致额外的代码容易出现错误,因此这本身并不是一个足够好的理由。

想要执行选项 2 的原因是,当数据在用户空间和数据库之间流动时,我在应用程序的许多地方都在转换字符串/ObjectId。不仅适用于_id 字段,还适用于otherItemIdlistOfRelatedThingIds。它们都在输出时(通过网络)隐式转换为字符串,并且需要在输入时手动转换回来。这不是世界上最糟糕的事情,但如果没有充分的理由要这样做,那么我将切换到数据库中的字符串。

【问题讨论】:

  • 我认为这个问题毫无意义。但是您可以讨论使用 MongoDB 内部的ObjectId 还是为_id 字段使用自行开发的自定义字符串/数字是否有意义。
  • 感谢您让我知道您认为我的问题毫无意义。现在如果有人问,Wernfried Domscheit 对此有何看法,我会毫不犹豫地说:“哦,Wernfried 认为这个问题毫无意义”
  • 好吧,这个问题本身并不是毫无意义的。但是为 ObjectId 使用字符串的方法没有多大意义。

标签: mongodb bson


【解决方案1】:

ObjectID 类型具有用于排序的内置时间戳。您引用的 12 个字节中的 4 个字节专用于表示自 unix 纪元以来的时间(以秒为单位)。当您创建 ObjectID 时,它们可以根据创建顺序自动相互排序。

您可以使用 ObjectID 上的 .getTimeStamp() 函数来返回时间戳。

var id = new ObjectId();
console.log(id.getTimestamp())

您可能认为在存储文档方面节省了一些基础架构成本,但在访问、排序和索引方面也节省了开销。

【讨论】:

  • ObjectId 的字符串表示也是可排序的,因此这不是将数据存储为 ObjectId 的理由(我也不需要按“生成 ID 的日期”进行排序) .您说“......在访问、排序和索引方面也节省了开销”。节省多少?你能链接到证明这些节省的东西吗?
猜你喜欢
  • 2014-07-30
  • 1970-01-01
  • 2015-12-13
  • 1970-01-01
  • 2020-10-16
  • 2020-10-25
  • 1970-01-01
  • 1970-01-01
  • 2012-03-18
相关资源
最近更新 更多