Рис. 1. Взаимодействие приложения с СУБД в системах с разным числом звеньев
Встроенные СУБД по сравнению с клиент-серверными имеют ряд преимуществ и недостатков. К преимуществам встроенных СУБД можно отнести следующие особенности.
Простота разработки приложений. Программисту не требуется установка и настройка СУБД на своём рабочем месте. Программа имеет полный контроль над логикой работы с БД.
Простота развёртывания приложений. В большинстве случаев достаточно скопировать файлы динамически подгружаемых библиотек в директорий приложения, при этом пользователю даже не нужно иметь права администратора на своём компьютере или другом устройстве, например, на планшете.
Простота обслуживания локальной базы данных. Как правило, приложение со встроенной СУБД эксплуатируется в однопользовательском режиме, а размер базы данных относительно невелик, поэтому необходимость в дополнительной настройке прав доступа и оптимизации быстродействия практически отсутствует. Регулярные операции обслуживания базы данных (резервное копирование, индексация, очистка, дефрагментация и т. п.) могут быть автоматизированы и реализованы непосредственно приложением, например, при его запуске.
Возможность работы в однозадачной операционной системе. Хотя времена господства MS DOS на персональных компьютерах давно прошли, разработчики встраиваемых систем для различных устройств и оборудования смогут по достоинству оценить эту возможность.
Как правило, более высокое быстродействие на операциях вставки, удаления и считывания одиночных записей. Это связано не только с однопользовательским режимом работы, но и с отсутствием затрат на упаковку данных приложением с последующей их передачей по сети СУБД-серверу. По сути, приложение напрямую работает с локально расположенными файлами через слой программных интерфейсов (API) встроенной СУБД.
Следует отметить, что возможно также использование встроенной СУБД в многопользовательском режиме для работы с разделяемыми по сети файлами данных. Такая технология получила название «файл-сервер» и была весьма популярна до широкого распространения клиент-серверных СУБД. Интересующихся я отсылаю к системам разработки под общим названием xBase. Сюда относятся такие продукты, как dBase, Paradox, FoxPro или Clipper (современная открытая кросс-платформенная реализация Clipper называется Harbour). Тем не менее, как минимум одна популярная встраиваемая СУБД до сих пор нередко используется в таком качестве, это Microsoft Access и его «мотор» MS Jet, являющийся компонентом операционной системы Windows.
Кроме преимуществ, встроенные СУБД обладают рядом ограничений и недостатков, вытекающих непосредственно из технологии.
Более высокий риск потерь и повреждения данных. Как мы помним, встроенная СУБД находится в том же процессе операционной системы, что и приложение. Соответственно, аварийное завершение работы приложения в момент записи данных может повредить их. Транзакции также контролируются непосредственно приложением, поэтому при аварийном останове некому будет откатить незавершённые модификации базы данных и она останется в несогласованном состоянии.
Ориентация на автономные однопользовательские клиентские и многопоточные серверные приложения. Хотя с помощью разделения файлов в сети можно организовать доступ к одной БД из нескольких приложений, находящихся на разных устройствах, такое решение будет ограничено небольшим числом пользователей и малыми размерами базы данных. Не касаясь серьёзных проблем обслуживания и обеспечения безопасности такой БД, на практике в сети передачи данных 100 мегабит/сек проблемы быстродействия начинаются уже при десятке пользователей, работающих с файлами размером нескольких сотен мегабайт данных.
Невозможность распределения вычислительной нагрузки. Встроенная СУБД работает на одном устройстве, а вычисления производит непосредственно приложение. Клиент-серверная СУБД может быть развёрнута в кластере из многих устройств, при этом она способна сама производить вычисления, возвращая приложению- клиенту результат.
Низкий уровень безопасности. Файлы базы данных должны быть целиком доступны пользователю как минимум на чтение. Таким образом, невозможно предотвратить копирование этих файлов злоумышленниками.
Как правило, функционал встроенной СУБД урезан по сравнению с клиент-серверной версией того же продукта. Например, встроенная версия Microsoft SQL Server Compact несовместима с клиентсерверными версиями и сравнима с Microsoft Access.
Конечно, перечисленных критериев недостаточно для полноценного выбора технологии и типа СУБД, но, надеюсь, у читателя появится базис для систематизации поиска согласно требованиям к разрабатываемой программной системе.
На практике иногда я встречал отношение к вопросам выбора СУБД на уровне высказывания: «Не будем ломать голову, возьмём Oracle: он, как танк, везде пройдёт и нам уж всяко подойдёт». Действительно, если вы не хотите поднапрячь голову сейчас, но согласны, что спустя некоторое время, возможно, придётся на этой же голове рвать волосы, то можно, не напрягаясь, попросить сделать за вас работу продавцов-консультантов продуктов «Большой тройки»[3].
Из ряда многочисленных встроенных СУБД, опробованных непосредственно на практике или в тестовом режиме, таких как xBase, Microsoft, Access, Microsoft SQL Server Compact, SQLite, Oracle Lite) наиболее интересным современным решением мне представляется Firebird по следующим причинам.
Кросс-платформенная СУБД, доступны версии для Windows, Linux и Mac.
Свободно распространяемая СУБД с открытым исходным кодом, допускающая использование в закрытых коммерческих продуктах.
Всего один основной DLL-файл для развёртывания (могут также понадобиться файлы ресурсов), одновременно работающий и как встроенная СУБД, и как клиентская библиотека для связи с СУБД- сервером Firebird. Соответствующий режим выбирается указанием или пропуском имени сервера в строке соединения.
Практически полностью поддержана функциональность своей клиент-серверной версии, включая поддержку встроенных типов данных, видов, триггеров, хранимых процедур и системы безопасности. Это значит, что разработанное программистом приложение будет иметь минимум специфики при работе со встроенной или клиент-серверной версией СУБД с возможностью переключения изменением всего одного параметра соединения.
Версионность данных, благодаря которой читающие транзакции не блокируют пишущие транзакции и наоборот. Разработчики отчётов оперативного контура информационных систем оценят эту возможность, когда требуется выдача согласованной информации на текущий момент времени.
Конечно, Firebird не лишён недостатков, особенно с точки зрения администратора баз данных, но для автономных приложений эта СУБД предоставляет разработчику заманчивые возможности. В дополнение к теме я приведу выдержки из своего небольшого обзора состояния Firebird, написанного в 2013 году с позиций как администратора БД, которому необходимо обеспечивать промышленную эксплуатацию баз данных под Firebird, так и инженера, постоянно решающего вопросы поддержки работоспособности продукта среди многих клиентов, эксплуатирующих разные версии СУБД.
Сноска. Firebird 2.5: состояние
Firebird достаточно лёгок в администрировании: для относительно небольших
баз данных и приложений СУБД практически не требует вмешательства администратора БД. Для разработчиков автономных приложений это важный фактор, позволяющий минимизировать затраты на поддержку приложений у клиентов, не предоставляющих удалённый доступ к своей сети или у которых не имеется своего администратора БД в штате службы ИТ, если она вообще есть.
Однако, если эксплуатируемых баз данных, приложений и пользователей в хозяйстве становится все больше, то прежняя лёгкость начинает превращаться в легковесность.
Особенности реализации требуют, чтобы операция создания внешнего ключа между двумя таблицами проводилась только при наличии одного единственного соединения к БД. Сами же таблицы создать можно и в обычном соединении, имея соответствующие права. Просуществовало это ограничение до версии 2.1, но у многих клиентов в эксплуатации находится ещё версия 1.5.
Штатных средств соединения в однопользовательском режиме нет. Поддержка предлагает утилитой gfix отключить базу данных в эксплуатации (!), потом включить её в режиме sysdba, что, впрочем, тоже не гарантирует единственного соединения, если более одного сотрудника имеют доступ с уровнем sysdba.
Редакций Firebird по-прежнему несколько, к SuperServer и Classic добавилась SuperClassic. Исторически, Interbase, на основе открытого кода которого возник Firebird, использовал classic-архитектуру: на каждое соединение СУБД стартует отдельный серверный процесс. Такой подход обеспечивает достаточно высокую надёжность (если один процесс аварийно завершается, то на работу остальных это не влияет) и параллелизм средствами операционной системы, но отсутствует разделяемый кэш данных в оперативной памяти. В SuperServer серверный процесс один, каждое соединение работает в своём потоке с разделяемым кэшем. Но SuperServer не умеет распараллеливать запросы: пока один запрос выполняется со 100% загрузкой одного ядра (одного процессора), остальные ждут. Ситуацию призвана исправить появившаяся редакция SuperClassic.
По большому счёту, «суперклассик» - это все тот же «классик», упакованный в один процесс: потоки внутри по-прежнему максимально изолированы и не разделяют кэш, поэтому риск сбоя или отказа СУБД- сервера снижается. Но один поток не соответствует соединению, имеется их пул, использующий потоки по мере необходимости, поэтому «суперклассик» будет несколько производительнее и рачительнее к оперативной памяти. Администратору также удобнее наблюдать и поддерживать в работоспособном состоянии один процесс, чем множество.
Собственно, кэш данных у Firebird весьма условный, СУБД использует кэш файлов операционной системы, поэтому сбросить его для проверки производительности «холодных» запросов невозможно даже перезапустив СУБД. К примеру, в SQL Server для этого есть специальная команда.
Средства администрирования, прежде всего аудита и мониторинга из комплекта достаточно примитивны. Например, трассировщик запросов, [4] образцом которого вполне может служить MS SQL Server Profiler, являет собой утилиту командной строки, запускаемую со своим конфигурационным файлом. Последующую расшифровку полученных результатов надо проводить вручную при помощи регулярных выражений. Есть коммерческие утилиты, предоставляющие более дружественный интерфейс. В версии 2.5 появились возможности накопления статистики в системных таблицах мониторинга вида MONSXXX.
Средством «полной очистки» БД от так называемого мусора до сих пор является процедура резервного копирования и последующего за ним восстановления при помощи утилиты gbak. Однако, подобная процедура означает отключение пользователей от СУБД на всё время восстановления, делая проблематичной работу в режиме 24x7. Файл базы данных понемногу растёт даже при нулевом балансе добавленных и удалённых записей с постоянной фиксацией транзакций, данные дефрагментируются, что может снизить производительность. Ощущается нехватка аналога команды VACUUM, имеющейся в СУБД PostgreSQL.
Firebird не блокирует используемые файлы. Таким образом файл БД можно скопировать на сервере прямо во время многопользовательской работы. Как оказалось, некоторые клиенты именно так и поступают, называя подобное непотребство «резервным копированием». Проблема заключается в том, что во время копирования нет никакой гарантии нахождения файла в целостном состоянии, как и отсутствия незавершённых транзакций. Наверное, все-таки лучше было бы предусмотреть блокирование, как дополнительную защиту «от дурака».
Наличие перечисленных проблем не позволяет поднять усреднённую планку использования выше чем уровень «СУБД рабочих групп и небольших предприятий», означающий для систем транзакционной обработки десятки пользователей при объёмах БД в десятки гигабайт. Но, вполне возможно, что и такого уровня будет достаточно для ваших приложений.
С другой стороны, с точки зрения программиста, Firebird представляет собой удобный СУБД-сервер: простой в установке, нетребовательный к ресурсам вычислительного устройства, переносимый между различными операционными системами, встраиваемый в приложение. Собственный язык программирования позволяет реализовать логику в хранимых процедурах и триггерах. Имеется большое число средств проектирования, разработки и отладки: от свободно распространяемых с открытым кодом до коммерческих. Стандартные средства сетевого доступа к СУБД имеются практически для всех платформ разработки от массово-корпоративной Явы до более экзотических вроде Руби.
Достарыңызбен бөлісу: |