`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Невидимка Berkeley DB

Статья опубликована в №38 (557) от 10 октября

0 
 

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

В 1991 г., когда в Университете Беркли велись работы над проектом свободного от лицензионных ограничений клона ОС UNIX, перед разработчиками встала задача реализовать аналог одной из многочисленных библиотек – dbm. В те времена широко распространенная и востребованная dbm реализовывала относительно несложные механизмы однопользовательского хранилища данных. Востребованность же библиотеки объяснялась просто – она освобождала программистов от повторного решения в какой-то мере тривиальных задач накопления и хранения данных. Один из будущих авторов знаменитой книги «Дизайн и реализация ОС 4.4BSD» («The Design and Implementation of the 4.4BSD Operating System» и исходные тексты BSD UNIX стали учебной партой для нескольких поколений программных архитекторов и системных программистов), ведущий архитектор 4.4BSD Кейт Бостик (Keith Bostic), предложил разработать свободный от лицензионного кода AT&T аналог dbm участникам проекта Марго Зельцер и Михаэлю Олсону. C этого момента началась история замечательного во всех отношениях программного продукта – Berkeley DB. Во-первых, он уникален тем, что объединил разработчиков на долгие годы, и это само по себе уже редкость – достаточно упомянуть тот факт, что Бостик и Зельцер стали счастливыми супругами, а в своем блоге Марго буквально пару месяцев назад набросала планы на ближайшие десять лет, и они полны оптимизма. Во-вторых, продукт, изначально создававшийся и распространявшийся на основе более чем либеральной BSD-лицензии, в конце концов позволил его разработчикам стать респектабельными бизнесменами, не изменяя приверженности свободным берклиевским традициям. В-третьих, респектабельность семейного бизнеса Бостика, Зельцер и «примкнувшего к ним» Олсона получила убедительное доказательство после приобретения его гигантом мира баз данных Oracle (сумма и условия сделки, происшедшей в феврале этого года, не афишировались). И наконец, в четвертых – Berkeley DB не повторила участи многих «прикупленных по случаю» программных проектов. Продукт развивается, и в последней, вышедшей недавно версии, предлагает пользователям совершенно новую функциональность.

К слову, личности разработчиков Berkeley DB весьма примечательны. И дело даже не в том, что не только женщин-программистов, а и «программистов вообще» класса Марго Зельцер не так уж и много. Хотя, если бы Марго Зельцер была только программисткой – автором Berkeley DB, этого было бы достаточно. Но она еще является одним из лучших профессоров Гарварда и отмечена престижной наградой за умение сочетать исследовательскую и преподавательскую работу (к сожалению, отдельной награды за умение сочетать работу с материнством не существует, в противном случае Марго Зельцер, забирающая в свой офис в Гарварде шестимесячную дочь, непременно эту награду получила бы). «По совместительству» Зельцер является основательницей компании Sleepycat (той самой, которую приобрела Oracle), матерью двоих детей, спортсменкой, обладательницей черного пояса карате и... известным заводчиком кошек. Согласитесь, весьма непривычный портрет коммерчески успешного разработчика открытого ПО (особенно на фоне тучных бородатых мужчин, явно не злоупотребляющих спортом). Впрочем, необычность здесь начинается даже с учебного заведения, которое закончила Зельцер – в отличие от традиционных MIT, UCSD и UC Berkeley будущая программистка поступила в Гарвард, и ее выбором была математика. Впоследствии Марго Зельцер перевелась на так называемый факультет прикладных наук – именно там в конце 70-х годов в Гарварде изучали компьютерные науки. Интересно, что впоследствии, уже после работы в нескольких компьютерных компаниях и успешной докторантуры, Зельцер отклонила предложение, поступившее ей из знаменитого MIT, по причине, амбициозность которой способна вызвать зависть у многих мужчин: «Я не думала, что если я выберу MIT, то смогу что-либо фундаментально изменить на его факультете компьютерных наук. А Гарвард тогда только создавал такой факультет и не имел ни одного курса по операционным системам...». При этом Марго Зельцер не стесняется говорить и о своих слабостях: «Когда муж предлагает мне оставить академическую работу и полностью переключиться на бизнес, я говорю, что бизнес – это риск, а я не люблю проигрывать. Вообще, академическая деятельность привлекает именно тех, кто не любит проигрывать».

Муж Зельцер, ранее кратко представленный как Кейт Бостик, также личность весьма незаурядная. По крайней мере, бизнес-опыта в области работы со свободным программным обеспечением ему не занимать – он был одним из основателей компании Berkeley Software Design Inc. (BSDi), которая задолго до нынешних фирм, производящих дистрибутивы Linux, выводила в коммерческое плавание собственный вариант операционной системы, основанной на кодах BSD. BSDi стала и первой жертвой «битвы с клонами» – в 1992 г. USL (Unix System Laboratories), тогда правообладатель UNIX, подала в суд на BSDi за нарушение прав собственности (многие считают недавний иск SCO к IBM полным аналогом этой истории).

Все эти, на первый взгляд, малозначимые детали нужны прежде всего для того, чтобы проиллюстрировать один совершенно очевидный автору статьи постулат – само по себе открытое программное обеспечение ни в коем случае не является ни «серебряной пулей», ни могильщиком бизнеса. Просто настоящего успеха добиваются по-настоящему яркие, талантливые личности. Ну а какой программист не согласится с тем, что двухсотмиллионная пользовательская аудитория созданной и поддерживаемой им более десятилетия программы – это настоящий успех? И даже самый ярый программист-скептик, считающий, что приведенная численная оценка приверженцев Berkeley DB завышена на порядок, согласится с тем, что и двадцать миллионов – тоже более чем внушительная цифра.

libdb.*

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

Berkeley DB позволяет использующему библиотеку программисту удобно оперировать базами данных и записями в них. В трактовании некоторых терминов Berkeley DB отличается от высокоуровневых СУБД, в большинстве же случаев терминология аналогична. Так, запись Berkeley DB, являющаяся парой, образованной ключом-идентификатором записи и данными записи, в некотором смысле идентична записи в двухколоночной таблице в терминах реляционных БД. Но так как и данные, и даже ключ в Berkeley DB могут сами быть наборами данных (например, структурами языка C), то вполне допустимы аналогии и с многоколоночными таблицами. Понятие БД в Berkeley DB, напротив, радикально отличается от так же звучащего термина высокоуровневых аналогов – здесь это множество записей с одинаковыми типами ключа и данных, формируемое на основании выбранного программистом механизма доступа (в высокоуровневых СУБД, в свою очередь, последний обычно полностью скрыт). В Berkeley DB существуют и уникальные конструкции, и, естественно, уникальные термины для их обозначения. Так, окружение (environment) Berkeley DB – это конструкция, позволяющая оперировать множеством БД с записями разных типов (здесь и далее под типом записи понимается пара типов ключа и данных) как единым целым. К специфическим понятиям Berkeley DB следует также отнести вторичные БД, позволяющие устранить важное и очевидное ограничение Berkeley DB, суть которого в неявной форме была только что указана. Речь, естественно, идет о единственности понятия ключа в записи Berkeley DB. А как быть, если данные записи представляют собой наборы данных, и программисту нужен, например, быстрый поиск в БД не только по ключам, но и по значениям определенных полей в этих наборах данных? Без вторичных БД для решения подобной задачи было бы необходимо последовательно просматривать записи базы до выполнения условия поиска, что крайне неэффективно. Вторичные же БД хранят индексы полей наборов данных записей и позволяют использовать механизмы быстрого поиска. Следует заметить, что создание вторичной БД инициируется программистом, а ведение поддерживается Berkeley DB в полностью автоматическом режиме (вторичная БД недоступна по записи). Впрочем, упомянутый как неэффективный механизм последовательного просмотра (иначе говоря – доступа) к записям базы данных часто бывает необходим. В Berkeley DB он реализован с помощью курсоров (cursor), для которых существует более распространенное название итераторов.

Методы доступа Berkeley DB – это механизмы, позволяющие эффективно решать задачи поиска записи по ключу, добавления и удаления записей. В зависимости от характера (типа) ключей можно выделить два класса методов доступа. Так, для ключей, характеризующих содержимое записи, применяются методы доступа с помощью сбалансированных деревьев (BTree) и хэш-функций (Hash). Для тех баз данных, в которых ключи характеризуют уникальный логический номер записи, используются методы доступа на основе очереди (Queue) и «номера записи» (Recno).

Упомянутый ранее язык Berkeley DB (аналогичный по уровню макроассемблеру) – это, естественно, раз мы ведем речь о библиотеке, – интерфейс прикладного программирования (API). Следует отметить, что, несмотря на язык разработки (ANSI C), Berkeley DB – красиво написанная объектно-ориентированная программа, и об этом надо знать для того, чтобы изучать ее отлично документированный API. Ключевая структура данных в Berkeley DB – дескриптор базы (C-структура __db, декларацию которой можно найти в файле db.in, находящемся в подкаталоге dbinc дистрибутива Berkeley DB), содержит указатели на функции API – методы, и поэтому во многом аналогична классу, например, в С++. Поэтому в документации Berkeley DB принят следующий шаблон описания многих функций:

DB->имя_функции()

Эта запись означает, что подобные функции допустимо использовать только после создания базы данных (результатом которого является в том числе и формирование структуры дескриптора, для него в документации принято имя типа DB) и только посредством вызова функции разыменованием указателя на нее в созданном дескрипторе:

#include 
typedef struct __db DB;
/* резервируем место под указатель на дескриптор базы */
DB db0_handle ;
/* создаем базу и дескриптор базы,
инициируем указатель на него */
db_create(*db0_handle ...);
/* удаляем базу, вызывая метод DB->close
разыменованием указателя в дескрипторе */
db0_handle->close( db0_handle...);

На самом деле после подобного краткого описания Berkeley DB можно было бы и остановиться, потому что программа сопровождается великолепной документацией, которую следовало бы брать за образец всем разработчикам ПО (и не только распространяемого с открытыми исходными текстами). И все же следует сказать несколько слов о том, что Berkeley DB позволяет получить использующему ее программисту.

Во-первых, начиная с последней версии, выпущенной уже под эгидой Oracle, Berkeley DB приобрела одно совершенно уникальное свойство, позволяющее устранить существенный недостаток «встраиваемых» программ. Давайте представим себе следующую ситуацию – вы разработали некий программный продукт с использованием библиотеки Berkeley DB и передали его на эксплуатацию заказчику. Но вот появились исходные коды новой версии библиотеки, устраняющие, например, только обнаруженную ошибку (даже очень хорошие программы не идеальны). Что вы должны сделать, чтобы обезопасить своего заказчика от потенциальных рисков, связанных с этой ошибкой? Естественно, пересобрать свою программу с новой версией libdb и переинсталлировать ее у заказчика. А если специфика его работы не допускает остановки исполнения вашей задачи? Именно для таких случаев Berkley DB предлагает механизм модернизации бинарного кода библиотеки без остановки сервиса базы данных.

Во-вторых, реализованный в Berkeley DB механизм транзакций (одновременных множественных операций с базами данных) полностью соответствует перечню свойств ACID (Atomicity, Consistency, Isolation, Durability). Это означает, что транзакции Berkeley DB действительно атомарны (т. е. неделимы и гарантированно приводят или к требуемым изменениям, или вообще не изменяют состояния базы данных), непротиворечивы (не приводят к запрещенным состояниям базы данных), изолированы (какое-либо взаимодействие одновременных транзакций, инициированных разными пользователями, невозможно) и наконец, надежны (сбои в работе системы после завершения транзакции не приводят к потере ее результатов).

В-третьих, последняя версия предлагает развитый набор средств репликации баз данных, что, учитывая неигрушечные «ограничения» (например, размер базы данных до 256 ТВ), позволяет создавать программы со «взрослыми» возможностями масштабирования.

В-четвертых, Berkeley DB очень хорошо и быстро делает то, что должна делать. При исполнении на современных ПК Berkeley DB позволяет выполнять примерно миллион операций чтения и более полумиллиона операций записи в секунду, а в зависимости от операционной среды количество полноценных ACID-транзакций в секунду колеблется от 30 до 90 тысяч. Качество реализации Berkeley DB подтверждают многочисленные факты. Например, во время бета-тестирования платформы для электронной коммерции Steam, основанной на Berkeley DB, за 20 месяцев без единого потерянного байта или сбоя было обработано более десяти миллионов транзакций, инициированных семью сотнями тысяч пользователей, при этом система умышленно оставлялась на несколько месяцев без какого-либо присмотра со стороны администраторов.

В-пятых, Berkeley DB – разработка, не страдающая манией гигантизма. Динамически загружаемая библиотека, собранная в ОС Windows XP, занимает немногим больше 500 KB.

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

Без ограничений универсальности

Невидимка Berkeley DB

Если вы думаете, что Berkeley DB пригодна для построения систем сугубо «программного» характера, то глубоко заблуждаетесь. Желтый чемоданчик на рисунке – устройство, востребованное и в серьезной инженерии, и в процессе эксплуатации сложных технических систем, и при организации масштабных научных экспериментов. Портативная мобильная система сбора и предварительной подготовки данных, несмотря на очевидность выполняемых функций, – изделие далеко не тривиальное. Записывать данные, поступающие от множества датчиков без каких-либо заведомо известных «послаблений» (например, – необязательно синхронно работающих), оцифровывать «на лету» аналоговые сигналы с частотами от долей герца до сотен килогерц (на практике – обычная вещь) и хранить информацию о них – вот далеко не полный перечень того, что должно уметь подобное устройство. Именно благодаря компактности, простоте использования и высокой производительности Berkeley DB разработчику-одиночке Стивену Робенсу (microship.com) удалось создать собственную реализацию системы сбора данных в реальные сроки и при более чем скромном бюджете.

0 
 

Напечатать Отправить другу

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

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT