Расширяемый механизм хранения данных

Информацию о JET Red механизме хранения Microsoft Access см. в разделе Access Database Engine .

Расширяемый механизм хранения данных

Другие имена	Джет Синий
Разработчик(и)	Майкрософт
Первоначальный выпуск	1994 год ( 1994 )
Репозиторий	github .с /Microsoft /Расширяемый-Storage-Engine
Написано в	С++
Операционная система	Microsoft Windows
Платформа	IA-32 , x86-64 , ARM и Itanium (и исторически DEC Alpha , MIPS и PowerPC )
Тип	Механизм базы данных
Лицензия	МОЯ лицензия
Веб-сайт	документы .microsoft .с /en-нас /окна /win32 /extensible-storage-engine /extensible-storage-engine

Extensible Storage Engine ( ESE ), также известный как JET Blue , — это технология хранения данных ISAM (метод индексированного последовательного доступа) от Microsoft . ESE является ядром Microsoft Exchange Server , Active Directory и поиска Windows . Он также используется рядом компонентов Windows, включая клиент Центра обновления Windows и Центр справки и поддержки . Его цель — позволить приложениям хранить и извлекать данные посредством индексированного и последовательного доступа.

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

Среда выполнения ESE (ESENT.DLL) поставляется в каждом Windows выпуске , начиная с Windows 2000 , при этом собственная версия среды выполнения ESE для x64 поставляется с версиями x64 для Windows XP и Windows Server 2003 . Microsoft Exchange до версии Exchange 2003 поставлялся только с 32-разрядной версией, поскольку это была единственная поддерживаемая платформа. Вместе с Exchange 2007 поставляется 64-разрядная версия.

Базы данных

База данных представляет собой одновременно физическую и логическую группу данных. База данных ESE выглядит для Windows как один файл. Внутренняя база данных представляет собой набор страниц размером 2, 4, 8, 16 или 32 КБ (варианты страниц размером 16 и 32 КБ доступны только в Windows 7 и Exchange 2010). организованы в виде сбалансированной структуры B-дерева . Эти страницы содержат метаданные для описания данных, содержащихся в базе данных, сами данные, индексы для сохранения интересных порядков данных и другую информацию. Эта информация перемешивается в файле базы данных, но предпринимаются усилия для того, чтобы данные, используемые вместе, были сгруппированы в базе данных. База данных ESE может содержать до 2 ³² страниц или 16 терабайт данных, для страниц размером 8 килобайт .

Базы данных ESE организованы в группы, называемые экземплярами. Большинство приложений используют один экземпляр, но все приложения также могут использовать несколько экземпляров. Важность экземпляра заключается в том, что он связывает одну серию журналов восстановления с одной или несколькими базами данных. В настоящее время к экземпляру ESE в любое время можно подключить до 6 пользовательских баз данных. Каждый отдельный процесс, использующий ESE, может иметь до 1024 экземпляров ESE.

База данных является переносимой, поскольку ее можно отсоединить от одного работающего экземпляра ESE, а затем подключить к тому же или другому работающему экземпляру. В отсоединенном состоянии базу данных можно скопировать с помощью стандартных утилит Windows. Базу данных невозможно скопировать, пока она активно используется, поскольку ESE открывает исключительно файлы базы данных. База данных может физически находиться на любом устройстве, поддерживаемом Windows для операций ввода-вывода с прямой адресацией.

Таблицы

Таблица — это однородный набор записей, в котором каждая запись имеет одинаковый набор столбцов. Каждая таблица идентифицируется именем таблицы, область действия которой является локальной для базы данных, в которой содержится таблица. Объем дискового пространства, выделенного для таблицы в базе данных, определяется параметром, заданным при создании таблицы с помощью операции CreateTable. Таблицы увеличиваются автоматически в ответ на создание данных.

