UUID это FixedString(16) - 16 байт String репрезентация минимум вообще хранить в clickhouse (и в любой базе) классический uuid v4 довольно бесполезная затея ;-) много места занимает, искать неудобно (значения не монолитно возрастают, через data skip indexes при select ничего толком не ускоряется (ну разве что bloom что-то ускорит) как промежуточное решение можно sequential uuid попробовать генерировать на стороне приложения https://www.google.by/search?q=sequential+uuid+github как более компактное решение twitter snowflake id / sonyflake id в UInt64 хранить..
То есть если у меня юид как тип юид- он не даст никак х плюсов или минусов в сравнении с обычной строкой ?
ну валидацию даст )
но лучше использовать "натуральные ключи" конечно...
что значит натуральные ? обычные инкременттальные айдишки ? если вы про это, то у меня нет особо выбора. у меня в кафке есть данные от стороннего сервсиа и я вот думал что лучше юзать. Где-то юзаем string, где-то uuid но какой-тот разницы я не заметил, решил здесь спросить спасибо)
будет быстрее в двое по сравнению с обычной строкой читать с диска быстрее в два раза сравнивать 16 байт вместо 32
ну странно что вы разницы никакой незаметили... можете тесты какие то расшарить что вы делали?
у меня нет условий выборки по этим ключам, тоолько чтение если нужно, поэтому, насколько я понимаю, мне не сильно прям критично но я услышал про количество данных для чтения с диска, спасибо)
CREATE TABLE uuid_table AS SELECT UUIDv4(), number FROM numbers(1000000); SELECT name, type, compression_codec, formatReadableSize(compressed_data_size), formatReadableSize(uncompressed_data_size) FROM system.columns WHERE table='uuid_table'; CREATE TABLE string_table AS SELECT toString(UUIDv4()), number FROM numbers(1000000); SELECT name, type, compression_codec, formatReadableSize(compressed_data_size), formatReadableSize(uncompressed_data_size) FROM system.columns; ну и там еще всякие compression_codec поиграться можно с ZSTD
Натуральные - имеющие смысл (даты + ключи, если не получится то сонифлейк/сноуфлейк как Слач уже подсказал). а стринг вс ююид не сделает большой погоды
не будет ) у КХ какое-то убер быстрое сравнение строк (мы тут проверяли в прошлом году спорили по поводу cityHash64(string) vs string для ключей, и получилось что на коротких строках +/- одинаково)
Обсуждают сегодня