Магистерский диплом
реклама
Министерство образования и науки Российской Федерации МОСКОВСКИЙ ФИЗИКО-ТЕХНИЧЕСКИЙ ИНСТИТУТ (государственный университет) ФАКУЛЬТЕТ РАДИОТЕХНИКИ И КИБЕРНЕТИКИ КАФЕДРА ИНФОКОММУНИКАЦИОННЫХ СИСТЕМ И СЕТЕЙ Сравнительное исследование технологий доступа к реляционным БД на базе нестандартных моделей данных Магистерская диссертация студента 517 группы Харичкина Александра Евгеньевича Научный руководитель Евдокимов А.В., к.ф.-м.н., доцент г. Москва 2011 Оглавление Введение.........................................................................................................................................3 Постановка задачи .........................................................................................................................4 Модели данных .............................................................................................................................7 Relational Database .....................................................................................................................7 Adaptive Object Model ................................................................................................................9 Универсальная структура данных с метамоделью ...............................................................11 Технологии ...................................................................................................................................13 JDBC ...........................................................................................................................................13 EJB ..............................................................................................................................................13 JPA ..............................................................................................................................................14 Описание реализаций исследуемых технологий .....................................................................14 Некоторые усовершенствования ............................................................................................15 Описание методики тестирования производительности ........................................................19 Окружение, в котором производится тестирование ............................................................20 Сценарии тестирования...........................................................................................................22 Результаты ....................................................................................................................................23 Описание исследуемых случаев .............................................................................................23 Результаты ................................................................................................................................24 Анализ результатов ..................................................................................................................28 «Нестандартная» однотабличная модель данных ...................................................................32 Цели ...........................................................................................................................................32 Описание модели, реализации ..............................................................................................33 Результат ...................................................................................................................................34 Заключение ..................................................................................................................................36 Список использованных источников .........................................................................................37 Введение В условиях постоянно и быстро развивающегося рынка информационных технологий, изменяющихся требований к бизнес-системам, потребности новых решениях для растущего числа задач, перед аналитиками ставится ряд задач, от решения которых кардинально зависит успех разрабатываемой бизнес-системы. Типичная информационная система содержит следующие составные части: База данных Бизнес-функциональность Пользовательский интерфейс На данный момент существует немалое множество технологий разработки информационных систем, причем эти технологии затрагивают каждую из перечисленных составных частей ИС. Таким образом, задача аналитика в тесном взаимодействии с ведущим разработчиком – принять решение относительно предпочтительных технологий, их реализаций, способа внедрения в продукт и взаимодействия между собой. Выбор технологий и способа их внедрения является особенно критичным при проектировании информационной системы. Верно принятое решение на этом шаге зачастую создает условия, при которых разработка продукта сразу направлена в нужное русло, и силами команды разработчиков доводится до готового решения в минимально возможные сроки и с минимальными затратами. Однако ошибка на шаге выбора технологий может оказать существенно негативное влияние на дальнейшую разработку: неоправданные трудозатраты команды разработчиков, невозможность выдать готовое решение к установленному сроку, неоптимальная работа приложения, а в худшем случае – и необходимость пересмотреть выбранный набор технологий и начать разработку с начала. Таким образом, суть действий аналитика и ведущего разработчика можно выразить следующим. Имеется набор начальных данных (составленных на основе требований заказчика, проработанный аналитиком и вынесенный в документ, обычно называемый Design Specification продукта), к примеру, объем базы данных заказчика, предполагаемое количество пользователей ИС, требуемое время отклика системы, количество и сложность бизнес-процессов, протекающих в системе и т. д. С другой стороны, ведущий разработчик стремится сделать процесс разработки удобным, быстрым, понятным, решая задачи, которые не имеют непосредственного отношения к конкретному продукту, но всегда возникают в программировании: уменьшить объем кода, сделать его по возможности повторно используемым, обеспечить должную масштабируемость системы, позаботиться о поддержке в будущем и даже принять во внимание то, что впоследствии бизнес правила, процессы, модели данных в системе могут измениться, таким образом требуя изменения логики работы приложения. В итоге, на основании бизнес-требований приложения и с учетом требований к разработке, составляется Техническое Задание, по которому работают непосредственно разработчики. Это самое ТЗ и являет собой перечисление технологий, рекомендованных к использованию, и рекомендации по внедрению их в программный продукт. Помимо предопределенного набора технологий в качестве отправной точки к решению поставленной задачи перед ведущими разработчиками и аналитиками стоит выбор объектной модели данных, а реализация модели целиком и полностью перекладывается на ответственность непосредственно разработчиков. В различных условиях постановки задачи (размеры базы данных, сложность и комплексность бизнес-процессов, количество пользователей приложения) зачастую очень важно на самом первом этапе разработки выбрать подходящую модель данных и воплощать её, согласуя реализацию с соответствующими технологиями, упомянутыми в предыдущем абзаце. Постановка задачи Главным аспектом предметной области, с которой сопряжено данное исследование, являются информационные системы. В пользу этого выбора можно привести достаточно большое число аргументов. Перечислим лишь некоторые из них 1. Информационные системы востребованы практически в любой отрасли производства и особенно сферы услуг. 2. Сложность и масштаб информационной системы практически неограниченны: это может быть и информационная система небольшого предприятия (например, учет оборудования на производстве), и работающие в пределах целых городов или государств службы автоматического предоставления информации и услуг (on-line справочные, страховые компании, провайдеры связи и т.д.) и поисковые системы, единые по всему миру (Google; Yahoo и т.д.), и 3. Ввиду многообразия и широкой распространенности информационные системы имеют многочисленные возможности по взаимодействию между собой: обмен сообщениями, всевозможные интеграции систем, API открытого доступа. Таким образом, исследование, примененное к информационным системам, должно иметь немалое значение не только для систематизации и популяризации знаний по существующим технологиям (в частности, применительно к данному исследованию доступа к данным), но и для обобщения, уточнения и дополнения знаний, численных результатов и рекомендаций к написанию информационных систем в среде бизнеса, образования и для дальнейших исследований. Напомним, что перед ведущими разработчиками ставятся задачи, в условиях которых фигурируют следующие условия Предполагаемый (или известный) объем данных, обрабатываемых приложением Количество пользователей системы Структура и сложность бизнес-процессов, протекающих в системе Требуемое время отклика системы на ввод пользователя Время жизни приложения, необходимость поддержки и сложность Необходимость интеграции с другими системами и приложениями При этом с точки зрения программистов, выполняющих ТЗ, выбор пути решения задачи во многом опирается на следующие понятия, стремясь максимизировать или минимизировать соответствующие численные значения Объем кода Сложность модели данных Масштабируемость Возможность повторного использования функциональности Конфигурируемость приложения Возможность изменять логику в режиме реального времени В таких разнообразных условиях, и при наличии большого набора вариантов для реализации, вопрос о корректном выборе наборов технологий, моделей данных, способов их взаимодействия становится критически важным с точки зрения бизнеса. И основная поставленная задача сейчас – систематизировать знания, результаты и выводы, полученные в ходе исследования, для придания им информационного и возможно даже рекомендательного характера для той области индустрии программирования, которая занимается разработкой информационных систем. Для того, чтобы разъяснить в общих словах, что поможет выявить это исследование, поставим несколько вопросов, на которые в заключение данной работы постараемся дать как можно более развернутые ответы, с объяснением сделанного выбора и приведением аргументов в его пользу. Какую технологию выбрать, если… Заранее известен объем данных (который можно кратко охарактеризовать как «большой»), на которых должна работать система, и с течением времени этот объем будет только увеличиваться. При этом большая часть данных должна быть доступна в режиме Read-only, то есть изменяться данные, как и структура данных, будут нечасто. («Справочная») Объем данных заранее известен, но структура данных не фиксирована. Таким образом, в приложении должна присутствовать некая «Административная» составляющая – возможность авторизованных пользователей влиять не только на данные, но и на их представление. В процессе жизнедеятельности приложения может потребоваться необходимость небольшого изменения структуры данных, например, изменение наборов атрибутов у объектов, введение новых типов объектов и т.д. («Оператор связи» - при изменении технологической составляющей телефонной/телекоммуникационной сети может потребоваться изменение структуры хранимой информации) Структура данных, как и сами данные, будет меняться стихийно – неизвестно ни начального объема данных, ни его динамики, при этом достаточно большая группа пользователей может вносить изменения и в структуру, и в сами данные («Страховая компания», с постоянно меняющимся набором предоставляемых пакетов услуг и большим числом конечных пользователей, пользующихся этими услугами) Модель данных имеет очень сложную структуру – иерархии типов объектов, привязки атрибутов к объектам определяются на каждом уровне иерархии в зависимости от привязки к атрибутным схемам, тоже иерархичным. «Административная» составляющая изменяется редко, но должна быть репрезентативна для пользователей-администраторов, то есть иметь наглядное и легко понимаемое представление («Телекоммуникационный оператор» в масштабах страны: Телекоммуникационные сети, оборудование, учет услуг и предоставление услуг, отдельный каталог пакетов услуг и продуктов и т. д.) Модели данных Relational Database Representing Objects as Tables структура Наиболее простой способ представление объектной информации в реляционной БД это ROT – для каждого объектного типа заводится отдельная таблица, каждый столбец которой представляет собой объектный атрибут. Таким образом, каждый объект со всеми своими параметрами будет представлен одной записью в этой таблице. Главное преимущество такого подхода к хранению информации – это его простота. Выборка значения атрибута для любого объекта сводится к выполнению наипростейшего sql запроса: select * from manager where id = ?; Так же очень большим плюсом является возможность накладывать ограничения (constratins) на любой отделаьный атрибут (salary not null), не затрагивая остальные. Данная модель не поддерживает хранение объектов с иерархической структурой типов. Таким образом общие атрибуты (например, salary, department) приходится дублировать в каждой из таблиц. Большое кол-во типов приводит к большому кол-ву таблиц в системе. Это является существенным минусом данного подхода, т.к. существенно ухудшает масштабируемость системы с точки зрения администрирования БД. Структура соединенных таблиц (Joined Tables) Добавив поддержку представления объектов с иерархией типов к предыдущему подходу представления объектной информации ROT, получим следующую структуру: Отличительной чертой является то, что общие атрибуты (hired when, salary, department для типов Manager и Developer) не дублируются в нескольких таблицах, а вынесены в отдельную таблицу, описывающую родительский тип (Employee). Теперь для выборки зарплаты всех сотрудников нужно обратиться только к одной таблице: select salary from employee С другой стороны, для получения значения всех атрибутов manager придется обратиться к трем таблицам вместо одной, как это было для ROT: select * from person p, employee e, manager m where p.id = ? and e.id = p.id and m.id = p.id; Аналогично ROT структура с соединенными таблицами имеет недостаток, связанный с большим количеством таблиц. Adaptive Object Model Время, когда бизнес-правила глубоко «зашиты» в код приложения исчерпывает себя. Зачастую у пользователей возникает желание изменять логику работы их приложения без написания нового кода. Требуется способность более простой адаптации приложения к изменяющимся нуждам бизнеса, таким образом чтобы каждая система удовлетворяла своим уникальным требованиям. Сегодня многие информационные системы обязаны быть динамичными и настраиваемыми, так чтобы они могли легко и быстро изменяться чтобы адаптироваться к новым нуждам бизнеса. Обычно это достигается путем вынесения некоторых аспектов системы, таких как бизнес-правила, на уровень базы данных, позволяя тем самым проще и доступнее изменять их. Получающиеся модели позволяют системам адаптироваться быстро за счет только лишь изменения значений в базе данных, а не за счет изменения исполняемого кода. Такой подход также побуждает к разработке и развитию инструментов, позволяющих администраторам систем создавать новые продукты без непосредственно программирования, а также позволяет изменять существующие бизнесмодели прямо в процессе их жизнедеятельности. Это снижает время выдачи новых решений непосредственно заказчику с месяцев до недель и даже дней. Таким образом, настройка системы теперь находится в компетенции тех, кто обладает достаточными знаниями бизнес-процессов, чтобы делать это эффективно. Адаптивная Объектная Модель (Adaptive Object Model) – система, которая представляет классы, атрибуты, связи между сущностями как метаданные. Такая система основывается в большей степени на экземплярах данных, чем на классах данных. Пользователь изменяет метаданные, чтобы подчеркнуть изменения в доменной модели. Эти изменения влияют непосредственно на поведение системы. Другими словами, такая система сохраняет свою объектную модель в базе данных и имеет сведения о том, как её интерпретировать. Следовательно, объектная модель является активной, когда она изменяется, система изменяется немедленно. Структура простейшей Адаптивной Объектной модели приведена на рисунке ниже Адаптивная Объектная Модель EntityType – сущность, представляющая тип (класс, описание) сущности в «стандартной» модели данных. Экземпляры EntityType создаются на каждый тип сущности, содержат информацию об особенностях конкретного типа, могут наследоваться друг от друга. Entity представляют собой все возможные экземпляры объектов. Entity имеют связь с EntityType, равно как в стандартной модели каждый экземпляр объекта принадлежит какому-нибудь типу, классу или описанию. PropertyType описывают атрибуты, или поля, объектов. Связь PropertyType с EntityType выражает привязку тех или иных атрибутов к классу или типу. В стандартной модели это соотносится с тем, что внутри описания класса присутствуют и описания полей. Property представляют непосредственно значение того или иного атрибута. Связь с PropertyType определяет принадлежность конкретного значения тому или иному описанию атрибута. Связь с Entity привязывает значение по конкретному атрибуту к конкретному объекту. В рамках данной работы используется немного более усложненная адаптивная объектная модель. Наряду с четырьмя сущностями, описанными выше, вводятся атрибутные группы, атрибутные схемы, атрибутные типы, таблица возможных перечислимых значений атрибутов. Связь EntityType-ProprtyType будет типа многие-ко-многим, поэтому появится дополнительная промежуточная таблица для этой множественной связи. Структура используемой модели данных описана в следующем подразделе: Универсальная структура данных с метамоделью Таблица object_types содержит описание объектных типов (классов) системы. Атрибут object_type_id – уникальный идентификатор, parent_id – ссылка на object_type_id предка в этой же таблице, name – название объектного типа, description – подробное описание объектного типа. Таблица attributes содержит описание атрибутов. attr_id – уникальный идентификатор атрибута, name – название. Дополнительно вводится таблица attr_object_types, для реализации связи «многие ко многим» между типами и атрибутами. attr_id – ссылка на attr_id атрибута (в таблице attributes), object_type_id - ссылка на object_type_id (в таблице object_types), к которому относится атрибут. Таблица objects содержит список экземпляров объектов. Object_id – уникальный идентификтор объекта, object_type_id – ссылка на object_type_id объектного типа (в таблице object_types), к которому относится экземпляр, name – краткое обозначение объекта. Таблица params содержит значения свойств объектов. Object_id – ссылка на object_id объекта (в таблице objects), attr_id – ссылка на attr_id атрибута (в таблице attributes), text_value, number_value, date – значение этого атрибута для данного объекта в зависимости от типа данных (char, number или date). Таблица refs содержит значения атрибутов-ссылок на объекты. Здесь object_id – ссылка на object_id объекта, который ссылается (в таблице objects), reference – ссылка на object_id объекта, на который ссылаются (в той же таблице). Таким образом, таблицы object_types, attributes и attr_object_types содержат описание (метаданные), а таблицы objects, params, refs – сами данные. Такой подход предполагает явное хранение метаданных об «объектных типах» и их атрибутах, а также (в предельном случае) хранение в одной таблице всех объектов и хранение в одной таблице значений всех (точнее, всех однотипных) атрибутов различных объектов. Дополнительными возможностями подхода является связь «многие ко многим» между атрибутами и объектными типами. Применение метамодели обладает следующими преимуществами: универсальность: предложенная в работе схема может использоваться в любых объектно-ориентированных приложениях без модификации структуры таблиц гибкость: изменения в предметной области требуют внесения исправлений только на уровне данных и не влияют на исходный код программы по сравнению с известными метамоделями данная модель обладает дополнительными возможностями сложных структур (иерархия объектов, связь многие-ко-многим между атрибутами и объектными типами). Однако такой подход при всех очевидных плюсах имеет и ряд серьезных технических проблем. Недостатки метамодели: низкая по сравнению с ROT подходом скорость запросов большой объем вспомогательных данных ослабленный контроль за целостностью данных сложность в понимании структуры при выборке данных Технологии JDBC JDBC (Java Database Connectivity) – технология, позволяющая получать доступ практически к любому источнику табличных данных для Java-приложения. Помимо возможности подключения к большому количеству баз данных SQL, JDBC позволяет получать данные из других источников, таких как обыкновенные файлы. JDBC определяет низкоуровневое API, разработанное для поддержки базовых функциональностей языка SQL независимо от какой-либо конкретной реализации базы данных. Другими словами, основное внимание уделяется выполнению SQL запросов и получению их результатов. EJB Enterprise JavaBeans (EJB) – это управляемая компонентная архитектура приложений на стороне сервера, предназначенная для модульного построения корпоративных приложений. Спецификация EJB является одним из нескольких Java API внутри спецификации Java EE. EJB – серверная модель, которая инкапсулирует бизнес-логику приложения. Спецификация EJB предназначена обеспечить стандартный путь реализации бизнес-кода, который распространен в корпоративных приложениях. Подобный код зачастую решает одни и те же задачи, и было замечено, что решения этих задач постоянно и многократно «изобретаются» программистами заново. Enterprise JavaBeans предназначена регулировать такие общие подходы, как сохранение данных, транзакционная целостность и безопасность стандартным путем, позволяя разработчикам сосредотачиваться на конкретных проблемах, вверенных им. Соответственно, спецификация EJB раскрывает детали того, как сервер приложений обеспечивает Обработку транзакций Интеграцию со службами хранения данных Управление конкурентным доступом … и многое другое Entity Bean – это разновидность Enterprise JavaBeans, компонент J2EE приложения на стороне сервера, который представляет долгоживущие данные, сохраняемые в БД. Entity Bean может сам управлять сохранением данных (Bean Managed Persistence) или может делегировать эту функцию своему EJB-контейнеру (Container Managed Persistence). Entity bean уникально идентифицируется по своему первичному ключу. Если контейнер, в котором запущен Entity Bean, потерпит неисправность, Entity bean, его первичный ключ, и любые удаленные ссылки сохранятся. JPA Одна из главных направленностей пятой версии Java Platform, Enterprise Edition является простота разработки. Изменения в платформе делают разработку корпоративных приложений с использованием Java технологии намного проще, с гораздо меньшим объемом кода. Следует заметить, что эти упрощения не изменили мощности самой платформы: платформа Java EE 5 поддерживает весь богатый набор функциональности предыдущей версии, J2EE1.4 Разработчики корпоративных систем должны были заметить значительное упрощение технологии Enterprise JavaBeans. Значимым улучшением в технологии EJB стало введение Java Persistence API, который упрощает модель сохранения сущностей в долговременную память и добавляет возможности, недоступные технологии EJB2.1. Java Persistence API управляет тем, как данные из реляционных таблиц отображаются на Java-объекты, на то, как эти объекты сохраняются в базу данных с целью доступа к ним в дальнейшем, и продолжительным поддержанием состояния сущности даже после того, как приложение, использующее её, заканчивает свою работу. В добавок к упрощению модели поддержания состояния сущностей, Java Persistence API стандартизует объектнореляционные отображения. Другими словами, с введением Java Persistence API технология EJB3.0 предлагает разработчикам модель программирования сущностей, которая одновременно проще и богаче предыдущих. Описание реализаций исследуемых технологий Для реализации технологий было разработано простое Web-приложение с использованием технологии Java Server Pages. Создана универсальная страница, отображающая объект со всеми его параметрами и дочерними объектами. Страница обращается к стандартному классу-помощнику, который предоставляет данные для отображения. В зависимости от исследуемой технологии, этот класс настроен на использование JPA или EJB соответственно. Настройки переключаются на использование другой технологии между испытаниями. К этому же приложению подключена вспомогательная Web-страница на JSP, в теле которой реализовывались соответствующие сценарии доступа к данным, такие, как доступ к заданному числу объектов последовательно, доступ к объектам и их иерархиям, полям и так далее. В этом же приложении были встроены подключаемые модули – соответственно, EJB модуль и JPA как часть приложения. Именно эти модули отвечали за доступ непосредственно к данным. В базе данных была создана структура метамодели. Наполнение данными происходило копированием с эталона базы данных одной из версий реального программного продукта (системы OSS). Дополнительно к этому, в тестовую базу была мигрирована структура телекоммуникационной сети одного из заказчиков. Эта же структура сети заказчика присутствовала в базе и в виде «плоских» таблиц, которые были использованы для исследования реляционной модели хранения данных. Наряду с реализацией указанных двух технологий доступа, были проведены некоторые усовершенствования подходов, о которых сказано в следующих подразделах. Некоторые усовершенствования Поверх рассматриваемых технологий зачастую силами команды разработчиков вводятся некоторые усовершенствования, предназначенные для работы именно в обозначенных условиях конкретной информационной системы и нацеленные на повышение производительности работы системы. Некоторые из этих усовершенствований успешно внедрены и используются известными системами, некоторые будут упомянуты в последующих разделах данного исследования, но некоторые существуют лишь как теоретическая предпосылка для реализации и исследования. Кэширование данных на стороне Application-сервера Зачастую данные, которые использует приложение, одновременно или с некоторым небольшим интервалом могут читаться несколькими пользователями (или многократно одним пользователем), при этом на каждое чтение будет приходится обращение к базе данных через сетевой протокол, дисковые операции самой базы данных и процессорное время сервера приложений, затрачиваемое на интерпретацию этих данных. Чтобы избежать избыточных накладок при работе с сетью, дисковыми подсистемами и процессором, вводят кэширование данных на стороне сервера приложений. В этом случае данные, к которым происходит обращение, сразу после считывания из базы помещаются во временное хранилище – кэш сервера приложений, и при последующем обращении к тем же данным (например, по уникальному идентификатору), поиск сперва будет производиться именно по этому временному хранилищу. Если за время между последовательными обращениями к одним и тем же данным они не успели «вытесниться» из кэша – сервер не будет обращаться к базе данных, а использует уже загруженные и интерпретированные данные из кэша. Плюсы и минусы такого подхода очевидны + экономия процессорного времени сервера приложений на интерпретацию данных + экономия времени работы дисковых подсистем базы данных + экономия затрат на сетевую передачу данных - дополнительные накладные расходы на содержание кэша в памяти сервера приложений - проблемы синхронизации конкурентного доступа и консистентного чтения при обращении к закэшированным данным - проблема тупиков «Deadlocks» при конкурентном изменении закэшированных данных И обозначенные плюсы, и минусы имеют большое значение для решения вопроса внедрения такого усовершенствования, однако практика показывает, что оно оправдывает себя при условии корректного построения архитектуры приложения для избежания обозначенных ошибок конкурентного доступа и при наличии бюджета на внедрение программной части и усовершенствования аппаратной составляющей данного нововведения. В рамках данной работы исследовался подход с частичным кэшированием данных на стороне Application сервера, и соответствующие измерения вынесены в раздел «Результаты». Полное кэширование метаданных В силу того, что метаданные (к которым относится информация о типах объектов, привязках объектов и атрибутов, иерархии наследования типов и атрибутных схем) по объему обычно значительно меньше самих данных (в частности потому, что одному объектному типу могут принадлежать одновременно миллионы объектов), зачастую имеет смысл полностью кэшировать метаданные на стороне сервера приложений. В результате имеем + Очень быстрый доступ к метаданным (просто поиск по ключу в hash-коллекции в оперативной памяти сервера приложений) + снижение нагрузки на базу данных (так как зачастую метаданные имеют гораздо более сложную структуру по сравнению с данными – множественные иерархии по нескольким ветвям наследования одновременно, например) - накладные расходы из-за повышенных требований к аппаратному обеспечению сервера приложений (так как нужно держать в оперативной памяти больший объем данных) - проблема обновления данных (которая, впрочем, возникает достаточно редко – так как метаданные по своей сути обновляются нечасто) Подход с кэшированием метаданных не входит в область исследования данной работы. Упоминание такого подхода здесь приводится в качестве обзорного материала. Денормализация данных (и метаданных) Опять же благодаря небольшому по сравнению с данными объему метаданных, и учитывая тот факт, что изменяются они крайне редко (только при изменении структуры модели данных приложения, а этот шаг должен быть обусловлен серьезным политическим решением руководителей разработки), зачастую имеет смысл денормализовать структуру метаданных – таким образом, избавившись от сложных иерархических запросов при доступе к ним. Известное решение, реализующее эту идею, применяет обыкновенные «плоские» таблицы без иерархий, в которых в «развернутом» виде хранятся метаданные, выбранные из соответствующих иерархических таблиц схемы с метамоделью. Изначальное заполнение таких плоских таблиц производится во время окна обслуживания сервера, и делается с помощью скриптового сценария на языке базы данных, а дальнейшая поддержка этой структуры осуществляется через триггеры – механизмы отслеживания событий, происходящих с объектами базы данных. + Значительное увеличение скорости доступа к данным - Более сложная поддержка новой структуры метаданных - Требование переписать существующую функциональность для работы с новой структурой - дополнительные накладные расходы при изменении структуры данных (то есть самих метаданных) Денормализация данных и метаданных является одним из центральных объектов исследования «однотабличной» модели данных, упомянутой в последнем пункте данного исследования. Соответствующие обзоры и результаты не будут приведены в общем разделе «Результаты». Материализация представлений Немалая часть функциональности информационной системы – отчетность – зачастую является самым узким местом по производительности. В случае, если работа механизма отчетности включена в логику бизнес-процесса, это создает серьезную проблему производительности всего приложения. А корни самой проблемы возникают из-за нормализованности данных. Тот вид, в котором данные хранятся в базе (будь то метамодель, или плоская таблица), призван улучшить визуальное отображение этих данных, упростить понимание структуры, ускорить операции добавления/изменения объектов, и зачастую просто является исторически принятым в пользование, так что изменение существующей структуры будет являться дорогой и, вполне вероятно, неоправданной операцией. Однако для отчетности порой бывает удобно переходить к другим структурам данных (от метамодели – к плоским таблицам, от плоских иерархических – к плоским одноуровневым и т.д.). В виду того, что возможности изменить саму структуру данных нет – прибегают к репликации данных для последующего изменения структуры уже реплицированной модели. Такое решение никак не затрагивает исходную базу данных, однако позволяет получать отчеты по измененной структуре с гораздо большей производительностью. Главной идеей подхода с репликацией является материализация представлений, с журналированием записей об обновлениях данных в представлении. На основе реплицированных данных (самих материализованных представлений) и журнала изменений (логи материализованных представлений) система репликации вносит изменения в реплицированные данные, при том что эти данные не обязаны иметь схожую с исходной структуру. В общем случае они могут быть совершенно не связаны структурно с исходными данными, но благодаря постоянно обновляющемуся журналу изменений данные в них поддерживаются в актуальном состоянии в любой момент времени, а благодаря реплике исходных данных (которая в данном случае устанавливается на отдельный экземпляр базы данных), снижается нагрузка на оригинальную базу данных, с которой работает приложение. В результате имеется + неограниченная возможность по увеличению производительности отчетов (засчет повторной и многократной материализации и изменения структуры данных) + снижение нагрузки на выполнение отчетов с исходного сервера базы данных - накладные расходы на поддержание материализованной реплики данных - более сложные процессы внедрения и поддержки такого решения в существующие продукты и проекты Измерения производительности приведенного подхода были произведены в рамках данного исследования, соответствующие значения приведены в разделе «Результаты» под ключевым словом «Replicated Database» Описание методики тестирования производительности Основной способ получения результатов производительности реализованных технологий и моделей данных в данном исследовании – нагрузочное тестирование. В ходе этого тестирования составляется сценарий доступа к данным, позволяющий максимально использовать исследуемый набор технологий, и этот сценарий выполняется большое количество раз, при этом на вход подаются случайные данные, произвольно распределенные среди всего набора. Операции, участвующие в нагрузочном тестировании, приведены ниже: 1. Выборка большого количества произвольных объектов с их параметрами 2. Выборка иерархии объектов под одним родителем 3. Отображение объекта в Web-интерфейсе 4. Навигация по объектам через Web-интерфейс по заранее заданному сценарию Такие условия применения технологий, конечно, не являются максимально приближенными к реальным примерам использования их в бизнес-системах, но тем не менее большинство процессов, происходящих в реально работающей системе, будут в большинстве случаев использовать именно описанные выше операции при доступе к данным посредством соответствующей реализации, а значит, и результат «реальной» работы приложения по производительности будет напрямую зависеть именно от производительности указанных операций. Окружение, в котором производится тестирование Здесь приведены характеристики и настройки аппаратного обеспечения, сервера приложения и базы данных, на которых были развернуты реализованные в виде приложений соответствующие реализации технологий и моделей данных. В качестве сервера приложения выступает open-source Glassfish Application Server v.3.0.1, поставляемый корпорацией Sun (на данный момент Oracle). По итогам исследований на реальных бизнес-системах этот сервер зарекомендовал себя как самый производительный среди многих ему подобных проектов, реализующих технологии Java Enterprise Edition. СУБД для реализации модели данных и хранения самих данных выбрана Oracle Database Express Edition – продукт, разрешенный для некоммерческого использования от корпорации Oracle. Ограничения его по сравнению с коммерческими версиями следующее: максимальный размер файлов данных, размещенных на жестком диске, для базы построенной на такой СУБД, составляет 4Gb, размер оперативной памати, используемый экземпляром базы – 1Gb, и при функционировании СУБД может быть задействовано не более 1 ядра процессора. Как видно по результатам, таких характеристик вполне достаточно для получения репрезентативных результатов замеров производительности. Аппаратная часть окружения представляет собой настольный компьютер, 2х-ядерный процессор Intel®Core™2 @1.67 GHz, с установленной памятью 3 GB RAM. На одном оборудовании установлена и СУБД, и сервер приложений, при этом двухъядерный процессор позволяет распараллеливать операции, выполняемые этими программами, без взаимного влияния их друг на друга. В качестве модели данных взята подробная модель телекоммуникационной сети, состоящей из более чем 150 тысяч логических соединений, 100 тысяч физических соединений, 20 тысяч сетевых устройств и элементов. Размер оригинальной базы данных составлял около 500Mb, размер этой же базы в терминах метамодели – 2,5 Gb. Весь объем данных вполне умещается в один экземпляр СУБД Oracle XE. Так как размер базы данных (имеется в виду именно «рабочая» её часть, 2,5 Gb), сравним с объемом оперативной памяти, выделяемой СУБД, при функционировании её немалое значение имеет фактор кэширования в памяти быстрого доступа данных по результатам запросов. Поэтому, вообще говоря, первые запросы (когда известно, что кэш данных пуст), и последующие (при заполненном кэше) могут значительно различаться в производительности. Чтобы избежать вносимой этим фактором ошибки, измерения в каждом случае проводились на базе данных с заполненным кэшем, причем его наполнение было более-менее «типичным» для данной операции. Это достигалось путем warm-up базы данных – предварительного выполнения операций, идентичных измеряемым, но без замера времени выполнения и занесения результата в итоговые таблицы. Таким образом, при этих «холостых» прогонах кэш базы заполнялся некоторым объемом данных, схожим с тем, что будет задействован впоследствии, так, как это обычно происходит в «боевых» системах, где в течение всей жизнедеятельности приложения совершаются примерно одинаковые действия. Усовершенствование методики тестирования таким образом снижает нагрузку на дисковую систему ввода/вывода, но увеличивает загрузку процессора, однако это не влияет значительно на результат, так как в действующих бизнес-системах соотношение объема базы данных с объемом выделяемой оперативной памяти сравнимо с указанным выше, а при масштабировании системы равномерно будет увеличиваться и нагрузка на дисковые подсистемы, и на ядра процессора. Кэширование данных вносит такой же вклад в работу СУБД, как и в исследуемом нами случае. Сценарии тестирования Помимо самих реализаций технологий и моделей данных, в ходе исследования были разработаны вспомогательные «легковесные» приложения, которые позволяют напрямую использовать готовую функциональность для доступа к данным и выводить результат в читаемом виде, а также замерять скорости выполнения операций и журналировать сам процесс выполнения. Для выборки большого количества объектов с их параметрами используется простое web-приложение с единственной jsp-страницей. При заходе на страницу сначала (до включения секундомера) выбирался произвольны набор уникальных идентификаторов объекта (ID) в количестве, для которого должен быть произведен замер, и запоминался в локальной коллекции. Затем для каждого из выбранных идентификаторов посредством исследуемой в данный момент технологии включался поиск объекта со всеми принадлежащими ему параметрами, в цикле по всем выбранным объектам. Наконец, выводилось время, затраченное приложением на выполнение всего сценария, и журналировалось во внешний файл. Таких запусков было проведено несколько: первоначально – для того чтобы заполнить кэш базы данных, на большом количестве объектов и без запоминания результатов, затем последовательные запуски с различным числом участвующих объектов (от 100 до полного размера базы данных – 700 тысяч объектов). Результаты замеров производительности приведены в следующем разделе – «Результаты» Для выборки объекта и его иерархии на подобной jsp-странице был написан простой фрагмент исполняемого кода, который принимает на вход идентификатор «родительского» объекта и рекурсивно «обходит» его детей, подгружая сами объекты и их параметры. Аналогично, сначала выполнялось несколько обходов без измерений, и затем выбирались заранее определенные объекты (с известным количеством потомков в иерархии), и выполнялся обход со включенным секундомером, а результат записывался во внешний файл. Для замеров времени отображения объекта в Web-интерфейсе использовалась бесплатная утилита J-Meter. Основная цель этой утилиты – как раз исполнение заранее заданных сценариев на Web-сервере. Был написан сценарий, в котором участвовали 100 объектов, и J-Meter последовательно навигировался на заданные объекты. Затем замерялось полное время работы сценария, и результат заносился в таблицу в разделе «Результаты» Для измерения выполнения сценария по навигации по объектам системы использовались уже не произвольные объекты в нужном количестве, а объекты, связанные родственными (родитель - дочерний объект) или ссылочными связями. Этот тест исполнялся пользователем – без каких-либо средств автоматизации тестирования. В ходе этого сценария предлагалось проследовать по цепочке связанных друг с другом объектов в Web-интерфейсе, причем время, затраченное на сценарий, замерялось самим пользователем. Такой тест является наиболее субъективным с точки зрения правдоподобности его результатов, но и в то же время является наиболее приближенным к реальным бизнес-процессам, протекающим в полномасштабных информационных системах. Отдельно стоит отметить сценарии, в которых были задействованы некоторые специфические усовершенствования имеющихся технологий, в частности – кэширование данных на стороне Application-сервера. Здесь интерес представляет производительность сценария при работе с полностью закэшированными данными, поэтому перед непосредственно исполнением сценария для замера времени его работы выполнялся абсолютно идентичный сценарий (с тем же набором входных данных), чтобы убедиться, что на стороне сервера все исследуемые данные попали в кэш. Результаты Описание исследуемых случаев Список сценариев, по которым производились замеры, приведен в предыдущей главе, «Методика тестирования производительности». При этом для тестирования указанных сценариев использовались конкретные реализации технологий на различных моделях данных 1. EJB 2.0 Entity-Bean на стороне Apllication-сервера, метамодель в базе данных 2. JPA + MetaModel 3. JPA + Relational Database 4. JDBC-запросы к «плоской» модели данных В качестве дополнительных условий вводились некоторые усовершенствования, доступные в той или иной технологии, как то: 1. Кэширование данных на стороне Application-сервера с технологией EJB 2. Использование внутреннего механизма кэширования JPA 3. Использование обозначенных технологий вне Application-сервера, через настольное Java-приложение Результаты В данном разделе будет приведено несколько групп результатов. Группы объединяют в себе различные технологии, модели и способы настройки приложения, которые схожи по некоторым аспектам их применения. Наборы технология+модель данных+конфигурация, исследуемые в данном разделе, характерны для off-line систем обработки данных. Например, система использующая данный набор может реализовывать workflow-процессы, нацеленные на изменение конфигурации оборудования, находящегося на учете предприятия, или процессы предоставления услуг конечным пользователям, исходя из предопределенного набора продуктов и вариантов. Различия между предложенными наборами – в основном, в трудозатратах на их реализацию, и главным образом – на написание кода, реализующего технологию. Загрузка объектов и их параметров Времена загрузки объектов даны в миллисекундах на объект. Перечень тестируемых реализаций следующий: 1. EJB 2.0 без кэширования на стороне сервера. 2. EJB2.0 с кэшированием только метаданных 3. EJB2.0 с полным кэшированием 4. JPA с настройками кэширования по умолчанию 5. JPA с настройками, призванными наилучшим образом ускорить производительность Результат 1. 2. 3. 4. 5. 100 объектов 24,1 13,2 2,9 12,3 4,9 1000 объектов 23,9 12,6 3,4 15,7 6,2 10K объектов 21,1 14,0 4,15 14,3 6,4 700K объектов 20,5 9,8 8,5 11,3 8,7 Навигация по страницам приложения Такие варианты характерны, например, для настольного приложения оператора callцентра компании, справочной службы, или, подобно предыдущему пункту, также могут быть частью процесса (на этот раз интерактивного) предоставления услуг и настройки оборудования В качестве непосредственно сценариев представлены следующие (время дано в секундах на открытие одной страницы) 1. Навигация по иерархии объектов (например, открыть родительский контейнер, зайти на первый дочерний объект, вернуться на родителя, зайти на следующий дочерний, обойти в свою очередь дочерние для него объекты и т. д.) 2. Навигация по ссылкам между объектами (например, пройти путь между двумя узлами сети передачи данных, заходя на каждый промежуточный сетевой элемент) 3. Открытие отдельной страницы объекта с большим числом параметров (усреднено по большому числу страниц) И в качестве наборов технологий взято следующее 1. EJB 2.0 без кэширования 2. EBJ2.0 с полным кэшированием на стороне сервера 3. JPA с настройками кэширования по умолчанию Результат 1. EJB2.0 nocache 2. EJB2.0 cache 3. JPA default 1. 10 страниц 2,78 1,61 2,37 1. 50 страниц 2,65 1,43 2,24 2. 10 страниц 1,9 1,12 2,16 2. 30 страниц 1,8 1,02 1,99 3. 100 страниц 2,86 2,54 3,43 Отображение отчетов В данном разделе исследования бессмысленно сравнивать различные технологии доступа к данным, так как основная вычислительная нагрузка для такого рода функциональности должна приходиться на базу данных. Попытка применить EJB или JPA при выполнении отчетов приведет к необходимости перебора всего существующего набора данных через соответствующую технологию, а это в свою очередь – к неоправданно большим затратам процессорного времени и излишнего ввода-вывода. Поэтому сравнение происходит именно между «плоскими» моделями данных и метамоделями, при наличии или отсутствии характерных дополнений и усовершенствований. Сами по себе отчеты имеют следующий вид и содержание (время в секундах на один отчет): 1. Отображение объекта со всеми его параметрами (Информация о географических объектах, стоящих на учете предприятия) ~12K объектов 2. Отображение объекта и его всех дочерних для него объектов (Информация об оборудовании со всеми его элементами: картами, портами и коннекторами) ~16K объектов 3. Отображение объекта и связанных с ним соседних объектов через ссылки. ~60K объектов При этом рассматриваются следующие модели хранения данных: 1. Плоская модель 2. Метамодель 3. Метамодель с поддержкой Replicated Database Отдельной строкой в таблице будет время «обновления» информации в отчете – то есть время отклика системы на изменение внешних данных. Это именно время, которое затрачивается системой на обновление хранимой в модели данных информации. Результат Плоская модель Метамодель Метамодель с RDB 1. 7,5 14 1,39 2. 15 21 3,05 3. 51 612 9,56 0 0 7 Refresh Сравнение реализаций подходов по количеству обращений в базу данных Еще одним показательным результатом в данном исследовании является сравнение количества последовательных обращений в базу данных при использовании той или иной технологии доступа. Подробнее о значимости такого сравнения будет сказано в разделе «заключение», здесь же приводятся непосредственно результаты. Исследуются подходы с 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 – AdaptiveObjectModel.com, 2000 http://www.adaptiveobjectmodel.com/OOPSLA2001/AOMIntriguingTechPaper.pdf 6. Leon Welick, Joseph W. Yode, Rebecca Wirfs-Broc Adaptive Object-Model Builder – AdaptiveObjectModel.com, 2009 – http://joeyoder.com/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
