Резидентные в памяти базы данных в телекоммуникационных сетях

Резидентные в памяти базы данных в телекоммуникационных сетях РЕЗИДЕНТНЫЕ В ПАМЯТИ БАЗЫ ДАННЫХ В ТЕЛЕКОММУНИКАЦИОННЫХ СЕТЯХ Выпускная квалификационная работа студента 352 группы Божко Константина Александровича Научный руководитель Анциперов В.Е к.ф м.н. г. Москва 2009 ВВЕДЕНИЕ 2 ИСПОЛЬЗОВАНИЕ

РЕЗИДЕНТНОЙ В ПАМЯТИ БАЗЫ ДАННЫХ В ТЕЛЕКОММУНИКАЦИОННЫХ СЕТЯХ 3 ИСПОЛЬЗОВАНИЕ РЕЗИДЕНТНЫХ В ПАМЯТИ БАЗ ДАННЫХ ДЛЯ РЕГИСТРАЦИИ ЗВОНКОВ МОБИЛЬНОЙ СВЯЗИ 3 ОСНОВНЫЕ ОТЛИЧИЯ РЕЗИДЕНТНЫХ В ПАМЯТИ БАЗ ДАННЫХ ОТ СТАНДАРТНЫХ 7 ПОЧЕМУ РЕЗИДЕНТНЫЕ В ОПЕРАТИВНОЙ ПАМЯТИ БАЗЫ ДАННЫХ

БЫСТРЕЕ? 7 ДОСТУПНОСТЬ ДАННЫХ В СЛУЧАЕ СБОЯ ОБОРУДОВАНИЯ 8 ЦЕЛИ И ЗАДАЧИ ЭКСПЕРИМЕНТОВ 12 СХЕМА ЭКСПЕРИМЕНТА 13 СХЕМА С ИСПОЛЬЗОВАНИЕМ СУБД 17 КОМПОНЕНТЫ ЭКСПЕРИМЕНТА В ТРАДИЦИОННОЙ СХЕМЕ 17 ЗАВИСИМОСТЬ ПРОИЗВОДИТЕЛЬНОСТИ ОТ КОЛИЧЕСТВА КОМАНД ПЕРЕД ЗАВЕРШЕНИЕМ ТРАНЗАКЦИИ 18

РЕЗУЛЬТАТЫ ЭКСПЕРИМЕНТА 1. Результаты эксперимента в синхронном случае 2. Результаты эксперимента в асинхронном случае 22 IMESTEN 25 КОМПОНЕНТЫ ЭКСПЕРИМЕНТА В АЛЬТЕРНАТИВНОЙ СХЕМЕ 25 РЕЗУЛЬТАТЫ ЭКСПЕРИМЕНТА 1. Результаты эксперимента в синхронном методе журналирования 26 2.

Результаты эксперимента в асинхронном случае 29 СРАВНЕНИЕ РЕЗУЛЬТАТОВ 31 СРАВНЕНИЕ В СИНХРОННОМ СЛУЧАЕ 31 СРАВНЕНИЕ В АСИНХРОННОМ СЛУЧАЕ 32 ЗАКЛЮЧЕНИЕ 33 ЛИТЕРАТУРА 35 ПРИЛОЖЕНИЯ 36 КОД ПРОГРАММЫ ГЕНЕРАТОРА 36 КОД ПРОГРАММЫ ПРИЛОЖЕНИЯ (ИНТЕРФЕЙС OCI) 38 КОД ПРОГРАММЫ ПРИЛОЖЕНИЯ (ИНТЕРФЕЙС

ODBC) 47 ПАРАМЕТРЫ СУБД ORACLE10G 53 IMESTEN 54 ВВЕДЕНИЕ В последние годы приобрёл популярность новый класс баз данных – резидентные в оперативной памяти базы данных (in-memory databases). Основная особенность архитектуры таких СУБД состоит в том, что база данных целиком размещается в оперативной памяти сервера, что позволяет отказаться от достаточно сложных алгоритмов обслуживания

