3

I want to hack ObjectId by manipulating the machineId like this:

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

the basic idea is to use 1 byte of machineId to distinguish the object type, my question is: is there any problem when doing so (considering uniqueness and sharding)?

--- update on Dec 9 ---

Due to the difference between the spec and implementation Why the bson java implementation uses 4 bytes inc field?, I'm going to change my solution a bit to following style:

         <timestamp> <machineId> <processId> <inc>
UserId   XXXXXXXX    XXXX        XXXX        01XXXXXX
OrderId  XXXXXXXX    XXXX        XXXX        02XXXXXX
CardId   XXXXXXXX    XXXX        XXXX        03XXXXXX
...
Community
  • 1
  • 1
BigFatSea
  • 473
  • 1
  • 6
  • 13
  • Thanks Adam, Kristina. My major concerns are: uniqueness and any potential impact on sharding (recall the foursquare case). Do you guys have any further comment? – BigFatSea Dec 08 '12 at 03:00
  • besides the caveats in my answer below, I can't think of any - last point though - if you are going to use it as a shard key, remember that having it as the leftmost element of a compound shard key, or a shard key by itself is a bad idea for write scaling - it will be monotonically increasing (plenty written about that), so you should think about a different prefix at least when choosing a shard key – Adam Comerford Dec 11 '12 at 10:22

2 Answers2

2

Assuming two bytes of machine id is sufficiently unique for your deployment, that should be fine. Neat idea!

kris
  • 23,024
  • 10
  • 70
  • 79
1

As long as you don't violate the spec, and the ObjectID is still the correct form, there is no reason you can't do this, and it will save you some space of course.

A couple of notes though:

First, if you are planning to do this by, say, overloading the code in a driver and altering how the ObjectID is generated, then you will be inserting the modified ObjectID as-is and the old "normal" one would never be inserted (most drivers are the ones actually generating the ObjectID, not the server, though it can be the server too).

That scenario, where it is inserted already altered, would be preferred. The reason?

If you update and change the generated ObjectID instead, or if you change the type later on and have to alter the ObjectID, you may hit issues if you try to use that field as a shard key (or part thereof) further down the road (shard key is immutable). The way around this in a sharded environment when you have to update a shard key, is to remove the document in question and re-add it rather than update.

Additionally, the update method is a needless operation you can avoid (may or may not be a concern for you).

Finally, there is uniqueness - since the machine ID is not going to change a lot anyway, I don't think you are going to hit any issues here, the inc field should take care of collisions within a single second, but just be careful in case the method you use to alter the ObjectID causes something odd to occur.

Adam Comerford
  • 21,336
  • 4
  • 65
  • 85