В программе пара докладов и неограниченное время для ответов на вопросы.
Если вы в Новосибирске — приходите на встречу, и мы расскажем вам про ClickHouse всё, что вы захотите узнать.
В программе рассказ про последние разработки в ClickHouse, про использование ClickHouse в аналитике Яндекса и, конечно, будет выделено почти неограниченное время для ответов на вопросы.
На следующей неделе у нас состоится митап для контрибьюторов ClickHouse. Встреча состоится в Москве. Будем обсуждать, как и куда развивать ClickHouse, какие есть перспективы.
Встреча пройдёт в Москве. Участие бесплатное.
В рамках встречи будет, в том числе, небольшой доклад про ClickHouse, а также неограниченное время для вопросов и ответов.
Но я бы не ожидал высоких результатов Cassandra (и ScyllaDB) на тех же запросах по следующим причинам:
(сразу скажу, что у меня нет глубоких представлений о том, как работает Cassandra, я исхожу из поверхностных сведений)
1. В Cassandra больше упор на полуструктурированные данные, по аналогии с BigTable. Можно иметь совершенно разный набор столбцов для разных ключей; количество столбцов может быть неограниченным. Но такой способ хранения данных менее оптимальный для их сканирования. Грубо говоря, на каждый ключ, во время чтения, приходится разбираться с тем, какие столбцы для него есть. Для сравнения, в ClickHouse структура таблицы жёсткая, хотя столбцов может быть достаточно много, и значения в них могут быть сильно разреженными.
2. Cassandra больше ориентирована на key-value сценарий работы: чтение и обновление данных по ключу.
Но в аналитических базах данных, чтение по ключу с низкой latency не требуется, и за счёт этого становятся допустимы такие оптимизации, как блочное сжатие данных более крупными блоками и разреженный индекс. В аналитических базах данных, одной строчке уделяется мало внимания, вся обработка данных рассчитана на обработку целыми пачками.
Чтобы уметь обновлять данные по ключу, требуется на каждую строчку иметь некоторые дополнительные данные — например, номер версии и timestamp. В Cassandra используется LSM-Tree, значит при обновлении, в базу пишутся записи вида «что и как обновить». Эти записи надо мерджить при чтении и это довольно дорого, если требуется выполнять не точечные чтения, а обработку пачек данных. В аналитических базах данных, для эффективного обновления данных, требуются сложные оптимизации.
Теперь рассмотрим, что такое «1MM transactions/sec per server». (1MM в переводе на русский — это один миллион.)
В контексте сравнения с аналитической СУБД это говорит только о том, что ScyllaDB — не аналитическая СУБД.
Для аналитических СУБД производительность измеряется в других величинах: пропускная способность при обработке одного или небольшого количества одновременных сложных запросов.
Не стоит думать, что я принижаю ScyllaDB. Давно хотел изучить для применения как key-value базу.
В этом смысле 1 млн. операций в секунду — очень хороший результат.
(Но стоит иметь ввиду, что, исходя из возможностей железа, специализированное решение могло бы работать намного быстрее.)
Для больших строк имеет смысл сделать следующее:
— при создании таблицы, указать index_granularity (то, что идёт последним параметром) слегка меньше: например, не 8192, а 1024;
— уменьшить значение настройки max_block_size, например, до 8192 (по-умолчанию, 65 536); прописать можно в users.xml для профиля default.
Спасибо, очень интересно!
Не могу сказать, что ClickHouse предназначен для полнотекстового поиска.
Но я рад, что всё работает и даже работает нормально.
Если рассматривать сценарий обработки большого количества «точечных» запросов, где не нужно считывать и пересекать большое количество записей, а нужно выполнять большое количество мелких запросов, то всё будет хуже, например, из-за особенностей организации индекса.
Для хранения логов программ в ClickHouse ещё часто используется brute-force решение.
Суть его в том, что в таблицу просто сохраняются тексты сообщений (а также всевозможные их свойства — имя хоста, номер потока, уровень логгирования, время обработки запроса и т. п.). В качестве первичного ключа используется время события.
Для поиска сообщений используется ограничение на диапазон дат и времени и оператор LIKE (или функция position) для поиска по тексту.
Также существуют функции positionCaseInsensitive, positionCaseInsensitiveUTF8 (их ещё нет в документации).
Получается, что осуществляется full scan в диапазоне по времени. Это не лучше. Главное в этом подходе — максимальная простота.
В частности, ClickHouse может сам так хранить свои логи запросов. Это можно включить настройкой log_queries = 1.
Сделал, чтобы было более удобное сообщение об ошибке:
Cannot resolve listen_host (::), error: Address family for hostname not supported: -9. If it is an IPv6 address and your host has disabled IPv6, then consider to specify IPv4 address to listen in <listen_host> element of configuration file. Example: <listen_host>0.0.0.0</listen_host>
ClickHouse может быть использован в том числе, для вставки данных напрямую из того места, которое эти данные генерирует.
Источник должен самостоятельно собирать данные в некоторые не слишком частые batch-и (раз в секунду — нормально) и отправлять их INSERT-ом по HTTP.
ClickHouse позволяет вставлять данные сравнительно эффективно.
О 10 000 строк в секунду (как вы написали) можно вообще не беспокоиться.
Реальные величины — это, например, 100 000 строк в секунду, в рассчёте на один сервер, на один поток; каждая строка имеет размер ~ 1 КБ (если передавать в несжатом виде по сети, то это съест 1 Gbit), или, например, 500 000 строк в секунду, если строчки поменьше.
Вы можете предположить, что INSERT работает неэффективно из-за использования HTTP и из-за передачи данных в текстовом формате. Рассмотрим масштаб проблемы.
HTTP chunked transfer encoding, это, по сути, один лишний memcpy. Допустим, 5 GB/sec на одно ядро. То есть, не тот масштаб, о котором имеет смысл беспокоиться при INSERT.
Передача данных в текстовом виде, это от 100 до 1000 MB/sec., в зависимости от того, насколько хорошо ваше приложение может записывать числа в текстовом виде и эскейпить строки. Видно, что масштаб соответствующий, и это может съесть до половины времени вашего приложения, если сериализация в текстовом виде реализована неэффективно. В этом случае, существует возможность использовать бинарный формат RowBinary. См. здесь.
Не получается, если запрос потоковый (начинает отдавать данные до окончания выполнения).
Так мы даже не можем поменять код ответа с 200 на 500, если после начала отдачи части данных произошёл эксепшен.
Разве что использовать HTTP Trailers, которые почти никто не поддерживает.
Время выполнения запроса пишется, например, при использовании форматов JSON, JSONCompact — внутри JSON-а.
Публичного roadmap-а нет.
Основным «драйвером» развития проекта являются потребности Яндекс.Метрики, ещё часть — остальных сервисов внутри Яндекса.
Не стоит недооценивать эти потребности :)
Про амбиции ничего сказать не могу.
Еще интересно прочитать, как Танки работают с ClickHouse. Чем пушат, чем читают.
ClickHouse подходит для хранения временных рядов.
Но нужно учесть несколько деталей.
ClickHouse не является готовой системой для работы с временными рядами и не является готовой системой мониторинга. ClickHouse — это СУБД. Вы можете хранить временные ряды в ней, но всю остальную обвязку, которая вам понадобится, придётся сделать самому или где-то взять.
Возможно, нам удастся через некоторое время открыть код интеграции ClickHouse и Graphite. Grafana с ним тоже работает.
В программе пара докладов и неограниченное время для ответов на вопросы.
Если вы в Новосибирске — приходите на встречу, и мы расскажем вам про ClickHouse всё, что вы захотите узнать.
Замечу, что сейчас TokuDB уже доступна бесплатно и в open-source.
http://bit.ly/ClickHouseMeetup
В программе рассказ про последние разработки в ClickHouse, про использование ClickHouse в аналитике Яндекса и, конечно, будет выделено почти неограниченное время для ответов на вопросы.
Разница в скорости выполнения объясняется количеством ядер.
Мы выполняли запросы на сервере с 16x2 ядер. Если точнее, на таком.
У вас 4x2 ядер. Как раз разница в 4 раза.
Это показывает, что выполнение запросов масштабируется по ядрам CPU.
Яндекс изнутри: инфраструктура хранения и обработки данных.
Встреча пройдёт в Москве. Участие бесплатное.
В рамках встречи будет, в том числе, небольшой доклад про ClickHouse, а также неограниченное время для вопросов и ответов.
Но я бы не ожидал высоких результатов Cassandra (и ScyllaDB) на тех же запросах по следующим причинам:
(сразу скажу, что у меня нет глубоких представлений о том, как работает Cassandra, я исхожу из поверхностных сведений)
1. В Cassandra больше упор на полуструктурированные данные, по аналогии с BigTable. Можно иметь совершенно разный набор столбцов для разных ключей; количество столбцов может быть неограниченным. Но такой способ хранения данных менее оптимальный для их сканирования. Грубо говоря, на каждый ключ, во время чтения, приходится разбираться с тем, какие столбцы для него есть. Для сравнения, в ClickHouse структура таблицы жёсткая, хотя столбцов может быть достаточно много, и значения в них могут быть сильно разреженными.
2. Cassandra больше ориентирована на key-value сценарий работы: чтение и обновление данных по ключу.
Но в аналитических базах данных, чтение по ключу с низкой latency не требуется, и за счёт этого становятся допустимы такие оптимизации, как блочное сжатие данных более крупными блоками и разреженный индекс. В аналитических базах данных, одной строчке уделяется мало внимания, вся обработка данных рассчитана на обработку целыми пачками.
Чтобы уметь обновлять данные по ключу, требуется на каждую строчку иметь некоторые дополнительные данные — например, номер версии и timestamp. В Cassandra используется LSM-Tree, значит при обновлении, в базу пишутся записи вида «что и как обновить». Эти записи надо мерджить при чтении и это довольно дорого, если требуется выполнять не точечные чтения, а обработку пачек данных. В аналитических базах данных, для эффективного обновления данных, требуются сложные оптимизации.
Теперь рассмотрим, что такое «1MM transactions/sec per server». (1MM в переводе на русский — это один миллион.)
В контексте сравнения с аналитической СУБД это говорит только о том, что ScyllaDB — не аналитическая СУБД.
Для аналитических СУБД производительность измеряется в других величинах: пропускная способность при обработке одного или небольшого количества одновременных сложных запросов.
Не стоит думать, что я принижаю ScyllaDB. Давно хотел изучить для применения как key-value базу.
В этом смысле 1 млн. операций в секунду — очень хороший результат.
(Но стоит иметь ввиду, что, исходя из возможностей железа, специализированное решение могло бы работать намного быстрее.)
Ещё хорошо бы написать сюда.
Для больших строк имеет смысл сделать следующее:
— при создании таблицы, указать index_granularity (то, что идёт последним параметром) слегка меньше: например, не 8192, а 1024;
— уменьшить значение настройки max_block_size, например, до 8192 (по-умолчанию, 65 536); прописать можно в users.xml для профиля default.
Не могу сказать, что ClickHouse предназначен для полнотекстового поиска.
Но я рад, что всё работает и даже работает нормально.
Если рассматривать сценарий обработки большого количества «точечных» запросов, где не нужно считывать и пересекать большое количество записей, а нужно выполнять большое количество мелких запросов, то всё будет хуже, например, из-за особенностей организации индекса.
Для хранения логов программ в ClickHouse ещё часто используется brute-force решение.
Суть его в том, что в таблицу просто сохраняются тексты сообщений (а также всевозможные их свойства — имя хоста, номер потока, уровень логгирования, время обработки запроса и т. п.). В качестве первичного ключа используется время события.
Для поиска сообщений используется ограничение на диапазон дат и времени и оператор
LIKE(или функцияposition) для поиска по тексту.Также существуют функции
positionCaseInsensitive,positionCaseInsensitiveUTF8(их ещё нет в документации).Получается, что осуществляется full scan в диапазоне по времени. Это не лучше. Главное в этом подходе — максимальная простота.
В частности, ClickHouse может сам так хранить свои логи запросов. Это можно включить настройкой
log_queries = 1.Cannot resolve listen_host (::), error: Address family for hostname not supported: -9. If it is an IPv6 address and your host has disabled IPv6, then consider to specify IPv4 address to listen in <listen_host> element of configuration file. Example: <listen_host>0.0.0.0</listen_host>
Источник должен самостоятельно собирать данные в некоторые не слишком частые batch-и (раз в секунду — нормально) и отправлять их INSERT-ом по HTTP.
ClickHouse позволяет вставлять данные сравнительно эффективно.
О 10 000 строк в секунду (как вы написали) можно вообще не беспокоиться.
Реальные величины — это, например, 100 000 строк в секунду, в рассчёте на один сервер, на один поток; каждая строка имеет размер ~ 1 КБ (если передавать в несжатом виде по сети, то это съест 1 Gbit), или, например, 500 000 строк в секунду, если строчки поменьше.
Подробнее.
Вы можете предположить, что INSERT работает неэффективно из-за использования HTTP и из-за передачи данных в текстовом формате. Рассмотрим масштаб проблемы.
HTTP chunked transfer encoding, это, по сути, один лишний memcpy. Допустим, 5 GB/sec на одно ядро. То есть, не тот масштаб, о котором имеет смысл беспокоиться при INSERT.
Передача данных в текстовом виде, это от 100 до 1000 MB/sec., в зависимости от того, насколько хорошо ваше приложение может записывать числа в текстовом виде и эскейпить строки. Видно, что масштаб соответствующий, и это может съесть до половины времени вашего приложения, если сериализация в текстовом виде реализована неэффективно. В этом случае, существует возможность использовать бинарный формат RowBinary. См. здесь.
Так мы даже не можем поменять код ответа с 200 на 500, если после начала отдачи части данных произошёл эксепшен.
Разве что использовать HTTP Trailers, которые почти никто не поддерживает.
Время выполнения запроса пишется, например, при использовании форматов JSON, JSONCompact — внутри JSON-а.
Основным «драйвером» развития проекта являются потребности Яндекс.Метрики, ещё часть — остальных сервисов внутри Яндекса.
Не стоит недооценивать эти потребности :)
Про амбиции ничего сказать не могу.
Это может рассказать doctornkz.
ClickHouse подходит для хранения временных рядов.
Но нужно учесть несколько деталей.
ClickHouse не является готовой системой для работы с временными рядами и не является готовой системой мониторинга. ClickHouse — это СУБД. Вы можете хранить временные ряды в ней, но всю остальную обвязку, которая вам понадобится, придётся сделать самому или где-то взять.
Возможно, нам удастся через некоторое время открыть код интеграции ClickHouse и Graphite. Grafana с ним тоже работает.