Pull to refresh
0
Badoo
Big Dating

Exasol: опыт использования в Badoo

Reading time 10 min
Views 17K
Exasol — это современная высокопроизводительная проприетарная СУБД для аналитики. Ее прямые конкуренты: HP Vertica, Teradata, Redshift, BigQuery. Они широко освещены в Рунете и на Хабре, в то время как про Exasol на русском языке нет почти ни слова. Нам бы хотелось исправить эту ситуацию и поделиться опытом практического использования СУБД в компании Badoo.

Exasol базируется на трех основных концепциях:

1. Массивно-параллельная архитектура (англ. massive parallel processing, MPP)


SQL-запросы выполняются параллельно на всех нодах, максимально используя все доступные ресурсы: ядра процессоров, память, диски, сеть. Понятие «мастер ноды» отсутствует — все серверы в системе равнозначны.

Отдельные стадии выполнения одного запроса также могут идти параллельно. При этом частично рассчитанные результаты передаются в следующую стадию, не дожидаясь окончания предыдущей.

2. Колоночное хранение (англ. columnar store)


Exasol хранит данные в колоночной форме, а не в форме отдельных рядов, как в классических СУБД. Каждая колонка хранится отдельно, разделяется на большие блоки, сортирируется, сжимается и равномерно распределяется по всем нодам.


Эффективность сжатия сильно варьируется в зависимости от типов данных и распределения значений в таблицах. В среднем данные в Badoo сжаты в 6,76 раз.

Колоночное хранение позволяет многократно ускорять аналитические запросы, а также вычитывать только те данные, которые необходимы для выполнения запроса. В классических СУБД необходимо прочитать весь ряд целиком, даже если в нем используется всего одна колонка.

3. In-memory analytics


В Exasol есть механизм, похожий на buffer pool в MySQL или shared buffer в PostgreSQL. Блоки данных, однажды загруженные с диска, остаются в памяти и могут быть повторно использованы для последующих запросов.

Как правило, в реальной жизни пользователи работают в первую очередь с «горячими» данными (последний день, неделя, месяц). Если у кластера достаточно памяти, чтобы вместить их целиком, то Exasol не будет трогать диск вообще.

Эти три концепции, собранные вместе в одной СУБД, показывают высокую производительность относительно сложности SQL-запросов и используемого «железа». Приведем конкретные цифры.

Сейчас в кластере Badoo используется 8 серверов со следующими характеристиками:
  • от 16 до 20 CPU Cores;
  • 768 Гбайт RAM;
  • 16x1 Тбайт HDD (RAID 1 — 8 Тбайт);
  • 10 Гбит сеть.

Общий объем памяти, доступной Exasol, составляет приблизительно 5,6 Тбайт.
Общий объем данных без сжатия — около 85 Тбайт.

Размеры крупных таблиц варьируются от 500 миллионов до 50 миллиардов рядов. Один аналитический запрос обрабатывает в среднем около 4,5 миллиардов рядов.

Производительность на реальных запросах за последний месяц:
Кол-во объектов в запросе Все запросы Запросы длительностью от 1 секунды
Кол-во Медиана Среднее Кол-во Медиана Среднее
До 3 240914 0.021 сек 9 сек 34808 29 сек 63 сек
От 4 до 10 45122 13 сек 47 сек 30005 34 сек 70 сек
От 11 до 30 12642 24 сек 69 сек 5615 45 сек 156 сек
От 31 и больше 740 41 сек 303 сек 740 41 сек 303 сек

Это не синтетический тест, а реальная статистика по настоящим запросам живых пользователей. Как можно увидеть, даже в самых сложных случаях, речь чаще всего идет о секундах и минутах, но никак не о часах или днях.

Сложность запроса в этом примере условно рассчитывается путем простого поиска слов FROM и JOIN в тексте SQL. Таким образом, мы находим примерное количество использованных объектов. Чем больше объектов используется, тем сложнее запрос.

Выделение в отдельную группу запросов длительностью от 1 секунды необходимо для того, чтобы снизить влияние слишком быстрых in-memory запросов на результат и показать наиболее близкую к реальности картину для тех случаев, когда все же нужно что-то прочитать с диска.

