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

Обновлено: 06.01.2025

Как показывает мировая практика и наш личный опыт, если высоконагруженное корпоративное приложение начинает медленно обрабатывать запросы пользователя, то с большей степенью вероятности проблема кроется в работе с базой данных (БД). Реляционные БД стали стандартом для хранения данных, и организация их работы с серверным и клиентским приложением — одна из самых важных задач разработчиков. Чтобы сделать платформу SimpleOne действительно быстрой, мы применили несколько современных технологий масштабирования и балансировки: разделили данные по типам, распределив их по четырём видам серверов, применили горизонтальное масштабирование и настроили кеширование с помощью базы данных NoSQL. Кроме того, мы поставили себе задачу минимизировать число обращений к БД и сделать их максимально быстрыми.

Кластеризация и горизонтальное масштабирование

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

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

Распределение данных и запросов между узлами кластера помогает во многих вычислительных задачах. Большинство корпоративных информационных систем способны выполнять вычисления одновременно на нескольких серверах, распределяя нагрузку, чтобы повысить скорость обработки данных. Однако при работе приложений с базами данных такой вариант не является самым оптимальным. Мы используем «умное» горизонтальное масштабирование, которое использует определённые ноды для решения конкретных задач.

Работа «умного» балансировщика

Балансировка в SimpleOne

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

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

Специализация серверов

Первый уровень масштабирования — распределение системы по видам выполняемых задач. Мы используем четыре типа серверов:

серверы клиентского приложения;
серверы системного приложения;
серверы баз данных;
серверы файлового хранилища.

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

Взаимодействие серверов в SimpleOne

Иерархия баз данных

На уровне реляционных баз данных мы используем архитектуру Master/Slave, в которой применяется репликация. Сервер БД Master получает только запросы на запись и реплицирует их на несколько серверов Slave. А все запросы на чтение обрабатывают серверы Slave. Таким образом, несмотря на то, что Master должен продублировать всю информацию на несколько Slave, он оказывается не сильно загружен, так как не отвечает за чтение. В свою очередь, большинство запросов к БД от системного приложения производятся именно на чтение, и, поставив 10 серверов Slave, мы почти в 10 раз увеличиваем производительность системы.

Обмен данными в архитектуре Master/Slave

Следующим этапом масштабирования является партицирование.

Партицирование

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

Например, принцип партицирования используется для распределения по разным серверам таблиц ядра системы и пользовательских таблиц. В отдельной базе данных на выделенном сервере размещены часто используемые sys_db_table, sys_db_column, user и другие системные таблицы, а те пользовательские таблицы вынесены на другие, менее производительные серверы.

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

Партицирование БД

Шардирование

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

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

Шардирование БД

Отдельное хранение файлов

Последним уровнем распределения данных, который мы используем в SimpleOne, является вынесение файлов за пределы базы данных. PostgreSQL позволяет хранить файлы непосредственно в БД, но, когда такие файлы имеют ощутимый размер, их чтение и запись снижают производительность всей БД. Поэтому в БД мы оставляем только ссылки на файлы, а сами данные выгружаем на отдельный файловый сервер S3. Так сокращается и число обращений к БД, и нагрузка на операции ввода-вывода.

Подробнее об этом можно прочитать в статье «Эффективное хранение данных в SimpleOne».

Базы данных и кеширование

На протяжении нескольких лет мы используем реляционную систему управления базами данных PostgreSQL и имеем экспертные знания в её настройке и администрировании. Это одна из старейших реляционных баз данных, работа с которой несколько сложнее, чем с MySQL или SQLite, но в результате грамотной настройки она даёт отличную стабильность и скорость работы. Ключевыми преимуществами использования PostgreSQL в SimpleOne стали полная SQL-совместимость, возможность программного расширения для хранения собственных процедур и обеспечение высокого уровня целостности данных.

Однако, сделав свой выбор в пользу PostgreSQL для хранения основного массива данных, мы дополнили ее кеширующим слоем в виде БД Redis, которая использует оперативную память сервера для хранения наиболее горячих данных. Такая связка показала отличную производительность, и о ней мы расскажем дальше.

Обработка запросов на чтение с использованием кеша на основе БД Redis

Особенности кеширования

