Основа для скорости — это хранение данных по столбцам и векторный движок. По этим признакам, система не отличается, например, от Actian Vector (бывшая Vectorwise), которая может похвастаться сравнимой скоростью обработки запросов.
Дополнительные преимущества в производительности достигаются за счёт:
— алгоритмической оптимизации;
— низкоуровневой оптимизации;
— специализации и проработки частных случаев.
Это продукты немного другого профиля.
Насколько я понимаю, основная задача Solr/ElasticSearch — работа с полнотекстовым индексом.
В ClickHouse нет полнотекстового индекса.
Основной характер нагрузки состоит в том, чтобы достать по диапазону первичного ключа какое-то, возможно весьма большое множество строк, и как можно быстрее выполнить над ним нужные операции: отфильтровать, агрегировать и т. п. При этом, сам индекс — первичный ключ, устроен достаточно примитивно, зато всегда требует немного оперативки (даже при наличии триллионов строк в таблице на одном сервере) и поддерживает локальность расположения данных на диске — для того, чтобы читать искомое множество данных с минимальным количеством seek-ов.
Короче говоря, в одних задачах важнее по-умному достать из базы небольшое количество данных, а в других — как можно эффективнее прочитать и обработать достаточно большое подмножество данных.
Да, совершенно верно. Изначально у нас не было цели разработать open-source СУБД.
Я понимаю, что использование русского языка для комментариев — это минус для open-source продукта.
При этом к самому факту наличия подробных комментариев на русском языке следует отнестись позитивно: это лучше, чем если бы комментариев не было или если бы они были бы менее понятными для основных разработчиков.
1) Планируется ли эти модули отдать в open source так же как и сам ClickHouse?
Не уверен. Например, для Python есть несколько разных модулей в виде простых обёрток над HTTP интерфейсом. Может быть, какой-то из них автор захочет выложить, пусть даже просто ради примера. Но они все не представляют большой ценности.
2) Планируется ли документировать TCP интерфейс, а то сейчас мы видим
Пока нет — TCP интерфейс и внутрений C++ интерфейс специально не документирован для того, чтобы не бояться ломать совместимость протокола и ABI. Поэтому, для внешних программ только HTTP интерфейс.
Спасибо! Стыдно сказать, я видел новость про open-source Greenplum и хотел изучить его подробнее, но потом забыл про это.
Надо будет уделить этому больше внимания. Возможно, утверждение «до сих пор не существовало» придётся пересмотреть.
Только эти интерфейсы документированы и ими можно пользоваться.
Есть также ODBC и JDBC драйверы.
ODBC драйвер находится в разработке. Он работает во многих случаях, но сейчас лучше им не пользоваться, если только вы не собираетесь самостоятельно его дорабатывать. Если очень надо, то можете найти его в исходниках.
JDBC драйвер находится в отдельном репозитории и на данный момент не выложен (это будем решать).
Нет, не пробовали. В качестве тестовых данных мы используем такие данные, которые нельзя загрузить в чужое облако.
Если сделаем подходящий набор тестовых данных, то надо будет попробовать. Ещё хотелось бы сравнить с Amazon Redshift.
Сообщения, как правило, разбиваются на много столбцов. Но не всегда — иногда пользователям лениво делать это достаточно детально. Большой стобец типа message обычно остаётся, и становится важно делать brute-force поиск подстроки в строке или регексп.
Оба этих случая достаточно хорошо оптимизированы. Например, поиск подстроки в строке, при условии, что сжатые данные помещаются в page cache, на одном сервере осуществляется со скоростью более 10 GB/sec.
К сожалению, время разработки больше двух лет (хотя с 2012 оно совмещено с использованием в продакшене на части задач).
Какое-то количество интересных решений имеется. Да, надо будет написать.
Он не делает full text search лучше, так как в нём нет соответствующих структур.
Да, удобнее записывать приличный объём логов для последующего анализа. Логи перед записью структурируются скриптом.
Анализ следующий (примеры):
— топ IP-адресов, с которых прилетают 503 за последние 1000 сек;
— показать урлы без параметров для заданного хоста с кодом товета 503 за последние 600 секунд, сортированные по повторяемости;
— считать по логам квантили и писать их в Графит (который тоже на ClickHouse);
— найти конкретные медленные запросы и посмотреть на них;
Возможно, тут имеется ввиду несколько другая ниша.
Хорошо. Но стоит иметь ввиду проблему — при таком подходе, программа может думать, что на той стороне настоящий MySQL или Postgres и задавать соответствующие запросы (например, select @@version_comment limit 1). А полную совместимость всё-таки сложно сделать.
Если смотреть сверху и без рассмотрения деталей, то архитектура ClickHouse не сильно отличается от архитектуры других MPP column-oriented СУБД. Например, можно прочитать про архитектуру Vertica здесь: vldb.org/pvldb/vol5/p1790_andrewlamb_vldb2012
.pdf
Если рассматривать детали, то это долго.
На всякий случай расскажу, какие имеются ввиду бенчмарки, и что значит, что ClickHouse в 2,8-3,4 раза быстрее.
В качестве тестовых данных, выбрали 1 млрд. строк — хитов из Метрики. Также есть урезанные dataset-ы на 100 млн. и 10 млн.
Объём данных ограничен необходимостью уменьшить время запуска тестов.
Составлено 43 SELECT запроса. Каждый запрос выполняется по отдельности, одновременная работа многих запросов не тестируется.
Из них 7 запросов используют первичный ключ, а остальные — full scan.
Запросы подобраны с учётом наших задач. Максимальное внимание уделено скорости фильтрации и агрегации.
Много запросов проверяют всевозможные сочетания типов столбцов при GROUP BY, разные кардинальности множества после GROUP BY, разную селективность условий в WHERE и т. п.
JOIN-ам, напротив, не уделено внимания — в тестах их нет вообще. В этом смысле, эти бенчмарки отличаются от бенчмарков TPC, где важным является выбранный порядок выполнения JOIN-ов. Конечно, ClickHouse поддерживает JOIN и делает это неплохо.
Запросы были составлены заранее, без предпочтения какой-либо системы и набор запросов не менялся. В том числе, присутствовали запросы, на которых ClickHouse показывал заведомо плохой результат, а также несколько запросов, которые ClickHouse не мог выполнить раньше.
Мы составили этот бенчмарк осенью 2013 года. Затем несколько раз обновляли результаты, последний раз в 2015.
Изначально в бенчмарк входили ClickHouse, Vertica, InfiniDB, MonetDB, Infobright, и ради прикола, MySQL и Hive.
Коротко, результаты в 2013 были такие: ClickHouse и Vertica примерно равны, InfiniDB в ~7 раз хуже и работает только после дополнительной настройки, MonetDB некоторые запросы выполняет прилично, а на некоторых почему-то хуже в сотни раз, Infobright рассматривать не имеет смысла, так как для бенчмарков использовалась community версия с ограничением в один поток на запрос.
В 2015 году результаты обновили, но только для ClickHouse и Verica (7.1.1). Это связано с тем, что проведение бенчмарков довольно трудоёмкое. Требуется где-то от половины недели до одной недели на каждую систему, и было бы странно тратить на это месяцы рабочего времени. Впрочем, половина систем из 2013 года уже выпадает из рассмотрения (InfiniDB разорились, а MonetDB слишком отстаёт от Actian Vector).
Для настройки Vertica мы привлекли одного специалиста, который имел с ней дело. На результаты это повлияло не сильно, так как Vertica хорошо работает по-умолчанию. Проекции в Vertica не использовались, так как важно избежать дублирования данных. Отдельные алгоритмы сжатия для каждого столбца подбирались, но не сильно повлияли на результаты.
Основные бенчмарки проводились в односерверной конфигурации — для простоты. Впрочем, для отдельных систем есть запуски на маленьком кластере из трёх серверов.
Каждый запрос запускался как «на холодную» (со сброшенным page cache), так и с данными в кэше.
Для запросов, использующих первичный ключ (читающих дипазон данных), Vertica существенно медленнее — где-то в 8 раз, как при работе с холоными данными, так и тогда, когда диск не используется. Я не могу точно сказать, с чем это связано. Может быть, на это влияют настройки, до которых мы не дошли. Если исключить эти запросы из рассмотрения, то Vertica всё равно существенно медленнее.
Для запросов, использующих full scan, важна скорость чтения данных (алгоритм сжатия, реализация чтения — насколько сложно десериализовать данные, нет ли лишних копирований; какие столбцы читаются в первую очередь, есть ли «неявные» индексные структуры для data skipping; локальность данных одного столбца), скорость выполнения выражений и фильтрации (как диспетчеризуются операции, есть ли векторный движок, есть ли кодогенерация), а также, для большинства запросов, скорость выполнения GROUP BY (какая структура данных используется, насколько хорошо она написана, насколько детально рассматриваются различные случаи, как распараллеливается агрегация, как передаются данные по сети при распределённой агрегации, как написан внутренний цикл, как вызываются операции с агрегатными функциями и т. п.)
PS. Так как производительность является многогранной величиной, почти всегда можно подобрать запросы, на которых одна система даёт результат лучше другой, и во столько раз, во сколько нужно. Мы постарались этого не делать. Хотя наши тесты нельзя назвать 100% объективными, я могу надеяться, что они по крайней мере, не являются мусором.
Hadoop гораздо лучше подходит для offline-вычислений, когда нужно много ворочать данными. В Hadoop больше инструментов для всесторонней обработки данных. А ClickHouse лучше подходит для онлайн запросов — по хорошо структурированным данным, достаточно быстрых и более-менее простых. При этом, ниша ClickHouse со временем сокращается, так как для Hadoop тоже есть и появляются новые средства, подходящие для онлайн запросов (при некоторых условиях).
Но для задачи — сделать аналитический инструмент для массовой аудитории, а не для внутренних пользователей, Hadoop использовать сложнее. Ведь придётся решить несколько побочных задач:
— как реплицировать данные между ДЦ;
— как обеспечить скорость выборки данных по первичному ключу при условии постоянного обновления данных.
Если не нужен массовый сервис, то надо пробовать PrestoDB, Drill и другие. Я сам хочу уделить этому больше внимания.
Opensource сейчас рассматривается как одно из направлений развития. Но я не могу давать лишние надежды — может быть, ничего не будет.
На самом деле, у нас есть серьёзные аргументы в пользу выпуска в opensource, которые пока не удалось ничем перекрыть.
Для общения с базой есть простой HTTP интерфейс. Есть родной протокол для межсерверного взаимодействия, который также используется в клиенте командной строки — он даёт чуть больше, например, показывает прогресс выполнения запроса. Этот протокол ни с чем не совместим.
Также имеется proof-of-concept ODBC драйвер, который находится в процессе разработки.
Основа для скорости — это хранение данных по столбцам и векторный движок. По этим признакам, система не отличается, например, от Actian Vector (бывшая Vectorwise), которая может похвастаться сравнимой скоростью обработки запросов.
Дополнительные преимущества в производительности достигаются за счёт:
— алгоритмической оптимизации;
— низкоуровневой оптимизации;
— специализации и проработки частных случаев.
Насколько я понимаю, основная задача Solr/ElasticSearch — работа с полнотекстовым индексом.
В ClickHouse нет полнотекстового индекса.
Основной характер нагрузки состоит в том, чтобы достать по диапазону первичного ключа какое-то, возможно весьма большое множество строк, и как можно быстрее выполнить над ним нужные операции: отфильтровать, агрегировать и т. п. При этом, сам индекс — первичный ключ, устроен достаточно примитивно, зато всегда требует немного оперативки (даже при наличии триллионов строк в таблице на одном сервере) и поддерживает локальность расположения данных на диске — для того, чтобы читать искомое множество данных с минимальным количеством seek-ов.
Короче говоря, в одних задачах важнее по-умному достать из базы небольшое количество данных, а в других — как можно эффективнее прочитать и обработать достаточно большое подмножество данных.
Я понимаю, что использование русского языка для комментариев — это минус для open-source продукта.
При этом к самому факту наличия подробных комментариев на русском языке следует отнестись позитивно: это лучше, чем если бы комментариев не было или если бы они были бы менее понятными для основных разработчиков.
Не уверен. Например, для Python есть несколько разных модулей в виде простых обёрток над HTTP интерфейсом. Может быть, какой-то из них автор захочет выложить, пусть даже просто ради примера. Но они все не представляют большой ценности.
Пока нет — TCP интерфейс и внутрений C++ интерфейс специально не документирован для того, чтобы не бояться ломать совместимость протокола и ABI. Поэтому, для внешних программ только HTTP интерфейс.
Надо будет уделить этому больше внимания. Возможно, утверждение «до сих пор не существовало» придётся пересмотреть.
Есть также ODBC и JDBC драйверы.
ODBC драйвер находится в разработке. Он работает во многих случаях, но сейчас лучше им не пользоваться, если только вы не собираетесь самостоятельно его дорабатывать. Если очень надо, то можете найти его в исходниках.
JDBC драйвер находится в отдельном репозитории и на данный момент не выложен (это будем решать).
Посмотреть авторов коммитов можно так:
git log --format='%aN %aE' | sort | uniq -c | sort -rn
Проблема в том, что Github не связывает твой email с твоим аккаунтом.
Это можно исправить… напишу через пару часов лично.
Если сделаем подходящий набор тестовых данных, то надо будет попробовать. Ещё хотелось бы сравнить с Amazon Redshift.
Оба этих случая достаточно хорошо оптимизированы. Например, поиск подстроки в строке, при условии, что сжатые данные помещаются в page cache, на одном сервере осуществляется со скоростью более 10 GB/sec.
Какое-то количество интересных решений имеется. Да, надо будет написать.
Да, удобнее записывать приличный объём логов для последующего анализа. Логи перед записью структурируются скриптом.
Анализ следующий (примеры):
— топ IP-адресов, с которых прилетают 503 за последние 1000 сек;
— показать урлы без параметров для заданного хоста с кодом товета 503 за последние 600 секунд, сортированные по повторяемости;
— считать по логам квантили и писать их в Графит (который тоже на ClickHouse);
— найти конкретные медленные запросы и посмотреть на них;
Возможно, тут имеется ввиду несколько другая ниша.
select @@version_comment limit 1). А полную совместимость всё-таки сложно сделать..pdf
Если рассматривать детали, то это долго.
На всякий случай расскажу, какие имеются ввиду бенчмарки, и что значит, что ClickHouse в 2,8-3,4 раза быстрее.
В качестве тестовых данных, выбрали 1 млрд. строк — хитов из Метрики. Также есть урезанные dataset-ы на 100 млн. и 10 млн.
Объём данных ограничен необходимостью уменьшить время запуска тестов.
Составлено 43 SELECT запроса. Каждый запрос выполняется по отдельности, одновременная работа многих запросов не тестируется.
Из них 7 запросов используют первичный ключ, а остальные — full scan.
Запросы подобраны с учётом наших задач. Максимальное внимание уделено скорости фильтрации и агрегации.
Много запросов проверяют всевозможные сочетания типов столбцов при GROUP BY, разные кардинальности множества после GROUP BY, разную селективность условий в WHERE и т. п.
JOIN-ам, напротив, не уделено внимания — в тестах их нет вообще. В этом смысле, эти бенчмарки отличаются от бенчмарков TPC, где важным является выбранный порядок выполнения JOIN-ов. Конечно, ClickHouse поддерживает JOIN и делает это неплохо.
Запросы были составлены заранее, без предпочтения какой-либо системы и набор запросов не менялся. В том числе, присутствовали запросы, на которых ClickHouse показывал заведомо плохой результат, а также несколько запросов, которые ClickHouse не мог выполнить раньше.
Мы составили этот бенчмарк осенью 2013 года. Затем несколько раз обновляли результаты, последний раз в 2015.
Изначально в бенчмарк входили ClickHouse, Vertica, InfiniDB, MonetDB, Infobright, и ради прикола, MySQL и Hive.
Коротко, результаты в 2013 были такие: ClickHouse и Vertica примерно равны, InfiniDB в ~7 раз хуже и работает только после дополнительной настройки, MonetDB некоторые запросы выполняет прилично, а на некоторых почему-то хуже в сотни раз, Infobright рассматривать не имеет смысла, так как для бенчмарков использовалась community версия с ограничением в один поток на запрос.
В 2015 году результаты обновили, но только для ClickHouse и Verica (7.1.1). Это связано с тем, что проведение бенчмарков довольно трудоёмкое. Требуется где-то от половины недели до одной недели на каждую систему, и было бы странно тратить на это месяцы рабочего времени. Впрочем, половина систем из 2013 года уже выпадает из рассмотрения (InfiniDB разорились, а MonetDB слишком отстаёт от Actian Vector).
Для настройки Vertica мы привлекли одного специалиста, который имел с ней дело. На результаты это повлияло не сильно, так как Vertica хорошо работает по-умолчанию. Проекции в Vertica не использовались, так как важно избежать дублирования данных. Отдельные алгоритмы сжатия для каждого столбца подбирались, но не сильно повлияли на результаты.
Основные бенчмарки проводились в односерверной конфигурации — для простоты. Впрочем, для отдельных систем есть запуски на маленьком кластере из трёх серверов.
Каждый запрос запускался как «на холодную» (со сброшенным page cache), так и с данными в кэше.
Для запросов, использующих первичный ключ (читающих дипазон данных), Vertica существенно медленнее — где-то в 8 раз, как при работе с холоными данными, так и тогда, когда диск не используется. Я не могу точно сказать, с чем это связано. Может быть, на это влияют настройки, до которых мы не дошли. Если исключить эти запросы из рассмотрения, то Vertica всё равно существенно медленнее.
Для запросов, использующих full scan, важна скорость чтения данных (алгоритм сжатия, реализация чтения — насколько сложно десериализовать данные, нет ли лишних копирований; какие столбцы читаются в первую очередь, есть ли «неявные» индексные структуры для data skipping; локальность данных одного столбца), скорость выполнения выражений и фильтрации (как диспетчеризуются операции, есть ли векторный движок, есть ли кодогенерация), а также, для большинства запросов, скорость выполнения GROUP BY (какая структура данных используется, насколько хорошо она написана, насколько детально рассматриваются различные случаи, как распараллеливается агрегация, как передаются данные по сети при распределённой агрегации, как написан внутренний цикл, как вызываются операции с агрегатными функциями и т. п.)
А вот хорошая ссылка про столбцовые базы данных — там рассматриваются многие детали:
www.cs.yale.edu/homes/dna/talks/Column_Store_Tutorial_VLDB09.pdf
PS. Так как производительность является многогранной величиной, почти всегда можно подобрать запросы, на которых одна система даёт результат лучше другой, и во столько раз, во сколько нужно. Мы постарались этого не делать. Хотя наши тесты нельзя назвать 100% объективными, я могу надеяться, что они по крайней мере, не являются мусором.
Но для задачи — сделать аналитический инструмент для массовой аудитории, а не для внутренних пользователей, Hadoop использовать сложнее. Ведь придётся решить несколько побочных задач:
— как реплицировать данные между ДЦ;
— как обеспечить скорость выборки данных по первичному ключу при условии постоянного обновления данных.
Если не нужен массовый сервис, то надо пробовать PrestoDB, Drill и другие. Я сам хочу уделить этому больше внимания.
На самом деле, у нас есть серьёзные аргументы в пользу выпуска в opensource, которые пока не удалось ничем перекрыть.
Для общения с базой есть простой HTTP интерфейс. Есть родной протокол для межсерверного взаимодействия, который также используется в клиенте командной строки — он даёт чуть больше, например, показывает прогресс выполнения запроса. Этот протокол ни с чем не совместим.
Также имеется proof-of-concept ODBC драйвер, который находится в процессе разработки.