За счет чего достигается высокая производительность, помимо перечисленных выше концепций.

Джойны (англ. join) и индексы


Exasol умеет делать очень быстрые джойны, причем совершенно не смущается от их количества.

Эффективный джойн всегда происходит по индексу. Индексы создаются автоматически в тот момент, когда вы впервые пытаетесь объединить две таблицы по определенным ключам. Если индекс не используется долгое время, то он так же автоматически удаляется.

При добавлении или удалении данных в таблицах с уже существующими индексами создаются «дельты», которые содержат только изменения. Если изменений накапливается слишком много (около 20% от общего объема), то происходит INDEX MERGE, который объединяет основной индекс с дельтой, после чего дельта удаляется. Это намного быстрее, чем полное пересоздание индекса с нуля. Механизм чем-то похож на Sphinx.

Индексы занимают относительно небольшой объем памяти. Подавляющее большинство индексов в нашей базе занимает меньше 100 Гбайт, в том числе это справедливо для многомиллиардных таблиц. Размер индекса определяется количеством входящих в него колонок, их типами данных и вариабельностью значений.

Глобальные джойны vs локальные джойны


Джойны бывают глобальные и локальные. Глобальный джойн происходит в тех случаях, когда объединяемые данные физически хранятся на разных нодах.


Локальный джойн происходит тогда, когда объединяемые данные хранятся на одной ноде.


Локальные джойны намного быстрее глобальных, потому что в этом случае не используется сеть. Такого эффекта можно добиться, если заранее распределить данные на нодах особым образом. В нашем примере это можно сделать так:
ALTER TABLE CUSTOMER DISTRIBUTE BY CITY_ID;
ALTER TABLE CITIES DISTRIBUTE BY ID;

При этом гарантируется, что для обеих таблиц ряды с одинаковыми значениями city_id будут всегда физически находиться вместе на одной ноде.

Также маленькие таблицы автоматически реплицируются (копируются целиком) на все ноды, что автоматически гарантирует быстрые локальные джойны к ним. Это особенно актуально для многочисленных небольших списков.

Главное отличие Exasol от других распределенных СУБД состоит в том, что вам не придется бояться глобальных джойнов и нет нужды создавать специальные проекции, чтобы их избежать. Безусловно, глобальные джойны медленнее локальных, но не настолько, чтобы это создавало проблемы. Подавляющее большинство джойнов в Badoo именно глобальные.

Условия эффективного джойна


Для того чтобы джойн происходил по наиболее эффективному сценарию, необходимо соблюдать ряд простых правил:

1. Условия должны быть только в формате columnA = columnB.

Хорошо:
JOIN table2 b ON (a.id=b.id)

Плохо:
JOIN table2 b ON (a.purchase_date > b.create_date)

2. Нежелательно использовать выражения.

Хорошо:
JOIN table2 b ON (a.purchase_date=b.purchase_date)

Плохо:
JOIN table2 b ON (a.purchase_date=TO_DATE(b.purchase_time))

3. Несколько условий можно объединять при помощи AND, но следует избегать OR.

Хорошо:
JOIN table2 b ON (a.id=b.id AND a.name=b.name)

Плохо:
JOIN table2 b ON (a.id=b.id OR a.name=b.name)

4. Типы данных колонок должны совпадать. DECIMAL к DECIMAL, VARCHAR к VARCHAR, DATE к DATE и так далее.

Если хотя бы одно из условий не выполняется, то происходит следующее:
  • либо индекс все равно будет создан, но после выполнения запроса сразу же удален (так называемый Expression Index);
  • либо Exasol будет делать джойн «всего ко всему», а затем фильтрацию. Последнее не так уж страшно, пока у вас не получается несколько триллионов рядов в промежуточном результате. Миллиарды — вполне возможно.


Root filter


Понятие «Root filter» вносит существенный вклад в высокую производительность Exasol. Его нельзя найти в официальной документации, но можно увидеть в секретных системных «вьюшках» и планах выполнения запросов.

Как работает фильтр?

Если в запросе есть достаточно селективное условие WHERE с константами, то Exasol будет читать только те блоки данных, которые подходят под указанное условие. Все остальные блоки он читать не будет.