Для горячих данных мы используем технологию с большой скоростью доступа — NoSQL Data Base. Она позволяет создавать кеш с наиболее используемыми данными в оперативной памяти сервера, которая имеет наивысшую скорость чтения. После первичного запроса к БД данные переносятся в кеш и в дальнейшем читаются уже из него. Причём некоторая информация из таких таблиц, как SSISDB table, SSISDB column, SSISDB columntype, всегда востребована и её сразу можно перемещать и хранить в кеше. Так мы не только ускоряем доступ к этим данным, но и разгружаем серверы БД, поскольку кеш может храниться в оперативной памяти серверов системных приложений.

В то время как традиционные СУБД соответствуют требованиям ACID к транзакционной системе, используемая для кеша база данных NoSQL вполне может работать с набором свойств BASE. Требования ACID (Atomicity — Атомарность, Consistency — Согласованность, Isolation — Изолированность, Durability — Долговечность) обеспечивают наиболее надёжную и предсказуемую работу БД. В то время как BASE (Basically Available — Базовая доступность, Soft State — Гибкое состояние, Eventual Consistency — Согласованность в конечном счёте) менее требовательны к транзакциям и согласованности данных.

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

Заключение

Наша стратегия — увеличение производительности за счёт сокращения размеров запросов, горизонтального масштабирования и балансировки нагрузки. Мы разделили все задачи по типам и обрабатываем их параллельно на разных серверах, а горизонтальное масштабирование серверов системных приложений и баз данных позволяет эффективно использовать ресурсы и плавно наращивать мощность. Платформа SimpleOne разрабатывается с учётом этих требований и может выполнять параллельные запросы к множеству экземпляров БД, показывая отличные результаты быстродействия в проектах любого масштаба.

16 Апреля 2021

Сервер баз данных (или сервер БД) - это важный сегмент в жизни любой компании, который должен обеспечивать целостность, сохранность и доступность данных в режиме 24/7. Что же это за серверы, какие типы БД бывают и какое железо под них необходимо читайте далее.

На серверах БД обычно хранится различная корпоративная информация, а также обрабатываются базы данных клиент-серверных программ. К выбору сервера предъявляются высокие требования - чем надежней, быстрее и отказоустойчивей будет оборудование, тем выше будет производительность и сохранность баз данных.

Существует много самых разнообразных современных серверов, повышающих рабочие показатели БД, однако существует большое множество типов баз данных, и какой же сервер нужен для каждого типа?

Виды баз данных

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

Базы данных SQL делятся на несколько видов:

MySQL - реляционные open source базы данных, предназначенные для небольших и средних проектов и представляющие собой недорогие и надежные инструменты. MySQL-БД поддерживают большое количество таблиц, имеют множество расширений и плагинов, упрощающих работу с системами. Они просты в установке, могут быть интегрированы в другие БД, и подходят для работы в любых CMS, фреймворки и языках программирования. В основном они используются локальными или удаленными клиентами, позволяя им работать с таблицами разных типов, поддерживающих полнотекстовый поиск или выполняющих транзакции на уровне отдельных записей;
PostgreSQL - занимает второе место по востребованности среди open source SQL-БД. Обладает большим числом встроенных функций и дополнений, в том числе для масштабирования в кластер и шардинга таблиц. Используется для работы со сложными данными при высоких требованиях к их сохранности, поскольку стабильна и практически не «ломается». Позволяет работать со структурированными данными, но поддерживает JSON/BSON, что дает некоторую гибкость в схеме данных. Также PostgreSQL предназначена для создания, хранения и извлечения сложных структур данных. Она поддерживает самые различные типы данных (среди них - числовые, текстовые, булевы, денежные, бинарные данные, сетевые адреса, xml и другие);
MSSQL - многопользовательский программный продукт, разработанный компанией Microsoft, обладающий высокой производительностью и отказоустойчивостью, тесно интегрированный с ОС Windows. Этот сервер поддерживает удаленные подключения, работает с многими популярными типами данных, дает возможность создавать триггеры и хранимые данные, имеет практичные и удобные утилиты для настройки. В основе языка запросов этой СУБД используется Transact-SQL (совместная разработка Microsoft и Sybase). При этом Transact-SQL - это реализация стандарта ANSI/ISO по SQL (структурированному языку запросов), но имеющая некоторые расширения. MSSQL широко применяется не только в веб-проектах, но и в desktop-программах. Ее используют при работе с реляционными БД различных размеров, начиная от персональных и заканчивая крупными базами данных в масштабе предприятия. Она задействуется в случаях, когда функционала MySQL оказывается недостаточно;
Oracle Database - это многомодельная объектно-реляционная СУБД, обычно используемая при выполнении задач по оперативной обработке транзакций (OLTP), обслуживанию хранилищ данных (DW) и для рабочих нагрузок по смешанным (OLTP и DW) базам данных. Она включает в себя табличные пространства, управляющие файлы, журналы и архивные журналы, файлы трассировки изменения блоков, ретроспективные журналы, файлы резервных копий (RMAN). Используя эту БД, можно как автоматизировать обычные бизнес-операции, так и выполнять динамический многомерный анализ данных (OLAP), проводить операции с документами xml-формата и управлять разделенной и локальной информацией.

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

