Сравнительное исследование технологий доступа к реляционным БД на базе нестандартных моделей данных (стр. 3 )

Сравнение реализаций подходов по количеству обращений в базу данных

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

Исследуются подходы с

1. Доступом к данным непосредственно через JDBC-драйвер

2. Доступом через EJB2.0 с полным кэшированием

3. Доступом через JPA с настройками кэширования по умолчанию

И непосредственно исследуемые случаи:

1. Открытие страницы с одним объектом (имеющим несколько десятков дочерних объектов и текстовые/ссылочные параметры

2. Среднее значение после открытия 50 страниц

3. Повторное открытие одной страницы (специально для исследования влияния настроек кэширования)

Результат	JDBC	EJB2.0	JPA
1 страница	3	117	230
50 страниц	3	65	84
1 страница повторно	3	44	27

Сравнение трудоемкости реализации подходов и моделей

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

Код на стороне сервера приложения в основном представляет собой реализацию той или иной технологии. В качестве исследуемых рассматриваются следующие варианты

1. EJB2.0 без дополнительных настроек, без поддержки иерархии объектных типов и атрибутных схем в метамодели

2. EJB2.0 с полноценной поддержкой метамодели

3. EJB2.0 с кешированием

4. JPA без дополнительных настроек, без поддержки иерархии объектных типов и атрибутных схем в метамодели

5. JPA с поддержкой наследования объектных типов и атрибутных схем

Исследуемыми параметрами принимаются такие, как

1. Объем написанного кода

2. Количество классов в реализации

Результат	1.	2.	3.	4.	5.
1.	63 Kb	286 Kb	405 Kb	22 Kb	33 Kb
2.	19	34	45	14	20

Анализ результатов

Упомянутые в данной работе сценарии доступа к данным встречаются в бизнес-процессах, являющихся неотъемлемой частью современных информационных систем. Так как подобного рода системы могут иметь совершенно различные конфигурации (назначение с точки зрения пользовательских операций, размеров базы данных, требований на быстродействие, масштабируемость, количество одновременно работающих пользователей), то и сценарии для нагрузочных испытаний взяты из таких «разнородных» систем. Целью выбора именно такого набора сценариев было сравнительное исследование моделей хранения данных и технологий доступа к ним в применении к реальным потребностям рынка информационных технологий.

В данном разделе будет приведен анализ проведённых испытаний и выводы в виде рекомендаций по применению той или иной технологии в связке с конкретной моделью данных к целым классам информационных систем. На самом деле данные, полученных в результате исследования, представляют собой материал для многокритериального анализа в задаче принятия решения, и перечисление всех возможных вариантов вместе с решениями в виде текста и таблиц будет слишком громоздко и неструктурированно, поэтому сделано всё возможное, чтобы охватить только ключевые моменты, наиболее часто встречающиеся на практике разработки информационных систем. С учетом этого, рекомендации изложены последовательно, «от простого к сложному», следуя по масштабу информационной системы, сложности бизнес-процессов, доступных ресурсов на разработку и так далее, с учетом специфичных особенностей и сложностей того или иного решения. Приводится описание информационной системы вместе с присущими именно ей особенностями, и далее – предполагаемый набор технологий, который наилучшим образом подходит для реализации такой системы (иными словами, который показал наилучший результат в ходе нагрузочных испытаний среди подобных технологий применительно к сценариям, характерным для данной системы)

1. Система с фиксированной структурой данных, которая описывается сравнительно небольшим набором сущностей, связанных друг с другом согласно определенным правилам. Основная активность – навигация по объектам и параметрам.

Вне зависимости от объёмов обрабатываемых данных, предлагаемый набор – JPA + набор «плоских» таблиц в базе данных. Такой подход характеризуется

· дешевизной разработки, благодаря доступным средствам автоматического создания структуры классов в JPA по имеющимся в базе данных таблицам и наоборот

· достаточной производительностью, благодаря простоте запросов к данным, генерируемых механизмом JPA. Вообще говоря, такой подход даёт возможность использовать все доступные ресурсы базы данных по-максимуму, большей производительности достичь невозможно ни при каких условиях.

Даже если существует редкая необходимость изменения структуры данных, эту операцию достаточно просто сделать в режиме Off-Line, то есть с остановленным сервером приложений, изменив нужным образом описания таблиц в базе данных и заново сгенерировав структуру классов в JPA.

2. Система со структурой данных, которая может изменяться без необходимости перезагрузки сервера.

Возникает необходимость редактирования и чтения не только данных приложения, но и метаданных – непосредственно структуры. Модель с «плоскими» реляционными таблицами уже не лучшим образом подходит для такой цели, так как в процессе активной работы применение операторов DDL к базе данных может значительно снизить производительность или даже привести к ошибкам. Рекомендация для такой системы – использование адаптивной модели данных (или метамодели), которая позволяет интерпретировать метаданные как данные, а значит, позволяет работать с ними в режиме On-Line без необходимости остановки и перезагрузки сервера приложений.

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

· Дешевизной разработки

· Простотой конфигурации

· Поддержкой всех необходимых особенностей многопользовательского Enterprise-приложения (это конкурентный доступ к данным, транзакционность, обработка ошибок и т. д.)

Однако, как видно из раздела «Результаты», при использовании JPA происходит значительно больше обращений в базу данных (хотя и запросы по сложности оказываются «легче», чем в других технологиях). В случае, когда база данных удалена от сервера приложений, канал связи будет являться узким местом для производительности.

В противовес JPA предлагается использование технологии EJB2.0 со своими особенностями:

· Возможность управления доступом. Запросы к данным не генерируются автоматическим механизмом (это вызывает недостаток контроля, как в случае JPA), а прописываются программистом на этапе разработки

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

3. Система со стихийно изменяющейся структурой данных.

Существуют системы, в которых «административная» составляющая сравнима по масштабу (объёму данных, числу пользователей) с «пользовательской». Такая ситуация приведет к тому, что сами метаданные будут меняться в равной степени часто с обычными данными системы, и это приведет к «сглаживанию» различий между этими составляющими. Этот факт обесценивает преимущества EJB2.0 перед JPA, описанные в предыдущем пункте, поэтому рекомендованный набор в данном случае – JPA + метамодель данных.

4. Система с достаточно небольшим объемом данных

В данном пункте «достаточно небольшой» объем означает, что аппаратные возможности сервера приложений позволяют большинство участвующих в процессах объектов постоянно держать в памяти быстрого доступа. Для такой системы в равной степени подходят возможности EJB2.0 с включенным механизмом кэширования и JPA со специальными настройками, рассчитанными на конкретную систему, но

· Разработка EJB2.0 реализации окажется значительно дороже своей JPA-альтернативы

· В случае, если реальный объем данных достаточно большой (намного больше возможностей оперативной памяти сервера приложений), но лишь малая часть («достаточно малая») используется гораздо чаще, чем остальные данные, реализация EJB2.0 с соответствующими улучшениями позволит контролируемо обрабатывать и держать в памяти быстрого доступа необходимые объекты, в то время как JPA этот контроль не предоставляет – и нужные данные будут вымещаться из кэша сервера непредсказуемо, что приведет к снижению производительности.

5. Система построения отчетов по большому объему данных

Несмотря на то, что переход от «плоских» реляционных таблиц к метамодели сопровождается снижением скорости доступа к данным, на «стандартные» сценарии навигации по объектам, выполнения бизнес-операций с отдельными объектами это ухудшение влияет не критически. Как видно из результатов нагрузочных испытаний, времена отклика системы на пользовательские действия по-прежнему остается в границах разумного допущения. Однако существуют операции, обрабатывающие большие количества объектов одновременно – такие, как построение отчетов, например. И в общем случае использование метамодели ухудшает производительность таких операций в несколько раз (засчет необходимости доступа в несколько разрозненных таблиц для того, чтобы достать параметры лишь одного объекта). Однако и для таких операций возможно разработать быстродействующее решение – об этом в данном исследовании написано в разделе «Некоторые усовершенствования», подразделе «Материализация представлений». Как видно из раздела «результаты», такое улучшение позволяет значительно ускорить операции построения отчетов.

«Нестандартная» однотабличная модель данных

Адаптивные модели данных позволяют интерпретировать структуру и метаданные (объектные типы, атрибуты, ограничения целостности) как данные, хранить их в соответствующих реляционных таблицах и обрабатывать наравне с другими данными приложения.

Если развивать такой подход далее, приходит мысль, что метаданные и этих таблиц можно представить в виде данных, а не структуры предопределенных таблиц в реляционной СУБД. Самой простой структурой для хранение абсолютно всех данных приложения (и метаданных, и непосредственно объектов с их параметрами) является одна таблица. Ниже будет показано, каким образом можно представить сложную структуру приложения с большим числом сущностей и большим объёмом данных в виде одной единственной реляционной таблицы.

Цели

Однотабличная модель данных позволяет инкапсулировать в себе практически любую структуру сущностей из предметной области. Например, набор «плоских» таблиц может быть разложен на набор объектных типов, атрибутов, объектов и их параметров соответственно, и каждый из экземпляров указанных сущностей может быть записан одной строкой такой таблицы. Связи между сущностями поддерживаются с помощью специальных полей: родительская сущность, атрибут, ссылка на сущность.

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

Ниже речь пойдет об исследованиях следующего характера:

· Исследование совместимости различных моделей данных, возможность их «вложения» друг в друга

· Увеличение уровня абстракции технологий доступа к данным над механизмом хранения, результаты исследования производительности и сложности таких преобразований

· Исследование влияния степени нормализации данных на быстродействие и сложность системы

Описание модели, реализации

Исследуемая модель представляет собой единственную таблицу со следующим набором полей:

· Id – уникальный идентификатор сущности. Применим в равной степени ко всем типам сущностей

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

· Type_def_id – идентификатор типа. Для объекта это –соответствующий объектный тип, для параметра – атрибут, который его определяет, для объектного типа – атрибутная схема, к которой он принадлежит.

· Reference – ссылочное поле, имеет смысл для параметров, имеющих ссылочный тип. Фактически является значением параметра.

· Value – текстовое поле, имеет смысл для текстовых/числовых параметров. Представляет собой значение. Для объекта, атрибута, объектного типа имеет значение имени.

Также в качестве начального наполнения в данную таблицу вносятся несколько «основополагающих» строк. Например, строки, где в Value будет прописано «Объектный тип», «Атрибутная схема», «объект», на которые впоследствии будут ссылаться по Type_def_id «корневые» атрибутные схемы, типы и объекты. Затем таблица заполняется метаданными – объектными типами, атрибутами, схемами, и только после – объектами и параметрами.

Таким образом, в одной иерархии по Type_Def_Id в этой таблице могут встречаться параметры, атрибуты и схемы, объекты, объектные типы и также схемы – здесь не существует ограничений и запретов на те или иные реляционные отношения.

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

Доступ к такой модели осуществляется через обобщенный интерфейс. Каждая строка таблицы представляет собой объект. Назовем его GObject (Generalized Object). У объекта существуют методы для работы с полями, например:

GObject getParent();

GObject getTypeDef();

void setReference(GObject reference);

void setValue(String value);

void addChild(GObject child);

Collection<GObject> getChildren();

И им подобные, составляющие полный набор, необходимый для полноценной работы со строкой таблицы.

Результат

Вложенность моделей данных друг в друга

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

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

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

Зависимость быстродействия системы от степени нормализации данных

Набор метаданных для каждого объекта вычисляется иерархически, с учетом наследования объектов, объектных типов и атрибутных схем, как это делается в «классической» метамодели. Однако, для увеличения производительности, возможно сохранение результатов вычисления метаданных для конкретного объекта в виде дочерних к нему записей, или же записей, дочерних к его типу. Актуальность таких данных (по сути, представляющих себя административную составляющую информационной системы, так как рядовые пользователи не должны иметь возможности вносить изменения в метаданные) поддерживается на уровне механизма администрирования системы. Так как метаданные по объему в общем случае значительно меньше самих данных, избыток вычислений, требуемых на поддержание такой структуры, будет невелик. Такой подход к тому же вносит некоторую избыточность в сами данные, денормализуя структуру. Но преимущество данного подхода налицо: количество доступов в таблицу для получения метаданных снижается на порядок, а то и в несколько десятков раз (засчет того, что нет необходимости «поднимать» всю структуру с учетом наследования, достаточно лишь обойти текущий уровень иерархии и, возможно, предыдущий уровень). Исследование такого подхода и даёт ответ на вопрос о зависимости уровня нормализации на быстродействие системы, причем однотабличная модель данных – простейшая структура, на которой можно проводить такое исследование.

Заключение

В данной работе проведено сравнительное исследование различных технологий доступа к данным, таких как Enterprise Java Beans версии 2.0, Java Persistence API, Java Database Connectivity, и различных моделей хранения данных, как Representing Objects as Tables, с использованием таблиц реляционной СУБД, и Adaptive Object Model, метамодель на основании иерархических таблиц. В ходе исследования проведены нагрузочные испытания указанных технологий при использовании их в различных стандартных сценариях доступа к данным.

На основе результатов нагрузочных испытаний сделаны выводы о достоинствах и недостатках соответствующих технологий в различных условиях использования. К самым показательным выводам можно отнести следующее: при использовании метамодели подход с JPA предлагает значительно более простую реализацию и меньшие затраты на разработку решения, однако в среднем немного уступает подходу с EJB2.0 по производительности. Несмотря на последний недостаток, существуют обстоятельства, при которых производительность JPA выше, чем его конкурента, на идентичных сценариях и наборах данных, как, впрочем, существуют случаи, когда производительность этого подхода значительно уступает EJB2.0. Для обобщения полученных результатов приведен анализ в виде рекомендаций о применимости той или иной модели данных в комбинации с соответствующим подходом для некоторых распространенных классов информационных систем.

В разделе, посвященном однотабличной модели данных, приведено описание ещё одной нестандартной структуры хранения. Такая структура интересна прежде всего с методической точки зрения, так как позволяет формализовать некоторые критерии оценки модели данных и представить численно их параметры, давая таким образом возможность сравнивать построенные архитектурные решения математическими методами. Здесь же указано направление дальнейшего исследования нестандартных моделей данных.

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

Список использованных источников

1. Antonio Goncalves Beginning Java™ EE 6 Platform with GlassFish™ 3 From Novice to Professional – APRESS©, 2009

2. Ed Roman, Scott Ambler, Tyler Jewell Mastering Enterprise JavaBeans™, Second Edition – Wiley Computer Publishing, 2002

3. Floyd Marinescu EJB™ Design Patterns – Wiley Computer Publishing, 2002

4. John O'Donahue Java Database Programming Bible – John Wiley & Sons©, 2002

5. Joseph W. Yoder, Federico Balaguer, Ralph Johnson Architecture and Design of Adaptive Object-Model – , 2000 - http://www. /OOPSLA2001/AOMIntriguingTechPaper. pdf

6. Leon Welick, Joseph W. Yode, Rebecca Wirfs-Broc Adaptive Object-Model Builder – , 2009 – http:///PDFs/04welicki. pdf

7. Mike Keith and Merrick Schincariol Pro JPA 2: Mastering the Java™ Persistence API – APRESS©, 2009

8. Reza Rahman Keeping a Relational Perspective for Optimizing JPA – 2009

9. Rima Patel Sriganesh, Gerald Brose, Micah Silverman Mastering Enterprise JavaBeans™ 3.0, Wiley Computer Publishing, 2006

10. Rod Johnson Expert one-on-one J2EE Design and Development – Wrox Press Ltd. October 2002

11. Thomas Kyte Expert Oracle Database Architecture, Second Edition – APRESS©, 2010