В этих примерах фильтр будет использоваться:
WHERE registration_date BETWEEN '2015-01-01' AND '2015-10-01'
WHERE foo >= 115
WHERE product_type IN ('book','car','doll')

А в этих примерах фильтр использоваться не будет:
WHERE registration_date BETWEEN CURRENT_DATE – INTERVAL '1' YEAR AND CURRENT_DATE
WHERE foo > (15 + 17)
WHERE email REGEXP_LIKE '(?i)@mail\.ru$'

Если Exasol может заранее очертить четкие и простые границы того, какие именно данные ему нужно прочитать, то он воспользуется такой возможностью и в десятки или сотни раз снизит количество операций чтения. Чем меньше чтений и чем меньше размер промежуточных результатов, тем быстрее все работает. При этом никакие специальные индексы не нужны — используется только статистика на базе колоночной структуры хранения данных.

Возможности и особенности SQL


Exasol полностью поддерживает базовый ANSI SQL. Это включает в себя GROUP BY, HAVING, ORDER BY, LIMIT, OFFSET, MERGE, FULL JOIN, DISTINCT и т.д. — словом, все, что мы привыкли видеть.

С точки зрения аналитического SQL, предлагается следующее:
  1. Window-функции, ROW_NUMBER, медианы, ранги, перцентили на любой вкус;
  2. Common Table Expressions;
  3. CUBE, ROLLUP, GROUPING SETS;
  4. GROUP_CONCAT;
  5. регулярные выражения PCRE, включая поиск, захват паттернов и их замену;
  6. функции для работы с датами и таймзонами;
  7. Geospatial-функции.

Нам показалось интересным то, что Exasol воспринимает пустую строку как NULL. Это никак нельзя отключить. Судя по всему, преобразование происходит где-то на очень глубоких уровнях, но серьезных проблем это не создает. Просто нужно об этом помнить при импорте.

Exasol жестко валидирует типы данных. Никаких автоматических приведений типов, неявных обрезаний слишком длинных строк, округлений и т.п. не происходит. В таких случаях вы всегда увидите ошибку, и это хорошо.

Транзакции


Exasol — транзакционная СУБД, full ACID compliant. Уровень изоляции — serializable. На практике в текущей реализации это означает, что в таблицу параллельно может писать только один писатель. Читателей может быть сколько угодно, и они не блокируются писателем. «Параллельные писатели» будут выполняться последовательно друг за другом, либо, в случае конфликтов и дедлоков, произойдет ROLLBACK.

DDL-запросы также транзакционны. Это означает, что вы можете создавать новые таблицы, вьюшки, добавлять колонки и т.д. — все это может происходить в одной транзакции. При необходимости можно легко сделать ROLLBACK и вернуть все как было.

Из-за колоночной структуры хранения, добавление и удаление колонок происходит практически моментально. Никаких простоев из-за долгих «альтеров» при изменении схемы таблиц на практике нет.

Импорт данных


Наиболее эффективно импортировать данные в Exasol при помощи встроенной утилиты exajload. Она максимально использует возможности управления потоками и параллельного подключения сразу к нескольким нодам.

Разрешается передавать сжатый поток данных без предварительной декомпрессии, что заметно снижает нагрузку на сеть. Поддерживаемые форматы: gz, zip, bz2.

Для аналитических СУБД актуален вопрос эффективной загрузки данных из Hadoop. Exasol позволяет напрямую загружать файлы в несколько потоков при помощи WebHDFS, минуя промежуточные серверы и снижая общий overhead.

Благодаря транзакционности можно также загружать данные напрямую в production-таблицу, целиком минуя staging. Если загрузка прервется (по любой причине), то произойдет ROLLBACK, и у вас останется старая копия таблицы. Если загрузка успешно завершится, то новые данные заменят старые.

Как и во многих других аналитических СУБД, в Exasol намного эффективнее подход ELT (Extract — Load — Transform), нежели классический ETL (Extract — Transform — Load). Лучше загружать «сырые» данные в промежуточную таблицу, а затем трансформировать их средствами самой СУБД, при этом используя все достоинства Massive Parallel Processing.

Кратко о поддержке


