Кэш страницы хранит страницы базы данных.
Кэш записи хранит копии активных и нейтральных записей.
Память системы хранит информацию контекста транзакции, индексные акселераторы и метаданные системы.
Рабочие потоки являются фоновыми потоками. Имеются два потока: поток "gopher" перемещает данные из последовательный файла регистрации Falcon в кэш страницы базы данных и из кэша страниц на диск. Второй поток программы записи страницы, который пишет страницы с blob.
2.4.5.1. Файл и структуры данных Falcon
Одиночные файлы базы данных Falcon хранят все данные записи, индексы, структуру базы данных и другую информацию. Индивидуальная информация сохранена в ряде страниц.
Страницы описывают блок распределения оперативной памяти в Falcon. Страницы используются, чтобы сохранить данные и индексировать информацию. Размер страницы и то, как Falcon кэширует и распределяет страницы для использования при сохранении информации, воздействует на эффективность в зависимости от записей, которые сохраняются.
Страницы, кэшируемые в памяти используются, чтобы сохранить индексы, blob'ы и структурные данные для конкретного пространства таблиц. Активные записи сохранены внутри отдельного кэша записей.
Все транзакции в базе данных регистрируются и сохранены внутри отдельного журнала. Журнал автоматически сбрасывается и изменения записываются на диск, когда имеется команда COMMIT, когда включен auto-commit или автоматически через каждые 30 секунд, когда транзакции не используются.
2.4.5.2. Последовательный файл регистрации Falcon
Falcon использует последовательный файл регистрации, чтобы сохранить некоторые типы информации до того, как данные окончательно сохранятся в базе данных. Файл регистрации используется, чтобы сохранить следующие типы информации:
Записи данных в течение совершающейся фазы.
Физические изменения базы данных, требуемые для восстановления данных после аварийного отказа.
Логические изменения базы данных, требуемые для восстановления ресурса после аварийного отказа.
Изменения статуса для всех активных транзакций.
Все транзакции в Falcon записаны в последовательный файл регистрации Falcon, а затем переданы к базе данных автоматически, если включен AUTOCOMMIT, или вручную, когда используется команда COMMIT.
Регистрация информации сохранена в памяти, и несохранные изменения файла регистрации периодически сбрасываются на диск. Фоновый поток обрабатывает содержание файла регистрации, передавая) изменения файла регистрации в базу данных. Передающий процесс устанавливает конечное состояние всех записей и страниц, независимо от любых вмешивающихся состояний, только конечное состояние фактически записано на диск.
Обратите внимание, однако, что последовательный файл регистрации только модифицирует данные записи через кэш страницы в оперативной памяти. Фактические данные записи будут записаны на диск, когда происходит процесс контрольной точки. Исключительная ситуация к этому правилу: индексные и blob-записи, которые немедленно записаны на диск как часть процесса.
Falcon создает два последовательных журнала. Первый журнал используется, чтобы сохранить последовательные данные файла регистрации, пока файл регистрации не достигает определенного размера. Если только этот размер был достигнут, регистрация переключена на второй последовательный журнал. Процесс продолжает читать из первого журнала, пока все транзакции не будут записаны в базу данных. Первый журнал затем освобожден и вновь создан.
Входы файла регистрации во втором файле затем обработаны до тех пор, пока все транзакции в файле регистрации завершены. Тот файл затем освобожден и вновь создан, готовым к использованию, как только первый журнал наполнится или станет блокированным для передачи.
2.4.5.2.1. Процесс обратной перемотки
Обратные перемотки транзакции обработаны потоком для соответствующей транзакции. Процесс обратной перемотки выполняет следующие действия:
Отступающие индексные модификации.
Отменяет любые данные blob, созданные транзакцией.
Освобождает распределенные слоты записи.
Отменяет версию записи, созданную в памяти.
2.4.5.2.2. Групповое завершение транзакций
Для эффективности Falcon использует систему, которая гарантирует, что все ждущие обработки модификации последовательного файла регистрации записаны на диск в то же самое время. Falcon может иметь многократные активные транзакции, но транзакции записывают все ждущие обработки изменения последовательного файла регистрации на диск только однократно, уменьшая число записей на диск и улучшая полную эффективность последовательного файла регистрации. Например:
Транзакция 1 создает все необходимые входы файла регистрации и начинает записывать файл регистрации на диск.
В то время как транзакция 1 завершается, транзакции 2 и 3 записывают их входы в последовательный файл регистрации.
Как только транзакция 1 закончила физическую запись, или транзакция 2 или 3 (но не обе) запишут незаписанную часть данных, находящуюся в оперативной памяти, файл регистрации будет готов к сбросу на диск. Потому как обе транзакции произошли после с последней записи на диск последовательного файла регистрации, информация для обемх записана на диск в то же самое время.
В то время как транзакции 2 и 3 записывают, транзакции 4, 5 и 6 записываются в журнал в оперативной памяти. Когда запись для 2 и 3 завершается, входы для 4, 5 и 6 записаны.
Результат вышеупомянутого процесса: имеются только три физические записи на диск, даже при том, что имеется шесть транзакций в последовательности:
Транзакция 1,
Транзакции 2 и 3,
Транзакции 4, 5 и 6.
Процесс продолжает работать только с одной транзакцией, записывающей все последовательные входы файла регистрации в оперативной памяти на диск, начиная с последней записи. Вся система гарантирует, что оперативная память и дисковый файл регистрации сохраняются в синхронизации с самым низким количеством физических записей на диск.
Вышеупомянутый процесс работает в тандеме с использованием двух последовательных журналов, чтобы гарантировать, что информация в оперативной памяти и на диске обновляется своевременно.
2.4.5.3. Восстановление аварийного отказа Falcon
Последовательный файл регистрации Falcon используется автоматически, когда первая таблица в базе данных Falcon открыта, чтобы восстановить транзакции и модифицировать базу данных. Когда транзакции и изменения записаны в последовательный файл регистрации, он включает входы, которые записывают изменения для всех областей базы данных, включая индексы, изменения для данных BLOB и любые структурные изменения базы данных.
В течение восстановления аварийного отказа Falcon исследует последовательный файл регистрации и идентифицирует первый вход, который не был передан к базе данных. Процесс восстановления записывает все незаписанные данные, изменяет индекс и данные blob, освобождая любые необходимые слоты записи (из удаленных записей) и завершая любые структурные изменения.
2.4.5.4. Кэши памяти Falcon
Falcon был разработан, чтобы выполняться лучше всего на системах с щедрыми объемами памяти. Кэши памяти, используемые Falcon подобны в некоторых отношениях другим СУБД и MySQL. Однако, структура кэш имеет ряд усовершенствований по сравнению с традиционной cтратегией кэширующей памяти. Механизмы, используемые Falcon относительно кэширования памяти включают:
Log Cache информация файла регистрации сохраняется в памяти и сбрасывается на диск, когда транзакции совершаются. Falcon хранит восемь окон для чтения и записи в журнал, и каждое окно 1 MB.
System and Index Cache данные, необходимые Falcon (определения таблицы и полей, состояние транзакции и т.д.) также поддерживаются в памяти для справочника. Кроме того, локальные индексные акселераторы представляют индексные сегменты, созданные выполняющейся транзакцией, также сохранены в памяти системы. Когда транзакция изменяет индексированные поля, это формирует индексный раздел акселератора в памяти системы, представляя изменения. При завершении транзакции все индексные измене ния для транзакции записаны в сортируемом порядке в последовательный вход и позже объединены с постоянным индексом.
Page Cache страницы базы данных читаются с диска для специфической базы данных. Размер кэша страницы управляется параметром falcon_page_cache_size, значение по умолчанию которого 4 MB установлено в файле my.cnf. Хотя изменения записи и индекса идут в последовательный файл регистрации прежде, чем запишутся в страницы базы данных, данные blob записаны непосредственно в кэш страницы. Это не дает регистрировать большие элементы данных, которые редко вызваны или изменены транзакцией, которая создает их.