Comments 19
Размер в сжатом виде получился 180.06 Мб.
По времени выполнения, все запросы идут 0.2 — 0.5 секунд, из которых львиная доля уходит на EXECUTE \ COMPILE. Просто на то, чтобы взлететь и понять, что нужно сделать. Данных совсем мало чтобы получить заметную разницу.
Вот бы взять ~1Тб туров, колоночек сделать штук пятьдесят и запрос чуть посложнее. Например, «топ 50 туров, которые искали люди, похожие на вас».
Из своего опыта могу сказать, что 250 отелей*60 размещений*18 вариантов срока пребывания*200 доп опций*сезон в 7 месяцев = примерно 30ГБ в БД Мастер-тур.
Вся Италия вместе с Сардинией будет как раз около ТБ.
На рынке есть моно-операторы, работающие только в одном направлении, но их мало уже осталось. Большинство крупных операторов работают минимум на всю Европу, но(!) у себя держат не полные данные, а примерочные, а полные данные дают по запросу клиента, запрашивая из внешних баз.
Вот здесь нам рассказывают, что для более-менее приемлемой аналитической работы с базой в 85ТБ нужно 8 20-головых нод с 5,6ТБ суммарной оперативки и 64ТБ хранилищем.
Самая крупная база, с которой имел дело лично я, весила 3,5ТБ. Это объём данных оператора в средне-тяжёлом весе за полный год. Обычно, хранят «под рукой» данные за два-три года.
Если предположить, что для работы с такой базой нужна будет одна нода в Exasol из примера Baidoo, против обычного 2-голового ксеона с 256ГБ оперативки в топе под Click-House, то выбор становится очевидным, правда?
Тут вопрос немного в другом. При росте объёма данных те проблемы и острые углы, которые есть у любого продукта, начинают проявляться намного ярче. По шести сотням мегабайт и 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 — репо для хомбрю с сервер+клиентом
> ~/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 очень большой, что критично при тесте кликхауса локально, в макоси. Но на время тестов, да и пока нет нормальной линуксовой машины, докер вполне можно потерпеть. ¯\_(ツ)_/¯
Впрочем, может там опять что-то изменилось, я перестал следить :(
Может еще Tarantool? Насколько знаю, он уже умеет держать в оперативке не все данные.
Я залил данные в демона, это заняло 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 тоже на такой нагрузке не будет.
В общем, тарантул — безусловно хорошая база, но она в данном случае совсем не подходит.
lua garbage collector плохо переживает много lua таблиц (в твоем коде — box.space.tours:pairs()).
Проблема 1 в 1 была когда мы делали Facebook linkbech, часть хранимой пришлось переписать на C, чтобы избавиться от этих эффектов.
Как вариант rust, C или попробовать наш SQL (который в альфа)
А почему нет индекса по полю price
?
Почему Вы пишете комментарии к постам шестилетней давности :)?
Если кратко, то индекса по полю price нет, потому что мы в данном примере мы сортируем по любому полю, не только по цене.
Можно добавить индексы по всем полям, но тогда вставка будет ещё медленней, и места на диске таблицы тоже будут занимать ещё больше. При этом ускорение от индексов будет только в случае, если условие WHERE не отсекает слишком много строк, иначе MySQL будет читать всю таблицу случайным чтением по одной строке, что очень медленно.
В ClickHouse же вторичных индексов на тот момент вообще не было.
Делаем быстрый поиск по турам на основе ClickHouse