Новое в СУБД ЛИНТЕР 6.1

Петр Лысачев, Виталий Максимов, Михаил Ермаков,
Научно-производственное предприятие РЕЛЭКС

В начало

Анализ особенностей системы.

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

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

Достоинства и недостатки

Итак, к достоинствам систем асинхронной репликации следует отнести:

•  Хорошую масштабируемость (стремящуюся к прямо пропорциональной зависимости от количества серверов, участвующих в процессе репликации в случае отсутствия изменяющих запросов)

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

•  Хорошая отказоустойчивость: отказ одного или нескольких серверов не приведет к остановке всей системы, а лишь немного замедлит работу, так как клиенты временно будут перераспределены между оставшимися серверами. Отказавший сервер может быть запущен в любой момент и сам произведет все необходимые действия для синхронизации с остальными.

Недостатки:

•  Падение эффективности в случае высокой динамики изменений – рассылка и параллельные изменения всех БД снижают скорость отработки поисковых запросов.

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

•  Необходимость нетривиального администрирования, разрешение коллизий с одинаковыми первичными ключами или по какой-либо причине рассогласованными данными. Уменьшить вероятность неразрешимых коллизий (или даже исключить ее) можно на этапе проектирования приложения или, в ряде случаев, при создании самих баз данных на разных серверах (например, выделением для автоинкрементальных полей отдельных непересекающихся для каждого сервера диапазонов значений).

Направление развития

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

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

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

•  Возможно, усложнение правил репликации, введение горизонтальной (только выборочные записи) и вертикальной (выборочные столбцы) репликации.

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

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

Система синхронизации DBSync

DBSync – это программное решение, предназначенное для построения распределенных прикладных систем, работающих с реляционными базами данных. Оно обеспечивает возможность off-line работы с информацией для удаленных и мобильных клиентов, а также последующей двунаправленной синхронизации данных с центральным сервером. Связь с базой данных осуществляется через ODBC, поэтому на базе DBSync можно строить решения для гетерогенных систем.

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

Структура DBSync показана на рисунке 2.

При установке DBSync в базе данных создается набор таблиц с метаданными синхронизации. В метаданных хранятся списки узлов синхронизации (удаленных баз данных), списки таблиц, которые необходимо синхронизировать, правила синхронизации и т.д. Кроме того, для прикладных таблиц, которые включены в процесс синхронизации данных, создаются вспомогательные таблицы. Вспомогательные таблицы используются механизмом определения изменений для хранения служебной информации. Механизм определения изменений базируется на триггерах. Когда прикладная задача модифицирует данные, информация об этом событии заносится во вспомогательные таблицы. При этом объем служебной информации ограничен и не увеличивается при многократных изменениях одной и той же записи. Синхронизация локальной базы с удаленным узлом возможна в режимах on-line и off-line .

Рисунок 2.

В режиме on-line клиент синхронизации устанавливает соединение с сервером синхронизации по одному из поддерживаемых on-line протоколов (TCP/IP, HTTP и т.д.). Затем формируется пакет синхронизации, передается на удаленный сервер БД и там обрабатывается. В зависимости от обстоятельств пакет синхронизации может содержать либо все данные (начальная синхронизация, восстановление после сбоев), либо данные, которые были модифицированы с момента последнего сеанса синхронизации с данным узлом. Модуль интеграции со службой каталогов определяет, какие именно таблицы и по каким условиям будут выгружены в удаленную базу. После успешной обработки пакета удаленной стороной в локальную базу возвращаются изменения, которые произошли в удаленной базе. На этом сеанс синхронизации завершается. В случае off-line протокола алгоритм обмена пакетами зависит от настроек DBSync.

DBSync обеспечивает возможности обмена данными между синхронизируемыми базами данных при помощи следующих сетевых протоколов:

•  TCP/IP – наиболее быстрое и надежное решение. Обеспечивает дуплексную сессию синхронизации. При необходимости шифрации сообщений имеется возможность работать через SSL.

•  HTTP – аналогично TCP/IP обеспечивает получение подтверждений о приходе пакетов от базы-приемника, и сохранения пакетов не требуется. Серверная часть (принимающая соединения) реализована в варианте собственного сервера, понимающего подмножество http . Главным преимуществом при использовании этого протокола является возможность работы через Internet.

•  E-MAIL – Данный вариант обмена не гарантирует надежной доставки данных, но позволяет использовать любые возможности для отправки данных, т.к. e-mail является очень распространенным сервисом.

•  FILE – Имеет такие же ограничения, как и E-MAIL. Пакет синхронизации данных оформляется в виде файла. Доставка файла осуществляется по ftp, с помощью гибких носителей и т.п.

В качестве прочих достоинств DBSync следует отметить:

•  работу с UNICODE;

•  формат сообщений XML;

•  простоту администрирования;

•  гибкость в конфигурировании.

Драйверы и интерфейсы

Наличие драйвера ODBC, стандартного интерфейса SQL CLI – норма для любой уважающей себя СУБД. ЛИНТЕР – не исключение. Стоит отметить, что драйвер ODBC (3.х) СУБД ЛИНТЕР существует для всех платформ, а не только для Microsoft Windows, и по сути своей является ещё одним универсальным API для разработки приложений. Это очень важный момент, обеспечивающий приложениям дополнительный уровень переносимости. Специально для версий ЛИНТЕР 6.x, в которых реализована поддержка национальных (да и вообще любых) кодировок, существует UNICODE ODBC-драйвер. Реализована полная поддержка ODBC esc-последовательностей. Для сокращения размеров приложений, рассчитанных на встроенные системы, возможно использование библиотеки с урезанной функциональностью.

Большинство современных приложений разрабатывается с использованием объектно-ориентированных языков программирования. При работе на платформах Microsoft провайдер OLE DB СУБД ЛИНТЕР облегчит разработку программ в различных средах программирования, использующих компоненты ADO, например, в среде Visual Basic .

Рисунок 3. Список таблиц в Браузере объектов (Linux).

Специально для поклонников Delphi и стремительно набирающего обороты Kylix , в ЛИНТЕР разработан интерфейс DBExpress . При разработке приложений на Delphi можно, конечно, использовать и ADO, однако для Kylix такой возможности нет, и наличие "родных" компонентов DBExpress – практически единственный вариант обеспечить совместимость.

Очень популярен у разработчиков web-приложений скриптовый язык PHP. Фактически с момента появления этого языка появилась возможности обращения из него к ЛИНТЕР. С развитием PHP разработчики этого популярного средства реализовали набор вызовов для работы с базами данных через ODBC. Однако этот шлюз не поддерживает большую часть функциональных возможностей этого интерфейса, например, работу с массивами параметров и ответов. Поэтому для СУБД ЛИНТЕР была сделана собственная реализация шлюза PHP->ODBC, которая позволяет при работе с PHP использовать практически все возможности ODBC.

содержание       назад       вперед