Таблицы имеют один или несколько индексов. Для данных записи должен существовать хотя бы один кластеризованный индекс. Если приложение не определяет кластеризованный индекс, используется искусственный индекс, который упорядочивает и кластеризует записи в соответствии с хронологическим порядком вставки записей. Индексы предназначены для сохранения интересных порядков данных и позволяют как последовательный доступ к записям в индексном порядке, так и прямой доступ к записям по значениям индексного столбца. Кластерные индексы в ESE также должны быть первичными, то есть ключ индекса должен быть уникальным.

Кластеризованные и некластеризованные индексы представляются с помощью деревьев B+ . Если операция вставки или обновления приводит к переполнению страницы, страница разделяется: выделяется новая страница, которая логически объединяется между двумя ранее соседними страницами. Поскольку эта новая страница физически не примыкает к своим логическим соседям, доступ к ней не столь эффективен. ESE имеет функцию онлайн-сжатия, которая повторно сжимает данные. Если ожидается, что таблица будет часто обновляться, пространство можно зарезервировать для будущих вставок, указав соответствующую плотность страниц при создании таблицы или индекса. Это позволяет избежать или отложить операции разделения.

Записи и столбцы

Запись — это связанный набор значений столбца. Записи вставляются и обновляются с помощью операций обновления и могут быть удалены с помощью операций удаления. Столбцы устанавливаются и извлекаются с помощью операций SetColumns и RetriveColumns соответственно. Максимальный размер записи составляет 8110 байт для страниц размером 8 килобайт, за исключением столбцов с длинными значениями. Типы столбцов LongText и LongBinary не вносят существенного вклада в это ограничение размера, и записи могут содержать данные, намного превышающие размер страницы базы данных, когда данные хранятся в столбцах с длинными значениями. Когда в записи хранится ссылка на длинное значение, требуется только 9 байт данных записи. этих длинных значений может достигать 2 гигабайт Размер (ГБ).

Записи обычно являются однородными, поскольку каждая запись имеет набор значений для одного и того же набора столбцов. В ESE также можно определить множество столбцов для таблицы, но при этом каждая запись будет содержать лишь небольшое количество значений столбца, отличных от NULL. В этом смысле таблица также может представлять собой набор разнородных записей.

ESE поддерживает широкий диапазон значений столбцов размером от 1 бита до 2 ГБ. Выбор правильного типа столбца важен, поскольку тип столбца определяет многие его свойства, включая порядок индексов. ESE поддерживает следующие типы данных:

Типы столбцов

Имя	Описание
Кусочек	троичное значение (NULL, 0 или 1)
Беззнаковый байт	1-байтовое целое число без знака
Короткий	2-байтовое целое число со знаком
Неподписанный короткий	2-байтовое целое число без знака
Длинный	4-байтовое целое число со знаком
Беззнаковый длинный	4-байтовое целое число без знака
ЛонгЛонг	8-байтовое целое число со знаком
Беззнаковыйдлинныйдлинный	8-байтовое целое число без знака
Валюта	8-байтовое целое число со знаком
IEEE одиночный	4-байтовое число с плавающей запятой
IEEE двойной	8-байтовое число с плавающей запятой
ДатаВремя	8-байтовая дата-время (целая дата, дробное время)
ГУИД	16-байтовый уникальный идентификатор
Двоичный	Двоичная строка длиной <= 255 байт.
Текст	Строка ANSI или Unicode длиной <= 255 байт.
Длинный двоичный файл	Большая двоичная строка, длина <2 ГБ.
Длинный текст	Большая строка ANSI или Unicode, длина < 2 ГБ

Фиксированные, переменные и помеченные столбцы

Каждая таблица ESE может определять до 127 столбцов фиксированной длины, 128 столбцов переменной длины и 64 993 столбца с тегами.

