Habr_Studio Feb 27 2017 at 20:01

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

21 min

251K

High performance*System Analysis and Design*SQL*

+41

Comments 19

begemot_sun Feb 27 2017 at 22:38

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

wildraid Feb 28 2017 at 06:09

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

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

robert_ayrapetyan Feb 27 2017 at 22:43

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

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

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

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

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

UFO just landed and posted this here

robert_ayrapetyan Feb 28 2017 at 01:26

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

cebka Feb 27 2017 at 23:59

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

voe Feb 28 2017 at 00:49

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

caban Mar 1 2017 at 03:03

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

xonix Feb 28 2017 at 05:38

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

Ivan22 Feb 28 2017 at 10:44

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

qdreadknight Feb 28 2017 at 12:22

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

potop Mar 2 2017 at 17:51

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

qdreadknight Mar 3 2017 at 16:09

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

qdreadknight Mar 3 2017 at 19:10

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

Sufir Feb 28 2017 at 16:10

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

Ivan22 Mar 1 2017 at 10:08

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

rrromka Feb 28 2017 at 21:45

Не All up, а OLAP.

Begetan Mar 1 2017 at 03:44

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

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

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

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

o6CuFl2Q Mar 2 2017 at 01:03

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

Show the best of all time