Библиотека сайта rus-linux.net
Архитектура приложений с открытым исходным кодом. Том 1. Глава 4. Berkeley DB
Оригинал: "Berkeley DB"Авторы: Margo Seltzer and Keith Bostic
Дата публикации: 2012 г.
Перевод: Н.Ромоданов
Дата перевода: октябрь 2012 г.
4.6. Менеджер буферирования: Mpool
Подсистема Mpool в Berkeley DB является размещаемым в памяти пулом буферов файловых страниц, скрывающим тот факт, что основная память является ограниченным ресурсом, для которого требуется библиотека, осуществляющая при работе с базами данных, размер которых больше размера памяти, перемещение страниц базы данных на диск и с диска в память. Кэширование страниц базы данных в памяти, было тем, что позволило исходной библиотеке хеширования значительно превзойти по производительности ранее использовавшиеся реализации hsearch и ndbm.
Хотя метод доступа Btree в Berkeley DB является достаточно традиционной реализацией B+tree, указатели между узлами дерева представлены в виде номеров страниц, а не в виде фактических указателей памяти, потому что реализация библиотеки использует формат данных, предназначенный для диска, также в качестве формата данных, используемого в памяти.
Есть и другие последствия влияния на производительность, обусловленные тем, что представление индексов Berkeley DB в памяти является на самом деле кэшем данных, постоянно хранящихся на диске. Например, всякий раз, когда Berkeley DB обращается к кэш-странице, она сначала фиксирует размещение страницы в памяти. Эта фиксация запрещает каким-либо другим потокам или процессам убирать эту страницу из пула буферов. Даже если индексная структура полностью помещается в кэш-памяти и ее не нужно сбрасывать на диск, Berkeley DB при каждом доступе, по-прежнему, сначала выполняет фиксацию страниц в памяти, а затем — их освобождение, поскольку согласно лежащей в основе модели, предлагаемой Mpool, это — кэш, а не постоянное хранилище данных.
4.6.1. Файловая абстракция Mpool
Предполагается, что Mpool находится на вершине файловой системы,
экспортируя файловые абстракции через интерфейс API. Например,
обработчики DB_MPOOLFILE, используемые для файлов, располагаемых на диске, представляют методы для перемещения страниц в файл и выборки страниц из файла. Хотя в Berkeley DB поддерживаются временные базы данных и базы данных, размещаемые только в памяти, для них также используются обработчики DB_MPOOLFILE из-за лежащей в их основе абстракций Mpool. Методы get и put являются основными в интерфейсах Mpool API: метод get гарантирует, что страница размещена в кэше, закрепляет страницу в памяти и возвращает указатель на эту страницу. Когда библиотека выполнит все действия с этой страницей, метод put отменяет закрепление этой страницы, что позволит удалять страницу из памяти. В ранних версиях Berkeley DB не было различия между закреплением страницы для чтения и закреплением страницы для записи. Однако для того, чтобы увеличить степень распараллеливания, мы расширили интерфейс Mpool API с тем, чтобы при обращении можно было сообщить о намерении обновить страницу. Эта возможность различать доступ для чтения от доступа для записи, имеет важное значение для реализации многовариантного управления распараллеливанием. Страница, закрепленная в памяти для чтения, если случится, что она изменится, может быть записана на диск, тогда как страница, закрепленная для записи, не может, поскольку она в любой момент может находиться в несогласованном состоянии.
4.6.2. Запись в журнал с упреждением
В Berkeley DB в качестве транзакционного механизма, позволяющего выполнить восстановление поле возможного отказа, используется запись в журнал с упреждением (или WAL - write-ahead-logging). Термин «запись в журнал с упреждением» определяет политику, требующую, чтобы записи в журнал, описывающие любые изменения, делались на диск перед фактическим обновлением данных, которые они описывают. Использование в Berkeley DB политики WAL в качестве транзакционного механизма имеет важные последствия для Mpool, и в Mpool приходится, с точки зрения проектирования, балансировать между реализацией общего механизма кэширования и необходимостью поддерживать протокол WAL.
В Berkeley DB на всех страницах данных записываются журнальные порядковые номера (номера LSN – log sequence number), позволяющие заносить в журнал записи, соответствующие самым последним обновлениям конкретной страницы. Чтобы реализовать политику WAL, нужно перед тем, как Mpool запишет какую-нибудь страницу на диск, удостовериться, что регистрационная запись, сооответствующая номеру LSN на странице, сохранена на диске. Задача проектирования состоит в том, чтобы реализовать эту функциональность так, чтобы ото всех клиентских программ Mpool не требовалось использовать формат страниц, идентичный используемому в Berkeley DB. В Mpool эта задача решается с помощью набора методов set (и get), которые обеспечивают необходимое поведение. Метод set_lsn_offset из DB_MPOOLFILE указывает смещение в байтах, где на странице Mpool должен искать номер LSN, необходимый для WAL. Если обращений к этому методу не было, то протокол WAL в Mpool не используется. Аналогичным образом метод set_clearlen сообщает Mpool, сколько байтов на странице занимают метаданные, которые нужно явно очистить, когда страница создается в кеше. Эти интерфейсы API позволяют реализовать в Mpool функции, необходимые для поддержки требований транзакционности, имеющиеся в Berkeley DB, не заставляя от всех пользователей Mpool реализовывать эти возможности.
Восьмой урок конструирования
Запись в журнал с упреждением – это еще один пример применения инкапсуляции и выделения слоя, причем даже в случае, когда эти функциональные возможности никогда не будут использоваться в другой части программного обеспечения: в конце концов, в каком количестве программ задумываются о номерах LSN в кэше? Несмотря на это, дисциплина полезна и облегчает поддержку программного обеспечение, его тестирование, отладку и расширение.
| Назад | К оглавлению книги | Вперед |