• Фиксированные столбцы — это, по сути, столбцы, которые занимают одинаковое количество места в каждой записи, независимо от их значения. Фиксированные столбцы занимают 1 бит для представления значения NULL значения столбца и фиксированный объем пространства в каждой записи, в которой установлен этот столбец или определенный позже фиксированный столбец.
• Столбцы переменных — это, по сути, столбцы, которые занимают разное количество места в каждой записи, в которой они установлены, в зависимости от размера конкретного значения столбца. Столбцы переменных занимают 2 байта для определения значения NULL и размера, а также переменный объем пространства в каждой записи, в которой установлен этот столбец.
• Столбцы с тегами — это столбцы, которые вообще не занимают места, если они не установлены в записи. Они могут быть однозначными, но также могут быть и многозначными. Один и тот же столбец с тегами может иметь несколько значений в одной записи. Когда в записи установлены тегированные столбцы, каждый экземпляр тегированного столбца занимает примерно 4 байта пространства в дополнение к размеру значения экземпляра тегированного столбца. Когда количество экземпляров одного тегированного столбца велико, накладные расходы на каждый экземпляр тегированного столбца составляют примерно 2 байта. Столбцы с тегами идеально подходят для разреженных столбцов, поскольку они вообще не занимают места, если не установлены. Если индексируется многозначный тегированный столбец, индекс будет содержать одну запись для каждого значения тегированного столбца.

В данной таблице столбцы попадают в одну из двух категорий: те, которые либо встречаются ровно один раз в каждой записи, возможно, с несколькими значениями NULL; и те, которые встречаются редко или которые могут встречаться несколько раз в одной записи. Столбцы с фиксированными и переменными относятся к первой категории, а столбцы с тегами — ко второй. Внутреннее представление двух категорий столбцов различно, и важно понимать компромиссы между категориями столбцов. Фиксированные и переменные столбцы обычно представлены в каждой записи, даже если вхождение имеет значение NULL. К этим столбцам можно быстро обратиться с помощью таблицы смещений. Вхождениям столбца с тегами предшествует идентификатор столбца, и столбец находится путем двоичного поиска в наборе столбцов с тегами.

Длинные значения

Столбцы типа Long Text и Long Binary представляют собой большие двоичные объекты. Они хранятся в отдельном B+дереве от кластеризованного индекса с ключом по длинному идентификатору значения и смещению байтов. ESE поддерживает добавление, перезапись диапазона байтов и установку размера для этих столбцов. Кроме того, в ESE имеется функция хранилища одного экземпляра, при которой несколько записей могут ссылаться на один и тот же большой двоичный объект, как если бы каждая запись имела свою собственную копию информации, т. е. без конфликтов блокировки между записями. Максимальный размер значения столбца «Длинный текст» или «Длинный двоичный код» составляет 2 ГБ.

Столбцы версии, автоинкремента и условного депонирования

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

Столбцы с автоинкрементом автоматически устанавливаются ESE таким образом, что значение, содержащееся в столбце, является уникальным для каждой записи в таблице. Эти столбцы, как и столбцы версии, не могут быть установлены приложением. Столбцы с автоинкрементом доступны только для чтения и автоматически устанавливаются, когда новая запись вставляется в таблицу с помощью операции обновления. Значение в столбце остается постоянным на протяжении всего срока существования записи, и для каждой таблицы допускается только один столбец с автоматическим увеличением. Столбцы с автоинкрементом могут иметь тип Long или Currency.

Столбцы условного депонирования можно изменить с помощью операции EscrowUpdate. Депонированные обновления представляют собой числовые дельта-операции. Столбцы условного депонирования должны иметь тип Long. Примеры числовых операций с дельтой включают добавление 2 к значению или вычитание 1 из значения. ESE отслеживает изменение значения, а не конечное значение обновления. В каждом из нескольких сеансов могут быть невыполненные изменения, внесенные с помощью EscrowUpdate в одно и то же значение, поскольку ESE может определить фактическое конечное значение независимо от того, какие транзакции фиксируются, а какие откатываются. Это позволяет нескольким пользователям одновременно обновлять столбец, внося числовые изменения дельты. При желании ядро ​​базы данных может удалять записи с нулевым значением столбца. Обычно такой столбец условного депонирования используется в качестве счетчика ссылок: многие потоки увеличивают/уменьшают значение без блокировок, а когда счетчик достигает нуля, запись автоматически удаляется.

Индексы

