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

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

Btrieve - это база данных, разработанная Pervasive Software . Архитектура 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 также остается обратной совместимостью, только одна функции (сплит файлов в отдельные средства массовой информации) при падении. В какой-то момент бывший генеральный директор Btrieve Рон Харрис заявил, что «API версии 1.0 все еще поддерживается в версии 6.15, и мы собираемся сохранить его навсегда!» ( Кайл , стр. 11).

Терминология базы данных [ править ]

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

Ядро базы данных с микроядром [ править ]

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

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

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

Пейджинг [ править ]

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

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

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

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

Обмен файлами [ править ]

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

Параллелизм [ править ]

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

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

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

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

Ссылки [ править ]