About distributed database management system based on MariaDB server.pdf В связи с интенсивным развитием и появлением новых интернет-технологий, таких,например, как «облачные» вычисления, остаётся актуальной задача распределённойобработки больших объёмов данных в режиме реального времени. Так, имеется необхо-димость в распределённой СУБД, т. е. системе управления, распределённой в компью-терной сети базы данных (БД) [1]. При этом распределённая БД должна обеспечиватьпрозрачный доступ к данным, т. е. должна выглядеть с точки зрения пользователей иприкладных программ как централизованная БД.Наиболее востребованными свойствами распределённых СУБД, ориентированныхна использование в «облачных» сервисах, для которых характерна работа с большими1 Работа выполнена в рамках реализации соглашения о сотрудничестве между кафедрой защитыинформации и криптографии ТГУ и ООО «Хайвекс Технолоджи» по проекту JelasticDB.объёмами данных, большим количеством пользователей, а также работа в условияхрезко изменяющейся нагрузки (возрастание объёма данных и/или потребностей их об-работки), считается масштабирование по требованию и отказоустойчивость. Под мас-штабированием понимается способность системы при увеличении рабочих нагрузокувеличивать свою производительность за счёт увеличения используемых ресурсов.В настоящее время существует множество распределённых СУБД со свойствоммасштабируемости [2], большую часть которых можно отнести к так называемомуNoSQL-подходу, в рамках которого не используются реляционные схемы данных. Дан-ное исследование направлено на разработку принципов построения системы управле-ния реляционной MySQL-совместимой распределённой БД со свойствами масштаби-руемости и отказоустойчивости.За основу взята открытая СУБД MariaDB (ветка MySQL), которая изначально ори-ентирована на управление локальными данными. Использование СУБД с открытымкодом позволяет избежать больших трудозатрат при построении экспериментальногостенда по изучению характеристик разрабатываемой СУБД (время отклика на за-прос, процент использования ресурсов и др.). Кроме того, сервер MariaDB (MySQL)отличается высокой производительностью и является довольно популярным при ис-пользовании как в коммерческих решениях, так и в учебных целях.Рассматривается разновидность многозвенной архитектуры клиент-сервер, когдафункция обработки (хранения) данных вынесена на несколько отдельных серверов.Клиентские приложения обращаются не напрямую к серверам БД, но через проме-жуточный слой. СУБД располагается в компьютерной сети с тремя уровнями узлов:балансировки нагрузки (балансировщики); приёма и обработки SQL-запросов (SQL-узлы); обеспечения физического доступа к данным (узлы хранилища). Запросы отклиентов направляются через балансировщика нагрузки на одну из доступных и наи-менее загруженных машин сети для обработки SQL-запроса. SQL-узел, в свою очередь,обращается к узлу хранилища, на котором находятся требуемые данные. Баланси-ровщик выявляет также отказавшие сервера и перенаправляет трафик SQL-запросовна рабочие узлы. Для повышения надёжности и увеличения быстродействия данныетиражируются по нескольким узлам хранилища с использованием механизма репли-кации. Для обеспечения обработки данных большого объёма используется механизмфрагментации, т. е. разбиение на части и распределение по отдельным узлам хранили-ща. В качестве узлов балансировки нагрузки используются MySQL proxy, в качествеSQL-узлов и узлов хранилища - серверы MariaDB.Такая архитектура обеспечивает горизонтальную масштабируемость и эластич-ность на всех уровнях, поскольку возможно увеличение (уменьшение) числа узлов лю-бого типа для повышения производительности системы при возрастании (уменьшении)рабочей нагрузки или для решения проблем, связанных с изменением размеров БД.В традиционном варианте сервер MariaDB включает в себя четыре основных мо-дуля [3]: кэш SQL-запросов; синтаксический анализатор SQL-запросов; оптимизаторSQL-запросов; движок хранилища данных (storage engine, далее - движок). Совокуп-ность модулей сервера MariaDB, за исключением движка, будем называть ядром. Об-ращение к движку происходит посредством низкоуровневого storage API, представ-ляющего собой список функций, выполняющих простые операции с таблицей. Дви-жок преобразует запросы к нему в операции чтения-записи диска. Кроме того, дви-жок может поддерживать много дополнительных возможностей, таких, как создание иподдержка структуры индексов, обеспечение ACID транзакций и др. СУБД MariaDBпозволяет в зависимости от конкретных нужд приложения использовать различныедвижки хранилища данных, которых на данный момент существует более десятка [4].Особенностью предлагаемого решения является использование удалённого движ-ка, который располагается на узле хранилища; в качестве него можно взять любойMySQL-совместимый движок. В типовом случае сервер MariaDB устанавливается наодной машине, на которой располагается и система хранения. В нашем случае серверMariaDB разделен на две части: ядро и движок. При этом движок вынесен на удалён-ный узел, который по сети принимает запросы от ядра. Для реализации данной схемыразработаны дополнительные модули для сервера MariaDB: виртуальный движок ивиртуальное ядро, а также протокол VSVD сетевого взаимодействия этих модулей.На SQL-узле устанавливается сервер MariaDB, использующий виртуальный дви-жок, а на узле хранилища - сервер MariaDB с загруженным реальным движком, новиртуальным ядром. SQL-узел не хранит данных, кроме описания БД и таблиц. Вир-туальный движок и виртуальное ядро нужны для состыковки реальных ядра и уда-лённого движка, чтобы ядро сервера MariaDB SQL-узла работало с удалённым движ-ком сервера MariaDB узла хранилища и наоборот, не замечая, что на самом деле онивзаимодействуют через сеть. Виртуальный движок перенаправляет запросы на узелхранилища, где виртуальное ядро принимает эти запросы и обращается с ними к ре-альному движку. Более подробно: каждый SQL-запрос в ядре MariaDB превращаетсяв серию вызовов функций storage API, которые группируются в одну функцию VSVDAPI, сериализуются и передаются на соответствующий узел хранилища, где формиру-ется ответ и таким же образом отправляется назад. Тем самым протокол VSVD схожс протоколом RPC по характеру своей работы (удалённый вызов процедуры). На сер-вере MariaDB узла хранилища стандартный MySQL-протокол отключен, используетсяпротокол VSVD для приема/передачи запросов VSVD API.Необходимой составляющей любого SQL-узла является базовый модуль, отвечаю-щий за репликацию и фрагментацию данных, управление одновременным доступомк данным, маршрутизацию storage API запросов, масштабирование и отказоустойчи-вость на уровне узлов хранилища.На данный момент реализована сетевая подсистема распределённой СУБД на ос-нове разделения сервера MariaDB на ядро и удалённый движок. Результаты работымогут быть использованы для построения экспериментального образца реляционноймасштабируемой распределённой СУБД, для чего необходимо разработать соответ-ствующее алгоритмическое и программное обеспечение для базового модуля SQL-узла.

Скачать электронную версию публикации