Индекс — это постоянный порядок записей в таблице. Индексы используются как для последовательного доступа к строкам в заданном порядке, так и для прямой навигации по записям на основе значений индексированных столбцов. Порядок, определяемый индексом, описывается в виде массива столбцов в порядке старшинства. Этот массив столбцов также называется ключом индекса. Каждый столбец называется сегментом индекса. Каждый сегмент индекса может быть либо возрастающим, либо нисходящим с точки зрения его вклада в порядок. Для таблицы может быть определено любое количество индексов. ESE предоставляет богатый набор функций индексирования.

Кластеризованные индексы

Один индекс может быть указан как кластерный или первичный индекс. В ESE кластеризованный индекс должен быть уникальным и называется первичным индексом. Другие индексы описываются как некластеризованные или вторичные индексы. Первичные индексы отличаются от вторичных индексов тем, что записью индекса является сама запись, а не логический указатель на запись. Вторичные индексы имеют первичные ключи на своих концах для логической связи с записью в первичном индексе. Другими словами, таблица физически кластеризована в порядке первичного индекса. Извлечение данных неиндексированных записей в порядке первичного индекса обычно происходит намного быстрее, чем в порядке вторичного индекса. Это связано с тем, что один доступ к диску может перенести в память несколько записей, доступ к которым будет осуществляться близко друг к другу во времени. Один и тот же доступ к диску удовлетворяет нескольким операциям доступа к записям. Однако вставка записи в середину индекса, определяемая порядком первичного индекса, может быть намного медленнее, чем добавление ее в конец индекса. Частота обновления должна быть тщательно продумана с учетом шаблонов поиска при проектировании таблицы. Если для таблицы не определен первичный индекс, то создается неявный первичный индекс, называемый индексом ключа базы данных (DBK). DBK — это просто уникальный возрастающий номер, увеличивающийся при каждой вставке записи. В результате физический порядок записей в индексе БДК является хронологическим порядком вставки, и новые записи всегда добавляются в конец таблицы. Если приложение желает кластеризовать данные по неуникальному индексу, это возможно путем добавления столбца автоинкремента в конец определения неуникального индекса.

Индексирование по многозначным столбцам

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

Разреженные индексы

Индексы также можно определить как разреженные. Разреженные индексы не имеют хотя бы одной записи для каждой записи в таблице. Существует несколько вариантов определения разреженного индекса. Существуют опции для исключения записей из индексов, когда весь ключ индекса имеет значение NULL, когда любой сегмент ключа имеет значение NULL или когда только первый сегмент ключа имеет значение NULL. Индексы также могут иметь условные столбцы. Эти столбцы никогда не появляются в индексе, но могут привести к тому, что запись не будет индексироваться, если условный столбец имеет значение NULL или не NULL.

Индексы кортежей

Индексы также можно определить так, чтобы они включали одну запись для каждой подстроки столбца «Текст» или «Длинный текст». Эти индексы называются кортежными индексами. Они используются для ускорения запросов с предикатами сопоставления подстрок. Индексы кортежей можно определить только для текстовых столбцов. Например, если значение столбца «Текст» — «Я люблю JET Blue» , а индекс настроен на минимальный размер кортежа в 4 символа и максимальную длину кортежа в 10 символов, то будут проиндексированы следующие подстроки:

«Я люблю Джет» «люблю Джет» «люблю Джет Б» «люблю JET Bl» «ве Джет Блу» «e JET Blue» «ДЖЕТ Блю» «ДЖЕТ Блю» «ЭТ Блю» «Т Синий» " Синий" "Синий"

Несмотря на то, что индексы кортежей могут быть очень большими, они могут значительно ускорить запросы вида: найти все записи, содержащие «JET Blue» . Их можно использовать для подстрок, длина которых превышает максимальную длину кортежа, путем разделения подстроки поиска на строки поиска кортежа максимальной длины и пересечения результатов. Их можно использовать для точного совпадения строк длиной до максимальной длины кортежа или до минимальной длины кортежа без пересечения индексов. Дополнительные сведения о выполнении пересечения индексов в ESE см. в разделе Пересечение индексов . Индексы кортежей не могут ускорить запросы, в которых строка поиска короче минимальной длины кортежа.

Транзакции

