LucidDB

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 14:51, 1 марта 2019.
LucidDB
Lucid.png
Разработчики: Eigenbase Foundation
Выпущена: 2004; 16 years ago (2004)
Постоянный выпуск: 0.9.4 / 5 January 2012 года; 8 years ago (2012-01-05)
Состояние разработки: Разработка прекращена
Написана на: Java, C++
Операционная система: Кросс-платформенное
Локализация: English
Тип ПО: Реляционная база данных, Бизнес аналитика, Хранилище данных
Лицензия: GPL 2
Веб-сайт LucidDB

LucidDB — первая и единственная Open-Source реляционная СУБД с основой на колоночной структуре, ориентированная на OLAP серверы и системы бизнес-логики. LucidDB базируется на принципах хранения столбцов, индексировании Bitmap, агрегировании/добавлении хэша и многовариантности на уровне страниц. В отличие от других баз данных, каждый компонент LucidDB был спроектирован с целью увеличения гибкости и производительности. Более того, для работы LucidDB не требуется администратор базы данных.

Архитектура

Рисунок 1 - Архитектура LucidDB

На рисунке 1 показана архитектура LucidDB. Ядро состоит из двух частей. Первая часть реализована на Java, а вторая на C++. Этот гибридный подход даёт ряд преимуществ:

  • часть Java обеспечивает простоту разработки, расширяемости и интеграции, а управляемая память уменьшает вероятность использования эксплойтов безопасности;
  • часть C ++ обеспечивает высокую производительность и прямой доступ к ресурсам операционной системы, сети и файловой системы низкого уровня;
  • система времени выполнения Java вычисляет машинно-кодовую оценку выражений SQL посредством комбинации генерации кода Java и компиляции «точно в срок» (как часть выполнения запроса).

Ниже приведены подробные обзоры некоторых из самых инновационных компонентов.

Колоночное хранение данных и индексирование битового массива

Исследования СУБД установили превосходство архитектуры «колоночное хранение данных» для систем баз данных с поддержкой чтения, таких как LucidDB. В LucidDB таблицы базы данных разделяются вертикально и хранятся в сильно сжатой форме. Вертикальное разбиение означает, что каждая страница на диске хранит значения только из одного столбца, а не из целых строк; в результате алгоритмы сжатия работают намного эффективнее, поскольку они могут работать на однородных доменных значений, часто с несколькими отдельными значениями. Например, столбец, в котором хранится компонент состояния адреса США, имеет только 50 возможных значений, поэтому каждое значение может быть сохранено с использованием только 6 бит вместо 2-байтовых символьных строк, используемых в традиционном несжатом представлении. Вертикальное разбиение также означает, что запрос, который обращается только к подмножеству столбцов ссылочных таблиц, может не читать полностью другие столбцы. Чистый эффект вертикального разбиения значительно повышает производительность за счет уменьшения дискового ввода-вывода и более эффективного кэширования (сжатие данных позволяет большому размеру логического набора данных вписываться в заданный объем физической памяти). Сжатие также позволяет более эффективно использовать дисковое хранилище (например, для поддержания большего количества индексов). Сопутствующим устройством для хранения столбцов является индексирование битового массива, которое имеет хорошо известные преимущества для хранилищ данных. В реализации индекса битового массива LucidDB используются функции сохранения столбцов; например, битовые массивы создаются непосредственно из представления сжатой строки и сами хранятся в сжатом состоянии, что значительно сокращает время загрузки. И во время запроса они могут быстро пересекаться, чтобы идентифицировать точную часть таблицы, которая соответствует результатам запроса. Все пути доступа поддерживает асинхронный ввод-вывод с интеллектуальной предварительной выборкой для оптимального использования пропускной способности диска. Следует отметить, что LucidDB не подходит для использования в качестве транзакционной базы данных. LucidDB очень быстро работает при загрузке или обновлении больших объемов данных одновременно, но он не предназначен для работы в однострочных операциях, типичных для транзакционных систем. Лучшей практикой является отделение аналитических систем от транзакционных систем. LucidDB может использоваться как хранилище данных или как хранилище оперативных данных в тандеме с традиционными транзакционными системами, используемыми в качестве источников данных.

Контроль версий страниц

LucidDB в основном подразумевает использование в режиме read-only, операции записи необходимы для загрузки данных в хранилище. Для того, чтобы чтение не прерывалось во время загрузки или обновления данных, используется контроль версий страниц. Данные страницы считываются по снимку, сделанному перед началом инициации транзакции. Когда появляется необходимость обновить страницу, новая версия страницы создается и наследуется от оригинальной страницы. Каждая последующая транзакция записи создает новую версию страницы и добавляет её в уже имеющуюся цепь наследования.

Оптимизация выполнения и запросов

