4 ms·

I look up collisions every time I generate an ID and it's also sychronized when the node is broadcasted on the global cluster. UUIDs use time and origin to mak

by bullen 5y ago

I look up collisions every time I generate an ID and it's also sychronized when the node is broadcasted on the global cluster. UUIDs use time and origin to make things unique something that is both an advantage and also a problem, say for example you want to hide origin and time?! Also as danuker said, why add a dependency for no real benefit, Log4J should have proved to you that it's better to write minimalistic implementations yourself. Finally there is a difference between reinventing the wheel and improving the wheel: http://move.rupy.se/file/wheel.jpg http://move.rupy.se/file/wheel.jpg I made a distributed database in 2000 lines of Java.

majewsky 5y ago
> UUIDs use time and origin to make things unique Some UUID formats do. Format 4 has all bits (except the format bits) drawn from (P)RNG.
- bullen 5y ago
  But then is uniqueness guaranteed?
  - mercantile 5y ago
    From Wiki originally: > the annual risk of a given person being hit by a meteorite is estimated to be one chance in 17 billion, which means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. So in a theoretical sense, no, but in a practical sense, yes. The same is true for any custom ID format like yours as well. 128 bits is enough to never hit a dup though, so you don't need to go crazy. Your database should be what authoritatively guarantees uniqueness at the end of the day — generate UUIDs assuming no collisions (which will ~always be true), but store in a UNIQUE index so things'll fail in case of a duplicate or a bug that results in trying to store the same ID twice.

by bullen 5y ago

majewsky 5y ago

> UUIDs use time and origin to make things unique Some UUID formats do. Format 4 has all bits (except the format bits) drawn from (P)RNG.

bullen 5y ago
But then is uniqueness guaranteed?
- mercantile 5y ago
  From Wiki originally: > the annual risk of a given person being hit by a meteorite is estimated to be one chance in 17 billion, which means the probability is about 0.00000000006 (6 × 10−11), equivalent to the odds of creating a few tens of trillions of UUIDs in a year and having one duplicate. In other words, only after generating 1 billion UUIDs every second for the next 100 years, the probability of creating just one duplicate would be about 50%. So in a theoretical sense, no, but in a practical sense, yes. The same is true for any custom ID format like yours as well. 128 bits is enough to never hit a dup though, so you don't need to go crazy. Your database should be what authoritatively guarantees uniqueness at the end of the day — generate UUIDs assuming no collisions (which will ~always be true), but store in a UNIQUE index so things'll fail in case of a duplicate or a bug that results in trying to store the same ID twice.