Транзакция — это логическая единица обработки, ограниченная операциями BeginTransaction и CommitTransaction или Rollback. Все обновления, выполняемые во время транзакции, являются атомарными; они либо все появляются в базе данных одновременно, либо ни один не появляется. Любые последующие обновления другими транзакциями невидимы для транзакции. Однако транзакция может обновлять только те данные, которые за это время не изменились; в противном случае операция завершится неудачно сразу, без ожидания. Транзакции только для чтения никогда не требуют ожидания, а транзакции обновления могут только мешать друг другу, обновляя транзакцию. Транзакции, прерванные откатом или сбоем системы, не оставляют следов в базе данных. Как правило, при откате состояние данных восстанавливается до состояния, которое было до начала транзакции.

Транзакции могут иметь до 7 уровней вложенности, при этом один дополнительный уровень зарезервирован для внутреннего использования ESE. Это означает, что можно откатить часть транзакции без необходимости отката всей транзакции; CommitTransaction вложенной транзакции просто означает успех одной фазы обработки, а внешняя транзакция все же может потерпеть неудачу. Изменения фиксируются в базе данных только тогда, когда фиксируется самая внешняя транзакция. Это называется фиксацией на уровне транзакции 0. Когда транзакция фиксируется на уровне транзакции 0, данные, описывающие транзакцию, синхронно сбрасываются в журнал, чтобы гарантировать, что транзакция будет завершена даже в случае последующего сбоя системы. Синхронная очистка журнала обеспечивает надежность транзакций ESE. Однако в некоторых случаях приложение желает заказать свои обновления, но не гарантирует немедленного внесения изменений. Здесь приложения могут фиксировать изменения с помощью JET_bitIndexLazyFlush.

ESE поддерживает механизм управления параллелизмом, называемый многоверсионностью. При использовании нескольких версий каждая транзакция запрашивает согласованное представление всей базы данных в том виде, в каком она была на момент начала транзакции. Единственные обновления, с которыми он сталкивается, — это обновления, сделанные им самим. Таким образом, каждая транзакция работает так, как если бы она была единственной активной транзакцией, выполняющейся в системе, за исключением случаев конфликтов записи. Поскольку транзакция может вносить изменения на основе считанных данных, которые уже были обновлены в другой транзакции, многоверсионность сама по себе не гарантирует сериализуемость транзакций. Однако при желании сериализуемость может быть достигнута путем простого использования явных блокировок чтения записей для блокировки данных чтения, на которых основаны обновления. Блокировки чтения и записи могут быть явно запрошены с помощью операции GetLock.

Кроме того, ESE поддерживает расширенную функцию управления параллелизмом, известную как блокировка условного депонирования. Блокировка условного депонирования — это одновременное обновление, при котором числовое значение изменяется относительным образом, т. е. путем добавления или вычитания другого числового значения. Обновления условного депонирования не конфликтуют даже с другими одновременными обновлениями условного депонирования для тех же данных. Это возможно, поскольку поддерживаемые операции являются взаимозаменяемыми и могут независимо фиксироваться или откатываться. В результате они не мешают одновременным транзакциям обновления. Эта функция часто используется для поддерживаемых агрегатов.

ESE также расширяет семантику транзакций от операций манипулирования данными до операций определения данных. Можно добавить индекс в таблицу и одновременно выполнять транзакции, обновляющие одну и ту же таблицу, без каких-либо конфликтов при блокировке транзакций. Позже, когда эти транзакции завершены, вновь созданный индекс доступен для всех транзакций и содержит записи для обновлений записей, сделанных другими транзакциями, которые не смогли обнаружить присутствие индекса во время обновлений. Операции определения данных могут выполняться со всеми функциями, ожидаемыми от механизма транзакций для обновления записей. Операции определения данных, поддерживаемые таким образом, включают AddColumn, DeleteColumn, CreateIndex, DeleteIndex, CreateTable и DeleteTable.

Курсорная навигация и буфер копирования