Кеш-буферов традиционных СУБД, а это, в свою очередь, даёт существенный выигрыш в производительности приложений баз данных. В качестве примера СУБД резидентных в оперативной памяти баз данных можно назвать Oracle TimesTen, Altibase, SolidDB, CSQL, SQLite и многие другие (см например, http://en.wikipedia.org/wiki/In-memory_d atabase). Разработчики этих СУБД позиционируют их как СУБД реального времени, поэтому резидентные в оперативной памяти базы данных используются только в специальных

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

СУБД интерфейсами – ODBC, JDBC и поддерживают язык запросов SQL. Это позволяет использовать многие из имеющихся приложений баз данных и с резидентными в оперативной памяти базами данных с минимальными доработками этих приложений. Казалось бы, все перечисленные достоинства резидентных в оперативной памяти баз данных должны были бы привести к их всеобщему использованию во всех отраслях, где используются реляционные базы данных,

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

СУБД – сервера Oracle и СУБД Oracle TimesTen, работающей с резидентными в оперативной памяти базами данных. Хотелось на опыте убедиться в том, что производительность СУБД Oracle TimesTen значительно превосходит производительность сервера Oracle при аналогичных функциональных характеристиках. ИСПОЛЬЗОВАНИЕ РЕЗИДЕНТНОЙ В ПАМЯТИ БАЗЫ ДАННЫХ В ТЕЛЕКОММУНИКАЦИОННЫХ

СЕТЯХ ИСПОЛЬЗОВАНИЕ РЕЗИДЕНТНЫХ В ПАМЯТИ БАЗ ДАННЫХ ДЛЯ РЕГИСТРАЦИИ ЗВОНКОВ МОБИЛЬНОЙ СВЯЗИ Для современной мобильной связи актуально использование высокопроизводительных систем регистрации длительности звонков, а также использования абонентами дополнительных услуг связи, например, роуминг, GPRS, переадресация вызова. Например, когда абонент делает звонок, нужно зафиксировать длительность вызова, а также использование роуминга, если звонок совершён из другого региона либо абонент

пересёк границу регионов обслуживания во время вызова. При этом наша система регистрации должна обрабатывать до нескольких десятков тысяч конкурентных звонков, собирать статистику по ним и сохранять эту информацию в некой центральной базе данных. Стандартная система такова: вся информация сохраняется напрямую в одной таблице в центральной, “дисковой” реляционной базе данных, где потом обрабатывается и используется приложениями.

Однако с ростом количества абонентов увеличивается число обращений к таблице. Как следствие, растёт конкуренция между обращениями. При достижении максимальной производительности увеличивается время ожидания в очереди за доступом к таблице. Абонентам приходится долго ждать соединения, а иногда они вообще не могут дозвониться. В таких случаях необходима модернизация оборудования.

Рис. 1. Стандартная схема обработки звонков мобильной связи. В качестве альтернативного решения предлагается использование набора резидентных в оперативной памяти баз данных в качестве посредников между приложением, обслуживающим звонки, и центральной “дисковой” базой данных. Каждая такая база обеспечивает немедленное сохранение данных вызова до тех пор, пока эта информация не достигнет центральной базы. Предлагается децентрализовать процесс сбора информации по

звонкам, распределив несколько экземпляров регистрирующего приложения и резидентных оперативной в памяти баз данных на отдельных узлах по всей зоне обслуживания абонентов. Рис. 2. Альтернативная схема обработки звонков мобильной связи. На каждом отдельном узле приложение соединяется локально с резидентной в оперативной памяти базой для регистрации начала и/или окончания вызова в своей географической зоне.

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

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

хранения общей статистики о звонках, а также для восстановления базы в случае падения репликации. А в случае падения основного узла этот фоновый процесс “агент” переадресует обращения к резервному узлу. Каждый раз, когда абонент звонит, получает или прерывает вызов по мобильной связи, приложение делает запись в таблицу резидентной в оперативной памяти базы данных. Каждая такая запись содержит время записи, идентификатор, а также информацию о использованных услугах.

Фоновый процесс “агент” периодически выборку первых несколько тысяч строк на своём узле и передаёт эту информацию в центральную “дисковую” СУБД. После успешного завершения передачи этих данных выбранные строки удаляются из базы «в памяти» на данном узле. ОСНОВНЫЕ ОТЛИЧИЯ РЕЗИДЕНТНЫХ В ПАМЯТИ БАЗ ДАННЫХ ОТ СТАНДАРТНЫХ ПОЧЕМУ РЕЗИДЕНТНЫЕ В ОПЕРАТИВНОЙ ПАМЯТИ

БАЗЫ ДАННЫХ БЫСТРЕЕ? Основная работа стандартной, дисковой СУБД происходит в предположении, что данных расположены на диске. Алгоритмы оптимизации, управление пулами, технология индексного поиска сконфигурированы основываясь на этом предположении. Даже когда дисковая база сконфигурирована так, что вся информация находится в главной памяти, её производительность ограничена предположением нахождения данных на диске.

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

индексные страницы, и их структура упрощается. Схема управления данными становится проще и компактнее. Рис. 3. Сравнение стандартной базы данных с встроенной. В традиционных СУБД, клиентское приложение обращается к серверу базы данных через некоторые типы IPC соединений, которые ухудшают производительность SQL-операций. Приложение может ссылаться напрямую в адресное пространство встроенной базы данных, избегая

накладные расходы IPC-соединений и рационализирую обработку запросов. Такое соединение называется «прямым». Традиционный клиент-серверный доступ также возможен, хотя такая конфигурация привносит значительное ухудшение в производительность сервера резидентной в оперативной памяти базы данных из-за накладных расходов, связанных с сетевым доступом. ДОСТУПНОСТЬ ДАННЫХ В СЛУЧАЕ СБОЯ ОБОРУДОВАНИЯ Защита данных от сбоев оборудования достигается через

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

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

изменений в другую базу данных;  репликация изменений в резидентной в оперативной памяти базе данных в таблицу дисковой базы (в случае её использования в качестве кэша СУБД);  позволяет приложению определять изменения в таблице. Так же есть операция, называемая контрольной точкой. Этот процесс является фоновым и имеет слабое воздействие на операции в базе данных (в случае асинхронных

контрольных точек). Контрольные точки выполняются автоматически, их периодичность зависит от предварительно установленных атрибутов используемых хранилищ данных. Для сохранности файлов данных на диске в случае сбоя, произошедшего во время выполнения контрольной точки, их создаётся несколько (обычно 2). Эти файлы обновляются по очереди и должны быть расположены на отдельных дисках от тех, на которых хранятся журнальные файлы с целью уменьшения конкуренции ввода/вывода.

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

для облегчения модернизации и сопровождения баз данных. Рис. 4. Репликация встроенной базы данных. Для достижения наилучшей производительности используется схема репликации, основанная на транзакционных записях. Репликация на основном и дополнительном экземпляре контролируется репликационным агентом, который оперирует по протоколу TCP/IP. Репликационный агент на основном сервере читает записи из транзакционного журнала.

Он направляет эти изменения своему второму элементу на дополнительном сервере. Далее репликационный агент на дополнительном сервере делает обновление в дополнительной базе данных. Если агент подписчика не готов принять записи, направленные ему с основного сервера, агент мастера сохраняет не переданные записи в своём журнале до тех пор, пока они не будут применены на дополнительном сервере. В описанном ранее сценарии использования встроенных баз данных используется репликация в конфигурации

“зеркальная копия”. Основная база данных повторяется дополнительной с соответствующим механизмом доступности, встроенном в приложение. Рис. 5. Репликация в конфигурации «зеркальная копия». ЦЕЛИ И ЗАДАЧИ ЭКСПЕРИМЕНТОВ Целью проводимых мной экспериментов было оценить количественно преимущество использования резидентных в оперативной памяти баз данных перед стандартной СУБД. Основным показателем являлось максимальная производительность приложения – то есть такое максимальное

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

схеме. В этом случае графики производительности выходили на некоторую аппроксимирующую прямою, которая и характеризовала максимальное количество обработанных звонков в секунду. Также обе схемы (с использованием стандартной СУБД и резидентной в оперативной памяти базой данных) тестировались в двух режимах записи журнальной информации на диск – синхронном и асинхронном. Это делалось потому, что использование резидентных в оперативной памяти баз данных в своей основе предполагает

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

оценить выигрыш в производительности при использовании баз данных «в памяти» не зависимо от сервера. СХЕМА ЭКСПЕРИМЕНТА Цель моего эксперимента состояла в сравнении показателей производительности, которые можно достичь используя архитектуру стандартной СУБД и резидентной в оперативной памяти баз данных. Также ставилось задача максимально приблизить эксперимент к процессам, происходящим в реальной жизни. Эксперимент представляет собою макет, генерирующий звонок абонента по мобильной связи и обрабатывающий

этот вызов. В обработке звонка я отказался от операции резервирования средств для совершающего звонок абонента для проверки возможности вызова. То есть интересовал сам факт совершения вызова, рассматривалась система