Устойчивость для оптимизированных для памяти таблиц

Область применения:SQL Server

OlTP в памяти обеспечивает полную устойчивость для оптимизированных для памяти таблиц. Когда транзакция, изменяющая оптимизированную для памяти таблицу, завершается, SQL Server (как и для дисковых таблиц) гарантирует, что изменения останутся постоянными и переживут перезагрузку базы данных, если доступно соответствующее хранилище. Есть два ключевых компонента устойчивости таблицы: ведение журнала транзакций и сохранение изменений данных в хранилище на диске.

Дополнительные сведения об ограничениях размера для устойчивых таблиц см. в разделе "Оценка требований к памяти" для таблиц Memory-Optimized.

Журнал транзакций

Все изменения, внесенные в таблицы на диске или устойчивые таблицы, оптимизированные для памяти, заносятся в одну или несколько записей журнала транзакций. При фиксации транзакции SQL Server записывает записи журнала, связанные с транзакцией на диск перед обменом данными с приложением или сеансом пользователя, зафиксированным транзакцией. Это гарантирует, что изменения, внесенные транзакцией, будут устойчивы. Журнал транзакций для оптимизированных для памяти таблиц полностью интегрирован с тем же потоком журнала, который используется дисковыми таблицами. Эта интеграция позволяет существующим операциям резервного копирования, восстановления и восстановления журнала транзакций продолжать работать без дополнительных действий. Однако, поскольку In-Memory OLTP может значительно повысить пропускную способность транзакций вашей нагрузки, операции ввода-вывода журнала могут стать ограничивающим фактором производительности. Чтобы обеспечить повышение пропускной способности, подсистема ввода-вывода для журнала должна поддерживать увеличенную нагрузку.

Файлы данных и дельта-файлы

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

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

Транзакции пользователей не имеют непосредственного доступа к данным и разностным файлам. Все операции чтения и записи используют структуры данных в памяти.

Файл данных

Файл данных содержит строки из одной или нескольких оптимизированных для памяти таблиц, которые были вставлены несколькими транзакциями как часть операций INSERT или UPDATE. Например, одна строка может быть из оптимизированной для памяти таблицы T1, а следующая строка — из таблицы T2. Строки добавляются в файл данных в порядке транзакций в журнале транзакций и обеспечивают последовательный доступ к данным. Это на порядок увеличивает пропускную способность ввода-вывода по сравнению с операциями ввода-вывода с произвольным доступом.

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

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

Размер: каждый файл данных имеет размер примерно в 128 МБ для компьютеров с памятью больше 16 ГБ и 16 МБ для компьютеров с памятью, меньшей или равной 16 ГБ. В SQL Server 2016 (13.x) SQL Server может использовать режим больших контрольных точек, если он считает, что подсистема хранения достаточно быстра. В режиме больших контрольных точек файлы данных имеют размер 1 ГБ. Это позволяет повысить эффективность подсистемы хранения для рабочих нагрузок с высокой пропускной способностью.

Разностный файл

Каждый файл данных сопряжен с разностным файлом с таким же диапазоном транзакций и отслеживает удаленные строки, вставленные транзакциями в этом диапазоне. Эти файлы данных и разностных файлов называются парой файлов контрольной точки (CFP), и это единица выделения и освобождения ресурсов, а также единица операций слияния. Например, разностный файл, соответствующий диапазону транзакций (100, 200), хранит удаленные строки, которые были вставлены транзакциями в диапазоне (100, 200). Как и файлы данных, доступ к разностному файлу осуществляется последовательно.

При удалении строки строка не удаляется из файла данных, но ссылка на строку добавляется в разностный файл, связанный с диапазоном транзакций, где была вставлена эта строка данных. Поскольку удаляемая строка уже существует в файле данных, разностный файл только сохраняет информацию о ссылке {inserting_tx_id, row_id, deleting_tx_id} , следуя порядку в журнале транзакций с исходными операциями удаления или обновления.

Размер: каждый разностный файл имеет размер примерно в 16 МБ для компьютеров с памятью больше 16 ГБ и 1 МБ для компьютеров с памятью, меньшей или равной 16 ГБ. Запуск SQL Server 2016 (13.x) SQL Server может использовать режим больших контрольных точек, если он считает, что подсистема хранения достаточно быстра. В режиме больших контрольных точек разностные файлы имеют размер 128 МБ.

Заполнение файлов данных и дельта-файлов

Файлы данных и разностные файлы заполняются на основе записей журнала транзакций, которые выполнялись с оптимизированными для памяти таблицами. Сведения о вставленных и удаленных строках добавляются в соответствующий файл данных и разностный файл. В отличие от дисковых таблиц, для которых страницы данных и индексов заполняются случайным вводом и выводом при достижении контрольной точки, сохранение оптимизированной для памяти таблицы — это непрерывная фоновая операция. Выполняется обращение к нескольким разностным файлам, поскольку транзакция может удалить или обновить любую строку, вставленную предыдущей транзакцией. Сведения об удалении всегда добавляются в конец разностного файла. Например, транзакция с меткой времени фиксации 600 вставляет одну новую строку и удаляет строки, вставляемые транзакциями с меткой времени фиксации 150, 250 и 450, как показано на следующем рисунке. Все четыре операции ввода-вывода файла (три для удаленных строк и 1 для недавно вставленных строк) являются операциями только для добавления к соответствующим разностным файлам и файлам данных.

Доступ к данным и разностным файлам

Доступ к файлам данных и дельта-файлам может осуществляться при наступлении следующих событий.

