Re: voyage/mongo randomly wrong OIDs
Posted by Henrik Sperre Johansen on Sep 02, 2013; 8:34am
URL: https://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4706072.html
On Aug 31, 2013, at 3:30 , Sven Van Caekenberghe <[hidden email]> wrote:
>
> On 31 Aug 2013, at 13:47, Stéphane Ducasse <[hidden email]> wrote:
>
>> Sabine
>> what we could do is to propose a "subclass of UUID" and to group several UUID generators.
>> Like that with a couple of classes, we could get a better eco system where people can pick the one they want.
>>
>> stef
>
> I just made my own, called NeoUUIDGenerator, http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo/packages/Neo-UUID
>
> @Sabine
>
> IMHO what I think a local counter does not, is give you uniques over different machines, images, instances - that is why there is also the concept of node identification.
>
> In my implementation I combine the millisecond clock, a small random number, a counter and a node id. The node id is based on several elements, it should be different when running multiple images.
>
> This is a hack, not something that I can prove mathematically. But it can't be worse than pure random. I think the speed is also acceptable:
>
> | generator |
> generator := NeoUUIDGenerator new.
> [ generator next ] bench. '408,000 per second.'
>
> | generator |
> generator := UUIDGenerator new.
> [ generator generateBytes: UUID nilUUID forVersion: 4 ] bench. '13,300 per second.'
>
> SvenSo sorta like UUID type 3/5, but with a custom object identifier scheme, and no hashing?
Not sure it'd be fair to call that any kind of UUIDGenerator anymore, as the UUID standard and its encompassing types is a pretty well-defined ;)
IIRC, the reason those went out of flavor in favor of type 4, is the fact they do potentially identify the source computer from which they were created, and thus a purely random approach was considered better. (as long as it is just that, which, as this thread illustrates, is another matter)
Cheers,
Henry
URL: https://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4706072.html
On Aug 31, 2013, at 3:30 , Sven Van Caekenberghe <[hidden email]> wrote:
>
> On 31 Aug 2013, at 13:47, Stéphane Ducasse <[hidden email]> wrote:
>
>> Sabine
>> what we could do is to propose a "subclass of UUID" and to group several UUID generators.
>> Like that with a couple of classes, we could get a better eco system where people can pick the one they want.
>>
>> stef
>
> I just made my own, called NeoUUIDGenerator, http://www.smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo/packages/Neo-UUID
>
> @Sabine
>
> IMHO what I think a local counter does not, is give you uniques over different machines, images, instances - that is why there is also the concept of node identification.
>
> In my implementation I combine the millisecond clock, a small random number, a counter and a node id. The node id is based on several elements, it should be different when running multiple images.
>
> This is a hack, not something that I can prove mathematically. But it can't be worse than pure random. I think the speed is also acceptable:
>
> | generator |
> generator := NeoUUIDGenerator new.
> [ generator next ] bench. '408,000 per second.'
>
> | generator |
> generator := UUIDGenerator new.
> [ generator generateBytes: UUID nilUUID forVersion: 4 ] bench. '13,300 per second.'
>
> Sven
Not sure it'd be fair to call that any kind of UUIDGenerator anymore, as the UUID standard and its encompassing types is a pretty well-defined ;)
IIRC, the reason those went out of flavor in favor of type 4, is the fact they do potentially identify the source computer from which they were created, and thus a purely random approach was considered better. (as long as it is just that, which, as this thread illustrates, is another matter)
Cheers,
Henry
signature.asc (859 bytes) | Free forum by Nabble | Edit this page |