данные вида (date_time, uid_from UInt32, uid_to UInt32 и еще 10 колонок - все целочисленные). Они попадают , как в MergeTree , так и AggregatingMergeTree. Запросы вида prewhere date_time between x and y where uid_from = или uid_to=. С аггрегацией проблем нет - время отклика удовлетворяет. Все хуже, когда человек хочет получить сырые данные из MergeTree. При таком запросе восникает iowait (смотрел в glances), полная утилизация диска. Храним 2 таблицы MT - одна order by (uid_from , toStartOfHour(date_time)) и (uid_to , toStartOfHour(date_time)). Сознательно уменьшали index_granularity с дефолтного значения до 256, надеясь, что это как-то должно разгрузить диски. Строк ~30-40kk в день. Менять диски, и вообще оборудование - нельзя 😊. уходить от кх куда-то в более подходящее для такого (кассандра и т.д) тоже не вариант, в силу инертности персонала. Есть идея (навеяно https://www.percona.com/sites/default/files/ple19-slides/day1-pm/clickhouse-for-timeseries.pdf) загружать все в одну таблицу - где сортировка будет (uid, direction, date_time), а остальное запихнуть, например в массив. Подскажите, правильное ли направление мыслей, или же исходная схема имеет место быть, и но проблемы не из-за архитектурного решения, а из-за железа?
>prewhere date_time between x and y where uid_from = или uid_to= и сколько таких запросов одновременно? Сколько строк они возвращают? Partition by что? сколько партиций сканирует запрос? Order by у select-а есть?
Запросов одновременно ~10-15. Строк возвращают по разному - начиная от десятков строк, заканчивая миллионом ( файлы порой несколько Гб). Партиции недельные - диапазон дат тоже разнится , чаще всего 2-3 месяца, нужна полная статистика , например , начиная с начала года. Сортировка order by toStartOfHour одновремя была, сейчас вообще отключили .
т.е. КХ выступает в роли block storage ? Я сомневаюсь что тут поможет что-то типа кассандры. По описанию вам просто надо читать очень много, и диски физически не могут выдать больше. Я бы начал с оптимизации диска на уровне железа и линукса, типа используется железный раид, убрать ...
Не совсем понимаю данный термин, но чтение действительно преобладает. Raid10 , везде. Железный. По поводу оптимизации линукса - смотрел в документации кх, выставлял параметры , которые в ней указаны. Хоть, хоть как-то сделать чуть лучше, хотим с lz4 на zstd перепрыгнуть, но по ощущениям , большого выигрыша ждать не стоит.
железные рейды зачастую узкое место, у них очень слабые cpu , он не могут процессить с такой скоростью как современные HDD отдают. Я как-то раз переключил lsi-что-то там в режим hba, сделал из тех же самых 12 HDD софт-раид и получил перфоманс *2 в КХ на запросах которым надо много читать
Обсуждают сегодня