Как подобрать сервер под базу данных?

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

для кэширования наиболее интенсивно используемых участков базы данных задействуется большой объем оперативной памяти;
дисковая подсистема должна характеризоваться высокой производительностью, то есть способностью обрабатывать большое количество небольших запросов в единицу времени - IOPS (input/output per second);
для обработки запросов и операций над данными необходима высокая вычислительная мощность.

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

Сервера под базу данных должны соответствовать аппаратным требованиям, зависящим от числа пользователей:

для 10 пользователей требуется сервер с частотой процессора не менее 2,2 ГГц, не менее двух ядер на каждый процессор, не менее 4 Гб оперативной памяти типа DDR3, не менее 3 SAS/SATA дисков, имеющими скорость вращения 7200 об/мин.;
для 20 пользователей требуется сервер с частотой процессора не менее 2,3 ГГц, не менее четырех ядер на каждый процессор, не менее 6 Гб оперативной памяти типа DDR3, не менее 3 SAS/SATA дисков, имеющими скорость вращения 7200 об/мин.;
для 50 пользователей требуется сервер с частотой процессора не менее 2,5 ГГц, не менее восьми ядер на каждый процессор, не менее 16 Гб оперативной памяти типа DDR3, не менее 6 SAS/SATA дисков, имеющими скорость вращения 7200 об/мин.;
для 100 пользователей требуется сервер с двумя процессорами частотой не менее 2,8 ГГц, не менее десяти ядер на каждый процессор, не менее 16 Гб оперативной памяти типа DDR4, не менее 10 SAS дисков, имеющими скорость вращения 10000 об/мин.;
для 200 пользователей требуется сервер с четыремя процессорами частотой не менее 2,8 ГГц, не менее 8 ядер на каждый процессор, не менее 64 Гб оперативной памяти типа DDR4, не менее 16 SAS дисков, имеющими скорость вращения 10000 об/мин.;
для 500 пользователей требуется сервер с четыремя процессорами частотой процессора не менее 3 ГГц, не менее 16 ядер на каждый процессор, не менее 128 Гб оперативной памяти типа DDR4, не менее 24 SAS дисков, имеющими скорость вращения 10000 об/мин.;

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

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

Например, при одновременной работе с типовым проектом 100 пользователей необходимая ширина канала сервера баз данных:

минимальная: 100 Мбит/сек;
рекомендуемая: 1 Гбит/сек.

Ширина канала при этом находится в линейной зависимости от количества пользователей.

Что выбрать: SSD или HDD? А может NVMe?

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

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

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

Главное преимущество SSD перед HDD состоит в том, что «твердотельники» существенно ускоряют работу сервера. Если классический накопитель осиливает чтение данных на скорости до 230 Мб/с, SSD могут прочитать до 700 Мб/с и более. Разница в скорости записи также существенна - SSD записывают 500 Мб/с и более, а HDD, в лучшем случае - 90 Мб/с. Если необходимо быстрое решение задач при большой загрузке оборудования - то стоит остановить свой выбор на SSD.

Сравниваем IOPS для наиболее популярных SSD.

Кроме того, SSD отличаются от HDD независимостью скорости чтения от фрагментации файлов, меньшими габаритами и весом (SSD могут быть конструктивно выполнены в корпусах гораздо меньших размеров, чем HDD). Однако число циклов перезаписи у твердотельных накопителей меньше, чем у жестких дисков, и стоят SSD дороже.

Также активно «наступает на пятки» HDD-дискам накопитель стандарта NVMe (Non-Volatile Memory Express). Этот стандарт был разработан для максимально полного использования потенциала технологии флэш-памяти. Современные накопители NVMe Gen3 на базе PCI повышают производительность серверов до 5000 Мб/с, то есть в десять раз больше аналогичного показателя для SSD SATA\SAS.

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