Автономные контрольные точки

Этот поток добавляет вставленные и удаленные данные в строки данных, оптимизированные для памяти, и в соответствующие пары файлов данных и разностных файлов. SQL Server 2014 (12.x) имеет один рабочий процесс автономной контрольной точки. SQL Server 2016 (13.x) и более поздних версий имеют несколько рабочих точек.

Операция слияния

Эта операция объединяет один или несколько файлов данных и разностных файлов и создает новую пару файлов.

В процессе восстановления после сбоя

При перезапуске SQL Server или возврате базы данных в сети данные, оптимизированные для памяти, заполняются парами данных и разностных файлов. Разностный файл выступает в качестве фильтра для удаленных строк при чтении строк из соответствующего файла данных. Поскольку каждая пара файлов данных и разностных файлов не зависит друг от друга, эти файлы загружаются одновременно для уменьшения времени, затраченного для добавления данных в память. После загрузки данных в память, движок In-Memory OLTP применяет активные записи журнала транзакций, которые еще не охвачены файлами контрольных точек, чтобы данные, оптимизированные для памяти, были полными.

Во время операции восстановления

Файлы контрольных точек In-Memory OLTP создаются из резервной копии базы данных, а затем применяется одна или несколько резервных копий журналов транзакций. Как и при аварийном восстановлении, модуль OLTP In-Memory параллельно загружает данные в память, чтобы свести к минимуму влияние на время восстановления.

Объединение данных и разностных файлов

Данные для оптимизированных для памяти таблиц хранятся в одной паре файла данных и разностного файла или в нескольких парах (которые также называют парой файлов контрольных точек или CFP). Файлы данных хранят вставленные строки, а разностные файлы содержат ссылки на удаленные строки. Во время выполнения рабочей нагрузки OLTP, пока операции DML обновляют, вставляют и удаляют строки, формируются новые пары файлов для сохранения новых строк, а ссылки на удаленные строки вводятся в разностные файлы.

С течением времени при операциях DML количество данных и разностных файлов увеличивается, что приводит к увеличению использования дискового пространства и увеличению времени восстановления.

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

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

В следующем примере группа файлов таблицы с оптимизацией под память содержит четыре пары файлов данных и дельта с меткой времени 500, содержащих данные из предыдущих транзакций. Например, строки в первом файле данных соответствуют транзакциям с меткой времени больше 100 и меньше или равной 200. Это также можно записать в виде (100, 200]. Как видим, второй и третий файлы данных заполнены меньше чем на 50 % после учета более 50 % строк, отмеченных как удаленные. Операция слияния объединяет эти две пары файлов и создает новую пару, содержащую транзакции с меткой времени больше 200 и меньше или равной 400, т. е. объединенный диапазон двух пар файлов. Очевидно, что другая пара файлов с диапазоном (500, 600] и непустой разностный файл для диапазона транзакций (200, 400] показывают, что слияние может быть выполнено параллельно с транзакциями, включая удаление других строк из исходных пар файлов.

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

Политика слияния SQL Server

SQL Server реализует следующую политику слияния:

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

• Может производиться слияние одной пары файлов с самой собой, если размер файла данных в два раза превышает целевой размер и при этом удаляется более половины строк. Файл данных может увеличиться до целевого размера, если, например, одна транзакция или несколько параллельных транзакций вставляет или обновляет большой объем данных, заставляя файл данных увеличиваться за пределы целевого размера, так как транзакция не может охватывать несколько CFPs.

Ниже приведены некоторые примеры, которые демонстрируют объединяемые CFP’ы в рамках политики слияния.

Смежные файлы-исходники CFPs (полнота в %)	Объединить выделенное
CFP0 (30 %), CFP1 (50 %), CFP2 (50 %), CFP3 (90 %)	(CFP0, CFP1) CFP2 не выбран, так как он делает результирующий файл данных больше 100% идеального размера.
CFP0 (30 %), CFP1 (20 %), CFP2 (50 %), CFP3 (10 %)	(CFP0, CFP1, CFP2). Файлы выбираются, начиная слева. CFP3 не выбран, так как он делает результирующий файл данных больше 100% идеального размера.
CFP0 (80 %), CFP1 (30 %), CFP2 (10 %), CFP3 (40 %)	(CFP1, CFP2, CFP3). Файлы выбираются, начиная слева. CFP0 пропускается, так как в сочетании с CFP1 результирующий файл данных превышает 100% идеального размера.

Не все пары файлов со свободным пространством подходят для слияния. Например, если два смежных CFP заполнены на 60%, их нельзя объединять, и у каждого из этих CFP имеется 40% неиспользуемого хранилища. В худшем случае все CFP заполнены на 50%, что соответствует использованию хранилища всего на 50%. Хотя удаленные строки могут существовать в хранилище, так как CFPs не подходят для слияния, удаленные строки, возможно, уже были удалены из памяти сборкой мусора в оперативной памяти. Управление хранением и памятью происходит независимо от сборки мусора. хранилище, занимаемое активными ЦФП (не все ЦФП обновляются), может быть в два раза больше, чем размер устойчивых таблиц в памяти.

Жизненный цикл CFP

Пары файлов проходят несколько этапов, прежде чем они могут быть удалены из памяти. Для контрольных точек базы данных и резервных копий журналов файлы должны проходить через эти этапы, а ненужные файлы в конечном итоге должны удаляться. См. описание этих этапов в sys.dm_db_xtp_checkpoint_files.

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

Связанный контент

• Создание хранилища для оптимизированных для памяти объектов и управление ими