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

· + экономия времени работы дисковых подсистем базы данных

· + экономия затрат на сетевую передачу данных

· - дополнительные накладные расходы на содержание кэша в памяти сервера приложений

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

· - проблема тупиков «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
Refresh	0	0	7