Требования и возможности индексов LeoBase

• Средства определения групп повторяющихся значений: переход в начало/конец группы, на следующую предыдущую группу;
• Быстрый поиск значения по индексу и выдача первого номера записи, удовлетворяющего условию поиска;
• Средства для преобразования номеров записей из двух БД, связанных между собой. Связь БД по записям можно представить в виде направленного графа:



Стрелки показывают направление связи в LeoBase, но индексы позволяют проводить преобразование как вправо, так и влево, от одного множества записей к другому.

• Возможность вводить новые элементы, удалять старые и перемещать существующие не только по одному, а по пакетам;
• Словарь (гистограмма) индекса, который увеличивает скорость поиска и ускоряет операции изменения индекса (планируется).

Приблизительная завиcимость скорости поиска от количества записей в БД и сложности запроса на поиск (количества термов) показана на графике внизу:

Требования и возможности виртуальных битовых массивов

• Поддержка до 1200 одновременно используемых массивов;
• Весьма оптимальная структура хранения данных в памяти. При работе менеджер ВБМ может использовать всю доступную ему оперативную память, но при запросе с помощью специальной процедуры эту память можно освободить. В Windows-версии такого запроса делать не нужно — память освободится автоматически;
• Базовые функции — установка/сброс бита, проверка на то, установлен ли бит — расширены такими, как установка битов в определенном интервале номеров, выдачи номера N-го бита среди установленных, выдача номера бита по номеру среди установленных, последовательным проходом по единичным битам в сторону увеличения/уменьшения номера бита и многими другими;
• Функционально полный набор операций между битовыми массивами: логическое AND, OR, SUB, NOT;
• Методы сохранения и восстановления массивов из файла;
• Быстрое занесение информации из индекса LeoBase в битовый массив, например, занесение всей текущей группы повторяющихся значений или занесение всех значений индекса в определенном диапазоне номеров в индексе. Именно благодаря такой возможности результатом запроса на поиск в LeoBase являются все записи, удовлетворяющие запросу, а не только первая, причем результат возвращается очень быстро.

Возможности и требования LSF

• Буферизация чтения и записи. Под буфер может выделяться вся память компьютера;
• Гибкая работа с буфером. При наличии свободной памяти LSF может забрать ее целиком, но при необходимости у него можно забрать эту память в таком объеме, который нужен. В версии для Windows этот запрос не нужен -- LSF отрабатывает системные запросы по выделению памяти и сам отдает ее в нужном количестве;
• Поддержка отложенной записи в файлы на диске;
• Набор операций с файлами по сравнению со стандартным значительно расширен. Этот набор позволяет использовать LSF в качестве полноценного файлового менеджера. Кроме стандартных записи и чтения, поддерживается заполнение файла определенным байтовым значением, вырезание фрагмента файла, вставка пустого места в любое место файла, перемещение фрагмента файла в любое место и многое другое;
• Независимость числа файлов, зарегистрированных под LSF, от максимального количества дескрипторов файлов DOS;
• Возможность назначать различные уровни привилегий буферизации разным файлам и разным частям одного файла. Таким образом, более важные файлы или их части будут находится в буфере LSF дольше, чем остальные. Можно назначать разные степени важности частей файлов в зависимости от конкретной ситуации;
• Мощная система триггеров. Благодаря этому есть возможность переопределить или дополнить практически все стандартные действия LSF, например, вести статистику выполненных действий, кодировать записываемую на диск информацию и многое другое. Перекрыв триггера, можно адаптировать LSF к работе на других платформах и организовать доступ к абстрактному устройству, например, к удаленному носителю по выделенному каналу;
• Прозрачное для программиста размещение одного или нескольких файлов на нескольких физических носителях, что в подавляющем большинстве случаев снимает проблему нехватки места для файлов. В случае же нехватки места имеется возможность спасения информации на отдельных носителях, в качестве которых могут использоваться даже дискеты. В следующем сеансе работы информацию с этих носителей можно перенести на основные носители, освободив там место;
• Для успешной работы LSF необходимо около 10 К оперативной памяти. Для регистрации одного файла требуется около 60 байт памяти.

Работа с LSJ

