а программисты один хрен его не понимают и главное не хотят его понимать
Ну так это проблема программистов или их менеджеров. Любой продукт надо понимать, чтобы уметь им пользоваться. ClickHouse — штука с кучей своих особенностей, и именно эти особенности, если правильно ими пользоваться, позволяют быть куда более эффективным, чем Oracle или Vertica. О чем я и другие ребята рассказывают на хайлоадах и других конференциях. Вертику, кстати, тоже надо уметь готовить.
Ну и не забывайте, что ClickHouse — это open source, поэтому документация пока не самая сильная сторона. Но всегда можно посмотреть в код, что и как работает. С Oracle/Vertica это невозможно в принципе. Или спросить в каналах поддержки. Было бы желание.
Думать о замене надо лишь в том случае, если что-то не устраивает в текущем решении. Авторы статьи описали свои проблемы с RedShift, ради которых они затеяли переезд на ClickHouse. А какая мотивация у вас?
Большое спасибо за расшифровку, но в качестве пожелания на будущее — посылайте автору, пожалуйста, на редактирование, так как в тексте получилось много опечаток из-за недостаточного понимания расшифровщиком предметной области. Ну и способ построения многих фраз при докладе вживую и в тексте я бы, конечно, отличается, и многие фразы можно было бы причесать.
Я думаю, что дело не в оптимизаторе Exasol, а в том, что у него все в памяти. Если при запросе на денормализированной таблице, скорость чтения колонок с диска (да еще при наличии кеша ОС) может не сильно уступать памяти, то при джойнах Вертике приходится лишний раз (разы) походить по диску, собрать таблицы для джойна. И как раз поэтому оптимизатор в Вертике очень важен, чтобы уменьшить заходы на диск (кроме того там есть нюансы, влияющие на эффективность джойнов).
Присоединюсь к недоумению ascrus и добавлю, что в статье есть правильная фраза «В контексте сравнения с Exasol важно отметить, что Vertica не является in-memory базой данных и более того, в Vertica нет буферного пула. То есть БД предназначена в первую очередь для обработки объёмов данных, которые значительно превосходят размер оперативной памяти». Поэтому тест сравнивает апельсины с лимонами :) Но все равно интересно.
«Вы не любите кошек? Вы просто не умеете их готовить» (с)
Для начала замечу, что HP купили Вертику в 2011 (когда у Вертики уже были сотни счастливых корпоративных клиентов в US), то есть Вы все время работали с HP-шной уже версией и багами. После покупки основные разработчики, получив хорошие деньги, разбежались, и не удивительно, что в новой (относительно core Vertica) функциональности находят не мало проблем. На то она и новая.
Еще замечу, что от PostreSQL там только диалект SQL и вроде некоторые вещи, связанные с планировщиком запросов. Вертика выросла из http://db.lcs.mit.edu/projects/cstore/. Поэтому говорить о «Postgres за основу» — это несколько неправда. Вертиковцы бы очень обиделись :)
Вертиковский подход к бекапам отличается от традиционного. Если внимательно почитать документацию и это осознать, то проблем не будет. Во-первых, при грамотной конфигурации у управлении кластером бекап в принципе не сильно нужен. За шесть лет промышленной эксплуатации нам ни разу не пришлось использовать бекап (и ни разу данные, конечно же, не были потеряны), хотя мы меняли сервера, кластеры, датацентры и пр. Во-вторых, бекап делается на уровне файловой системы (банальным rsync), из чего логично вытекают ограничения на идентичный кластер и т.д. (зачем восстанавливать бекап в неидентичный кластер — я не очень понимаю, и не уверен, что у других распределенных RDBMS тут сильно лучше).
> Я думаю что список может быть куда длинней, это я по памяти написал то, что наш системщик выкопал. Но каждый раз при словах, что нужно что-то сделать с вертикой, у него нервный тик начинается :)
Может быть, стоит сменить не БД, а системщика? Честно, менее проблемной базы я не встречал, а мне пришлось поработать с большинством крупных. А уж «вес» проблем по отношению к достоинствам и вовсе минимален.
Впрочем, я свое мнение не навязываю, просто делюсь. Мы тоже пробуем переехать с Вертики, но отнюдь не из-за технических проблем.
Лет 10 назад мне предлагали поучаствовать в разработке подобной системы для правительства Москвы (мы отказались, так как сроки и деньги совсем не соответствовали сложности задачи). Идея была очень похожая — интеграция всех возможных источников, ведомственных баз данных, CRM систем и т.п., и, самое существенное, навешивание семантики (тогда Semantic Web было модным словосочетанием), выявление связей, управление знаниями. В этой статье очень ярко показано, что главное не сами данные, а взаимосвязи, их поиск и наглядное представление. Честно говоря, если это все работает так, как рассказывает товарищ, то это очень круто. Большому брату станет жить существенно легче :)
Хм, то есть за 4 секунды читается колонка, вычисляется регулярное выражение и строится индекс. Вторая таблица маленькая, для нее только вычисляется выражение. Потом идет джойн, используя уже построенный индекс (кстати то, что он строится только для одной таблицы, еще один аргумент в пользу хеша: для merge надо строить с двух сторон). То есть, насколько я понимаю, это как раз пример, когда заранее построенный индекс НЕ используется, а строится динамически в памяти.
>Судя по всему, кеш представляет собой просто те же самые блоки, которые хранятся на диске, только загруженные в память. Добавление нового значения не приводит к перестройке старых блоков и, соответственно, не дропает уже закешированные старые блоки.
Ок, логично. На самом деле в Вертике то же самое происходит, только этим занимается кэш файловой системы (блок = файл), поэтому об этом мало кто знает :)
>Результат профилирования:
Интересно, а почему в 3 и 4й строчке out rows меньше, чем in?
Кстати из этого результата не очевидно, как индексы используется (и используются ли вообще). А какая селективность индекса (или кардинальность колонок) activity_user_id и activity_dt?
>Есть данные, которые загружаются каждые 15 минут. При этом для ETL используем целиком собственное программное решение, которое позволяет дробить загрузку как угодно. Можно хоть раз в минуту загружать, только практического смысла мало.
Так мой вопрос был изначально про кеш. Если данные грузятся в таблицу часто, то что происходит с кешем. Скажем, добавилось в очередной загрузке новое значение в колоноку — надо полностью перестраивать, если я правильно понимаю.
>На самом деле, даже это не подходит. Exasol в большинстве случаев работает со сжатыми данными, не разжимая их и не получая оригинальные значения в процессе выполнения. Это означает, что колонка, в которой всего 5-10 вариантов значений, сожмётся в разы лучше, чем колонка, в которой десятки тысяч вариантов. При этом формально количество «ячеек» будет одинаковым.
Если мы хотим что-то сравнивать, то это нормальный критерий для колоночных баз данных. Что там как сожмется — второй вопрос. Кстати, если ли возможность управлять, как именно колонка сжимается, или это все внутри и автоматом?
>Сужу по тому признаку, что JOIN по уже существующему индексу ест очень мало памяти. Никакая хеш таблица в такой объём не влезла бы.
А что значит «ест»? Если в процессе выполнения запроса, то дополнительная память не нужна, индекс же уже в памяти (или на диске, наверное, тоже может быть, да?). А сколько занимает сам индекс, можно оценить?
Мир экзотических деревьев, конечно, существует, но кроме LSM-деревьев и TokuDB Fractal-trees, по-моему ничего в боевых системах не используется (spatial-индексы не берем). Для merge join необходима сортировка, что дорого на больших данных.
> Судя по этим данным, в Badoo ETL процесс практически не вытесняет кеш.
То есть вы загружаете данные, на чаще, чем раз в час, правильно я понимаю? А realtime аналитику не пробовали делать? Возможно?
>Например, следующие запросы могут отличаться по сложности в сто-двести раз, но при этом формально сканировать одно и то же количество «рядов».
Вообще, в колоночной базе количество строк — это не самый объективный параметр :) Но лучше не придумали, я пробовал оценивать по количеству «ячеек» — то есть строки умножить на столбцы, это несколько адекватнее, но такую статистику сложнее получить.
>Подробностей они не рассказывают и очень тщательно охраняют этот секрет.
Обычно это означает, что особого секрета нет :) Но судя по тому, что поддерживается только «равно» — это хеш.
>Если DISTRIBUTE BY явно не указан, то ряды случайно раскидываются по нодам таким образом, чтобы везде было поровну.
>Особо маленькие таблицы дополнительно полностью загружаются в память каждой ноды для того, чтобы всегда делать к ним локальный JOIN. Существует параметр, который позволяет управлять тем, что считается «маленькой таблицей» в данном случае, но он задаётся сразу на весь кластер.
«3. Fault tolerance. В своей практике мы сталкивались с несколькими аварийными сценариями. Например, заканчивалось свободное место, или кто-то случайно физически отключал часть работающих серверов от сети. Никаких существенных проблем с этим мы не заметили. База заранее пишет о проблеме, останавливается и ждет исправления ситуации. „
То есть база не может работать хотя бы без одной ноды? Ей необходимы все?
1). Vertica всегда читает диск, даже если анализ идёт по «горячим» данным.
Это не совсем так, только что загруженные данные могут висеть в памяти некоторое время.
2). Vertica не так эффективно использует большие объёмы памяти. Если я правильно понял ребят из HP, объём памяти на типичной ноде для вертики не превышает 200-300Гб.
Это тоже не совсем так. Дело не в том, что Вертика не эффективно использует большие объемы памяти. А в том, что память используется в основном во время выполнения запросов. Соответственно, необходимый объем зависит от сложности запросов и количестве клиентов, который одновременно выполняют запросы.
3). В Vertica необходимо строить проекции для того, чтобы делать эффективные локальные join'ы. На больших объёмах нельзя просто придти и начать join'ить какие-то совершенно случайные колонки. В Exasol'е — можно. Индексы построятся сами после первого SELECT'а.
И это тоже не совсем правда :) В Вертике можно прийти и джойнить совершенно случайные колонки. В стар-схемах обычно одна таблица очень большая, и много маленьких — этот сценарий работает без проблем. Две большие таблицы могут джойниться небыстро, но как часто в реальной жизни встречаются такие сценарии? Некоторое подобие индекса в Вертике строится в памяти во время выполнения запроса (hash join). Но чтобы получить максимальную производительность (оптимизировать WHERE-clause, group by, джойны) — да, надо делать проекции. Но оно того стоит.
Спасибо, давно хотел поподробнее посмотреть на это европейское чудо, и Вы частично удовлетворили любопытство.
Несколько вопросов по тексту:
1. «Как правило, в реальной жизни пользователи работают в первую очередь с «горячими» данными (последний день, неделя, месяц). Если у кластера достаточно памяти, чтобы вместить их целиком, то Exasol не будет трогать диск вообще.» — а что происходит с кешем, если происходит постоянная загрузка данных?
2. «Один аналитический запрос обрабатывает в среднем около 4,5 миллиардов рядов.» — как Вы это определили? Есть подробная статистика?
3. «Эффективный джойн всегда происходит по индексу. Индексы создаются автоматически в тот момент, когда вы впервые пытаетесь объединить две таблицы по определенным ключам. Если индекс не используется долгое время, то он так же автоматически удаляется. » — то есть базу данных требуется «разогревать», чтобы построить индексы? Это несколько противоречит утвреждению «Вы просто загружаете данные и можете сразу их анализировать на высокой скорости.» Не совсем понятно, кстати, какие это индексы, если JOIN работает только по условию «равно». Бинарные индексы прекрасно подходят и под условия больше-меньше. То есть это хеш-индексы, скорее всего. Оно конечно хорошо, но для джойнов больших таблиц может быть неэффективно.
4. «Также маленькие таблицы автоматически реплицируются (копируются целиком) на все ноды, что автоматически гарантирует быстрые локальные джойны к ним. Это особенно актуально для многочисленных небольших списков.» — то есть разработчик не имеет над этим контроля? Или все таблицы по дефолту реплицируются везде, и разработчик должнен явно указывать 'distribute by' для больших таблиц? Может ли быть несколько колонок в distribute by? Чем еще управляет разработчик в физическом дизайне?
Вообще, статья хороша, как вводная, но она плохо объясняет, как именно Exasol достигает высоких результатов. Можно поверить, что он быстро работает, но скорость запросов на ваших дорогущих серверах (768GB RAM) и сравнительно небольших объемах не выглядит большой в сравнении с той же Вертикой.
Хотя Release Notes прочитаны сразу после выхода, я ждал этой статьи :) Как всегда, по полочкам.
Для нас самое интересное оказалось в мелочах, которые «болели» давно:
— Наконец-то констрейнты стали настоящими — я даже не поверил, когда это прочитал в Release Notes
— Наконец-то гранты можно раздавать на схему целиком, а не на каждую таблицу
— Наконец-то задокументированы хинты для управления планом запроса
Это те мелочи, которых очень не хватало в сравнении с другими RDBMS. То ли услышали клиентские стоны, то ли время пришло.
Ну и восстановление по таблицам тоже не лишнее.
Насколько улучшилась производительность пока не понятно, обновиться просто не получилось, сначала приходится поднимать версию Debian.
Полезный перевод, спасибо. Стоунбрейкер давно критикует Hadoop. Наверное, с 2009г со статьи в SIGMOD 2009 (тут есть ссылка database.cs.brown.edu/projects/mapreduce-vs-dbms). И судя по этим более поздним статьям суть его претензий не меняется, Hadoop — это универсальный, но достаточно неэффективный инструмент для тех задач, которые им чаще всего пытаются решать, если сравнивать со специализированными инструментами. А попытка сделать его эффективным приводит к тому, что от Hadoop почти ничего не остается. Что не отменяет того, что есть задачи, когда Hadoop оправдан, тот же неструктурированный поиск.
Кстати, довольно странно, что он пишет об Impala, но не упоминает о Stinger.
Странно, что эта статья не вызвала интереса. Может, не попала в нужный хаб? Я обычно ставил еще в «Администрирование баз данных», там много народу читает.
С сомнением отношусь к софту, который автоматизирует загрузку из произвольных источников, но думаю, что вы знаете, что делаете :) Маскировка персональных данных — это хорошая идея. Но не вижу проблемы в лоб захэшировать персональные данные через SQL. В чем суть вашего решения?
Ну так это проблема программистов или их менеджеров. Любой продукт надо понимать, чтобы уметь им пользоваться. ClickHouse — штука с кучей своих особенностей, и именно эти особенности, если правильно ими пользоваться, позволяют быть куда более эффективным, чем Oracle или Vertica. О чем я и другие ребята рассказывают на хайлоадах и других конференциях. Вертику, кстати, тоже надо уметь готовить.
Ну и не забывайте, что ClickHouse — это open source, поэтому документация пока не самая сильная сторона. Но всегда можно посмотреть в код, что и как работает. С Oracle/Vertica это невозможно в принципе. Или спросить в каналах поддержки. Было бы желание.
Под 110 есть даже полноценная зеркальная система со съемными объективами — Pentax 110 (https://en.wikipedia.org/wiki/Pentax_Auto_110)
Для начала замечу, что HP купили Вертику в 2011 (когда у Вертики уже были сотни счастливых корпоративных клиентов в US), то есть Вы все время работали с HP-шной уже версией и багами. После покупки основные разработчики, получив хорошие деньги, разбежались, и не удивительно, что в новой (относительно core Vertica) функциональности находят не мало проблем. На то она и новая.
Еще замечу, что от PostreSQL там только диалект SQL и вроде некоторые вещи, связанные с планировщиком запросов. Вертика выросла из http://db.lcs.mit.edu/projects/cstore/. Поэтому говорить о «Postgres за основу» — это несколько неправда. Вертиковцы бы очень обиделись :)
Вертиковский подход к бекапам отличается от традиционного. Если внимательно почитать документацию и это осознать, то проблем не будет. Во-первых, при грамотной конфигурации у управлении кластером бекап в принципе не сильно нужен. За шесть лет промышленной эксплуатации нам ни разу не пришлось использовать бекап (и ни разу данные, конечно же, не были потеряны), хотя мы меняли сервера, кластеры, датацентры и пр. Во-вторых, бекап делается на уровне файловой системы (банальным rsync), из чего логично вытекают ограничения на идентичный кластер и т.д. (зачем восстанавливать бекап в неидентичный кластер — я не очень понимаю, и не уверен, что у других распределенных RDBMS тут сильно лучше).
> Я думаю что список может быть куда длинней, это я по памяти написал то, что наш системщик выкопал. Но каждый раз при словах, что нужно что-то сделать с вертикой, у него нервный тик начинается :)
Может быть, стоит сменить не БД, а системщика? Честно, менее проблемной базы я не встречал, а мне пришлось поработать с большинством крупных. А уж «вес» проблем по отношению к достоинствам и вовсе минимален.
Впрочем, я свое мнение не навязываю, просто делюсь. Мы тоже пробуем переехать с Вертики, но отнюдь не из-за технических проблем.
Тогда 64GB на индекс не выглядит чем-то очень маленьким. Впрочем, если памяти много, то почему бы и нет :)
Спасибо за разговор. Приятно поговорить с умным человеком :)
Ок, логично. На самом деле в Вертике то же самое происходит, только этим занимается кэш файловой системы (блок = файл), поэтому об этом мало кто знает :)
>Результат профилирования:
Интересно, а почему в 3 и 4й строчке out rows меньше, чем in?
Кстати из этого результата не очевидно, как индексы используется (и используются ли вообще). А какая селективность индекса (или кардинальность колонок) activity_user_id и activity_dt?
Так мой вопрос был изначально про кеш. Если данные грузятся в таблицу часто, то что происходит с кешем. Скажем, добавилось в очередной загрузке новое значение в колоноку — надо полностью перестраивать, если я правильно понимаю.
>На самом деле, даже это не подходит. Exasol в большинстве случаев работает со сжатыми данными, не разжимая их и не получая оригинальные значения в процессе выполнения. Это означает, что колонка, в которой всего 5-10 вариантов значений, сожмётся в разы лучше, чем колонка, в которой десятки тысяч вариантов. При этом формально количество «ячеек» будет одинаковым.
Если мы хотим что-то сравнивать, то это нормальный критерий для колоночных баз данных. Что там как сожмется — второй вопрос. Кстати, если ли возможность управлять, как именно колонка сжимается, или это все внутри и автоматом?
>Сужу по тому признаку, что JOIN по уже существующему индексу ест очень мало памяти. Никакая хеш таблица в такой объём не влезла бы.
А что значит «ест»? Если в процессе выполнения запроса, то дополнительная память не нужна, индекс же уже в памяти (или на диске, наверное, тоже может быть, да?). А сколько занимает сам индекс, можно оценить?
Мир экзотических деревьев, конечно, существует, но кроме LSM-деревьев и TokuDB Fractal-trees, по-моему ничего в боевых системах не используется (spatial-индексы не берем). Для merge join необходима сортировка, что дорого на больших данных.
То есть вы загружаете данные, на чаще, чем раз в час, правильно я понимаю? А realtime аналитику не пробовали делать? Возможно?
>Например, следующие запросы могут отличаться по сложности в сто-двести раз, но при этом формально сканировать одно и то же количество «рядов».
Вообще, в колоночной базе количество строк — это не самый объективный параметр :) Но лучше не придумали, я пробовал оценивать по количеству «ячеек» — то есть строки умножить на столбцы, это несколько адекватнее, но такую статистику сложнее получить.
>Подробностей они не рассказывают и очень тщательно охраняют этот секрет.
Обычно это означает, что особого секрета нет :) Но судя по тому, что поддерживается только «равно» — это хеш.
>Если DISTRIBUTE BY явно не указан, то ряды случайно раскидываются по нодам таким образом, чтобы везде было поровну.
>Особо маленькие таблицы дополнительно полностью загружаются в память каждой ноды для того, чтобы всегда делать к ним локальный JOIN. Существует параметр, который позволяет управлять тем, что считается «маленькой таблицей» в данном случае, но он задаётся сразу на весь кластер.
Ясно. В данных условиях разумно.
Спасибо за ответы!
Насчет сервисов — это не столь существенно, вопрос реализации и именования.
«3. Fault tolerance. В своей практике мы сталкивались с несколькими аварийными сценариями. Например, заканчивалось свободное место, или кто-то случайно физически отключал часть работающих серверов от сети. Никаких существенных проблем с этим мы не заметили. База заранее пишет о проблеме, останавливается и ждет исправления ситуации. „
То есть база не может работать хотя бы без одной ноды? Ей необходимы все?
1). Vertica всегда читает диск, даже если анализ идёт по «горячим» данным.
Это не совсем так, только что загруженные данные могут висеть в памяти некоторое время.
2). Vertica не так эффективно использует большие объёмы памяти. Если я правильно понял ребят из HP, объём памяти на типичной ноде для вертики не превышает 200-300Гб.
Это тоже не совсем так. Дело не в том, что Вертика не эффективно использует большие объемы памяти. А в том, что память используется в основном во время выполнения запросов. Соответственно, необходимый объем зависит от сложности запросов и количестве клиентов, который одновременно выполняют запросы.
3). В Vertica необходимо строить проекции для того, чтобы делать эффективные локальные join'ы. На больших объёмах нельзя просто придти и начать join'ить какие-то совершенно случайные колонки. В Exasol'е — можно. Индексы построятся сами после первого SELECT'а.
И это тоже не совсем правда :) В Вертике можно прийти и джойнить совершенно случайные колонки. В стар-схемах обычно одна таблица очень большая, и много маленьких — этот сценарий работает без проблем. Две большие таблицы могут джойниться небыстро, но как часто в реальной жизни встречаются такие сценарии? Некоторое подобие индекса в Вертике строится в памяти во время выполнения запроса (hash join). Но чтобы получить максимальную производительность (оптимизировать WHERE-clause, group by, джойны) — да, надо делать проекции. Но оно того стоит.
Несколько вопросов по тексту:
1. «Как правило, в реальной жизни пользователи работают в первую очередь с «горячими» данными (последний день, неделя, месяц). Если у кластера достаточно памяти, чтобы вместить их целиком, то Exasol не будет трогать диск вообще.» — а что происходит с кешем, если происходит постоянная загрузка данных?
2. «Один аналитический запрос обрабатывает в среднем около 4,5 миллиардов рядов.» — как Вы это определили? Есть подробная статистика?
3. «Эффективный джойн всегда происходит по индексу. Индексы создаются автоматически в тот момент, когда вы впервые пытаетесь объединить две таблицы по определенным ключам. Если индекс не используется долгое время, то он так же автоматически удаляется. » — то есть базу данных требуется «разогревать», чтобы построить индексы? Это несколько противоречит утвреждению «Вы просто загружаете данные и можете сразу их анализировать на высокой скорости.» Не совсем понятно, кстати, какие это индексы, если JOIN работает только по условию «равно». Бинарные индексы прекрасно подходят и под условия больше-меньше. То есть это хеш-индексы, скорее всего. Оно конечно хорошо, но для джойнов больших таблиц может быть неэффективно.
4. «Также маленькие таблицы автоматически реплицируются (копируются целиком) на все ноды, что автоматически гарантирует быстрые локальные джойны к ним. Это особенно актуально для многочисленных небольших списков.» — то есть разработчик не имеет над этим контроля? Или все таблицы по дефолту реплицируются везде, и разработчик должнен явно указывать 'distribute by' для больших таблиц? Может ли быть несколько колонок в distribute by? Чем еще управляет разработчик в физическом дизайне?
Вообще, статья хороша, как вводная, но она плохо объясняет, как именно Exasol достигает высоких результатов. Можно поверить, что он быстро работает, но скорость запросов на ваших дорогущих серверах (768GB RAM) и сравнительно небольших объемах не выглядит большой в сравнении с той же Вертикой.
Для нас самое интересное оказалось в мелочах, которые «болели» давно:
— Наконец-то констрейнты стали настоящими — я даже не поверил, когда это прочитал в Release Notes
— Наконец-то гранты можно раздавать на схему целиком, а не на каждую таблицу
— Наконец-то задокументированы хинты для управления планом запроса
Это те мелочи, которых очень не хватало в сравнении с другими RDBMS. То ли услышали клиентские стоны, то ли время пришло.
Ну и восстановление по таблицам тоже не лишнее.
Насколько улучшилась производительность пока не понятно, обновиться просто не получилось, сначала приходится поднимать версию Debian.
Кстати, довольно странно, что он пишет об Impala, но не упоминает о Stinger.
С сомнением отношусь к софту, который автоматизирует загрузку из произвольных источников, но думаю, что вы знаете, что делаете :) Маскировка персональных данных — это хорошая идея. Но не вижу проблемы в лоб захэшировать персональные данные через SQL. В чем суть вашего решения?