Комментарии 19
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за Ваш труд, интересная информация по тестам! Только лучше было бы все же предварительно настроить MySQL, это было бы больше похоже на реальные испытания.
Ради интереса, сгенерировал tours.csv и положил в Exasol (1 node, бесплатный который).
Размер в сжатом виде получился 180.06 Мб.
По времени выполнения, все запросы идут 0.2 — 0.5 секунд, из которых львиная доля уходит на EXECUTE \ COMPILE. Просто на то, чтобы взлететь и понять, что нужно сделать. Данных совсем мало чтобы получить заметную разницу.
Вот бы взять ~1Тб туров, колоночек сделать штук пятьдесят и запрос чуть посложнее. Например, «топ 50 туров, которые искали люди, похожие на вас».
Размер в сжатом виде получился 180.06 Мб.
По времени выполнения, все запросы идут 0.2 — 0.5 секунд, из которых львиная доля уходит на EXECUTE \ COMPILE. Просто на то, чтобы взлететь и понять, что нужно сделать. Данных совсем мало чтобы получить заметную разницу.
Вот бы взять ~1Тб туров, колоночек сделать штук пятьдесят и запрос чуть посложнее. Например, «топ 50 туров, которые искали люди, похожие на вас».
А давайте посчитаем косты на Exasol и ClickHouse для работы с терабайтной базой туров?
Из своего опыта могу сказать, что 250 отелей*60 размещений*18 вариантов срока пребывания*200 доп опций*сезон в 7 месяцев = примерно 30ГБ в БД Мастер-тур.
Вся Италия вместе с Сардинией будет как раз около ТБ.
На рынке есть моно-операторы, работающие только в одном направлении, но их мало уже осталось. Большинство крупных операторов работают минимум на всю Европу, но(!) у себя держат не полные данные, а примерочные, а полные данные дают по запросу клиента, запрашивая из внешних баз.
Вот здесь нам рассказывают, что для более-менее приемлемой аналитической работы с базой в 85ТБ нужно 8 20-головых нод с 5,6ТБ суммарной оперативки и 64ТБ хранилищем.
Самая крупная база, с которой имел дело лично я, весила 3,5ТБ. Это объём данных оператора в средне-тяжёлом весе за полный год. Обычно, хранят «под рукой» данные за два-три года.
Если предположить, что для работы с такой базой нужна будет одна нода в Exasol из примера Baidoo, против обычного 2-голового ксеона с 256ГБ оперативки в топе под Click-House, то выбор становится очевидным, правда?
Из своего опыта могу сказать, что 250 отелей*60 размещений*18 вариантов срока пребывания*200 доп опций*сезон в 7 месяцев = примерно 30ГБ в БД Мастер-тур.
Вся Италия вместе с Сардинией будет как раз около ТБ.
На рынке есть моно-операторы, работающие только в одном направлении, но их мало уже осталось. Большинство крупных операторов работают минимум на всю Европу, но(!) у себя держат не полные данные, а примерочные, а полные данные дают по запросу клиента, запрашивая из внешних баз.
Вот здесь нам рассказывают, что для более-менее приемлемой аналитической работы с базой в 85ТБ нужно 8 20-головых нод с 5,6ТБ суммарной оперативки и 64ТБ хранилищем.
Самая крупная база, с которой имел дело лично я, весила 3,5ТБ. Это объём данных оператора в средне-тяжёлом весе за полный год. Обычно, хранят «под рукой» данные за два-три года.
Если предположить, что для работы с такой базой нужна будет одна нода в Exasol из примера Baidoo, против обычного 2-голового ксеона с 256ГБ оперативки в топе под Click-House, то выбор становится очевидным, правда?
Именно на терабайтную базу косты одинаковые будут. 1Тб сырых данных как раз примерно ужмутся в 200Гб сжатых и целиком влезут в память бесплатной версии. И как раз это всё заведётся на машинке с 256Гб памяти.
Тут вопрос немного в другом. При росте объёма данных те проблемы и острые углы, которые есть у любого продукта, начинают проявляться намного ярче. По шести сотням мегабайт и fullscan можно сделать, сохранив адекватное время ответа. А вот хотя бы на пятистах гигах ClickHouse должен оторваться от MySQL уже на много порядков. Особенно на запросе чуть посложнее WHERE + ORDER BY.
Тут вопрос немного в другом. При росте объёма данных те проблемы и острые углы, которые есть у любого продукта, начинают проявляться намного ярче. По шести сотням мегабайт и fullscan можно сделать, сохранив адекватное время ответа. А вот хотя бы на пятистах гигах ClickHouse должен оторваться от MySQL уже на много порядков. Особенно на запросе чуть посложнее WHERE + ORDER BY.
Спасибо за статью, но запросы слишком простые — не ни аггрегаций, ни группировок, ни вложенных запросов, ни джоинов.
Потом у самого кликхауса на сайте есть бенчмарки против MySQL, и там прекрасно видно их сравнение.
Было бы гораздо интереснее посмотреть сравнение против Elastic Search, Splunk, Druid...
че-т не очень искали :)
https://github.com/excitoon/ClickHouse/releases — собранные бинарники
https://github.com/excitoon/homebrew-clickhouse — репо для хомбрю с клиентом
https://github.com/hatarist/homebrew-clickhouse — репо для хомбрю с сервер+клиентом
https://github.com/excitoon/ClickHouse/releases — собранные бинарники
https://github.com/excitoon/homebrew-clickhouse — репо для хомбрю с клиентом
https://github.com/hatarist/homebrew-clickhouse — репо для хомбрю с сервер+клиентом
Чо-то как-то так себе сборка, я вам скажу:
> ~/Downloads/clickhouse-client
dyld: Symbol not found: __ZSt14__once_functor
Referenced from: /Users/yuriy/Downloads/clickhouse-client (which was built for Mac OS X 10.12)
Expected in: /usr/local/opt/gcc/lib/gcc/6/libstdc++.6.dylib
in /Users/yuriy/Downloads/clickhouse-client
fish: '~/Downloads/clickhouse-client' terminated by signal SIGABRT (Abort)
Пардон, я со свежезареганного аккаунта, поэтому править комменты не могу. Исправленный:
https://github.com/excitoon/ClickHouse/releases — собранные бинарники (уже старые)
https://github.com/excitoon/homebrew-clickhouse — репо для хомбрю с клиентом (тоже уже старое)
https://github.com/hatarist/homebrew-clickhouse — репо для хомбрю с сервер+клиентом (стараюсь обновлять, но может быть лениво)
в последнем случае всячески приветствуются:
— автоматизация тестов и обновления пакета (как brewbot'ы делают для bottle'ов),
— исправления для того, чтобы пройти в homebrew-core репу. дело было давно, но отклонили. см. https://github.com/Homebrew/homebrew-core/pull/7222
— банальные обновления ссылки/хеша/тестирование того, что пакет собирается, с последующими пуллреквестами
ссылка на идею сделать официальный homebrew-репозиторий на стороне яндекса: https://github.com/yandex/ClickHouse/issues/235
Тоже сначала плевался от докера, оверхед от virtualbox/xhyve по I/O очень большой, что критично при тесте кликхауса локально, в макоси. Но на время тестов, да и пока нет нормальной линуксовой машины, докер вполне можно потерпеть. ¯\_(ツ)_/¯
https://github.com/excitoon/ClickHouse/releases — собранные бинарники (уже старые)
https://github.com/excitoon/homebrew-clickhouse — репо для хомбрю с клиентом (тоже уже старое)
https://github.com/hatarist/homebrew-clickhouse — репо для хомбрю с сервер+клиентом (стараюсь обновлять, но может быть лениво)
в последнем случае всячески приветствуются:
— автоматизация тестов и обновления пакета (как brewbot'ы делают для bottle'ов),
— исправления для того, чтобы пройти в homebrew-core репу. дело было давно, но отклонили. см. https://github.com/Homebrew/homebrew-core/pull/7222
— банальные обновления ссылки/хеша/тестирование того, что пакет собирается, с последующими пуллреквестами
ссылка на идею сделать официальный homebrew-репозиторий на стороне яндекса: https://github.com/yandex/ClickHouse/issues/235
Тоже сначала плевался от докера, оверхед от virtualbox/xhyve по I/O очень большой, что критично при тесте кликхауса локально, в макоси. Но на время тестов, да и пока нет нормальной линуксовой машины, докер вполне можно потерпеть. ¯\_(ツ)_/¯
а насчет excitoon'овских ничего не могу сказать, он действительно собирал для 10.12, и официально сборка для макоси поддерживается с сиерры (раз, два), но я сидел на El Capitan, и с ним сначала все было ОК, потом сильно сломалось, а теперь снова все ОК, если динамически библиотеки линковать.
Впрочем, может там опять что-то изменилось, я перестал следить :(
Впрочем, может там опять что-то изменилось, я перестал следить :(
Может еще Tarantool? Насколько знаю, он уже умеет держать в оперативке не все данные.
Не похоже, чтобы Tarantool подходил — он же сделан как быстрая сетевая хеш-таблица, а не чтобы делать быстрый фулскан.
Я залил данные в демона, это заняло 1 минуту 51 секунду процессорного времени тарантула и 535 Мб памяти.
Но что потом с этими данными делать? У тарантула нет возможности выбрать отфильтрованные данные без использования индекса. Если же выбирать все данные в lua, то даже в локальной консоли сервера это занимает очень приличное время (заметьте, что я даже сортировать не начинал, как и обработку записей тоже):
Если же добавлять индексы, то потребление памяти будет ещё больше. Очевидно, что движок Vinyl быстрее memtx тоже на такой нагрузке не будет.
В общем, тарантул — безусловно хорошая база, но она в данном случае совсем не подходит.
Я залил данные в демона, это заняло 1 минуту 51 секунду процессорного времени тарантула и 535 Мб памяти.
Но что потом с этими данными делать? У тарантула нет возможности выбрать отфильтрованные данные без использования индекса. Если же выбирать все данные в lua, то даже в локальной консоли сервера это занимает очень приличное время (заметьте, что я даже сортировать не начинал, как и обработку записей тоже):
tarantool> local start = os.clock(); for k, v in box.space.tours:pairs() do end; print(string.format("elapsed time: %.2f sec\n", os.clock() - start))
elapsed time: 5.90 sec
Если же добавлять индексы, то потребление памяти будет ещё больше. Очевидно, что движок Vinyl быстрее memtx тоже на такой нагрузке не будет.
В общем, тарантул — безусловно хорошая база, но она в данном случае совсем не подходит.
Небольшой апдейт: поигравшись с количеством ядер, выделенных под «наливалку» (GOMAXPROCS=3) и количеством одновременных потоков (1024 намного лучше, чем изначальные 16), которые заливают в Тарантул, мне удалось сократить время заливки до 40 секунд. Однако на время выборки это не влияет.
Классика…
lua garbage collector плохо переживает много lua таблиц (в твоем коде — box.space.tours:pairs()).
Проблема 1 в 1 была когда мы делали Facebook linkbech, часть хранимой пришлось переписать на C, чтобы избавиться от этих эффектов.
Как вариант rust, C или попробовать наш SQL (который в альфа)
lua garbage collector плохо переживает много lua таблиц (в твоем коде — box.space.tours:pairs()).
Проблема 1 в 1 была когда мы делали Facebook linkbech, часть хранимой пришлось переписать на C, чтобы избавиться от этих эффектов.
Как вариант rust, C или попробовать наш SQL (который в альфа)
А почему нет индекса по полю price?
Почему Вы пишете комментарии к постам шестилетней давности :)?
Если кратко, то индекса по полю price нет, потому что мы в данном примере мы сортируем по любому полю, не только по цене.
Можно добавить индексы по всем полям, но тогда вставка будет ещё медленней, и места на диске таблицы тоже будут занимать ещё больше. При этом ускорение от индексов будет только в случае, если условие WHERE не отсекает слишком много строк, иначе MySQL будет читать всю таблицу случайным чтением по одной строке, что очень медленно.
В ClickHouse же вторичных индексов на тот момент вообще не было.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем быстрый поиск по турам на основе ClickHouse