Comments 6
Что за новая мода использовать клик как хранилище логов? Как вы организуете батчевую вставку логов? Скорее всего никак, тогда как вы боретесь с переполнением очереди теневого слияния? Выкручиванием этого параметра в небеса? Кажется что это так себе решение.
Не нужно клик пытаться использовать несвойственным ему образом и проблем не будет.
А чем плохо хранить в CH логи? Если накапливать их в Kafka, то вставлять можно крупными пакетами. А по тем записям, которые ещё в топике можно делать запросы kSQL.
Самое интересное, что мы используем клик для хранения информации о... кликах, показах и так далее. Буквально для чего его и создавали в свое время в Яндексе :)
Хороший ORDER BY обычно включает 3-5 столбцов, расположенных в порядке увеличения кардинальности
Индекс эффективный когда большая кардинальность в начале. Почему у вас наоборот?
Так получилось, что у нас изначально довольно большая широкая таблица, вокруг которой строятся представления. Из-за этого и сами представления страдают гигантизмом. Так и вышло, что рекомендации плюс-минус делать 3-5 столбцов, а для скорости нам нужно использовать больше. Согласен, разумно было про это проговорить в статье.
Статья вроде про CH, а смотрю - написано про мат вью. Создаётся впечатление, что основной инструмент достижения высокой скорости выборки - использование предварительно вычисленных представлений, т.е. считаем, что записей будет меньше, чем чтений и основное время отдаём на пересчет представлений по триггеру. Представления - они же не специфичны для CH. В Oracle такое есть. В чем разница тогда меж толпой мат вью в Oracle и такой же толпой мат вью в CH?
Погружение в ClickHouse: делаем первые и успешные шаги