2

I'm currently using uuid npm package to generate unique IDs for the elements of my graph database in my node.js app.

It generates RFC-compliant 128-bit long IDs, like 

6e228580-1cb5-11e8-8271-891867c15336

I'm currently thinking to shift to shortid npm package, which does a similar job but generates 7-bit long IDs:

PPBqWA9

My database requests are already long and I want to shorten them, so I'm considering the switch from uuid to shortid.

However, the question: I understand that the 128-bit long compliant UUID generator guarantees that it's going to be unique. What about the 7-bit one? I understand it can provide about 78364164096 unique possibilities which is not bad, but I already have about 50M unique objects in my DB, each of which has a unique index, so I'm just curious if that algorithm would really be able to generate a unique ID considering that 78364164096 is only 1350 times more than 50000.

Any ideas? Should I use a 7-bit identifier or a 128-bit one?

Aerodynamika
  • 7,883
  • 16
  • 78
  • 137
  • 2
    I think you mean 7-byte instead of 7-bit. And it was unclear if those 7-byte ids are constrained to printable or printable-ASCII characters. – flaviodesousa Feb 28 '18 at 19:04

1 Answers1

5

I will assume the shorter ids provided by the shortid package to be full 56 bit long. But most likely they take 56-bit long space (7 bytes) but only something like 42-bit long payload.

Both 56-bit and 128-bit ids are subject to collision. The difference is the probability of having a collision. I think the 56-bit one REQUIRE you to be able to handle collisions, so you'll end up having a more complex code. The 128-bit is quite unlikely to produce collisions to the point of generally not being considered.

For the sake of simplicity and safety, I would choose the time proven 128-bit.

flaviodesousa
  • 7,255
  • 4
  • 28
  • 34