CC BY
70
УДК 004.045
А. А. Еремеевский, В. X. Ханов
РАЗРАБОТКА ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ ДЛЯ ХРАНЕНИЯ БОЛЬШИХ ОБЪЕКТОВ
Рассматриваются проблемы хранения и обработки сложных структур данных и предлагается новый тип хранения таких данных. Проводится сравнительный анализ компактности хранения разработанной СУБД с существующими.
В настоящее время при проектировании систем по анализу значительного объема информации все чаще встает вопрос о ее эффективном хранении и обработке. Одним из таких видов информации является временной ряд.
Моделирование и анализ потока данных временного ряда - обширная и быстроразвивающаяся область исследования. Потоки данных временного ряда часто возникают в управлении промышленными производствами, мониторинге цифровых сигналов или при отслеживании корпоративных процессов. Анализ потока данных временного ряда широко используется для применения в экономическом прогнозировании, биржевом анализе, контроле качества и производства в крупных проектах.
По своему содержанию временной ряд - это результат наблюдения за одним или несколькими параметрами какого-либо процесса. При наблюдении значения этих параметров фиксируются и привязываются к моменту наблюдения. В результате образуется упорядоченная в хронологическом порядке последовательность измеренных значений, которая и называется временным рядом.
В области исследования баз данных было предложено множество узкоспециализированных баз данных, высокоуровневых представлений временных рядов, а также мер для нахождения заданных последовательностей. Методы нахождения последовательностей больших временных рядов, соответствующих заданной последовательности, в последнее время привлекли большой интерес и было предложено множество решений [1-3].
Однако, несмотря на широкое распространение анализа временных рядов, гораздо меньшее внимание было уделено их хранению. Все найденные решения анализа сводились к использованию в узких областях применения. Основной проблемой является отсутствия единого хранилища, которое в свое время предоставили реляционные системы управления базами данных (РСУБД) для данных простейших структур. И хотя РСУБД имеет все необходимые средства для описания и хранения временных рядов, они не могут обеспечить требуемой производительности при обработке больших временных рядов и тем более при обработке последних в реальном времени.
Сегодня для решения задач хранения и анализа временных рядов используются узкоспециализированные системы или объектно-реляционные системы управления базами данных. Однако такие системы не позволяют задавать временной ряд произвольной структуры (например, учитывающий внутреннюю структуру ряда) или расширять методы поиска и анализа [4].
Объектно-ориентированные СУБД хотя и позволяют сохранять произвольные структуры данных, однако так-
же не могу обеспечить эффективного извлечения и анализа временных рядов.
В результате возникает проблема разработки единого хранилища для временных рядов, а также любых других объектов, требующих применения высокоуровневых индексов при извлечении и анализе данных. Данное хранилище должно обладать следующими свойствами:
- эффективно хранить и обрабатывать сложные структуры данных (временные ряды);
- обеспечивать масштабируемость;
- поддерживать существующие стандарты доступа к данным;
- обеспечить расширяемость на системном и прикладном уровне.
Обзор текущей ситуации. Как было сказано выше, на данный момент существует два основных способа хранения: реляционные базы данных и объектно-ориентированные.
В реляционных БД все данные хранятся в двумерных таблицах, называемых отношениями. Каждый столбец таблицы озаглавлен атрибутом, описывающим тип элементов столбца. Строка данных таблицы называется кортеж. Таблицы связаны между собой по ключевому полю. Как видно, в данной БД очень сложно хранить сложные структуры данных (например, для каждого временного ряда придется создавать отдельную таблицу, которая будет содержать по одному кортежу для каждого значения).
Сама концепция реляционных баз данных не предусматривает хранение объектов как таковых, лишь их представлений путем разбиения на таблицы и установления связей между ними. Разумеется, процесс преобразования какого-либо объекта в таблицы - процесс весьма однообразный и трудоемкий, поэтому в дополнение к реляционным БД были разработаны объектно-реляционные системы управления БД (ОРСУБД).
Принцип работы ОРСУБД по своей сути ничем не отличается от РСУБД, за исключением того, что весь процесс преобразования объектов в таблицы берет на себя система и конечный пользователь по сути не участвует в этом процессе.
Независимо от использования РСУБД или ОРСУБД процесс сохранения объектов в базу можно представить следующим образом (рис. 1).
Как видно, любой объект представляет из себя дерево отношений между членами объекта и его методами. При сохранении весь объект представляется в виде таблиц с соответствующими объекту отношениями. Разумеется, что данный метод не может быть эффективным при обработке большого количество данных, так как сам по себе процесс преобразования между реляционной и объект-
ной структурой будет отнимать немалую часть ресурсов, а использовать данный подход в реальном времени не представляется возможным.
Другой подход к хранению представляют объектноориентированные системы управления базами данных, они не имеют каких либо четких соотношений и сохраняют объект целиком без преобразования его в какую-либо иную структуру данных (рис. 2) [5].
Как видно, данная система позволяет эффективно сохранять объекты, не тратя ресурсы на их преобразование, однако методы хранения скрыты и подробного описания последних разработчики ООСУБД естественно не предоставляют. К тому же, данный подход не позволяет извлекать объекты, используя индексы, или получать частичные данные от объекта непосредственно из базы данных (например, чтобы получить спектр временного ряда, нужно будет сначала извлечь его целиком, а потом уже сделать необходимые преобразования).
Данная технология идеально подходит для большого количества объектов и малом размере (количестве данных) единичного объекта. Подобная структура данных широко распространена во множестве Web-приложений. Наглядным примером может служить электронный магазин, где в качестве объектов могут выступать: пользователь, товар, заказ. У каждого конечного объекта набор свойств будет довольно мал, тогда как самих объектов может быть большое количество (в крупных интернет-магазинах количество товаров может составлять десятки тысяч, а количество пользователей около миллиона).
Однако для объектов, содержащих большое количество данных, подобный подход применять довольно сложно, так как наиболее часто необходимо получить не все данные, а сделать только частичную выборку, например, для временного ряда порой необходимо извлечь только короткие временные промежутки. Разумеется, в данном случае извлекать весь объект в оперативную память, а
Объект в памяти
Polygon *poly =
new_polygon();
for (i=0;i<100;i++) {
Point *p = new_point(); p->x = 10; p->y = 20;
poly->contents[i] = p;
};
poly->contents[5]->x = 100; convert_object_to_tables(); INSET INTO tablel... UPDATE table2...
ОРСУБД
SELECT FROM tablel. SELECT FROM table2... convert_tables_to_obj ects();
for (i=0;i<100;i++) { poly[i]->display();
}
Рис. 1. Хранение объектов в ОРСУБД
Объект в памяти
ОРСУБД
Polygon *poly =
new_polygon();
for (i=0;i<100;i++) {
Point *p = new_point(); p->x = 10; p->y = 20;
poly->contents[i] = p;
};
poly->contents[5]->x = 100;
Рис. 2. Хранение объектов в ООСУБД 36
затем производить необходимые вычисления весьма затратно с точки зрения ресурсов компьютера.
Гораздо разумнее было бы обращаться к методам объекта напрямую через СУБД и возвращать в память уже обработанные данные. Такой подход существенно снижает расход ресурсов операционной системы, а также количество операций.
Подходы и принципы новой разработки. Из обзора текущей ситуации видно, что существует острая потребность в создании некой базы данных для работы с объектами большого размера, причем система управления базой данных должна позволять работать с произвольными объектами, а не являть собой некое узкоспециализированное решение для каких-либо конкретных типов данных. Таким образом, основными свойствами СУБД должны быть:
1) независимое хранение структуры объектов и данных;
2) расширение базы данных за счет создания новых объектов;
3) компактное хранение данных;
4) извлечение данных через методы и свойства самого объекта, а не всего объекта целиком;
5) расширяемость объектов.
Графически взаимодействие между СУБД и объектами можно представить следующим образом (рис. 3).
Как видно, СУБД не работает напрямую с данными, а использует методы уже созданных объектов для сохранения и извлечения последних. Такой метод открывает широкие возможности в плане извлечения данных (так как они могут извлекаться абсолютно произвольно в зависи-
мости от методов объекта), а также имеет компактную структуру хранения данных, поскольку сохраняются в итоге именно сами данные, а не структура (методы, свойства) каждого объекта.
Разумеется, для создания обширной базы объектов и обеспечения расширяемости, СУБД должна предоставлять возможность сторонним разработчикам создавать свои собственные объекты с необходимыми методами и свойствами. При этом для обеспечения совместимости и удобства при создании новых объектов СУБД должна обеспечивать:
1) привязку структуры объектов к неким стандартам;
2) использование нескольких языков программирования.
Стандартизация при создании объектов также обеспечит целостность СУБД, так как объекты, не удовлетворяющие стандартам (например, не имеющие обязательных методов), попросту не будут использованы.
При данном подходе встает вопрос о достаточно мощной рефликтации (использование свойств и методов ранее созданных объектов) между различными языками программирования.
Данную проблему позволяет с успехом решить платформа NET, созданная компанией Microsoft в 2001 г.
Во-первых, Microsoft.NET позволяет разным языкам интегрироваться, т. е. одному языку использовать типы, созданные на других языках. Например, CLR (Common Language Runtime - общеязыковая исполняющая среда) позволяет создать на C++ класс, производный от класса, реализованного на Visual Basic. CLR делает это возможным, так как она определяет и предоставляет общую сис-
Хранилище данных объектов
Данные Данные
Данные Данные
Данные Данные
Вызов необходимых методов объекта для получения нужных данных
Объект 1 Объект 4
Объект 2 Объект 5
Объект 3 Объект 6
тему типов (Common Type System, CTS), которую должны использовать все языки, ориентированные на CLR. Сам Microsoft предлагает несколько таких языков: C++ с управляемыми расширениями, С#, Visual Basic.NET, а также JScript. Кроме того, другие компании и учебные заведения создают компиляторы других языков, совместимых с CLR [6].
Во-вторых, благодаря тому, что скомпилированный код представляет собой CIL-язык (Common Intermediate Language - общий промежуточный язык), который хранит в себе описание всех типов кода (данная информация хранится в Meta-тэгах), появилась возможность находить и использовать методы и свойства уже скомпилированного кода (механизм отражения - Reflection).
Все это позволяет реализовать ООСУБД, которая соответствовала бы следующим свойствам:
1) каждый тип данных ООСУБД представляет собой заранее описанный объект, хранящийся в виде динамической библиотеки (DLL);
2) использование в SQL-запросах свойств и методов объектов для сравнения, выборки и других операций;
3) получение на выходе SQL-запроса (в случае SELECT) набор объектов, которые будут иметь собственные свойства и методы;
4) расширение ООСУБД новыми объектами любым конечным пользователем и, как следствие, создание репозитория.
Принцип хранения данных. Как известно, в языках программирования уже давно реализован процесс сериализации объектов (сохранения их на жесткий диск) и десири-ализации (получение начального состояния объекта из данных на жестком диске). Однако данный метод не подходит для разрабатываемой СУБД по следующим причинам:
1) при сохранении объекта сохраняется данные о его структуре и типах данных;
2) сохраняются абсолютно все данные объекта;
3) не выполняется условие раздельного хранения данных и структуры объектов.
Также вполне естественно, что, используя данный метод, СУБД будет расходовать много лишнего места на носителе, так как каждая строка таблицы БД представляет собой идентичный тип данных. Также могут сохраняться вспомогательные переменные объекта, которые не должны быть использованы при его извлечении из БД.
Разработанная СУБД использует собственный механизм сохранения информации, основанный на раздельном сохранении данных о типе объектов и их данных.
По своей сути хранилище данных - это набор таблиц, где каждая колонка является данными определенного объекта, а строка представляет из себя набор данных одного или нескольких объектов. Все таблицы состоят из двух файлов:
1) Table Description (TDS) - файл описания таблицы.
2) Table Data (TDT) - файл с сохраненными данными.
Файл описания таблицы - это файл простейшей структуры, который описывает колонки таблицы: количество и тип (рис. 4).
Данный файл служит для определения типов объектов и их дальнейшего использования для извлечения данных из файла данных TDT. То есть СУБД берет на себя задачу инициализации нужных типов объектов в соответствии с используемыми таблицами.
Файл TDT представляет собой набор бинарных данных, содержащих непосредственно извлекаемые данные объекта, а также размер каждого набора данных. Запись размера в данный файл необходима, так как данные одного и того же объекта в различных строках могут занимать различный объем (например, один объект может сохранять массивы различной длины в каждой строке). Размер набора данных позволяет точно определить начало и конец набора данных для каждого конкретного объекта в каждой строке. Структуру файла TDT представлена на рис. 5.
Т ак как размер данных представляет собой число фиксированного размера (4 байта), то можно осуществлять итерацию по объектам путем извлечения размера данных, а затем самого объекта.
Работа СУБД с файлами представлена на рис. 6.
Разработанная СУБД должна обеспечивать компактность при хранении объектов большого размера. В ходе разработки был проведен сравнительный анализ с популярными реляционной и объектно-ориентированной СУБД.
Для анализа был выбран объект временного ряда, который представляет собой два массива, один из которых содержит временные значения, другой непосредственно значения ряда. Так как каждое временное значение представляет собой целый тип (4 байта), а значение ряда в данный момент времени дробный тип (8 байт), то очевидно, что минимальный объем данных, сохраненных в БД будет: (4 + 8)* количество значений ряда.
В выбранных СУБД для сравнения был создан аналог подобного объекта, с абсолютно идентичными данными, т.е. с типами по 4и 8 байт. Это позволило сделать корректное сравнение.
При сравнении создавалось 5 объектов для сохранения (в случае РСУБД - 5 таблиц) с равным количеством элементов. Сравнение было произведено в 4 этапа, на каждом из которых количество элементов в ряде увеличивалось: 100, 10 000, 100 000 и 1 000 000 соответственно.
В качестве РСУБД была выбрана MySQL - СУБД с открытым кодом, которая получила огромную популярность в среде разработок интернет-приложений.
В качестве ООСУБД была выбрана Versant DB, которая является лидером среди ООСУБД и широко исполь-
Колонка 1 Тип Колонка n Тип
Pto. 4. Cтрyктрya файла описания таблицы
Размер данных Данные Размер данных Данные
Pto. 5. Огруктура файла данных 38
зуется программистами C++, а также в приложениях на платформе NET.
Результаты представлены на рис. 7, 8.
Как видно, компактность разработанной СУБД MyDB превышает MySQL в среднем в 2,6 раза, а Versant DB - в 1,4 раза.
Таким образом, в результате разработки СУБД был реализован новый подход хранения данных сложной структуры, который обеспечивает:
1) извлечение и сохранение данных непосредственно через сами объекты;
2) расширяемость СУБД за счет создание новых объектов на различных языках программирования;
3) компактность хранения данных, превосходящую существующие разработки.
Библиографический список
1. Chan, K. -P. Efficient Time Series Matching by Wavelets / K.-P. Chan, Fu A.-C. // ICDE. 1999. P. 126-133.
2. Faloutsos, C. Fast Subsequence Matching in Time-Series Database / C. Faloutsos, M. Ranganathan, Y. Manolopoulos // SIGMOD. 1994. P. 419-429.
3. Das, G. Finding Similar Time Series / G. Das, D. Gunopulos, H. Mannila // PKDD. 1997. P. 88-100.
4. Прохоров, А. Использование объектно-реляционных СУБД для хранения и анализа временных рядов / А. Прохоров // Компьютер-Пресс. 2000. № 6.
5. Versant Object Database [Электронный ресурс]. Электрон. дан. Режим доступа: http://versant.com. Загл. с экрана.
6. Рихтер, Дж. Программирование на платформе Microsoft .NET Framework : пер. с англ. / Дж. Рихтер. 2-е изд., испр. М. : Изд.-торговый дом «Русская редакция», 2003.
Запрос
Инициализация объектов из файла TDS
Использование объектов для извлечения данных из файла TDT
tr
Рис. б. Работа СУБД с файлами TDT и TDS
£
Рис. 7. Сравнение разработанной СУБД с MySQL
Рис. 8. Сравнение разарботанной СУБД с Versant DB
A. A. Eremeevskiy, V. Kh. Khanov
DEVELOPMENT OF OBJECT ORIENTED DATABASES MANAGEMENT SYSTEM FOR STRONG LARGE OBJECTS
Development of Object oriented database management system for storing large objects. Considered problem ofstoring and processing complex data structures and proposed new way of storing these data. Analyzed storing compact of developed DBMS with existing
