...) ENGINE = MergeTree ORDER BY id
Но чувствую, что тут что-то не так, есть причины так не делать?
навскидку грустно будет при вставках, так как тяжко будет мержам (каждая строка - в рандомное место)
UUID жирный, много байтиков занимает
нельзя так делать высокая кардинальность PK путь в деградации производительности у вас постоянно будет больше мержей используйте какой нибудь snowflake id который на времени базируется и генерите его в приложении он монотонно возрастает
PK для *MergeTree должны быть столбцы с низкой кардинальностью постоянно используемые в запросах то есть всякие даты, типы событий и т.п.
У меня как раз есть такая табличка - очень не советую этот подход. В таблице 1.2млрд записей, ключ сортировки - record_id типа UUID. Поиск по record_id: использование памяти - 101 мб, время - 2013 мс, прочитано строк - 1.2 млрд А теперь делаем её копию, добавляем поле hashedRecordID UInt64 MATERIALIZED sipHash64(record_id) и меняем ключ сортировки на hashedRecordID. Поиск по hashedRecordID+record_id: использование памяти - 0, время - 6 мс, прочитано строк - 73 тыс
Обсуждают сегодня