Для того, чтобы задействовать механизм моментальных снимков, следует создать системный журнал. При работе комплекса БД заполнение системного журнала организовано циклически. Он состоит из нескольких секций одинакового размера. Запись в секции идет последовательно. Когда свободных секций не остается, аннулируются данные сначала первой секции, затем следующей и т.д. Число секций и размер каждой является важными характеристиками. Рассмотрим следующую аналогию. Имеется альбом фотографий, с фотоснимками разных стран. Количество фото, которые там могут поместится ограничены его объемом. При переполнении альбома выбрасываются самые старые фотографии и на их место помещаются новые.Если путешествия происходят очень часто, альбом заполняется и обновляется достаточно быстро. Таким образом, максимальная давность фото о событии определяется толщиной альбома и частотой поездок по разным странам.

Так и в системном журнале, самое старое состояние базы, которое можно будет посмотреть (активизировав соответствующий снимок) зависит от размера журнала, частоты изменений БД, а также от количества секций (так как при необходимости секция аннулируется целиком).

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

Поясним работу системного журнала. Имеется системный журнал, состоящий из 4 секций.

На шаге 1 системный журнал пустой. На шаге 2 у него заполнены 3 секции целиком и в конце первой секции установлен снимок, используя который генерируется объемный отчет. На третьем шаге системный журнал переполняется. При этом данные в первой секции должны быть аннулированы.

Однако так как генерируется отчет по снимку, тот зафиксирован ядром LeoBase. Поэтому сервер прекращает заполнения системного журнала, блокирует все системные транзакции до снятия снимка (завершения генерации отчета).

Выходов из этой ситуации два. Либо увеличить общий объем системного журнала, либо разбить его на большее число секций, при том же объеме.

Если число секций будет 5, появится шанс, что установленный снимок будет не в первой, а во второй секции. При этом блокировка произойдет только при повторном заполнении первой секции и переходе ко второй. Это дает дополнительное время, за которое генерация отчета может завершится. Однако переключение между секциями требует некоторого времени. Основная задача проектировщика - найти баланс между числом секций и скоростью работы.

Возможности и требования UPGRADE

Поясним назначение данной системы на следующем примере.

Компания N создала информационно-справочную систему большого объема. Изменение и пополнение базы данных происходит постоянно, причем пользователи, купившие этот продукт, должны своевременно получать новую версию базы. Есть два способа решения этой проблемы. Первый - рассылать всем абонентам полную копию новой базы. Если общий объем данных, по сравнению с изменениями, достаточно велик, то это тянет за собой значительные накладные расходы. Второй вариант - пересылать только новую и измененную информацию. Безусловно, это гораздо эффективнее. Именно реализация второго варианта возложена в LeoBase на систему UPGRADE.

Проведение UPGRADE разделятся на две фазы. Фаза 1 проводится на компьютере, называемом хостом, где хранится последний вариант базы данных. Ее результатом становится UPGRADE-файл, содержащий все изменения и дополнения, произошедшие с заданного момента времени. Фаза 2 проводится на компьютере - абоненте, который на основе информации, считанной из UPGRADE-файла производит актуализацию содержимого собственной базы данных.

Необходимым условием успешной работы фазы 1 является ведение на хосте журнала изменений. UPGRADE-файл может быть двух форматов: Fast и Compact. В первом случае файл формируется относительно быстрее, однако его размер больше, нежели во втором. Формат Compact требует обязательного наличия системного журнала, а размер полученного UPGRADE-файла является минимально возможным. Основное отличие между двумя форматами заключается в том, что в Fast-формате в UPGRADE-файл модифицируемые записи помещаются целиком, а в Compact — только реально измененные поля. Это не относится к МЕМО-полям, которые и в том, и в другом случае записываются в UPGRADE-файл только при необходимости (т.е. это не относится к изменению содержимого самой записи).

Для операций обновления и согласования БД большое значение имеет понятие системного и UPGRADE-времени LeoBase. Они представляют собой переменные типа TLBSystemTime. UPGRADE-время используется для синхронизации содержимого БД на хосте и абоненте. Системное время служит начальным отсчетом для проведения фазы 1 на хосте.

 

Click Here to Return Back

Webmasters, contact Belarus.net support
Click Here to visit Belarus.net