ClickHouse: очень быстро и очень удобно

[begemot_sun]

Всё круто. Но не увидел ограничений. А они есть. Где про них прочитать?

[wildraid]

В документации ClickHouse честно о них пишут. Навскидку:
1) Неэффективные большие JOIN'ы. Ограничения на sub-select'ы. Совсем произвольный отчёт из ста больше таблиц не так просто построить.
2) Свой SQL. Нужно вручную различать и понимать разницу между LOCAL \ GLOBAL JOIN, ANY \ ALL, WHERE \ PREWHERE. Непросто будет мигрировать на другой SQL-совместимый софт.
3) Нет транзакций, нет апдейтов в простой форме.

Но, если систему изначально строить с учётом этих особенностей, то всё решаемо.

[robert_ayrapetyan]

>>В ClickHouse нельзя модифицировать данные. Это для многих может быть сюрпризом, но на самом деле вам не нужно модифицировать данные — это иллюзия.

Ой ли. Это только для компаний верхнего эшелона, которых можно пересчитать по пальцам.

Для простых смертных иллюзия это как раз наоборот то, что нужно хранить сырые события, на случай «а вдруг завтра понадобится построить новый ЛЮБОЙ репорт по событиям».

Ну вот реальная ситуация: у нас за день собирается с десяток лярдов событий (каждую минуту поступают пачками пре-аггрегированные данные), и сохраняются в таблице для дальнейшей аналитики (аггрегируются уже по часам\суткам). Все это происходит на одном простеньком PostgreSQL сервере и использует какие-то жалкие десятки гиг хранилища.

При этом если использовать ClickHouse описанным вами способом и хранить «сырые события», то конечно понадобится 400 серверов и 3Петабайта под хранилища…

[robert_ayrapetyan]

Хм, интересно, спасибо. Искал где-то год назад — не нашел, причем запомнилось что «В ClickHouse нельзя модифицировать данные».

[cebka]

Я был также впечатлен удобством и скоростью работы ClickHouse и написал плагин для хранения аналитики по фильтрации спама для своего Rspamd: https://www.rspamd.com/doc/modules/clickhouse.html Получилось крайне удобно, так как можно получать данные в реальном времени — до 10 секунд примерно. Единственная проблема, на которую я наткнулся, — это необходимость помещать промежуточные результаты джоинов в память, которая от такой грубости имеет свойство быстро кончаться. Впрочем, допускаю, что это я ненастоящий сварщик в данном случае.

[voe]

получается можно данных решением заменить ELK?

[caban]

Logstash. Вопрос визуализации и сборки данных.

[xonix]

А можете, если возможно, сказать пару слов о том, как соотносятся ClickHouse и Amazon Redshift? На работе есть юзкейс под который как будто идеально ложится ClickHouse, но босс хочет Redshift. По позиционированию смотрятся близкими продуктами, так ли это?

[Ivan22]

ну редшифт это MPP субд в облаке, более классическая. Сравнивать долго можно, но по моему имху главное тут другое:
Я бы на месте босса сказал — «ок, найдешь опытного админа под этот кликхаус — берем».

[qdreadknight]

Я правильно понял, что ClickHouse можно использовать свободно в любых коммерческих продуктах?
Сделайте Метрику человеческой. http://www.liveinternet.ru/stat/bizmania.ru/visitors.html — показывает информацию по аудитории. Где найти аналогичный вариант у вас — за долгие годы я так и не нашел ответ.

[potop]

Стандартные отчёты -> Посетители -> Лояльность
не подходят отчёты, которые там есть?

[qdreadknight]

У меня отчета по лояльности нет. Может быть он экспериментальный?

[qdreadknight]

Отчет нашел, немного не так. Но он вообще не об этом. Мне не визиты нужны, а посетители.

[Sufir]

А как у ClickHouse с offset() и count()? Обычно это тяжелые операции для больших объемов, при этом весьма востребованные для просмотра статистических данных.

[Ivan22]

В теории оффсет (или любая оконная функция) зависит от того пресортированные ли у нас данные по этому полю — если да — быстро, если нет медленно. Судя по описанию данные лежат уже сортированные по выбранному полю — .т.к. что если оффсет по нему — будет быстро, если нет — медленно.
Каунт вообще одиночный мало полезен — юзайте таблицы статистики, а чаще используется с группировкой — и там опять же зависит от того группирует по полю распределения по кластеру — быстро, нет — медленно

[rrromka]

Не All up, а OLAP.

[Begetan]

Очень водушевляющая статья. Была ли мысль написать модуль сразу в nginx для логов? Как я понял это один из базовых кейсов.

И еще вопрос. Есть, к примеру, логи netflow. Там фигурирует src ip, dst ip, src port, dst port, bytes, packets и все в таком духе.

Типичный паттерн когда клиент с одного и того же IP адреса устанавливает кучу соединений к другим адресам, а они ему отвечают (torrent).

Насколько эфективно база CH может сжать вот эти последовательности в логах?

[o6CuFl2Q]

В дополнение к докладу, можно посмотреть видеозапись встречи в Санкт-Петербурге, которую мы провели пару дней назад: http://bit.ly/ClickHouseMeetup