Умирающая технология?


Внешне все именно так и выглядит. Например, намерение компании Inprise перенести свою, некогда массовую, СУБД Paradox в операционную систему Linux практически не вызвало отклика в среде программистов, при этом выпуск Kylix производства той же компании стал одним из важных событий 2001 года.


На самом же деле, встраиваемые СУБД продолжают выполнять роль рабочей лошадки во многих продуктах, в том числе и коммерческих, причем, весьма популярных системах! Скажем, ставшая у нас чуть ли стандартом де-факто в отрасли система 1С:Предприятие в подавляющем большинстве случаев использует встраиваемую СУБД dBASE, которая несколько лет назад была самой известной представительницей своего класса.


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


Здесь автор, следуя распространенному литературному штампу, просто обязан начать новый раздел, озаглавив его "Мифы о СУБД", после чего кинуться развенчивать эти мифы в пух и прах. Но, в данном случае, ничего подобного не произойдет. В основном это связано с тем, что у автора самого "рыльце в пушку". Откуда же возникло столь устойчивое мнение о неоспоримой эффективности SQL-серверов?

 

Персональные базы данных

 

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


Кроме того, в персональных базах данных, как в капле воды отражается все архитектурное многообразие современных информационных приложений. Итак, персональная база данных, как правило, имеет архитектуру, показанную на рисунке 1. Четыре уровня приложения, образуют "слоистую" структуру, причем каждый уровень взаимодействует исключительно со своими соседями. Основные преимущества подобной организации очевидны: это простота и, как следствие, надежность.

 


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

 

Еще раз о КСА

 

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

 


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


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

 


Впервые идея удаленного пользовательского интерфейса была реализована в многотерминальных комплексах (МТК), получив свое логическое завершение еще в 1984 году при создании X-протокола (в котором, однако, интерфейс-сервером считается часть, которую мы  привыкли считать клиентом). Тем не менее, находятся разработчики, которых не удовлетворяют существующие протоколы. Например, для взаимодействия клиентной части с логическим сервером в ERP-системе Baan используется специально разработанный терминальный протокол.


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


МТК -- далеко не единственный способ реализации интерфейс-серверов. Во второй половине 80-х университетские лаборатории подарили миру еще одну информационную новинку -- мировую паутину. В ее фундамент лег простой, гибкий и удобный язык описания интерфейсов, известный всем, как HTML. В настоящее время он в сочетании с набором других протоколов и языков позволяет построить практически любой интерфейс, удовлетворяющий современным нуждам. Проницательный читатель без труда узнает в этом описании Intranet-технологию, которая с большим основанием считается технологией приложений будущего. Конечно же, мощная научная идея не замедлила найти свое воплощение в коммерческих разработках, изменившись до неузнаваемости и получив новое название - сервер приложения.


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


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

 

Как выбрать СУБД?

 

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


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


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


Еще хуже обстоит дело с эргономичностью. Англичане говорят: "вкус пудинга познается в еде", добавляя вслед за этим "о вкусах не спорят". В самом деле, у всякой популярной СУБД есть несколько интерфейсов, реализованных для разных языков и в разных парадигмах. В результате задача усложняется многократно: вместе с проблемой выбора СУБД приходится одновременно выбирать подходящий язык и библиотеки. Да и само слово "удобство" весьма расплывчато: один считает, что библиотеки для языка C вполне достаточно, другой думает, что разработка на Perl или Tcl будет намного быстрее, а третий утверждает, что без Delphi/Kylix писать приложения баз данных вообще невозможно. Пожалуй, единственное утверждение, которое никто не станет оспаривать - это то, что быстродействие приложения всегда обратно пропорционально скорости его разработки.


Надежность СУБД также является камнем преткновения в современном мире СУБД. Общественное мнение давно уже приучено к мысли, что SQL-сервера надежнее встраиваемых СУБД за счет механизмов журналирования и транзакций. Однако и это утверждение перестает быть очевидным, стоит только лишь ознакомиться с системой журналирования Berkeley DB. Впрочем, обо всем по порядку.

 

Постановка задачи


Очевидно, что существует множество СУБД, которые выглядят весьма привлекательно для разработчика. Однако внимание автора сосредоточилось только лишь на двух из них: PostgreSQL и Berkeley DB. Первая представляет SQL-сервер, а вторая -- встраиваемую СУБД. Единственное, что объединяет обе системы - свободное распространение по лицензии GNU. Ну, и пожалуй, то, что существуют версии для большинства используемых ОС - в частности, поддержаны Windows и Linux.


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


Однако, подобная расстановка сил далеко не всегда соответствует реальному положению дел. Например, заняться серьезным сравнительным изучением СУБД автора заставила весьма "персональная" задача ведения личного архива программного обеспечения. Отличие этой задачи от задачи ведения, скажем, каталога фонотеки заключается в объемах обрабатываемой информации. Если вы не меломан-фанатик, обьем вашей фонотеки вряд-ли выйдет за пределы 300 наименований. А типичный дистрибутив Linux даже по самым скромным подсчетам насчитывает более 600 пакетов и несколько тысяч файлов. Без специальных средств автоматизации в этом многообразии немудрено запутаться, и это подтверждают непрерывно растущие объемы дистрибутивов и пугающе странные зависимости между пакетами. Если кому-либо кажется, что поставленная задача чересчур экзотична, можно привести пример еще одной крупной базы данных: почтового архива. За свою долгую сетевую жизнь автор накопил порядка 10000 сообщений объемом более 100 мегабайт. В основном, это архивы наиболее интересных конференций, форумов и списков рассылок.


Для ведения файлового архива автор с самого начала предпочел воспользоваться PostgreSQL. Подтверждая сформулированное выше правило, причины такого выбора оказались историко-информационными: в отличие от, скажем, MySQL, PostgreSQL входит в стандартный дистрибутив RedHat Linux, и вполне естественно, что внимание автора было привлечено в первую очередь именно к этой СУБД.


Использование SQL-сервера для ведения персональной базы данных на первый взгляд может показаться "стрельбой из пушки по воробьям". С другой стороны, автор пришел к этому решению после долгого и мучительного опыта работы с такими популярными ВСУБД, как MS Access, dBASE, а затем Paradox. Эта эпопея может стать самостоятельным произведением искусства, однако результат можно сформулировать весьма кратко: встраиваемые СУБД совершенно не способны работать с достаточно большими (имеется ввиду поставленная автором задача) объемами данных. Кроме того, все перечисленные СУБД являются коммерческими, что в наших условиях автоматически означает "ворованными". Более того, автору была нужна СУБД для Unix-системы, так как большую часть своего рабочего времени автор проводит в среде Linux.


О том, как автор познакомился с Berkeley DB, можно написать не менее захватывающую историю. Началась она совершенно случайно, в результате выполнения команды apropos open, которая привела к описанию вызова dbopen, явно относящегося к некой базе данных. Однако дальнейшее ознакомление с этой СУБД превратилось в настоящий детектив, так как выделить ее как самостоятельный пакет оказалось просто невозможно. В конце-концов (тоже совершенно случайно!) внимание автора было обращено на встраиваемую СУБД, носящую название Berkeley DB. Сопровождением BDB занимается компания Sleepycat (www.sleepycat.com), с сайта которой и был взят дистрибутив. И тут выяснилось, что именно эта база включена в пакет glibc, который традиционно считается неделимым с точки зрения специалистов по Linux!


То, что стандартные библиотеки C являются самой загадочной частью ОС Linux, заслуживает отдельного обсуждения. Сейчас же можно определенно сказать, что раз уж BDB посчитали настолько фундаментальной подсистемой, что ее включили в состав базовых библиотек, то определенно есть смысл ознакомиться с ней поближе. Пожалуй, это хороший кандидат для создания персональных баз данных. (продолжение следует)

2004.04.14
19.03.2009
В IV квартале 2008 г. украинский рынок серверов по сравнению с аналогичным периодом прошлого года сократился в денежном выражении на 34% – до $30 млн (в ценах для конечных пользователей), а за весь календарный год – более чем на 5%, до 132 млн долл.


12.03.2009
4 марта в Киеве компания Telco провела конференцию "Инновационные телекоммуникации", посвященную новым эффективным телекоммуникационным технологиям для решения задач современного бизнеса.


05.03.2009
25 февраля в Киеве компания IBM, при информационной поддержке "1С" и Canonical, провела конференцию "Как сохранить деньги в условиях кризиса?"


26.02.2009
18-19 февраля в Киеве прошел юбилейный съезд ИТ-директоров Украины. Участниками данного мероприятия стали ИТ-директора, ИТ-менеджеры, поставщики ИТ-решений из Киева, Николаева, Днепропетровска, Чернигова и других городов Украины...


19.02.2009
10 февраля в Киеве состоялась пресс-конференция, посвященная итогам деятельности компании "DiaWest – Комп’ютерний світ" в 2008 году.


12.02.2009
С 5 февраля 2009 г. в Киеве начали работу учебные курсы по использованию услуг "электронного предприятия/ учреждения" на базе сети информационно-маркетинговых центров (ИМЦ).


04.02.2009
29 января 2009 года в редакции еженедельника "Computer World/Украина" состоялось награждение победителей акции "Оформи подписку – получи приз!".


29.01.2009
22 января в Киеве компания "МУК" и представительство компании Cisco в Украине провели семинар для партнеров "Обзор продуктов и решений Cisco Small Business"

 

 
 
Copyright © 1997-2008 ИД "Комиздат".