WikiDer > Архитектура Btrieve

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

Btrieve это база данных разработан Повсеместное программное обеспечение. В архитектура Btrieve был разработан с учетом управления записями. Это означает, что Btrieve имеет дело только с базовыми примитивами создания записи, извлечения данных, обновления записи и удаления данных. Вместе с Ядро базы данных MicroKernel оно использует ISAM, Индексированный метод последовательного доступа в качестве основного механизма хранения.

Btrieve - это, по сути, база данных, которая использует ключи и индексы организовывать данные. Однако сама файловая структура в основном построена на меньших единицах данных, называемых в Btrieve «страницами». Хотя структура изменилась в различных версиях Btrieve, структура файла по-прежнему вращается вокруг записи управления файлами (FCR), которая определяет конфигурацию страниц, и страниц в файле Btrieve, содержащих данные. Исторически Btrieve использовала «физические страницы» или страницы, которые находились в фиксированных позициях в файле. Начиная с версии 6.0, начали использоваться «логические страницы», которые были сопоставлены с таблицами распределения страниц (PAT) - это позволило Btrieve изменить свой метод обновления записей с того, что позже было известно как «разбиение на страницы до изображения», на метод, названный « теневой пейджинг ".

Btrieve стремится к Обратная совместимость, поскольку версии Btrieve до версии 6.15 использовали стандартный формат файла и до выпуска Btrieve 6.0 были полностью обратно совместимы. Btrieve 6.0 представила новые функции и была вынуждена нарушить совместимость со старыми версиями программного обеспечения, чтобы реализовать более продвинутые функции. В API аналогичным образом оставался обратно совместимым, с удалением только одной функции (разделение файлов на отдельные носители). В какой-то момент бывший Бтрив Исполнительный директор Рон Харрис заявил, что «API версии 1.0 все еще поддерживается в версии 6.15, и мы собираемся сохранить его навсегда!» (Кайл, стр.11).

Терминология базы данных

Первоначально Pervasive использовал термин «навигационная база данных» для описания Btrieve, но позже изменил его на «транзакционную базу данных». Использование термина "навигационная база данных" было необычным, поскольку навигационная база данных использует "указатели" и "пути" для навигации между данными записи, и эти указатели содержатся в самой записи; ISAM, которая является основной структурой Btrieve, использует таблицу вторичных индексов для хранения этих указателей, чтобы сократить время поиска. Таким образом, эти два типа баз данных различны и могут объяснять, а могут и не объяснять, почему Pervasive начал использовать различную терминологию для классификации своей базы данных. (Примечание: это не совсем правильно. Навигационная база данных - это база данных, в которой логический доступ к данным в базе данных осуществляется через интерфейс уровня приложения или API. Это навигационная система в том смысле, что приложение отслеживает логические отношения. код "перемещается" по базе данных. Какие физические методы используются для этого, например, ISAM, встроенные указатели и т. д., почти не имеет отношения к обсуждению. Напротив, реляционная база данных не предоставляет прикладному уровню никаких способ "навигации" по логической структуре базы данных и вместо этого предоставляет интерфейс на уровне набора для выбора, агрегирования и объединения данных. Реляционные базы данных могут также использовать различные физические методы для доступа к данным, включая упомянутые выше, но важный аспект быть «реляционным» означает, что доступ к данным осуществляется реляционно, т. е. соперничает с моделью запроса набора, а не с моделью навигации.)

Ядро базы данных микро-ядра

Модель MKDE позволяет подключать различные серверные базы данных к программному продукту Pervasive.

Начиная с версии 6.15 Pervasive начал использовать новый модульный метод разделения базы данных. бэкэнд из интерфейса, который использовали разработчики. Они отделили основные операции базы данных (такие как обновление, запись и удаление записей) от Btrieve и Масштабируемый SQL модули. Отделив ядро ​​базы данных Micro-Kernel (MKDE) от других функций, которые он разрешал программисты использовать одновременно несколько методов доступа к базе данных. Например, приложение может быть создано с помощью Btrieve API и другой заявление для доступа к одним и тем же данным можно использовать совершенно другой метод, например Scalable SQL. Поскольку записывать примитивы были отделены от этих методов, оба приложения могут использовать MKDE для доступа к одним и тем же данным файл.

Ядро базы данных Micro-Kernel не связано с микроядро ядра операционной системы.