Но тотального перехода с HDD и SSD стандарта SATA\SAS на NVMe пока не предвидится, поскольку только на базе жестких и твердотельных накопителей возможна сборка аппаратных RAID-массивов, а RAID нужно строить обязательно, поскольку вероятность выхода из строя дисков очень высока, а время простоев сервера баз данных должно быть равна нулю, либо хотя бы к нему стремиться. Хотя стоит отметить, что компания DELL анонсировала поддержку аппаратного RAID на NVMe накопителях в своём новейшем поколении серверов Gen15. Увы, тестов и обзоров на момент написания статьи ещё нет.

А самый дешёвый SSD не быстрее будет?

Стоимость SSD выше, по сравнению с жесткими дисками, однако экономить на покупке твердотельника на стоит.

Если приобрести самый дешевый SSD, можно свести на нет производительность сервера: накопители перестанут справляться с растущим количеством операций записи, что может привести к задержкам в работе RAID-массивов и к выходу накопителей из строя. Потребительский SSD, на который взвалили такую огромную нагрузку, перейдет в режим чтения Read Only, то есть записать в него информацию станет невозможно.

Кроме того, если выбрать вместо корпоративного SSD накопитель клиентского класса, то он окажется неподходящим для чтения или записи в условиях нагрузки 24/7. Цикл нагрузки клиентских SSD строится по схеме 20/80 (20% времени в активной работе, 80% - в режиме ожидания или в спящем режиме).

При оценке пригодности SSD для сервера базы данных следует обращать внимание значения IOPS, Latency и DPWD.

Наши рекомендации

Мы рекомендуем использовать кластеры баз данных из нескольких серверов, чтобы обеспечить отказоустойчивость. Надёжными представителями отказоустойчивости являются производители Hewlett Packard Enterprise и DELL. Новые серверы не всегда могут быть по карману, поэтому мы предлагаем нашим клиентам взять сервер на вторичном рынке, при этом в идеальном состоянии и с гарантией 2 года. Например:

В предыдущей статье данного цикла, опубликованной в № 4’2000 нашего журнала, мы рассмотрели наиболее популярные настольные СУБД, такие как dBase, Paradox, FoxPro, Access, MSDE. Настоящая статья посвящена серверным СУБД — Oracle, Informix, DB2, Sybase, Microsoft SQL Server.

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

Архитектура «клиент-сервер»

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

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

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

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

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

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

Сервер баз данных осуществляет целый комплекс действий по управлению данными. Основными его обязанностями являются:

В качестве рабочего места пользователя может быть использован обычный персональный компьютер, что позволяет не отказываться от привычной рабочей среды. Иными словами, в простейшем случае клиент-серверная информационная система состоит из двух основных компонентов:

Существуют и более сложные реализации архитектуры «клиент-сервер», например многозвенные информационные системы с использованием серверов приложений, реализующих бизнес-логику и осуществляющих обработку данных. Однако обсуждение архитектуры таких систем находится за пределами данного обзора — о подобных системах мы, возможно, поговорим в конце данного цикла.

Преимущества архитектуры «клиент-сервер»

Информационные системы, использующие архитектуру «клиент-сервер», обладают серьезными преимуществами по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД. Ниже будут рассмотрены наиболее важные из них.

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

Вторым преимуществом архитектуры «клиент-сервер» является возможность хранения бизнес-правил (например, правил ссылочной целостности или ограничений на значения данных) на сервере, что позволяет избежать дублирования кода в различных клиентских приложениях, использующих общую базу данных. Кроме того, в этом случае любое редактирование данных, в том числе и редактирование средствами, не предусмотренными разработчиками информационной системы (например, различными утилитами администрирования сервера), может быть произведено только с учетом этих правил. Если последние версии некоторых настольных СУБД и способны хранить ограничения на значения данных либо тексты SQL-запросов, триггеры и хранимые процедуры в них, как правило, отсутствуют — их просто некому выполнять. Исключением здесь, пожалуй, является только Microsoft Data Engine, но, как мы уже говорили в предыдущей статье данного цикла, отнести к настольным эту СУБД можно весьма условно — фактически MSDE представляет собой локальный сервер баз данных, обладающий всеми характерными для серверной СУБД атрибутами, включая отдельный серверный процесс.

