xtdb 2022-09-19 | Slack Archive

zeitstein06:09:07

I was going to use https://github.com/zelark/nano-id, which uses string ids. @taylor.jeremydavid https://clojurians.slack.com/archives/CG3AM2F7V/p1663192655830849?thread_ts=1663191223.983299&cid=CG3AM2F7V this: > Don't use stringified UUIDs though, as actual UUIDS will be much more efficient. Can we elaborate on the above statement? Why are they more efficient? Is the statement always true (e.g. even if I use string ids say 10 chars long)?

lispyclouds08:09:12

My educated guess would be as https://github.com/ptaoussanis/nippy is used to serialize docs, it has specialization for Date and UUIDs: https://github.com/ptaoussanis/nippy/pull/27

✅ 1

refset10:09:46

Hey @U02E9K53C9L UUIDs are encoded and handled as 16-bytes total, via Nippy (plus a 1-byte prefix), whereas UTF-8 strings are between 1-4 bytes per char See also https://clojurians.slack.com/archives/CG3AM2F7V/p1649170454387559?thread_ts=1649169824.672809&cid=CG3AM2F7V 🙂 And for codec reference (e.g. Dates are mostly handled natively, not via Nippy): https://github.com/xtdb/xtdb/blob/ae34fd5b27aa33ea914df6bc4ab52c3e3d853c19/core/src/xtdb/codec.clj#L82-L100

zeitstein10:09:17

Thank you to the both of you! I'm sorry to say that I'm still not sure exactly what "efficient" means here. Are UUIDs just using less disk space? Or will db reads be faster when using UUIDs too? I'm wanting URL-friendly ids (both alphabet-wise and length-wise), and I feel completely out of my depth evaluating the trade-offs here.

refset10:09:22

> Are UUIDs just using less disk space? Or will db reads be faster when using UUIDs too? These two are fairly entwined. Fewer bytes means: less I/O, faster byte-wise comparisons during index traversals, better caching density etc.

refset10:09:56

Whether or not any of that is perceptible for your app/users is another matter, of course 🙂

zeitstein11:09:58

Thank you! Seems like sticking with strings for now is not too bad.

2022-09-19

Channels