在Mongodb中使用自定义ID相关的效率成本是多less？
我打算使用这个NPM包 （shortid）生成较短的ID，主要用于URL，我希望按照指示使用它作为Mongodb ID（至less对于某些集合）。
与使用自定义ID相关的成本是多less？ 它会影响查询时间，写入时间等任何重要的方式？
这些types的问题可以很快走到意见的争斗之中，而不是说出一个意见，我认为提供一些利弊，让你决定哪个更适合这个应用程序会更有意义。
假设“shortid”的格式将以stringforms存储，我认为Abigail Watson 对Google Groups上类似问题的回复总结了一些较大的观点。 她的回应主要是针对meteor应用程序，所以她的一些专业人员与Meteor团队做出的devise决定有关，但是你可以看到你应该如何考虑是否使用ObjectId或“shortid”是基于应用的决定。
她的全部回应：
ObjectId优点
- 它有一个embedded式的时间戳。
- 这是默认的Mongo _idtypes; 普及
- 与其他应用程序和驱动程序的互操作性
ObjectId缺点
- 这是一个对象，在实践中操作有点难度。
- 有些时候你忘记把你的string换成新的ObjectId（）
- 它需要创build服务器端对象来维护_id唯一性
- 这使得通过minimongo产生客户端的问题
string优点
- 开发人员可以创build特定于域的_id拓扑
string缺点
- 开发人员必须确保_ids的独特性
- findAndModify（）和getNextSequence（）查询可能会失效
根据我的理解，Meteorselect使用string，基本上归结为延迟补偿，并能够在mini-mongo中在客户端生成_id。 默认的ObjectId实现并不适合作为延迟补偿框架的一部分在客户端上生成，因此他们决定推出自己的_idscheme。
就我个人而言，我发现ObjectIds中embedded的时间戳在应用程序生命周期的晚些时候是非常宝贵的。 他们更难于操作，并且为应用程序的开发周期增加了更多的debugging时间。 但是对于额外的10或20小时的debuggingObjectIds，可以返回10倍或100倍的节省。 例如：在工作中，由于embedded了时间戳，我们只是挽回了一年的生产数据，这为我们节省了数十万美元的研发时间和精力。
如果可以确保有一个中央机构来生成它们，ObjectId是非常好的。 它们也是任何时间序列数据的首选索引types。 尽pipe尝试为整个应用程序做出独一无二的决定似乎很有诱惑力，但我发现select一个stringvs ObjectId（与其他一些索引scheme相比）实际上归结为集合中数据的拓扑结构。
在select集合的_id时可能会提出的一些有用的问题：
- 收集中的数据是否需要延迟补偿？
- 是时间序列数据吗？
- 其他应用程序或工具实用程序是否将访问该集合？
- 集合中的数据的拓扑结构是什么？
https://groups.google.com/d/msg/meteor-talk/f-ljBdZOwPk/oQYZQxCAKN8J
我的两个投入组合的考虑是否使用“shortid”的主要原因是较短的URL为什么不创build一个URL属性也是索引，并只用于获取具有URL ID的文档？ 您可以保留ObjectId这样您就不必担心路上的分片或依赖性问题，同时也会缩短URL ID值。