В первой статье данного цикла (см. КомпьютерПресс 3’2000) мы уже упоминали о том, что для описания серверных бизнес-правил в наиболее типичных ситуациях (например, при реализации связей master/detail) нередко используются так называемые CASE-средства (CASE означает Computer-Aided System Engineering) для создания диаграмм «сущность-связь». Эти инструменты позволяют описать подобные правила на уровне логической и физической моделей данных без какого бы то ни было программирования, а затем сгенерировать код соответствующих серверных объектов — триггеров, хранимых процедур, серверных ограничений. В этом случае клиентские приложения будут избавлены от значительной части кода, связанного с реализацией бизнес-правил непосредственно в приложении. Отметим также, что часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых процедур сервера, что позволяет еще больше «облегчить» клиентское приложение, а это означает, что требования к рабочим станциям могут быть не столь высоки. Это в конечном итоге снижает стоимость информационной системы даже при использовании дорогостоящих серверной СУБД и аппаратного обеспечения.

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

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

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

Модернизация устаревших информационных систем

С проблемой модернизации устаревших информационных систем рано или поздно сталкивается почти каждый разработчик или IT-менеджер. В нашей стране все еще нетрудно встретить банковские системы, использующие dBase, а также относительно свежие коммерческие разработки, созданные с помощью Clipper, средством обмена данными которым служат отнюдь не Internet и не сетевые протоколы, а курьер с дискетами и электричка (это вовсе не всегда происходит из-за неосведомленности разработчиков — просто у их клиентов нет и в ближайшее время не будет денег на приличное оборудование и соответствующую инфраструктуру). Именно поэтому мы полагаем, что проблема модернизации информационных систем в России еще долго будет оставаться актуальной.

В целом варианты модернизации информационной системы можно условно разделить на следующие категории:

1. Замена СУБД с сохранением структуры базы данных и пользовательских приложений (или относительно небольшой их модернизацией).

2. Замена и СУБД, и пользовательских приложений с сохранением структуры базы данных.

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

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

Первая категория представляла собой драйверы различных серверных СУБД для средств разработки, ориентированных в целом на использование настольных баз данных (например, драйверы Oracle для Clipper, преобразовывающие функции Clipper в вызовы функций клиентского API Oracle — Oracle Call Interface); обычно эти драйверы поставлялись в виде библиотек, компилируемых вместе с приложением. «Потомки» подобного программного обеспечения существуют и сейчас — одним из них является, например, библиотека Borland SQL Links, изначально предназначенная для использования приложений Paradox с серверными СУБД.

Вторая категория продуктов, ныне практически забытая, представляла собой некое подобие серверов баз данных, управлявших набором файлов настольных СУБД. Типичными примерами таких продуктов являлись разнообразные «dBase-серверы», управлявшие набором dBase-таблиц и перехватывавшие обращения к ним клиентских приложений. Подобные «серверы» в определенной степени решали проблему сетевого трафика и даже поддержки ссылочной целостности, но в силу ограничений, накладываемых на хранимый объем данных, характерных для форматов настольных СУБД, достаточно быстро уступили место «настоящим» серверам баз данных.

Если говорить о первом варианте модернизации, в этом отношении больше всего повезло пользователям Microsoft Access — процесс замены базы данных Microsoft Access на MSDE (или Microsoft SQL Server) происходит достаточно безболезненно, и пользовательские приложения при этом обычно сохраняют свою работоспособность. Так как в данном случае все эти СУБД (Access, MSDE и SQL Server) принадлежат одному производителю, перенос данных между ними осуществляется вполне корректно, с сохранением всех определенных в базе данных бизнес-правил. Кроме того, утилиты переноса данных из Access содержатся в комплекте поставки и других серверных СУБД (например, Oracle). Относительно безболезненно можно осуществить перенос данных из Visual FoxPro в Microsoft SQL Server.

Что касается замены других версий настольных СУБД на серверные, здесь могут возникнуть определенные проблемы. Например, при переносе данных из dBase или Paradox в какую-нибудь серверную СУБД обслуживающее их приложение, написанное на Delphi, вполне может отказаться работать даже после корректной перенастройки библиотек доступа к данным, особенно если оно содержит сведения о метаданных. Возможны также различные неприятности, связанные с использованием строчных и прописных букв в наименованиях полей, применением русских наименований полей (и вообще локализованных версий, поддерживающих национальные традиции написания чисел и дат и нередко превращающих числовые данные и даты в при переносе в другую СУБД в нечто невообразимое), несовместимости некоторых типов данных (это особенно часто происходит при переносе таблиц Paradox в другие СУБД). Наконец, если в серверной СУБД определены какие-либо бизнес-правила, нет никакой гарантии, что они идеально соблюдались в настольной СУБД, из которой переносятся данные, и в этом случае некоторое количество «ручного» труда по разбору данных, не соответствующих этим правилам, вам или вашим пользователям гарантировано.

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

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

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

