node.js - 在 Mongodb 中使用自定义 ID 的效率成本是多少

Question

我计划使用 this NPM package (shortid) 生成较短的 ID，主要用于 URL，我希望按照指示将它们用作 Mongodb id(至少对于某些集合)。

使用自定义 ID 的相关费用是多少？它会以任何显着方式影响查找时间、写入时间等吗？

Answer 1

这些类型的问题很快就会陷入意见之争，因此我认为提供一些优缺点并让您决定哪个更适合此应用程序更有意义，而不是陈述意见。

假设“shortid”的格式将存储为一个字符串，我认为 Abigail Watson 的回应到 similar question on Google Groups总结了一些较大的点。她的回答主要针对 Meteor 应用程序，因此她的一些赞成/反对意见与 Meteor 团队做出的设计决策有关，但您可以看到您应该如何考虑是否使用 ObjectId或者“shortid”是基于应用程序的决定。

她的完整回复:

ObjectId Pros

• it has an embedded timestamp in it.
• it's the default Mongo _id type; ubiquitous
• interoperability with other apps and drivers

ObjectId Cons

• it's an object, and a little more difficult to manipulate in practice.
• there will be times when you forget to wrap your string in new ObjectId()
• it requires server side object creation to maintain _id uniqueness
• which makes generating them client-side by minimongo problematic

String Pros

• developers can create domain specific _id topologies

String Cons

• developer has to ensure uniqueness of _ids
• findAndModify() and getNextSequence() queries may be invalidated

Meteor's choice to go with a string, as I understand it, basically boils down to latency compensation and being able to generate the _id on the client-side in mini-mongo. The default ObjectId implementation didn't lend itself to being generated on the client as part of the latency compensation framework, so they decided to roll their own _id scheme.

Personally, I find the embedded timestamps in ObjectIds to be invaluable later in an application's lifecycle. They are more difficult to manipulate, and they add more debugging time to an application's development cycle. But for the extra 10 or 20 hours you put into debugging the ObjectIds, can return 10x or 100x savings down the road. Example: at work, we just salvaged a year's worth of production data because of the embedded timestamps, which has saved us probably hundreds of thousands of dollars of R&D time and effort.

ObjectId's are great if you can ensure that there's one central authority for generating them. They're also the preferred index type for any type of timeseries data. And while it may seem tempting to try to make a one-or-the-other decision for your entire app, I find choosing a string vs ObjectId (vs some other index scheme) really boils down to the topology of the data in the collection.

Some useful questions to maybe ask when choosing the _id for a collection:

• Does the data in the collection need latency compensation?
• Is it time-series data?
• Will other applications or worker utilities be accessing the collection?
• What is the topology of the data in the collection?

https://groups.google.com/d/msg/meteor-talk/f-ljBdZOwPk/oQYZQxCAKN8J

我要投入的两分钱是考虑如果使用“shortid”的主要原因是为了缩短 URL 为什么不创建一个 URL 属性，该属性也被索引并仅用于获取具有 URL id 的文档？您可以保留 ObjectId，这样您就不必担心以后的分片或依赖性问题，同时还可以使用更短的 URL ID 值。