Оптимизатор спроектирован с учетом среды хранения информации, то есть не нужны никакие дополнительные телодвижения, чтобы имплементировать типичные аналитические шаблоны. Оптимизатор использует различные эвристики и анализ вычислительных затрат, чтобы достичь hint-free проектирования. В частности, анализ вычислительных затрат позволяет определить оптимальную очередь для выполнения запросов.

Обработчик запросов включает в себя высокопроизводительный сортировщик, компоновщик и агрегатор хэшей. Все эти механизмы спроектированы для наиболее эффективного использования памяти. Встроенный обработчик выделяет память, с учетом объёма доступной и потребностями различных операций.[Источник 1]

Особенности

В таблице приведены основные функции, которые есть в LucidDB[Источник 2].

Категория Особенность Описание
Хранение Колоночное хранение таблицы Очень высокая скорость сжатия данных для столбцов с многократными значениями; сокращение ввода-вывода для запросов, которые имеют доступ только к подмножеству столбцов; большая эффективность кэширования;
Умная индексация Автоматически адаптируется к представлению Bitmap или B-tree в зависимости от распределения данных (даже с использованием обоих параметров в одном и том же индексе для разных частей одной и той же таблицы), что дает оптимальное сжатие данных и сокращение ввода-вывода;
Параллелизм Поддерживает параллелизм чтения и записи, позволяя читателям получать доступ к таблице во время загрузки или обновления данных;
Лэйблы хранилищ Позволяет сообщать глобальное состояние базы данных;
Быстрый+последовательный бэкап Обеспечивает постоянное резервное копирование системы во время работы с запросами; инкрементные и сжатые параметры минимизируют архивное хранение и пропускную способность;
Оптимизация Star join optimization Технология Star Join Query позволяет улучшить производительность путем уменьшения времени выполнения запроса, т.е. оптимизатор динамически применяет «маски» фильтров в параллельных планах запросов;
Индексация, упорядочивание и присоединение на основе вычислительной сложности Название преимущества говорит само за себя;
Выполнение Агрегация хэшей Может масштабировать до числа, чтобы даже самые большие наборы данных в ограниченной ОЗУ сжимались с помощью косово-устойчивого дискового разбиения;
Умная предвыборка Высокая производительность и большая эффективность кеша и диска, поскольку LucidDB почти всегда может точно предсказать, какие блоки диска необходимы для удовлетворения запроса;
Связь SQL/MED архитектура Позволяет LucidDB подключаться к разнородным внешним источникам данных через адаптеры внешних данных и получать доступ к их содержимому в качестве внешней таблицы;
JDBC обработчик Позволяет запрашивать другие таблицы в любом источнике данных JDBC через LucidDB, при этом фильтры попадают туда, где это возможно;
Flat file обработчик Позволяет обрабатывать неструктурированные файлы (например, BCP или CSV-формат), как внешние таблицы через LucidDB;
Расширяемость SQL/JRT архитектура Позволяет разрабатывать новые функции и преобразования на Java и подключаться к запущенному экземпляру LucidDB;
User-defined функции Позволяет расширить набор встроенных функций по желанию пользователя;
User-defined трансформации Позволяет добавлять в систему новые функции таблицы;
Стандарты SQL:2003 Сглаживание миграции приложений в другие продукты СУБД и обратно;
JDBC, HTTP Позволяет подключаться к популярным интерфейсам, таким как движок Mondrian OLAP;
UNICODE Поддержка хранения и доступа к международным символьным данным;
J2EE Java-архитектура позволяет развертывать LucidDB на сервере приложений J2EE (точно так же, как hsqldb или Derby); использование Java в качестве основного механизма расширяемости делает его доступным для интеграции со многими доступными API-интерфейсом предприятия;

Сравнение производительности специализированных БД InfoBright, InfiniDB и LucidDB с использованием Star Schema Bechmark

Для сравнения производительности InfoBright, InfiniDB и LucidDB - специализированных БД на базе MySQL для организации обработки больших массивов данных (Data Warehouse) использовался тестовый набор Star Schema Bechmark (SSBM). SSBM – это тестовый набор хранилищ данных, в котором используется классическая звездообразная схема, пример которой показан на рисунке 2.

Рисунок 2 - Звездообразная схема базы данных SSBM

В процессе тестирования в каждую БД было загружено 610 Гб данных. Наилучшие показатели продемонстрировало MySQL-хранилище InfiniDB, причем превосходство во всех тестах было значительное.[Источник 3]