Oracle RDBMS (она же Oracle Database) на первом месте среди СУБД. Система популярна у разработчиков, проста в использовании, у нее понятная документация, поддержка длинных наименований, JSON, улучшенный тег списка и Oracle Cloud.

Особенности

Обрабатывает большие данные.
Поддерживает SQL, к нему можно получить доступ из реляционных БД Oracle.
Oracle NoSQL Database с Java/C API для чтения и записи данных.

2. MySQL

MySQL работает на Linux, Windows, OSX, FreeBSD и Solaris. Можно начать работать с бесплатным сервером, а затем перейти на коммерческую версию. Лицензия GPL с открытым исходным кодом позволяет модифицировать ПО MySQL.

Эта система управления базами данных использует стандартную форму SQL. Утилиты для проектирования таблиц имеют интуитивно понятный интерфейс. MySQL поддерживает до 50 миллионов строк в таблице. Предельный размер файла для таблицы по умолчанию 4 ГБ, но его можно увеличить. Поддерживает секционирование и репликацию, а также Xpath и хранимые процедуры, триггеры и представления.

Особенности

Масштабируемость.
Лёгкость использования.
Безопасность.
Поддержка Novell Cluster.
Скорость.
Поддержка многих операционных систем.

3. Microsoft SQL Server

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

Особенности

Высокая производительность.
Зависимость от платформы.
Возможность установить разные версии на одном компьютере.
Генерация скриптов для перемещения данных.

4. PosgreSQL

Масштабируемая объектно-реляционная база данных, работающая на Linux, Windows, OSX и некоторых других системах. В PostgreSQL 10 есть такие функции, как логическая репликация, декларативное разбиение таблиц, улучшенные параллельные запросы, более безопасная аутентификация по паролю на основе SCRAM-SHA-256.

Особенности

Поддержка табличных пространств, а также хранимых процедур, объединений, представлений и триггеров.
Восстановление на момент времени (PITR).
Асинхронная репликация.

NoSQL-базы данных

5. MongoDB

Самая популярная NoSQL система управления базами данных. Лучше всего подходит для динамических запросов и определения индексов. Гибкая структура, которую можно модифицировать и расширять. Поддерживает Linux, OSX и Windows, но размер БД ограничен 2,5 ГБ в 32-битных системах. Использует платформы хранения MMAPv1 и WiredTiger.

Особенности

Высокая производительность.
Автоматическая фрагментация.
Работа на нескольких серверах.
Поддержка репликации Master-Slave.
Данные хранятся в форме документов JSON.
Возможность индексировать все поля в документе.
Поддержка поиска по регулярным выражениям.

6. DB2

Работает на Linux, UNIX, Windows и мейнфреймах. Эта СУБД идеально подходит для хост-сред IBM. Версию DB2 Express-C нельзя использовать в средах высокой доступности (при репликации, кластеризации типа active-passive и при работе с синхронизируемым доступом к разделяемым данным).

Особенности DB2 11.1

Улучшенное встроенное шифрование.
Упрощённая установка и развёртывание.

7. Microsoft Access

Система управления базами данных от Microsoft, которая сочетает в себе реляционное ядро БД Microsoft Jet с графическим интерфейсом пользователя и инструментами разработки ПО.

Особенности

Можно использовать VBA для создания многофункциональных решений с расширенными возможностями управления данными и пользовательским контролем.
Импорт и экспорт в форматы Excel, Outlook, ASCII, dBase, Paradox, FoxPro, SQL Server и Oracle.
Формат базы данных Jet.

8. Cassandra

СУБД активно используется в банковском деле, финансах, а также в Facebook и Twitter. Поддерживает Windows, Linux и OSX. Для запросов к БД Cassandra используется SQL-подобный язык — Cassandra Query Language (CQL).

Особенности

Линейная масштабируемость.
Быстрое время отклика.
Поддержка MapReduce и Apache Hadoop.
Максимальная гибкость.
P2P архитектура.

9. Redis

Особенности

Автоматическая обработка отказа.
Транзакции.
Сценарии LUA.
Вытеснение LRU-ключей.
Поддержка Publish/Subscribe.

10. Elasticsearch

Легко масштабируемая поисковая система корпоративного уровня с открытым исходным кодом. Благодаря обширному и продуманному API обеспечивает чрезвычайно быстрый поиск, работает в том числе с приложениями для обнаружения данных. Используется такими компаниями, как Википедия, The Guardian, StackOverflow, GitHub. ElasticSearch позволяет создавать копии индексов и сегментов.

Читайте также: