在MongoDB中使用UUID代替ObjectID [英] Using UUIDs instead of ObjectIDs in MongoDB

问题描述

出于性能原因，我们正在将数据库从MySQL迁移到MongoDB，并考虑将哪些内容用于MongoDB文档的ID.我们正在争论使用MongoDB默认的ObjectID还是使用UUID(这是迄今为止在MySQL中我们一直在使用的东西)之间的争论.到目前为止，我们必须支持这些选项中的任何一个的参数如下:

We are migrating a database from MySQL to MongoDB for performance reasons and considering what to use for IDs of the MongoDB documents. We are debating between using ObjectIDs, which is the MongoDB default, or using UUIDs instead (which is what we have been using up until now in MySQL). So far, the arguments we have to support any of these options are the following:

对象ID: ObjectID是MongoDB的默认值，我假设(尽管不确定)这是有原因的，这意味着我希望MongoDB可以比UUID更有效地处理它们，或者有其他原因更喜欢它们.我还发现这个stackoverflow答案提到使用ObjectID可以使索引更有效，但是具有一些度量标准也很好这种更有效"的程度是多少.

ObjectIDs: ObjectIDs are the MongoDB default and I assume (although I'm not sure) that this is for a reason, meaning that I expect that MongoDB can handle them more efficiently than UUIDs or has another reason for preferring them. I also found this stackoverflow answer that mentions that usage of ObjectIDs makes indexing more efficient, it would be nice however to have some metrics on how much this "more efficient" is.

UUID: 我们支持使用UUID(这是非常重要的)的基本论点是，几乎任何数据库都以一种或另一种方式支持UUID.这意味着，如果将来我们出于某种原因决定从MongoDB切换到其他方式，并且我们已经有了一个API，该API可以根据数据库的ID从数据库中检索文档，因为该ID可以继续，因此该API的客户端没有任何变化完全一样.如果我们要使用ObjectID，我不确定如何将它们迁移到另一个数据库.

UUIDs: Our basic argument in favour of using UUIDs (and it is a quite important one) is that they are supported, one way or another, by virtually any database. This means that if some way down the road we decide to switch from MongoDB to something else for whatever reason and we already have an API that retrieves documents from the DB based on their IDs nothing changes for the clients of this API since the IDs can continue to be exactly the same. If we were to use ObjectIDs I'm not really sure how we would go about migrating them to another DB.

对于这些选项中的一种是否比另一种更好?有人对它有任何见解吗?为什么?您曾经在MongoDB中使用过UUID而不是ObjectID，如果是，您遇到的优点/问题是什么?

Does anyone have any insights on whether one of these options may be better than the other and why? Have you ever used UUIDs in MongoDB instead of ObjectIDs and if yes what were the advantages / problems you came across?

推荐答案

我认为这是个好主意，Mongo也是如此.他们将UUID列为 _id字段<的通用选项之一/a>.

I think this is a great idea and so does Mongo; they list UUIDs as one of the common options for the _id field.

注意事项:

• 性能-如其他答案所述，基准 show UUID导致插入性能下降.在最坏的情况下(集合中的文档从1000万增加到2000万)，它们的速度要慢大约2-3倍-每秒插入2,000(UUID)和7,500(ObjectID)文档之间的差.这是一个很大的差异，但是其重要性完全取决于您的用例.您会一次批量插入数百万个文档吗?对于大多数我构建的应用程序，常见的情况是插入单个文档.在那个测试中，差异很多更小(6,250 -vs- 7,500；〜20％). ID类型根本不是限制因素.
• 可移植性-当然，其他数据库确实倾向于提供良好的UUID支持，因此可移植性将得到改善.或者，由于UUID较大(位更多)，因此可以将ObjectID重新打包为UUID的形状" .这种方法不如直接可移植性好，但确实为您提供了前进的道路.

• Performance -- As other answers mention, benchmarks show UUIDs cause a performance drop for inserts. In the worst case measured (going from 10M to 20M docs in a collection) they've about ~2-3x slower -- the difference between inserting 2,000 (UUID) and 7,500 (ObjectID) docs per second. This is a large difference but it's significance depends entirely on you use case. Will you be batch inserting millions of docs at a time? For most apps I've build the common case is inserting individual documents. In that test the difference is much smaller (6,250 -vs- 7,500; ~20%). The ID type is simply not the limiting factor.
• Portability -- Other DBs certainly do tend to have good UUID support so portability would be improved. Alternatively, since UUIDs are larger (more bits) it is possible to repack an ObjectID into the "shape" of a UUID. This approach isn't as nice as direct portability but it does give you a path forward.

应对其他一些答案:

• UUID具有本机支持-您可以使用 函数与您使用ObjectID()的方法完全相同；将字符串转换为等效的BSON对象.
• UUID并不是特别大-与96位的ObjectID相比，它们是128位. (它们应使用二进制子类型0x04进行编码.)
• UUID可以包含时间戳-特别是，UUIDv1编码的时间戳具有60位精度，而ObjectID中只有32位.精度提高了6个数量级以上，因此是毫微秒而不是秒.实际上，它可以是一种比Mongo/JS Date对象更准确地存储创建时间戳的好方法，但是...
  • UUID()中的内置功能仅生成v4(随机)UUID，因此，要利用此功能，您需要依靠应用或Mongo驱动程序来创建ID.
  • 与ObjectID不同，由于 UUID的分块方式，时间戳记没有给你一个自然的秩序.这可能是好事，也可能是坏事，具体取决于您的用例.
  • 在您的ID中包含时间戳记通常不是一个好主意.您最终会泄漏任何暴露ID的文档的创建时间.更糟的是，v1 UUID还为生成它们的机器编码一个唯一的标识符，该标识符可以公开有关您的基础架构的其他信息(例如，服务器数量).当然，ObjectID也会对时间戳进行编码，因此对它们来说也是如此.
  • UUIDs have native support -- You can use the UUID() function in the Mongo Shell exactly the same way you'd use ObjectID(); to convert a string into equivalent BSON object.
  • UUIDs are not especially large -- They're 128 bit compared to ObjectIDs which are 96 bit. (They should be encoded using binary subtype 0x04.)
  • UUIDs can include a timestamp -- Specifically, UUIDv1 encodes a timestamp with 60 bits of precision, compared to 32 bits in ObjectIDs. This is over 6 orders of magnitude more precision, so nano-seconds instead of seconds. It can actually be a decent way of storing create timestamps with more accuracy than Mongo/JS Date objects support, however...
    • The build in UUID() function only generates v4 (random) UUIDs so, to leverage this this, you'd to lean on on your app or Mongo driver for ID creation.
    • Unlike ObjectIDs, because of the way UUIDs are chunked, the timestamp doesn't give you a natural order. This can be good or bad depending on your use case.
    • Including timestamps in your IDs is often a Bad Idea. You end up leaking the created time of documents anywhere an ID is exposed. To make maters worse, v1 UUIDs also encode a unique identifier for the machine they're generated on which can expose additional information about your infrastructure (eg. number of servers). Of course ObjectIDs also encode a timestamp so this is partly true for them too.

    这篇关于在MongoDB中使用UUID代替ObjectID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！