1. В Exasol в настоящий момент нет продвинутой поддержки серверов с разной конфигурацией в рамках одного кластера. Все ноды получают одинаковый объем данных и одинаковый объем вычислительных задач. Весь кластер будет работать со скоростью самой слабой ноды. Поэтому лучше в самом начале поставить 2-4 мощных сервера, чем 10 слабеньких. Расширяться потом вам будет значительно проще.

2. Добавление новой ноды занимает несколько минут. После этого Exasol можно сразу поднимать и пускать пользователей, не дожидаясь окончательного перераспределения данных на дисках. При этом все будет работать чуть медленнее из-за дополнительных сетевых операций, но по мере увеличения количества нод разница становится менее заметной. Процессом реорганизации данных можно управлять вручную, запуская команду REORGANIZE для конкретных схем или таблиц. Таким образом, можно реорганизовать более важные таблицы раньше, чем все остальные.

3. Fault tolerance. В своей практике мы сталкивались с несколькими аварийными сценариями. Например, заканчивалось свободное место, или кто-то случайно физически отключал часть работающих серверов от сети. Никаких существенных проблем с этим мы не заметили. База заранее пишет о проблеме, останавливается и ждет исправления ситуации. В ряде случаев происходит автоматический рестарт, если проблема исчезла. При этом если не заглядывать в логи, можно и не узнать, что вообще что-то происходило.

Exasol способен пережить полную потерю некоторого количества нод без остановки работы. Существует особый параметр «redundancy», который определяет, на сколько нод будет физически сохраняться каждый блок данных. Чем выше значение этого параметра, тем больше нод можно потерять. Но за это ожидаемо приходится платить местом на дисках.

4. SSD диски для Exasol не играют большой роли. Блоки данных очень большие, они читаются и записываются крупными партиями друг за другом. Random disk access практически отсутствует. Вместо SSD лучше поставить больше памяти.

Цены


К сожалению, Exasol — это не open source software. Необходимо оплачивать лицензию. Фиксированных цен нет — с каждым партнером компания договаривается индивидуально. Скорее всего, стоимость будет зависеть от объема используемой оперативной памяти, что типично для СУБД, позиционирующих себя как in-memory.

Также у Exasol есть бесплатный trial. Он представляет собой версию, которая работает только на одной ноде и использует до 10 Гбайт оперативной памяти. Этого достаточно для devel-окружения и для того, чтобы проверить ваши запросы на небольшой части данных и составить общее впечатление.

Кроме того, Exasol запустил специальную программу для стартапов, по которой предлагается 500 Гбайт данных в облаке за 500 евро в месяц. При этом не нужно покупать дорогостоящее железо. К сожалению, мы не можем оценить преимущества их облака, т.к. мы с ним не работали.

Физически компания Exasol находится в городе Нюрнберге (Германия). Можно приехать к ним в гости, пройти обучающие курсы, поговорить с разработчиками.

Заключение


В целом Exasol стал для нас реальным открытием. Вы просто загружаете данные и можете сразу их анализировать на высокой скорости. It just works.

При этом нет никакой возни с индексами, представлениями, какими-то ручными оптимизациями. Можно связать между собой данные из абсолютно разных источников, а не только те, которые заранее были для этого предназначены. Любые джойны к вашим услугам.

Фактически вы ограничены только способностью сформулировать свою задачу в форме SQL-запроса. Если для каких-то особых случаев возможностей SQL окажется недостаточно, то Exasol позволяет создавать custom-функции на Python, LUA, Java, R. При этом сохраняются все плюсы колоночного хранения, общей параллельности всех операций и эффективного использования памяти.

Если вам интересны любые другие аспекты работы с Exasol, а также организация эффективного ETL-процесса — пишите в комментариях, я с удовольствием вам отвечу.

Спасибо за внимание!

Полезные ссылки


  1. Exasol website
  2. User Manual (ver 5.0.11)
  3. Technical Whitepaper — объяснения про Massive Parallel Processing
  4. Free trial
  5. Solution center — в основном полезные видео и ответы на частые вопросы
Tags:
Hubs:
+27
Comments 24
Comments Comments 24

Articles

Information

Website
badoo.com
Registered
Founded
2006
Employees
501–1,000 employees
Location
Россия
Representative
Yuliya Telezhkina