Курсор — это логический указатель внутри индекса таблицы. Курсор может быть расположен на записи, перед первой записью, после последней записи или даже между записями. Если курсор расположен до или после записи, текущей записи нет. В одном индексе таблицы можно разместить несколько курсоров. Многие операции с записями и столбцами основаны на положении курсора. Позицию курсора можно перемещать последовательно с помощью операций перемещения или напрямую с помощью индексных клавиш с помощью операций поиска. Курсоры также можно перемещать в дробную позицию внутри индекса. Таким образом, курсор можно быстро переместить в положение панели большого пальца. Эта операция выполняется с той же скоростью, что и операция поиска. Никакие промежуточные данные не должны быть доступны.

Каждый курсор имеет буфер копирования для создания новой записи или изменения существующей записи, столбец за столбцом. Это внутренний буфер, содержимое которого можно изменить с помощью операций SetColumns. Модификации буфера копирования не приводят к автоматическому изменению сохраненных данных. Содержимое текущей записи можно скопировать в буфер копирования с помощью операции Подготовка обновления, а операции обновления сохраняют содержимое буфера копирования в виде записи. Буфер копирования неявно очищается при фиксации или откате транзакции, а также при операциях навигации. RetriveColumns можно использовать для извлечения данных столбца либо из записи, либо из буфера копирования, если таковой существует.

Обработка запросов

Приложения ESE неизменно запрашивают свои данные. В этом разделе документа описываются функции и методы, позволяющие приложениям писать логику обработки запросов в ESE.

Сортировки и временные таблицы

ESE предоставляет возможность сортировки в виде временных таблиц. Приложение вставляет записи данных в процесс сортировки по одной записи, а затем извлекает их по одной записи в отсортированном порядке. Сортировка фактически выполняется между последней вставкой записи и первым получением записи. Временные таблицы также можно использовать для частичных и полных наборов результатов. Эти таблицы могут предлагать те же функции, что и базовые таблицы, включая возможность последовательного или прямого перехода к строкам с использованием ключей индекса, соответствующих определению сортировки. Временные таблицы также можно обновлять для расчета сложных агрегатов. Простые агрегаты могут рассчитываться автоматически с помощью функции, аналогичной сортировке, где желаемый агрегат является естественным результатом процесса сортировки.

Индексы покрытия

Получение данных столбца непосредственно из вторичных индексов является важной оптимизацией производительности. Столбцы можно получить непосредственно из вторичных индексов, без доступа к записям данных, с помощью флага RetrieveFromIndex в операции RetieveColumns. При навигации по индексу гораздо эффективнее извлекать столбцы из вторичного индекса, чем из записи. Если данные столбца были получены из записи, то необходима дополнительная навигация для поиска записи по первичному ключу. Это может привести к дополнительному доступу к диску. Когда индекс предоставляет все необходимые столбцы, он называется покрывающим индексом. Обратите внимание, что столбцы, определенные в первичном индексе таблицы, также находятся во вторичных индексах и могут быть получены аналогичным образом с помощью JET_bitRetrieveFromPrimaryBookmark.

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

Пересечение индексов

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

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

Предварительно объединенные таблицы

Соединение — это обычная операция в нормализованной таблице, при которой логически связанные данные собираются вместе для использования в приложении. Объединения могут быть дорогостоящими операциями, поскольку для переноса связанных данных в память может потребоваться множество обращений к данным. В некоторых случаях эти усилия можно оптимизировать, определив одну базовую таблицу, содержащую данные для двух или более логических таблиц. Набор столбцов базовой таблицы представляет собой объединение наборов столбцов этих логических таблиц. Столбцы с тегами делают это возможным благодаря хорошей обработке как многозначных, так и разреженных данных. Поскольку связанные данные хранятся вместе в одной записи, доступ к ним осуществляется одновременно, что сводит к минимуму количество обращений к диску для выполнения соединения. Этот процесс можно распространить на большое количество логических таблиц, поскольку ESE может поддерживать до 64 993 столбцов с тегами. Поскольку индексы могут быть определены для многозначных столбцов, индексировать «внутренние» таблицы все равно можно. Однако существуют некоторые ограничения, и приложениям следует тщательно рассмотреть возможность предварительного присоединения, прежде чем использовать этот метод.

