Библиотека сайта rus-linux.net
Архитектура приложений с открытым исходным кодом. Том 1. Глава 4. Berkeley DB
Оригинал: "Berkeley DB"Авторы: Margo Seltzer and Keith Bostic
Дата публикации: 2012 г.
Перевод: Н.Ромоданов
Дата перевода: октябрь 2012 г.
4.3. Методы доступа: Btree, Hash, Recno, Queue
Методы доступа в Berkeley DB позволяют осуществлять поиск как по ключу, так и методом итерации, и использовать байтовые строки переменной и фиксированной длины. В методах доступа BTree и Hash поддерживается использование пар ключ/значение с переменной длиной строк. В Recno и Queue поддерживается использование пар номер-записи/значение (причем Recno поддерживает использование значений переменной длины, а Queue поддерживает значения только фиксированной длины).
Основное различие между методами доступа BTree и Hash в том, что в BTree для ключей предлагается локализация ссылок тогда, как в Hash - нет. Это означает, что BTree является правильным методом доступа почти для всех наборов данных; но метод доступа Hash пригоден для таких больших наборов данных, для которых даже структура индексов BTree не поместится в память. В таком случае память лучше использовать для данных, а не для структур индексов. Этот компромисс имел гораздо больше смысла в 1990 году, когда оперативной памяти было обычно намного меньше, чем сегодня.
Разница между методами Recno и Queue в том, что в Queue поддерживается блокировка на уровне записей, из-за чего можно использовать значения только фиксированной длины. В Recno можно использовать объекты переменной длины, но, как и в случае с BTree и Hash, поддерживается блокировка записей только на уровне страниц.
Первоначально мы разрабатывали Berkeley DB таким образом, чтобы функции CRUD (функции Create - создание, Read - чтение, Update - обновление и Delete - удаление) использовали ключи, чтобы приложениям был предоставлен простейший интерфейс. Впоследствии для поддержки итерации мы добавили курсоры. Такая последовательность разработки привела к беспорядку и расточительным случаям, когда внутри библиотеки дублировались большие фрагменты путей исполнения кода. Со временем это привело к невозможности осуществлять поддержку и мы преобразовали все операции с ключами в операции с курсорами (операции с использованием ключей теперь вызывают из кэша курсор, выполняют операцию и возвращают курсор в пул курсоров). Это один из примеров бесконечно повторяемых правил разработки программного обеспечения: не оптимизировать порядок исполнения кода, если это ухудшает его понятность и увеличивает сложность, до тех пор, пока вы не будете знать, что необходимо сделать именно так.
Третий урок конструирования
Архитектура программы ухудшается не из-за того, что она постепенно стареет. Архитектура программы ухудшается прямо пропорционально количеству вносимых в программу изменений: исправление ошибок ухудшает деление на слои, а новые возможности оказывают воздействие на всю конструкцию. Решение о том, что архитектура программы ухудшилась настолько, что вы должны изменить всю конструкцию или переписать модуль, является тяжелым решением. С одной стороны, поскольку архитектура ухудшилась, сопровождение и дальнейшее разработка программы становятся все труднее, и в конце концов сопровождение устаревшего фрагмента можно поддерживать в каждом релизе только с привлечением грубой силы тестировщиков, поскольку никто не понимает, как программа работает внутри. С другой стороны, пользователи будут горько жаловаться на нестабильность и несовместимости, которые являются следствием фундаментальных изменений. Независимо от того, какой путь вы выбирете, вы, как архитектор программы, можете лишь гарантировать, что кто-нибудь будет недоволен.
Мы опускаем подробное обсуждение внутренних особенностей методов доступа в Berkeley DB; они реализуют довольно известные алгоритмы Btree и хэширования (Recno является слоем над кодом Btree, а Queue является функцией поиска файловых блоков, хотя и усложненной за счет добавления блокировок на уровне записей).
| Назад | К оглавлению книги | Вперед |