184 похожих чатов

Вопрос про влияние ключа сортировки на скорость работы CollapsingMergeTree. Например, есть

CollapsingMergeTree, ключ сортировки record_id имеет тип UUID. Её задача - удалять дубли.
В таблице 1.2 млрд записей, в день пишется около 100 млн новых, которые попарно схлопываются и остаются только оставшиеся без пар.

Выбор произвольной записи из этой таблицы по record_id занимает 2000мс и ест 100мб памяти, а если ключом сортировки сделать sipHash64(record_id), то поиск по нему происходит уже за 11мс.

Вопрос - а повлияет ли замена ключа сортировки с record_id на sipHash64(record_id) на скорость\качество схлопывания всей CollapsingMergeTree? Потому что сейчас есть ощущение, что приличная часть дублей никогда не схлопывается (не успевает?) до наступления TTL.

8 ответов

3 просмотра

вместо UUID лучше использовать snowflake id UInt64 оно монотонно нарастает и ORDER BY и merge Работать будут быстрее

Alexey-Sokolov Автор вопроса
Slach [altinity]
вместо UUID лучше использовать snowflake id UInt64...

Спасибо, поизучаю. Но в текущей ситуации они прилетают извне и для начала надо научиться более быстро работать с этими. Разве что генерить для каждой прилетающей записи второй адишник и внутри работать с ним, а наружу отдавать оригинальный.

Alexey Sokolov
Спасибо, поизучаю. Но в текущей ситуации они прил...

ну можете попробовать FINAL использовать чтобы дедупликация проходила уже в момент SELECT ...

Slach [altinity]
ну можете попробовать FINAL использовать чтобы дед...

а если выборка затронет 1ТБ данных, селект же будет дожидаться?

Alexey-Sokolov Автор вопроса

Кстати, с группировкой не всё так однозначно как с выбором одной записи: select record_id from TableWithUUIDKey group by record_id having sum(Sign) != 0 - 10 гигов памяти, 6700мс select record_id from TableWithHashedKey group by recordHash, record_id having sum(Sign) != 0 - 14 гигов памяти, 10200мс

Gleb
а если выборка затронет 1ТБ данных, селект же буде...

select не ждет. Он сам делает final на лету, для себя лично.

потому что UUID 128бит. И надо больше памяти и возможно начинается вытеснение группировки на диск

на шедулер мержей ключ таблицы не влияет, шедулер мерже рассматривает размеры и кол-во партов

Похожие вопросы

Обсуждают сегодня

А как старый хаскел с новым стыковать ? потому как тут работает https://play.haskell.org/saved/C3xpMzcd, а вот тут https://stepik.org/lesson/7602/step/9?unit=1473 нет ошибка C...
Fedor
131
что насчет пагинга? на осдеве непонятно(
Vi Chapmann 🪙
26
Народ, кто шарит в расширенных разделах (EBR/EPR) на дисках с разметками MBR? Везде пишут (в вики рус/англ) в частности + другие источники смотрел, что первый сектор расширенн...
Eugene Krasnikov (ᴊɪɴ x)
1
Вопрос я правильно понимаю что в коде newtype ArrowMap k v = ArrowMap { getArrowMap :: k -> Maybe v } getArrowMap есть функция типа k -> Maybe v, если да, то не понимаю задач...
Fedor
64
Ребят, что лучше для реверса: гидра или ида?
En Vind Av Sorg
26
Делаю велосипед логгер. К сообщению хочу прикрутить некоторую информацию, типа, кем отправлено, какой уровень, и всякое такое. И тут подумалось мне, почему бы не хранить весь...
Serjone
24
Как Вы считаете нормально ли в двадцатых годах 21 века в ВУЗах Российской Федерации обучать студентов работе с TASM? Не слишком ли это "архаично"? (Если оффтоп или флейм для э...
Spiker01
52
Всем привет! Использую gitlab-ci. Настроил gitlab-agent для деплоя в куб. При деплое проекта в логах такая ошибка: Executing deploy plan failed to watch "ns:my-project/Ingress...
Konstantin Moiseev
4
Комрады, хотел уточнить. Проперть в OnDestroy юнита-хозяина по-прежнему доступна? И еще уточнение: finalization юнита наступает раньше или позже OnDestroy?
Ed Doc
48
Где-то есть статьи, как писать на OCaml после Kotlin (ну или похожей направленности)? Я привык к интерфейсам и наследованию классов, а здесь это выглядит совершенно не так.
Раскопки Майтрейи Коц
6
Карта сайта