UUID, efficiency and indices

[mbn18 (Michael Ben-Nes)]

We need an external unique ID for each entity (type). For example: Device, user, Measurement.
ID type is UUID4 => 437e8c3b-0b92-4e9f-b111-f361b22a5888

Our first thought was:

uuid: string @index(exact) @upsert .

Our concern for performance raised the following questions:

1. Is string is the most efficient type? Maybe list of bytes (is it possible?)
2. Which index foot print is smaller? hash or exact? The uuid is 128bit, but it is also saved as UTF8 which is more bloated than binary.
3. Should we split the uuid to types, like user.uuid, device.uuid and etc, And that to avoid over bloated index?

Other thoughts (of less urgency but interesting non the less).

• split the uuid and search by the prefix and filter by the suffix:
  1. uuid_prefix => 437e8c3b
  2. uuid_postfix => 0b92-4e9f-b111-f361b22a5888

Or maybe write a custom tokenizer that specialize with uuid?

[mrjn (Manish R Jain)]

@mbn18

• Is string is the most efficient type? Maybe list of bytes (is it possible?)

String is fine. We thought about having blob, but then realized it’s the same thing as string in Go.

@mbn18

• Which index foot print is smaller? hash or exact? The uuid is 128bit, but it is also saved as UTF8 which is more bloated than binary.

Hash is slightly smaller, I think. We’d hash the string and store that hash as key for the index internally.

@mbn18

1. Should we split the uuid to types, like user.uuid , device.uuid and etc, And that to avoid over bloated index?

You could do that, if you expect each of these to become quite big.

@mbn18

Or maybe write a custom tokenizer that specialize with uuid ?

That’s a possibility too. But, hash should be able to do the job.