KSUID order not predictable

[timofriedlberlin]

Hey there

The README states this:

In short, running a set of KSUIDs through the UNIX sort command will result in a list ordered by generation time.

I have the following code:

func TestKsuidOrder(t *testing.T) {
	k1 := ksuid.New()
	k2 := ksuid.New()
	assert.Equal(t, -1, ksuid.Compare(k1, k2))
}

Running it like this go test ./ -v -count=100 -run=TestKsuidOrder results in

    ksuid_test.go:31: 
                Error Trace:    ./ksuid_test.go:31
                Error:          Not equal: 
                                expected: -1
                                actual  : 1
                Test:           TestKsuidOrder

I was expecting that ksuid.New is generating sequences which can be naturally ordered?

If this is the expected behaviour which I see - then I guess the README should be more clear about that.

[timofriedlberlin]

Also, here in the README with the example of the cli tool:

$ ksuid -n 4
0ujsszwN8NRY24YaXiTIE2VWDTS
0ujsswThIGTUYm2K8FjOOfXtY1K
0ujssxh0cECutqzMgbtXSGnjorm
0ujsszgFvbiEr7CDgE3z8MAUPFt

But when using the first two ids the cli generated they are clearly not in natural order:

node -e 'console.debug("0ujsszwN8NRY24YaXiTIE2VWDTS" < "0ujsswThIGTUYm2K8FjOOfXtY1K")'
false

node -e 'console.debug("aaa" < "bbb")'
true

[timofriedlberlin]

This article states the following:

https://blog.kowalczyk.info/article/JyRZ/generating-good-unique-ids-in-go.html

4 bytes of time (seconds)

So I guess this means the generations of two successive ksuids must be apart about 1s until they really will be ordered by creation, is that correct ?

[achille-roussel]

You are correct, KSUIDs are roughly ordered but the default random generation we use does not guarantee absolute ordering.

A strategy we've used in some place is to generate one KSUID then derive the next ones from it by incrementing its value, which then creates a locally ordered sequence of ids.

[caldempsey]

@timo-klarshift In my experience of the library a delay of 3 seconds per K-SUID is a safe bet to guarantee ordering. I think the main feature is that they are K-Sortable, not that they are accurate on a per-second basis. If you need that I'd check out sonyflakes which are not always unique but will remain unique and sortable to millisecond precision. Hope that helps.

[timofriedlberlin]

This is really not a good approach if you want to create many of them in a high throughput system