Автор: Curt Monash
Дата публикации оригинала: 2008-08-16
Перевод: Олег Кузьменко
Источник: Блог Курта Монаша

После моего представления Exasol нетехнического характера у меня на это ушло 5 ½ месяцев, но, наконец, я получил информацию от технических специалистов Exasol (в частности, самую полезную помощь оказали Матиас Голомбек (Mathias Golombek) и Карстен Вейдманн (Carsten Weidmann)). Вот некоторые основные моменты:

  • Как Vertica и ParAccel, Exasol разрабатывает колоночную СУБД, предназначенную для хранилищ данных и имеющую архитектуру MPP без разделения ресурсов.

  • В концепции, которой придерживается Exasol, нет места т.н. узлам-«начальникам» или узлам-«хозяевам», на которых работает программное обеспечение, отличающееся от того, что установлено на других узлах. Вместо этого, все узлы равны между собой. Например, приложение, обращающееся к системе, может получить IP адрес любого узла; этот узел затем разбирает SQL-запрос и распределяет работу по другим узлам.

  • Exasol удовлетворяет критериям ACID, помещая блоки на диск в случае операции update. И, конечно, к данным, находящимся на диске, можно слать запросы…

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

  • Exasol применяет компрессию, типичную для колоночной СУБД – интенсивное использование сжатия с использованием словаря и токенов, а также других, неуказанных алгоритмов сжатия; хранение данных сжатыми в памяти и т.д.

  • Как и другие поставщики решений для хранилищ данных на базе архитектуры MPP, Exasol распределяет данные между узлами при помощи хэш-ключа. Это - самый наиболее часто встречающийся метод в индустрии, потому что благодаря ему получается случайное/равномерное распределение по узлам, что хорошо с точки зрения параллелизма. Вдобавок, у вас облегчается жизнь в плане производительности при выполнении некоторых трудных хэш-объединений (hash joins).

  • Как и Vertica, Exasol реплицирует небольшие таблицы (например, таблицы измерений) на каждый узел.

  • Оптимизатор Exasol автоматически, на лету создает и поддерживает индексы объединения (join indexes). Exasol не согласился со мной, когда я сказал “О, как материализованные представления?” Но я подозреваю, что это тот тип индекса объединения, который, как неофициально говорит Teradata, является специальным случаем материализованного представления, и который, как публично заявляет Teradata, очень похож на материализованное представление.

  • В целом, Exasol описывает свой оптимизатор, как «очень ориентированный на архитектуру MPP».

  • Exasol написал код своей СУБД, главным образом, с «чистого листа». Сейчас, кажется, у них есть что-то вроде распределенной операционной системы, называемой EXACluster, которая работает поверх Linux, но есть такое ощущение, что они заменяют фундамент, на котором построен Linux, чем-то своим. Например, доступом к диску занимается EXACluster.

  • EXACluster уже командует отказоустойчивостью/переключением нагрузки между узлами.

  • Exasol реплицирует данные между узлами для того, чтобы предусмотреть возможность переключения между ними. Это похоже на то, что делает Vertica. Также, если вы добавите узлов и перезапустите Exasol, то данные будут автоматически перераспределены.

  • Самая большая работающая система, о которой упомянул Exasol, имеет 3 терабайта пользовательских данных. Она насчитывает 5 узлов с 32 гигабайтами памяти на каждом.

  • Для любого фиксированного общего объема памяти, который готов получить пользователь, Exasol рекомендует больше узлов с меньшим объемом памяти на узел. Я не спросил почему.

  • СУБД Exasol не поддерживает хранимые процедуры. Они утверждают, что хранимые процедуры были бы главным образом полезны для ELT/ETL, и что их альтернативы работают вполне хорошо.

  • Как и большинство компаний, специализирующихся в области хранилищ данных, Exasol рекомендует подход ELT (Extract/Load/Transform) вместо ETL (Extract/Transform/Load).

  • СУБД Exasol поддерживает функции, определенные пользователем (UDFs).

  • Exasol работает над поддержкой типа данных BLOB. Геопространственные данные также в планах компании, но похоже на то, что активного проекта по поддержке геопространственных данных пока не ведется.

Мы также поговорили о возможности одновременной работы многих пользователей, но это всегда запутанный вопрос. Exasol сказал, что на сегодняшний момент не может быть больше, чем 50 одновременных «входов» (log-ins) в систему – число, которое они приравнивают к 1000 именованных пользователей (потому что запросы выполняются так быстро). Они также говорят, что они проводили внутреннее тестирование системы, которая обрабатывала до 400 одновременных запросов. Я не стал спрашивать о том, что они сделали бы для того, чтобы сбалансировать быстро и долго выполняющиеся запросы, отчасти потому, что Exasol создает впечатление, что на их системах все запросы выполняются быстро. Очевидно, что все это довольно неясно и туманно.

По схожему вопросу Exasol говорит, что общая пропускная способность выше в том случае, когда, по крайней мере, имеется определенное число одновременных пользователей. В качестве доказательства были предложены, подумать только, результаты теста TPC-H. Вероятно (сам я этого не проверял), Exasol (и также ParAccel, у которой, несомненно, схожая архитектура) решили выполнить тесты с большим, чем минимально необходимо, числом одновременных пользователей. SMP-cистемы, полагает Exasol, ведут себя по-другому.

Наконец, пара моментов менее технического характера:

  • Лицензирование: по числу гигабайтов оперативной памяти. (Такая схема подходит для систем, ориентированных на размещение данных в памяти.) Система с 100 Гбайт памяти стоит 120 тыс. евро по прайс-листу (Exasol – немецкая компания - прим. переводчика). Не существует линейной зависимости между ценой и объемом памяти.

  • Партнер, чье имя было удалено из февральского поста о Exasol, теперь обнародован официально. Exasol в Японии сотрудничает с сервисным подразделением Hitachi. Exasol говорит, что у Hitachi есть 15-20 человек, которые работают над тем, как вывести Exasol на японский рынок. Потенциальные клиенты – необязательно клиентский контингент Hitachi.

Ссылки на статьи Курта по следующим категориям (на английском языке):
Analytic technologies, Columnar database management, Data warehousing, Exasol, In-memory DBMS, Memory-centric data management


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: