То есть вы загружаете данные, на чаще, чем раз в час, правильно я понимаю? А realtime аналитику не пробовали делать? Возможно?
Есть данные, которые загружаются каждые 15 минут. При этом для ETL используем целиком собственное программное решение, которое позволяет дробить загрузку как угодно. Можно хоть раз в минуту загружать, только практического смысла мало.
Глобально по realtime аналитике задавал вопрос их основателю. Ответ был буквально следующий: «Последние блоки колонок не сжаты, можно часто импортировать по чуть-чуть рядов, существенного оверхеда на это нет».
Но лучше не придумали, я пробовал оценивать по количеству «ячеек» — то есть строки умножить на столбцы, это несколько адекватнее, но такую статистику сложнее получить.
На самом деле, даже это не подходит. Exasol в большинстве случаев работает со сжатыми данными, не разжимая их и не получая оригинальные значения в процессе выполнения. Это означает, что колонка, в которой всего 5-10 вариантов значений, сожмётся в разы лучше, чем колонка, в которой десятки тысяч вариантов. При этом формально количество «ячеек» будет одинаковым.
Вопрос оценки сложности выполнения запроса в аналитической базе достоин отдельной большой статьи. Я так троллил других вендоров во время PoC, когда специально писал генератор с очень неудобной селективностью на VARCHAR, а потом спрашивал: «А почему так медленно?» :)
Но судя по тому, что поддерживается только «равно» — это хеш.
Мне всё же кажется, что это не хеш. По крайней мере, не классический хеш, как в row-based базах данных.
Сужу по тому признаку, что JOIN по уже существующему индексу ест очень мало памяти. Никакая хеш таблица в такой объём не влезла бы. Также Exasol без проблем делает streaming частично завершённого JOIN'а в какой-нибудь дальнейший GROUP BY. Как это было бы возможно без предварительной сортировки данных — не очень представляю. Больше склоняюсь к какому-то очень хитрому распределённому Merge Join, но это всё чистой воды теория.
В ней упоминаются волшебные вещи: ART-tree, AVL-tree, CSB-tree, FAST.
Похоже, мир академических деревьев намного обширнее, чем мы могли бы представить с юзерской точки зрения. :)
Зависит от параметра «redundancy». Например, при «redundancy=2» можно потерять одну ноду. При «redundancy=3» можно потерять две ноды. При «redundancy=1» нельзя потерять ни одной, но зато всё место на дисках — ваше.
На самом деле, всё немного сложнее. Exasol представляет собой объединение нескольких сервисов. Например, ExaSolution управляет SQL запросами и предоставляет интерфейс для юзеров. ExaStorage управляет хранением данных, дисками, кешами. ExaOperation осуществляет общение нод друг с другом, управляет лицензиями. Есть сервис для логирования, для синхронизации времени, и т.д.
В некоторых очень редких случаях возможно такое, что один из сервисов начинает глючить, теряет кворум, пишет warning'и какие-нибудь. Но это всё либо само восстанавливается, либо быстро патчится. С какими-то серьёзными проблемами пока не сталкивались, данные не теряли.
Класс! Приятно получить комментарий от человека, который в теме.
1. а что происходит с кешем, если происходит постоянная загрузка данных?
Отличный вопрос. К сожалению, сейчас нет известной мне возможности узнать, что конкретно лежит в кеше, какие таблицы и блоки. Приходится судить постфактум по профайлингу на реальных запросах. В системных вьюшках записывается, сколько данных было реально прочитано с диска.
Судя по этим данным, в Badoo ETL процесс практически не вытесняет кеш.
Вероятно, это связано с двумя самыми популярными стратегиями загрузки данных:
Перезагружаем таблицу целиком каждый день. Это работает для маленьких таблиц до 1 миллиарда рядов.
Загружаем только последнюю неделю\день\час. Это работает для больших и очень больших таблиц.
В итоге, в кеше оказываются маленькие таблицы целиком и самые новые данные для больших таблиц. А это именно то, над чем аналитики чаще всего проводят анализ.
2. как Вы это определили? Есть подробная статистика?
Да, Exasol сохраняет много различной статистики. Он делает скрытый профайлинг всех запросов и хранит очень подробную информацию за последние 24 часа. Буквально хранится каждая стадия выполнения запроса на каждой отдельно взятой ноде. Время от времени он делает агрегацию и сохраняет обобщённую информацию за день, неделю, месяц.
Собственно, я посмотрел среднее количество ROWS за день для всех типов SCAN в рамках одного запроса.
Другое дело, что, в случае с колоночными базами, понятие «ряды» очень-очень растяжимое.
Например, следующие запросы могут отличаться по сложности в сто-двести раз, но при этом формально сканировать одно и то же количество «рядов».
SELECT id FROM table;
SELECT * FROM table;
3. то есть базу данных требуется «разогревать», чтобы построить индексы?
Не совсем. Индексы персистентные. Они сохраняются и после полного рестарта базы.
Юзер ощущает построение индексов только в тот момент, когда он в самый первый раз пытается сделать JOIN по таким колонкам, которые за последний месяц ни разу не использовались для JOIN'а. После этого индекс поддерживается автоматически во время ETL-процесса (IMPORT, INSERT, UPDATE, DELETE, MERGE), и юзер этого процесса не видит.
Что это за волшебные индексы — великий вопрос. Я много раз задавал его самым разным людям внутри Exasol и даже лично беседовал с их автором: Falko Mattasch. No luck! Подробностей они не рассказывают и очень тщательно охраняют этот секрет.
4. то есть разработчик не имеет над этим контроля? Или все таблицы по дефолту реплицируются везде, и разработчик должнен явно указывать 'distribute by' для больших таблиц? Может ли быть несколько колонок в distribute by? Чем еще управляет разработчик в физическом дизайне?
В физическом плане разработчик может только указать DISTRIBUTE BY для больших таблиц. Можно делать distribute по нескольким колонкам, но тогда они все вместе должны участвовать в JOIN'е.
Если DISTRIBUTE BY явно не указан, то ряды случайно раскидываются по нодам таким образом, чтобы везде было поровну. Если баланс в силу каких-то причин нарушается, то в профилировщике можно увидеть фазу REDISTRIBUTE, которая его восстанавливает.
Особо маленькие таблицы дополнительно полностью загружаются в память каждой ноды для того, чтобы всегда делать к ним локальный JOIN. Существует параметр, который позволяет управлять тем, что считается «маленькой таблицей» в данном случае, но он задаётся сразу на весь кластер.
С вертикой в то время не удалось связаться и организовать полноценный PoC. Похоже, просто были какие-то административные проблемы внутри HP. Но сейчас у них уже всё хорошо с этим.
В поисках принципиальных отличий Exasol от Vertica, на последнем Highload++ поговорил с представителями HP и с коллегами из Avito. Узнал следующее:
1). Vertica всегда читает диск, даже если анализ идёт по «горячим» данным.
2). Vertica не так эффективно использует большие объёмы памяти. Если я правильно понял ребят из HP, объём памяти на типичной ноде для вертики не превышает 200-300Гб.
3). В Vertica необходимо строить проекции для того, чтобы делать эффективные локальные join'ы. На больших объёмах нельзя просто придти и начать join'ить какие-то совершенно случайные колонки. В Exasol'е — можно. Индексы построятся сами после первого SELECT'а.
В целом, исхожу из того, что память быстрее, чем диски. Она становится всё дешевле, её становится всё больше. И чем лучше СУБД работает с памятью, тем лучше для пользователей.
Но Вертика тоже отличный продукт. Ничего против неё не имею.
Есть данные, которые загружаются каждые 15 минут. При этом для ETL используем целиком собственное программное решение, которое позволяет дробить загрузку как угодно. Можно хоть раз в минуту загружать, только практического смысла мало.
Глобально по realtime аналитике задавал вопрос их основателю. Ответ был буквально следующий: «Последние блоки колонок не сжаты, можно часто импортировать по чуть-чуть рядов, существенного оверхеда на это нет».
На самом деле, даже это не подходит. Exasol в большинстве случаев работает со сжатыми данными, не разжимая их и не получая оригинальные значения в процессе выполнения. Это означает, что колонка, в которой всего 5-10 вариантов значений, сожмётся в разы лучше, чем колонка, в которой десятки тысяч вариантов. При этом формально количество «ячеек» будет одинаковым.
Вопрос оценки сложности выполнения запроса в аналитической базе достоин отдельной большой статьи. Я так троллил других вендоров во время PoC, когда специально писал генератор с очень неудобной селективностью на VARCHAR, а потом спрашивал: «А почему так медленно?» :)
Мне всё же кажется, что это не хеш. По крайней мере, не классический хеш, как в row-based базах данных.
Сужу по тому признаку, что JOIN по уже существующему индексу ест очень мало памяти. Никакая хеш таблица в такой объём не влезла бы. Также Exasol без проблем делает streaming частично завершённого JOIN'а в какой-нибудь дальнейший GROUP BY. Как это было бы возможно без предварительной сортировки данных — не очень представляю. Больше склоняюсь к какому-то очень хитрому распределённому Merge Join, но это всё чистой воды теория.
Есть одна интересная статья по поводу индексов в аналитике:
www.vldb.org/pvldb/vol7/p97-schuhknecht.pdf
В ней упоминаются волшебные вещи: ART-tree, AVL-tree, CSB-tree, FAST.
Похоже, мир академических деревьев намного обширнее, чем мы могли бы представить с юзерской точки зрения. :)
На самом деле, всё немного сложнее. Exasol представляет собой объединение нескольких сервисов. Например, ExaSolution управляет SQL запросами и предоставляет интерфейс для юзеров. ExaStorage управляет хранением данных, дисками, кешами. ExaOperation осуществляет общение нод друг с другом, управляет лицензиями. Есть сервис для логирования, для синхронизации времени, и т.д.
В некоторых очень редких случаях возможно такое, что один из сервисов начинает глючить, теряет кворум, пишет warning'и какие-нибудь. Но это всё либо само восстанавливается, либо быстро патчится. С какими-то серьёзными проблемами пока не сталкивались, данные не теряли.
Отличный вопрос. К сожалению, сейчас нет известной мне возможности узнать, что конкретно лежит в кеше, какие таблицы и блоки. Приходится судить постфактум по профайлингу на реальных запросах. В системных вьюшках записывается, сколько данных было реально прочитано с диска.
Судя по этим данным, в Badoo ETL процесс практически не вытесняет кеш.
Вероятно, это связано с двумя самыми популярными стратегиями загрузки данных:
В итоге, в кеше оказываются маленькие таблицы целиком и самые новые данные для больших таблиц. А это именно то, над чем аналитики чаще всего проводят анализ.
Да, Exasol сохраняет много различной статистики. Он делает скрытый профайлинг всех запросов и хранит очень подробную информацию за последние 24 часа. Буквально хранится каждая стадия выполнения запроса на каждой отдельно взятой ноде. Время от времени он делает агрегацию и сохраняет обобщённую информацию за день, неделю, месяц.
Собственно, я посмотрел среднее количество ROWS за день для всех типов SCAN в рамках одного запроса.
Другое дело, что, в случае с колоночными базами, понятие «ряды» очень-очень растяжимое.
Например, следующие запросы могут отличаться по сложности в сто-двести раз, но при этом формально сканировать одно и то же количество «рядов».
Не совсем. Индексы персистентные. Они сохраняются и после полного рестарта базы.
Юзер ощущает построение индексов только в тот момент, когда он в самый первый раз пытается сделать JOIN по таким колонкам, которые за последний месяц ни разу не использовались для JOIN'а. После этого индекс поддерживается автоматически во время ETL-процесса (IMPORT, INSERT, UPDATE, DELETE, MERGE), и юзер этого процесса не видит.
Что это за волшебные индексы — великий вопрос. Я много раз задавал его самым разным людям внутри Exasol и даже лично беседовал с их автором: Falko Mattasch. No luck! Подробностей они не рассказывают и очень тщательно охраняют этот секрет.
В физическом плане разработчик может только указать DISTRIBUTE BY для больших таблиц. Можно делать distribute по нескольким колонкам, но тогда они все вместе должны участвовать в JOIN'е.
Если DISTRIBUTE BY явно не указан, то ряды случайно раскидываются по нодам таким образом, чтобы везде было поровну. Если баланс в силу каких-то причин нарушается, то в профилировщике можно увидеть фазу REDISTRIBUTE, которая его восстанавливает.
Особо маленькие таблицы дополнительно полностью загружаются в память каждой ноды для того, чтобы всегда делать к ним локальный JOIN. Существует параметр, который позволяет управлять тем, что считается «маленькой таблицей» в данном случае, но он задаётся сразу на весь кластер.
В поисках принципиальных отличий Exasol от Vertica, на последнем Highload++ поговорил с представителями HP и с коллегами из Avito. Узнал следующее:
1). Vertica всегда читает диск, даже если анализ идёт по «горячим» данным.
2). Vertica не так эффективно использует большие объёмы памяти. Если я правильно понял ребят из HP, объём памяти на типичной ноде для вертики не превышает 200-300Гб.
3). В Vertica необходимо строить проекции для того, чтобы делать эффективные локальные join'ы. На больших объёмах нельзя просто придти и начать join'ить какие-то совершенно случайные колонки. В Exasol'е — можно. Индексы построятся сами после первого SELECT'а.
В целом, исхожу из того, что память быстрее, чем диски. Она становится всё дешевле, её становится всё больше. И чем лучше СУБД работает с памятью, тем лучше для пользователей.
Но Вертика тоже отличный продукт. Ничего против неё не имею.