Пейджинг

Формат файла Btrieve полностью состоит из страниц, то есть данных, которые перемещаются между памятью и носителем, когда движок выполняет Ввод / вывод операция. В версиях до 6.0 использовались только страницы данных, индексные страницы и запись управления файлом (FCR). Файл имел индекс для поиска, связанный с физическими страницами. Начиная с версии 6.0 логические страницы начали использоваться, то есть страницы, сопоставленные с физические страницы (страницы в фиксированном месте в файле) на диске с помощью набора таблицы размещения страниц (ПАТ).

Запись управления файлом

Контрольная запись файла (FCR) содержит важную информацию о файлах базы данных Btrieve. Он держит размер страницы, количество страниц, которые используются в данный момент, количество ключей, которые могут индексировать файл, количество записей в файле и другие детали. После версии 6.0 для резервирования использовались два FCR. 32-битное поле счетчика использования, которое существует в каждом FCR, используется для определения того, какой FCR был допустим для использования. Каждый раз, когда над файлом выполняется операция, поле увеличивается. FCR с наибольшим количеством использований становится действительным FCR. FCR хорошо описан в исходных образцах от Джима Кайла. С появлением MKDE версии 8 структура страницы FCR изменилась. Размер страницы теперь перемещается внутри FCR и не является обычным 32-битным полем. Начиная с версии 8, вам нужно рассчитать размер страницы, взяв 32-битное поле со смещением 0x2A и умножив на 256.

Таблицы размещения страниц

А таблица размещения страниц (PAT) отображает логические страницы на физические. Каждый PAT - это просто физическая страница, расположенная в четко определенных местах. Как и FCR, PAT всегда встречаются парами, при этом действующая на данный момент копия указывается более высоким счетчиком использования. Первая пара PAT непосредственно следует за первыми двумя FCR и занимает физические страницы 2 и 3. Далее следует переменное количество других страниц, а за ними, в свою очередь, следует новая пара PAT. Каждый PAT имеет фиксированное количество указателей на логические страницы, причем каждая пустая запись имеет нулевое значение.

Количество логических записей, которые могут храниться в PAT, определяется размером его страницы. Каждый указатель страницы в версиях 6.x и 7.x MKDE занимает 4 байта пространства, а заголовок PAT занимает 8 байтов, поэтому количество логических страниц в PAT становится:

Количество логических страниц = (Размер страницы ÷ 4) - 8

С появлением MKDE версии 8 размер заголовка страницы изменился, поэтому эта формула больше не применяется, но принцип остается прежним.

Пейджинг до изображения против теневого пейджинга

До версии 6.0 предварительный просмотр изображения использовался при обновлении записей. Он включал создание нового «файла предварительного изображения» перед внесением изменений, а затем страницы из исходного файла данных были временно скопированы в этот новый файл предварительного изображения. Затем система внесет изменения в исходный файл. Если обновление будет прервано и на страницу будет записана только половина данных, то система просто откатит страницу, скопировав страницу из файла предварительного изображения обратно на поврежденную страницу в исходном файле базы данных, а затем временный файл предварительного изображения будет удален. Файлы прообраза имели расширение .PRE, поэтому обнаружение этих файлов в системе обычно указывало на то, что транзакция произошла некорректно и восстановление не было успешным.

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

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

Альтернативные страницы последовательности сортировки

Альтернативная последовательность сортировки (ACS) страницы - это страницы, которые позволяют сортировать записи в другом порядке. Сопоставление представляет собой сборку письменной информации в стандартном порядке. Обычно это называется алфавитным порядком, хотя сортировка не ограничивается упорядочением букв алфавит. Например, ACS может разрешить сортировку сортировки как с учетом регистра, так и без учета регистра. До версии 6.0 в файле можно было сохранить только один ACS, однако после выпуска 6.0 с файлом можно было одновременно связать более одной страницы ACS.

Дополнительные страницы

В файлах версии 6.0 и более поздних может существовать больше физических страниц, чем используется на самом деле. Это связано с тем, что при теневом разбиении на страницы некоторые страницы в системе могут не иметь записи в PAT. Эти страницы помечаются как «Дополнительные» и используются до того, как будет выделено место для новых страниц.

Таблицы распределения переменных хвостов