Ведение журнала и восстановление после сбоя

Функция ведения журнала и восстановления ESE обеспечивает гарантированную целостность и согласованность данных в случае сбоя системы. Ведение журнала — это процесс избыточной записи операций обновления базы данных в файл журнала. Структура файла журнала очень устойчива к сбоям системы. Восстановление — это процесс использования этого журнала для восстановления баз данных до согласованного состояния после сбоя системы.

Операции транзакций протоколируются, и журнал сбрасывается на диск во время каждой фиксации на уровне транзакции 0. Это позволяет процессу восстановления повторять обновления, сделанные транзакциями, которые фиксируют транзакцию уровня 0, и отменять изменения, сделанные транзакциями, которые не фиксировались на уровне транзакции. 0. Этот тип схемы восстановления часто называют схемой восстановления с «накатом вперед/назад». Журналы можно хранить до тех пор, пока данные не будут безопасно скопированы с помощью процесса резервного копирования, описанного ниже, или журналы можно повторно использовать циклическим образом, как только они больше не нужны для восстановления после сбоя системы. Циклическое ведение журнала минимизирует объем дискового пространства, необходимого для журнала, но влияет на возможность воссоздания состояния данных в случае сбоя носителя.

Резервное копирование и восстановление

Ведение журнала и восстановление также играют роль в защите данных от сбоя носителя. ESE поддерживает резервное копирование в режиме онлайн, при котором копируются одна или несколько баз данных вместе с файлами журналов таким образом, что это не влияет на операции базы данных. Базы данных могут продолжать запрашиваться и обновляться во время резервного копирования. Резервная копия называется «нечеткой резервной копией», поскольку процесс восстановления должен выполняться как часть восстановления из резервной копии для восстановления согласованного набора баз данных. Поддерживаются как потоковая передача, так и резервное копирование теневого копирования.

Потоковое резервное копирование — это метод резервного копирования, при котором в процессе резервного копирования создаются копии всех нужных файлов базы данных и необходимых файлов журналов. Копии файлов можно сохранять непосредственно на ленту или на любое другое устройство хранения. При потоковом резервном копировании не требуется никакого приостановки активности. Файлы базы данных и журналов суммируются, чтобы гарантировать отсутствие повреждений данных в наборе данных во время процесса резервного копирования. Потоковые резервные копии также могут быть инкрементальными. Инкрементальные резервные копии — это те, в которых копируются только файлы журналов и которые можно восстановить вместе с предыдущей полной резервной копией, чтобы привести все базы данных в последнее состояние.

Теневое копирование — это новый высокоскоростной метод резервного копирования. Резервное копирование теневого копирования происходит значительно быстрее, поскольку копия виртуально создается после короткого периода приостановки работы приложения. По мере последующих обновлений данных виртуальная копия материализуется. В некоторых случаях аппаратная поддержка резервных копий теневого копирования означает, что фактическое сохранение виртуальных копий не требуется. Резервные копии теневого копирования всегда являются полными резервными копиями.

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

Резервное копирование и восстановление на другое оборудование

При создании базы данных ESENT размер сектора физического диска сохраняется вместе с базой данных. Ожидается, что размер физического сектора будет оставаться постоянным между сеансами; в противном случае сообщается об ошибке. Когда физический диск клонируется или восстанавливается из образа диска на диск, который использует другой размер физического сектора ( диски расширенного формата ), ESENT сообщит об ошибках.

Это известная проблема, и у Microsoft есть готовые исправления. Для Windows Vista или Windows Server 2008 см. KB2470478. Для Windows 7 или Windows Server 2008 R2 см. KB982018.

История

JET Blue изначально был разработан Microsoft как перспективное обновление ядра базы данных JET Red в Microsoft Access , но никогда не использовался в этой роли. Вместо этого он стал использоваться Exchange Server, Active Directory, службой репликации файлов (FRS), редактором конфигурации безопасности, службами сертификации, службой имен Интернета Windows (WINS) и множеством других служб Microsoft, приложений и компонентов Windows. В течение многих лет это был частный API, используемый только Microsoft, но с тех пор он стал опубликованным API, который может использовать каждый.

