Comments 22
Было бы интересно прочитать побольше о архитектуре ClickHouse, а также за счет чего и на каких тестах она работает в 2,8-3,4 раза быстрее HP Vertica
Если смотреть сверху и без рассмотрения деталей, то архитектура 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 (какая структура данных используется, насколько хорошо она написана, насколько детально рассматриваются различные случаи, как распараллеливается агрегация, как передаются данные по сети при распределённой агрегации, как написан внутренний цикл, как вызываются операции с агрегатными функциями и т. п.)
А вот хорошая ссылка про столбцовые базы данных — там рассматриваются многие детали:
www.cs.yale.edu/homes/dna/talks/Column_Store_Tutorial_VLDB09.pdf
PS. Так как производительность является многогранной величиной, почти всегда можно подобрать запросы, на которых одна система даёт результат лучше другой, и во столько раз, во сколько нужно. Мы постарались этого не делать. Хотя наши тесты нельзя назвать 100% объективными, я могу надеяться, что они по крайней мере, не являются мусором.
Если рассматривать детали, то это долго.
На всякий случай расскажу, какие имеются ввиду бенчмарки, и что значит, что 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% объективными, я могу надеяться, что они по крайней мере, не являются мусором.
Очень интересно было бы результат бенчмарка для Spark.SQL посмотреть
Спасибо за развернутый ответ.
Я знаком с архитектурами современных MPP решений. Поэтому и интересно узнать вашу архитектуру, т.к. если ваше собственное решение, написанное за 2 года, обгоняет коммерческий продукт c 10-летней историей, спроектированный небезызвестным Стоунбрейкером, у вас однозначно должны быть какие-то ноу-хау в плане компрессии, обработки сжатых данных, индексов/bloom filters и т.д.
Я знаком с архитектурами современных MPP решений. Поэтому и интересно узнать вашу архитектуру, т.к. если ваше собственное решение, написанное за 2 года, обгоняет коммерческий продукт c 10-летней историей, спроектированный небезызвестным Стоунбрейкером, у вас однозначно должны быть какие-то ноу-хау в плане компрессии, обработки сжатых данных, индексов/bloom filters и т.д.
В opensource ждать?
А по какому протоколу идет общение с базой? Сами писали? Или вязли Mysql, Postgres, etc?
А по какому протоколу идет общение с базой? Сами писали? Или вязли Mysql, Postgres, etc?
Opensource сейчас рассматривается как одно из направлений развития. Но я не могу давать лишние надежды — может быть, ничего не будет.
На самом деле, у нас есть серьёзные аргументы в пользу выпуска в opensource, которые пока не удалось ничем перекрыть.
Для общения с базой есть простой HTTP интерфейс. Есть родной протокол для межсерверного взаимодействия, который также используется в клиенте командной строки — он даёт чуть больше, например, показывает прогресс выполнения запроса. Этот протокол ни с чем не совместим.
Также имеется proof-of-concept ODBC драйвер, который находится в процессе разработки.
На самом деле, у нас есть серьёзные аргументы в пользу выпуска в opensource, которые пока не удалось ничем перекрыть.
Для общения с базой есть простой HTTP интерфейс. Есть родной протокол для межсерверного взаимодействия, который также используется в клиенте командной строки — он даёт чуть больше, например, показывает прогресс выполнения запроса. Этот протокол ни с чем не совместим.
Также имеется proof-of-concept ODBC драйвер, который находится в процессе разработки.
Если решитесь выкладывать в opensource, а я очень надеюсь :) Подумайте пожалуйста в сторону использования протокола для драйверов уже готовых MySql (как сделали Memsql) или postgres — это позволит перевести текущие ПО быстрее.
ClickHouse используется для хранения и анализа логов различных сервисов в Яндексе. Типичным решением было бы использовать Logstash и ElasticSearch, но оно не работает на более-менее приличном потоке данных.
Ну про вставку данных могу поверить, а вот в то, что ClickHouse full text search делает лучше уже сомнительно.
Расскажите подробнее.
Он не делает full text search лучше, так как в нём нет соответствующих структур.
Да, удобнее записывать приличный объём логов для последующего анализа. Логи перед записью структурируются скриптом.
Анализ следующий (примеры):
— топ IP-адресов, с которых прилетают 503 за последние 1000 сек;
— показать урлы без параметров для заданного хоста с кодом товета 503 за последние 600 секунд, сортированные по повторяемости;
— считать по логам квантили и писать их в Графит (который тоже на ClickHouse);
— найти конкретные медленные запросы и посмотреть на них;
Возможно, тут имеется ввиду несколько другая ниша.
Да, удобнее записывать приличный объём логов для последующего анализа. Логи перед записью структурируются скриптом.
Анализ следующий (примеры):
— топ IP-адресов, с которых прилетают 503 за последние 1000 сек;
— показать урлы без параметров для заданного хоста с кодом товета 503 за последние 600 секунд, сортированные по повторяемости;
— считать по логам квантили и писать их в Графит (который тоже на ClickHouse);
— найти конкретные медленные запросы и посмотреть на них;
Возможно, тут имеется ввиду несколько другая ниша.
Ваши примеры работают на таблице предположим из двух из трех столбцов: hostid, timestamp, log_message?
Или перед тем как положить в базу сообщение парсится и кладется в базу уже по многим столбцам?
Если первый вариант, то очень даже хорошо.
Или перед тем как положить в базу сообщение парсится и кладется в базу уже по многим столбцам?
Если первый вариант, то очень даже хорошо.
Сообщения, как правило, разбиваются на много столбцов. Но не всегда — иногда пользователям лениво делать это достаточно детально. Большой стобец типа message обычно остаётся, и становится важно делать brute-force поиск подстроки в строке или регексп.
Оба этих случая достаточно хорошо оптимизированы. Например, поиск подстроки в строке, при условии, что сжатые данные помещаются в page cache, на одном сервере осуществляется со скоростью более 10 GB/sec.
Оба этих случая достаточно хорошо оптимизированы. Например, поиск подстроки в строке, при условии, что сжатые данные помещаются в page cache, на одном сервере осуществляется со скоростью более 10 GB/sec.
В open-source выложили сегодня: https://habrahabr.ru/company/yandex/blog/303282/.
Что можете плохого сказать про Hadoop в контексте сравнения с ClickHouse?
Hadoop гораздо лучше подходит для offline-вычислений, когда нужно много ворочать данными. В Hadoop больше инструментов для всесторонней обработки данных. А ClickHouse лучше подходит для онлайн запросов — по хорошо структурированным данным, достаточно быстрых и более-менее простых. При этом, ниша ClickHouse со временем сокращается, так как для Hadoop тоже есть и появляются новые средства, подходящие для онлайн запросов (при некоторых условиях).
Но для задачи — сделать аналитический инструмент для массовой аудитории, а не для внутренних пользователей, Hadoop использовать сложнее. Ведь придётся решить несколько побочных задач:
— как реплицировать данные между ДЦ;
— как обеспечить скорость выборки данных по первичному ключу при условии постоянного обновления данных.
Если не нужен массовый сервис, то надо пробовать PrestoDB, Drill и другие. Я сам хочу уделить этому больше внимания.
Но для задачи — сделать аналитический инструмент для массовой аудитории, а не для внутренних пользователей, Hadoop использовать сложнее. Ведь придётся решить несколько побочных задач:
— как реплицировать данные между ДЦ;
— как обеспечить скорость выборки данных по первичному ключу при условии постоянного обновления данных.
Если не нужен массовый сервис, то надо пробовать PrestoDB, Drill и другие. Я сам хочу уделить этому больше внимания.
Спасибо за интересный и подробный материал. Понятно, почему вы не использовали Google BigQuery. Но пробовали ли сравнить скорость выполнения одинаковых запросов к одинаковым данным в ClickHouse и Google BigQuery? Если да, какие результаты?
>> TokuDB в то время была доступна только за деньги.
а почему не купили?
а почему не купили?
Sign up to leave a comment.
Эволюция структур данных в Яндекс.Метрике