3

我想通过像这样操作 machineId 来破解 ObjectId：

         <timestamp> <machineId> <processId> <inc>
UserId   XXXXXXXX    XXXX01      XXXX        XXXXXX
OrderId  XXXXXXXX    XXXX02      XXXX        XXXXXX
CardId   XXXXXXXX    XXXX03      XXXX        XXXXXX
...

基本思路是用 1 字节的 machineId 来区分对象类型，我的问题是：这样做有没有问题（考虑唯一性和分片）？

--- 12 月 9 日更新 ---

由于规范和实现之间的差异为什么 bson java 实现使用 4 字节 inc 字段？，我将把我的解决方案更改为以下样式：

         <timestamp> <machineId> <processId> <inc>
UserId   XXXXXXXX    XXXX        XXXX        01XXXXXX
OrderId  XXXXXXXX    XXXX        XXXX        02XXXXXX
CardId   XXXXXXXX    XXXX        XXXX        03XXXXXX
...
4

2 回答 2

2

假设两个字节的机器 ID 对于您的部署来说是足够独特的，那应该没问题。好主意！

于 2012-12-07T19:29:30.560 回答
1

只要你不违反规范，并且 ObjectID 仍然是正确的形式，你没有理由不能这样做，它当然会为你节省一些空间。

不过有几点注意事项：

首先，如果您打算通过重载驱动程序中的代码并更改 ObjectID 的生成方式来执行此操作，那么您将按原样插入修改后的 ObjectID，而永远不会插入旧的“正常”对象 ID（大多数驱动程序是实际生成 ObjectID 的驱动程序，而不是服务器，尽管它也可以是服务器）。

这种情况下，它被插入已经改变，将是首选。原因？

如果您改为更新和更改生成的 ObjectID，或者如果您稍后更改类型并且必须更改 ObjectID，如果您尝试将该字段用作进一步的分片键（或其一部分），则可能会遇到问题（ shard key 是不可变的）。当您必须更新分片键时，在分片环境中解决此问题的方法是删除有问题的文档并重新添加它而不是更新。

此外，更新方法是您可以避免的不必要操作（您可能担心也可能不担心）。

最后，有唯一性 - 因为机器 ID 无论如何都不会改变很多，我认为你不会在这里遇到任何问题， inc 字段应该在一秒钟内处理碰撞，但要小心以防您用于更改 ObjectID 的方法导致发生奇怪的事情。

于 2012-12-07T19:32:15.387 回答