Итоги:

  • Время загрузки данных: InfiniDB: 24 010 сек., InfoBright: 51 779 сек., LucidDB: 140 736 сек (без создания индексов);
  • Итоговый объем базы на диске: InfoBright: 112 Гб, LucidDB: 120 Гб (без индексов), InfiniDB: 626 Гб;
  • InfiniDB отлично справляется с использованием доступных чипов ЦП с полной пропускной способностью ввода-вывода с диска;
  • SSBM может быть не очень хорош для InfoBright, синтетический характер теста не позволяет InfoBright показывать лучшие результаты;

Производительность выборки данных показана на рисунке 3:

Рисунок 3 - Производительность выборки данных

Установка и запуск

В представленном ниже видеоролике представлен процесс установки и запуска LucidDB.

Далее будет описан пример извлечения данных базы данных foodmart из базы данных MySQL и импортирования их в LucidDB. Для начала нужно в конец файла "luciddb-0.9.4\bin\classpath.gen" добавить запись, указывающую на файл jar MySQL JDBC. Затем сохранить этот файл и перезапустить сервер. После этого перезапускается сервер и связывается с базой данных MySQL:

CREATE SERVER foodmart_link
 FOREIGN DATA WRAPPER sys_jdbc
 OPTIONS (
 driver_class 'com.mysql.jdbc.Driver',
 url 'jdbc:mysql://localhost/foodmart?useCursorFetch=true',
 user_name 'root',
 password 'fdr6v5',
 login_timeout '10',
 fetch_size '1000',
 validation_query 'select 1',
 table_types 'TABLE',
 schema_name 'TESTING');
create schema foodmart_extract;
import foreign schema foodmart
 from server foodmart_link
 into foodmart_extract;

После того, как был выполнен этот запрос, запускаем следующее:

select table_name, column_name
 from sys_root.dba_columns
 where schema_name='FOODMART_EXTRACT'
 order by table_name,ordinal_position;

После этого будет видно, что импорт был успешен и можно будет видеть таблицы и столбцы из БД MySQL в LucidDB. Нужно иметь ввиду, что в этот момент времени данные по-прежнему находятся в БД MySQL. Затем создадим схему для данных. Чтобы сделать это, запустим следующий запрос:

create schema foodmart;
create user "foodmart" identified by 'foodmart' default schema foodmart;
grant execute on specific procedure applib.estimate_statistics_for_schema_no_samplingrate to "foodmart";
grant execute on specific procedure applib.CREATE_TABLE_AS to "foodmart";
CALL APPLIB.GRANT_SELECT_FOR_SCHEMA( 'FOODMART_EXTRACT', 'foodmart1' );
GRANT SELECT ON "SYS_ROOT"."DBA_COLUMNS" TO "foodmart";
GRANT SELECT ON "SYS_ROOT"."DBA_TABLES" TO "foodmart";

Первые две строки достаточно очевидны и создают схему под названием foodmart, а затем создает пользователя под названием foodmart с паролем foodmart и устанавливает для пользователей схему по умолчанию. Следующие 4 строки говорят LucidDB, что пользователь может оценить статистические данные для оптимизации базы данных, позволяют создать таблицу из исходной таблицы и увидеть несколько системных таблиц. Таким образом, теперь есть новая схема, новый пользователь, удаленная база данных, подключенная к серверу LucidDB, теперь самое время получить импортированные данные. Есть несколько способов сделать это. LucidDB использует ETL-процессы, импортируя данные позволяет преобразовывать данные, прежде чем они попадут в таблицу LucidDB. Поскольку используем foodmart, и он уже в том формате, который нужен, будем импортировать его с помощью вызова applib, который сделает всё проще. Сначала войдём в систему как новый пользователь. Для этого запустим клиент sqllineClient, который поставляется вместе с LucidDB и находится в папке "luciddb-0.9.4\bin\".

luciddb-0.9.4\bin\sqllineClient.bat -n foodmart -p foodmart

Затем сделаем запрос:

set schema foodmart_extract
CALL APPLIB.CREATE_TABLE_AS('FOODMART', 'account1', 'select * from "account"', true);

CREATE_TABLE_AS смотрит на таблицу в MySQL и создает прямую реплику в LucidDB, а true означает, что будет одновременное извлечение и вставка данных в LucidDB.


Источники

  1. Архитектура LucidDB // LucidDB [2007-2019] Дата обновления: 24.10.2009. URL: http://luciddb.sourceforge.net/arch.html (дата обращения: 11.11.2018)
  2. Особенности LucidDB // LucidDB [2007-2019] Дата обновления: 17.06.2010. URL: http://luciddb.sourceforge.net/features.html (дата обращения: 11.11.2018)
  3. Сравнение производительности специализированных БД InfoBright, InfiniDB и LucidDB // OpenNET [1996-2019] Дата обновления: 11.01.2010. URL: http://www.opennet.ru/opennews/art.shtml?num=24964 (дата обращения: 11.11.2018)