Работа над механизмом доступа к данным (DAE) началась в марте 1989 года, когда Аллен Рейтер присоединился к Microsoft. В течение следующего года команда из четырех разработчиков работала под руководством Аллена, чтобы в значительной степени завершить работу над ISAM. Microsoft уже имела BC7 ISAM (JET Red), но начала работу над механизмом доступа к данным (DAE) для создания более надежного ядра базы данных как входа в новую тогда область клиент-серверной архитектуры. Весной 1990 года команды BC7 ISAM и DAE объединились и образовали компанию Joint Engine Technology (JET); отвечает за создание двух двигателей: v1 ( JET Red ) и v2 (JET Blue), которые будут соответствовать одной и той же спецификации API (JET API). DAE стал JET Blue в честь цвета флага Израиля. BC7 ISAM стал JET Red в честь цвета флага России. Хотя JET Blue и JET Red были написаны по одной и той же спецификации API, они вообще не использовали общий код ISAM. Оба они поддерживали общий процессор запросов QJET, который позже вместе с BC7 ISAM стал синонимом JET Red.

JET Blue впервые появился в 1994 году как ISAM для WINS, DHCP и ныне несуществующих служб RPL в Windows NT 3.5. В 1996 году он снова появился в качестве механизма хранения данных для Microsoft Exchange. Дополнительные службы Windows выбрали JET Blue в качестве своей технологии хранения, и к 2000 году каждая версия Windows начала поставляться с JET Blue. JET Blue использовался Active Directory и стал частью специального набора кода Windows, называемого Trusted Computing Base (TCB). Число приложений Microsoft, использующих JET Blue, продолжает расти, и в 2005 году был опубликован API JET Blue, призванный облегчить использование постоянно растущего числа приложений и служб как внутри Windows, так и за ее пределами.

Запись в веб-блоге Microsoft Exchange заявил, что среди разработчиков, внесших свой вклад в JET Blue, Чин Ляо, Стивен Хехт, Мэтью Беллью, Ян Хосе, Эдвард «Эдди» Гилберт, Кеннет Кин Лам, Баласубраманиан Шрирам, Джонатан Лием, Эндрю Гудселл, Лорион Берчалл, Андрей Маринеску, Адам Фоксман, Иван Триндев, Спенсер Лоу и Бретт Ширли.

В январе 2021 года Microsoft открыла исходный код ESE. Он был размещен на GitHub с разрешительной лицензией MIT .

Сравнение с JET Red

существуют огромные различия Хотя они имеют общее происхождение, между JET Red и ESE .

• JET Red — это технология обмена файлами, тогда как ESE предназначен для внедрения в серверное приложение и не обеспечивает совместного использования файлов.
• JET Red делает все возможное для восстановления файлов, а ESE имеет упреждающую запись в журнал и изоляцию снимков для гарантированного восстановления после сбоя.
• JET Red до версии 4.0 поддерживает только блокировку на уровне страницы, тогда как ESE и JET Red версии 4.0 поддерживают блокировку на уровне записи.
• JET Red поддерживает широкий спектр интерфейсов запросов, включая ODBC и OLE DB . ESE не поставляется с механизмом запросов, а вместо этого полагается на то, что приложения пишут свои собственные запросы в виде кода C ISAM.
• JET Red имеет максимальный размер файла базы данных 2 ГиБ , а ESE имеет максимальный размер файла базы данных 8 ТиБ со страницами по 4 КиБ и 16 ТиБ со страницами по 8 КиБ.

Ссылки

• «Биржевая терминология» . Архивировано из оригинала 9 ноября 2008 г. Проверено 20 августа 2015 г.
• «Понимание основ информационного хранилища» . Архивировано из оригинала 9 июня 2007 года . Проверено 18 июня 2007 г.

Внешние ссылки

• Официальный сайт
• Расширяемый механизм хранения данных на GitHub
• Расширяемый механизм хранения — CodeProject