Библиотека сайта rus-linux.net
Архитектура приложений с открытым исходным кодом. Том 1. Глава 4. Berkeley DB
Оригинал: "Berkeley DB"Авторы: Margo Seltzer and Keith Bostic
Дата публикации: 2012 г.
Перевод: Н.Ромоданов
Дата перевода: октябрь 2012 г.
Закон Конвея утверждает, что конструкция системы отражает структуру организации, которая ее создала. Если это утверждение слегка развить, то мы могли бы ожидать, что некий программный объект, спроектированный и первоначально созданный двумя разработчиками, должен был каким-то образом отражать, но не структуру организации, а внутренние предубеждения и философию каждого участника разработки. Один из авторов настоящей главы (Margo Seltzer) провела свою карьеру среди миров файловых систем и систем управления базами данных. Если ее спросить, то она аргументировано докажет, что оба вида этих систем, по существу, являются одним и тем же, и, более того, операционные системы и системы управления базами данных являются, по существу, менеджерами ресурсов и провайдерами удобных абстракции. Различия «всего лишь» в деталях реализации. Второй автор (Keith Bostic) верит в инструментальные подходы в инженерии программного обеспечения и в разработке компонентов на базе простых составных блоков, поскольку такие системы заведомо превосходят системы с монолитной архитектурой в части разных важных «особенностей»: понятности, расширяемости, поддерживаемости, тестируемости и гибкости.
Если объединить оба этих подхода, вы не удивитесь, узнав, что большую часть последних двух десятилетий мы потратили на совместную разработку Berkeley DB - библиотеки программ, обеспечивающих быстрое, гибкое, надежное и масштабируемое управление данными. Berkeley DB предоставляет практически те же самые функции, которые многие ожидают от более традиционных систем, например, реляционных баз данных, но они собраны по-другому. Например, в Berkeley DB имеется быстрый доступ к данным по ключам и последовательный доступ, и есть поддержка транзакций и восстановления после сбоя. Однако, эти функции не выделяются в отдельный сервер приложений, а реализованы в виде библиотеки, которая компонуется непосредственно с тем приложением, в котором нужен этот сервис.
В этой главе мы заглянем глубже в систему Berkeley DB и увидим, что она состоит из набора модулей, каждый из которых воплощает в себе философию Unix «хорошо делать что-то одно». Приложения, в которые включены компоненты Berkeley DB, могут обращаться к ним непосредственно, либо могут просто пользоваться ими неявно через более привычные операции получения, сохранения или удаления элементов данных. Мы сосредоточимся на архитектуре системы – как мы начали, что мы разрабатывали, где мы оказались и почему. Конструктивные особенности могут потребовать (и, безусловно, потребуют!) производить адаптацию и изменения – что с течением времени становится жизненно важным для поддержки системы и сохранения ее непротиворечивости. Мы также вкратце рассмотрим эволюцию кода длительно существующих программных проектов. Разработка Berkeley DB велась в течение более двух десятилетий, а это, неизбежно предполагает, что в ее основе лежал хороший проект.
4.1. В начале
Berkeley DB восходит к эпохе, когда операционная система Unix была собственностью компании AT&T и были сотни утилит и библиотек, в родословных которых присутствовали строгие лицензионные ограничения. Марго Зельцер (Margo Seltzer) была аспирантом Калифорнийского университета в Беркли, а Кейт Бостик (Keith Bostic) был членом группы Computer Systems Research Group. В то время Кейт работал над удалением проприетарного программного обеспечения AT&T из дистрибутива Berkeley Software.
Проект Berkeley DB начинался со скромной задачи замены хэш-пакета hsearch, работающего в памяти, и хэш-пакетов dbm/ndbm, работающих с диском, новыми пакетами, имеющими лучшую реализацию хэш-функции, работающими как в памяти, так и с диском, и свободно распространяемыми без проприетарной лицензии. В основе библиотеки hash, написанной Марго Зельцер [SY91], лежало исследование линейно расширяемых хэш-таблиц, выполненное Витольдом Литвином (Witold Litwin). Библиотека была уникальна своей искусной схемой, позволяющей получать константное время отображения между хэш-значениями и адресами страниц, а также своей возможностью обрабатывать большие объемы данных — элементы, размер которых больше размера используемых для этого хэш-блоков или страниц файловой системы, размер которых обычно составляет от четырех до восьми килобайтов.
Если хэш-таблицы – это хорошо, то деревья Btrees и хэш-таблицы – это еще лучше. Майк Олсон (Mike Olson), также аспирант Калифорнийского университета в Беркли, написал ряд реализаций деревьев Btree и согласился написать еще одну. Мы втроем преобразовали программу, созданную Марго для хэш-таблиц, и программу для работы с деревьями Btree, созданную Майком, в интерфейс API, не зависящий от метода доступа, с помощью которого приложения обращались к хэш-таблицам или деревьям Btrees через специальные средства работы с базами данных, в которых были методы обработки, позволяющие читать и модифицировать данные.
Создавая эти два метода доступа, Майк Олсон и Марго Зельцер опубликовали научную статью ([SO92]), описывающую LIBTP, транзакционную библиотеку программного уровня, которая работает в адресном пространстве приложений.
Библиотеки хэш-таблиц и деревьев Btree были включены в окончательные релизы 4BSD под названием Berkeley DB 1.85. Технически, в методе доступа Btree были реализованы деревья вида B+link (двоичные деревья + ссылки), однако, в оставшейся части настоящей статьи мы будем пользоваться термином Btree, поскольку это название метода доступа. Вероятно, каждому, кто пользовался какой-нибудь системой, базирующейся на Linux или BSD, знакомы структура и интерфейсы API Berkeley DB 1.85.
Библиотека Berkeley DB 1.85 не изменялась в течение нескольких лет до тех пор, пока в 1996 году компания Netscape не заключила с Марго Зельцер и Кейт Бостик контракт на разработку полностью транзакционной схемы, описанной в статье о LIBTP, и на создание версии приложения промышленного уровня. В результате этих усилий была создана первая транзакционная версия Berkeley DB - версия 2.0.
Последующая история Berkeley DB проще и более традиционна: в Berkeley DB 2.0 (1997) были предложены транзакционные операции для Berkeley DB; Berkeley DB 3.0 (1999) была вновь версией, которую перепроектировали и в которую были добавлены дополнительные уровни абстракции, что косвенно привело к росту функциональных возможностей. В Berkeley DB 4.0 (2001) была представлена репликация и реализована высокая степень готовности, а в Oracle Berkeley DB 5.0 (2010) была добавлена поддержка SQL.
К моменту написания данной главы Berkeley DB является самым широко используемой в мире инструментальным набором, предназначенным для работы с базами данных, с сотнями миллионов установленных копий, работающих на всем, начиная от маршрутизаторов и браузеров и до почтовых программ и операционных систем. Несмотря на то, что проекту более двадцати лет, базовый инструментальный набор и объектно-ориентированный подход, используемый в Berkeley DB, позволяют поэтапно улучшать и перерабатывать проект в соответствие с требованиями программ, в которых он используется.
Первый урок конструирования
Для тестирования и сопровождения любого сложного программного пакета жизненно важно, чтобы он был спроектирован и собран в виде набора взаимодействующих модулей с хорошо определенными границами действия API. Границы могут (и должны!) сдвигаться по мере необходимости, но они всегда должны в нем присутствовать. Существование этих границ не позволит программному пакету превратиться в клубок спагетти, который невозможно будет поддерживать. Батлер Лампсон однажды сказал, что все проблемы в области компьютерных наук можно решить с помощью еще одного уровня косвенности. Если конкретно, то когда его спросили, что это значит с точки зрения объектной ориентированности, Лампсон ответил, что это означает, что за API могут быть несколько реализаций. Этот подход, позволяющий иметь за единым интерфейсом несколько реализаций, был воплощен в общей схеме и в реализации Berkeley DB, что позволило реализовать объектно-ориентированную систему несмотря на то, что библиотека написана на языке C.
| Назад | К оглавлению книги | Вперед |