в качестве PK - уменьшит производительность ClickHouse, в сравнении с целым числом? Спасибо!
да. Самая большая проблема даже не в том что UUID не монотонный, а в том что UUID 16 байт, против UInt64 - 8 байт. Просто все операции в два - три раза медленее с UUID. Также прямо сейчас наконец-то задумались как ужасно для btree индексов что UUID не монотонен, и создают аж 4 новых версии UUID. Рекомендую посмотреть на twitter snowflake и sony sonyflake (там 64 бит и монотонность) потому что время в первых битах 39 bits for time in units of 10 msec 8 bits for a sequence number 16 bits for a machine id
Большое спасибо! Первый раз строю бд в которой будет более млрд записей, потому думаю над pk - ибо это осноная табица, ее id не относятся ни к чему и нужна только уникальность. Пошел изучать sonyflake)
Лучше почитайте описание движка mergetree сначала
возможно вы роете не в ту сторону. 1. Зачем вам PK вообще? 2. Вам нужен простой хеш? Просто cityHash64 ?
Его надо не читать, а прочувствовать))
По сути, все что мне нужно, это обязательная уникализация записи. Т.к записи будут добавляться разными скриптами - хочу не допустить конфликта, совпадений ID записей. Возможно вы правы, и есть иное решение
Спасибо, беру во внмание ) Ранее работал только с PostgreSQL
Uuid который со временем еще и переполнится может если что. Году к 32 так насколько я помню.
Если надо перенести данные из PG, есть MaterilizePG движок базы данных
Спасибо! Пригодится еще)
https://youtu.be/UVSZRQyrXac
ну есть конфликт и что? какая разница? и в чем проблема естественного ключа?
Не знаю, так-то вы правы, ведь я могу ввообще не создавать уникальной идентификации записи, еси она мне не нужна 🙂 А группировать можно по любому целому числу или по времени Нашел уже пару статей по вашим рекомендациям, изучаю. Спасибо за ответы!
Обсуждают сегодня