В Btrieve каждая страница фиксирована, но размер записи может превышать размер страницы. Это означает, что записи часто необходимо фрагментировать и размещать на разных страницах. В случае очень больших записей это может означать, что для хранения записи может потребоваться использование многих сотен страниц. Подход со связным списком мог бы позволить такую ​​фрагментацию, но движку Btrieve было бы трудно читать последовательные записи. Поэтому, начиная с версии 6.1, в файле используется таблица, в которой хранятся указатели на каждую из страниц, составляющих запись данных. Эта таблица называется таблица распределения с переменным хвостом (НДС).

Индексирование

Btrieve использует индексы для определенных столбцов для быстрого получения данных. Структура наверху - это B-дерево структура данных и индексирует ID сотрудника столбец таблицы базы данных. Стрелки указывают от значения индекса к строкам, содержащим значение в столбце «Идентификатор сотрудника».

Btrieve использует B-дерево формат для хранения индексы записей в частности стол столбцы. Индекс сопоставляет каждый набор значений индексированного столбца с набором уникальных идентификаторов для ряды со значениями этих столбцов, что обеспечивает быстрый способ поиска строк в таблице с помощью индексированного столбца. B-деревья древовидные структуры данных и очень эффективны как механизм для быстрого поиска данных. Недостатком btree является то, что данные должны постоянно балансироваться при вставке в дерево, поэтому Btrieve сохраняет только индекс записи как btree, чтобы сократить время, необходимое для вставки и обновления записей. Для каждого индекса в системе хранится отдельное b-дерево, а информация о корневом узле хранится в FCR. В Btrieve 6.x новый индекс может быть создан во время создания файла или добавлен и удален после создания файла. Индексные страницы также создаются по мере необходимости. До Btrieve 6.0 существующие ключевые индексы нельзя было удалить, хотя дополнительные индексы можно было создавать и удалять по мере необходимости.

Btrieve позволяет дублировать ключевые значения в индексе. Btrieve обрабатывает повторяющиеся ключи, используя либо связанный дубликат метод, или используя повторяющийся дубликат метод (эта терминология начала использоваться с выходом версии 6.0). Связанный метод дублирования использовал пару указателей записей на самой странице индекса, чтобы указать на начало и конец двусвязный список дубликатов ключей. Это означало, что повторяющиеся ключи в списке располагались в том порядке, в котором они были введены. Метод дублирования ключа не использует связанный список, а делает все ключи уникальными, создавая новый индексный ключ и добавляя адрес указателя записи в конец ключа. Это означает, что ключ извлекается через порядок его расположения.

Обмен файлами

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

Параллелизм

Btrieve смог справиться параллельные транзакции в серии 6.x. До Btrieve 6.0 движок мог выполнять только блокировку на уровне файлов или эксклюзивный блокировка; начиная с 6.0, записи можно было блокировать индивидуально. Блокировка на уровне записи (или страницы) была известна как одновременный блокировка. Преимущества были очевидны: несколько клиентов могли получить доступ к файлу одновременно, пока они не пытались получить доступ к одной и той же записи, что приводило к увеличению производительности. Кроме того, другие клиенты могут читать заблокированные страницы и не будут видеть никаких изменений файла, участвующих в транзакции записи другим процессом, заблокировавшим запись.

Режим MEFS не полностью поддерживает одновременную блокировку. Если клиент запустил параллельную транзакцию, а затем попытался выполнить операцию записи в запись, механизм Btrieve вернул бы код состояния 85, который указывал, что файл был заблокирован, даже если использовалась параллельная блокировка.

Системные и пользовательские транзакции

Начиная с версии 6.15 Btrieve, появился новый тип транзакция базы данных был введен под названием системная транзакция, который был отделен от пользовательские транзакции. Пользовательские транзакции - это эксклюзивные и параллельные транзакции, в то время как системные транзакции представляют собой набор нетранзакционных операций и / или пользовательских транзакций. Системные транзакции использовались исключительно для восстановления данных MKDE. Если системный сбой вызывает повреждение данных, то при перезапуске MKDE он обнаруживает все файлы, в которых произошла ошибка системной транзакции, и пытается их восстановить. Однако, поскольку пользовательские транзакции могли быть потеряны при откате последней системной транзакции, могла быть установлена ​​опция, которая заставляла MKDE принудительно завершать системные транзакции, которые имели пользовательские транзакции, когда движок получил запрос «Завершить операцию».

Рекомендации