темпоральные таблицы с системным управлением версиями и таблицы с оптимизацией памятиSystem-Versioned Temporal Tables with Memory-Optimized Tables

Применимо к:Applies to: даSQL Server 2016 (13.x);SQL Server 2016 (13.x)yesSQL Server 2016 (13.x);SQL Server 2016 (13.x) и более поздние версии ДаБаза данных SQL AzureAzure SQL DatabaseYesБаза данных SQL AzureAzure SQL Database ДаУправляемый экземпляр SQL AzureAzure SQL Managed InstanceYesУправляемый экземпляр SQL AzureAzure SQL Managed InstanceПрименимо к:Applies to: даSQL Server 2016 (13.x);SQL Server 2016 (13.x)yesSQL Server 2016 (13.x);SQL Server 2016 (13.x) and later ДаБаза данных SQL AzureAzure SQL DatabaseYesБаза данных SQL AzureAzure SQL Database ДаУправляемый экземпляр SQL AzureAzure SQL Managed InstanceYesУправляемый экземпляр SQL AzureAzure SQL Managed Instance

Темпоральные таблицы с системным управлением версиями для таблиц, оптимизированных для памяти — это экономичное решение для сценариев, в которых требуется аудит и анализ на момент времени данных для данных, собранных из рабочих нагрузок In-Memory OLTP.System-versioned temporal tables for Memory-Optimized Tables are designed to provide cost-effective solution for scenarios where data audit and point in time analysis are required on top of data collected with In-Memory OLTP workloads. Они обеспечивают высокую скорость обработки транзакций, параллелизм без блокировки и в то же время возможность хранения большого объема данных журнала, которые легко можно запросить.They provide high transactional throughput, lock-free concurrency and at the same time, ability to store large amount of history data that can be easily queried.

ОбзорOverview

Темпоральные таблицы с системным управлением версиями автоматически сохраняют полный журнал изменений данных и предоставляют удобные расширения Transact-SQL для анализа на момент времени.System-versioned temporal tables automatically keep a full history of data changes and expose convenient Transact-SQL extensions for point in time analysis. В типичном сценарии журнал данных хранится в течение длительного времени (несколько месяцев и даже лет) несмотря на то, что они не запрашиваются регулярно.In a typical scenario, data history is retained for a very long period of time (multiple months, even years), even though it is not regularly queried.

Аудит и анализ данных на основе времени можно запросить в различных средах, особенно в системах OLTP, которые обрабатывают очень много запросов и используют технологию In-Memory OLTP.Data audit and time-based analysis can be demanded in different environments, especially in OLTP systems that process extremely large numbers of requests and where In-Memory OLTP technology is used. Однако использование таблиц, оптимизированных для памяти, в темпоральных сценариях весьма сложно, поскольку огромный объем созданных данных журнала обычно превышает доступный объем ОЗУ.However, using memory-optimized tables in temporal scenarios is challenging because a huge amount of generated historical data commonly exceeds the limit of available RAM memory. В то же время неоптимально использовать ОЗУ для хранения журнала данных только для чтения, доступ к которым осуществляется все реже по мере их старения.At the same time using RAM to store read-only historical data that is accessed less frequently as it becomes older is not an optimal solution.

Темпоральные таблицы с системным управлением версиями для таблиц, оптимизированных для памяти, обеспечивают высокую скорость обработки транзакций, параллелизм без блокировки и в то же время позволяют хранить большой объем данных журнала с помощью таблиц в памяти для хранения текущих данных (темпоральная таблица) и таблиц на диске — для данных журнала.System-versioned temporal tables for memory-optimized tables provide high transactional throughput, lock-free concurrency and at the same time, ability to store large amount of history data by using in-memory tables for storing current data (the temporal table) and disk-based tables for historical data. Влияние на операции DML сводится к минимуму за счет использования внутренней, автоматически созданной промежуточной таблицы, оптимизированной для памяти, в которой хранится журнал последних действий и которая позволяет выполнять DML из собственного кода.The impact on DML operations is minimalized through the use of an internal, auto-generated memory-optimized staging table that stores recent history and enables DMLs to be executed from natively compiled code.

Следующая диаграмма иллюстрирует такую архитектуру. Темпоральная архитектура в памятиThe following diagram illustrates this architecture.Temporal In-Memory Architecture

Сведения о реализацииImplementation Details

Следующие факты о темпоральных таблицах с системным управлением версиями и оптимизированными для памяти таблицами необходимо учитывать при создании таблицы с системным управлением версиями, оптимизированной для операций в памяти.The following facts about system-versioned temporal tables with memory optimized tables are considerations of which you need to be aware when creating a system-versioned memory-optimized table. Параметры синтаксиса и примеры см. в разделе CREATE TABLE (Transact-SQL).For syntax options and for an example, see CREATE TABLE (Transact-SQL).

  • Только долговечные, оптимизированные для памяти таблицы могут поддерживать системное управление версиями (DURABILITY = SCHEMA_AND_DATA).Only durable memory-optimized tables can be system-versioned (DURABILITY = SCHEMA_AND_DATA).
  • Таблица журнала для оптимизированной для памяти таблицы с системным управлением версиями должна размещаться на диске независимо от того, была ли она создана конечным пользователем или системой.History table for memory-optimized system-versioned table must be disk-based, regardless if it was created by the end user or the system.
  • Запросы, относящиеся только к текущей таблице (в памяти), можно использовать в модулях, скомпилированных в T-SQL.Queries that affect only the current table (in-memory) can be used in natively compiled T-SQL modules. Темпоральные запросы, использующие предложение FOR SYSTEM TIME, не поддерживаются в модулях, скомпилированных в собственном коде.Temporal queries using the FOR SYSTEM TIME clause are not supported in natively compiled modules. Использование предложения FOR SYSTEM TIME поддерживается с оптимизированными для памяти таблицами в нерегламентированных запросах и в модулях с несобственным кодом.Use of the FOR SYSTEM TIME clause with memory-optimized tables in ad hoc queries and non-native modules is supported.
  • Если SYSTEM_VERSIONING = ON, внутренняя промежуточная таблица, оптимизированная для памяти, создается автоматически для принятия последних изменений с системным управлением версиями, которые являются результатами операций обновления и удаления в текущей таблице, оптимизированной для памяти.When SYSTEM_VERSIONING = ON, an internal memory-optimized staging table is automatically created to accept the most recent system-versioned changes that are results of update and delete operations on memory-optimized current table.
  • Данные из этой внутренней промежуточной таблицы регулярно перемещаются в таблицу журнала на диске асинхронной задачей сброса данных.Data from the internal memory-optimized staging table is regularly moved to the disk-based history table by the asynchronous data flush task. Цель этого механизма — сохранить размер внутренних буферов памяти на уровне менее 10 % от потребляемой памяти родительских объектов.This data flush mechanism has a goal to keep the internal memory buffers at less than 10% of the memory consumption of their parent objects. Вы можете отслеживать общее потребление памяти темпоральной таблицей, оптимизированной для памяти, с системным управлением версиями, запрашивая sys.dm_db_xtp_memory_consumers (Transact-SQL) и получая сводные данные для внутренней промежуточной таблицы, оптимизированной для памяти, и текущей темпоральной таблицы.You can track the total memory consumption of memory-optimized system-versioned temporal table by querying sys.dm_db_xtp_memory_consumers (Transact-SQL) and summarizing the data for the internal memory-optimized staging table and the current temporal table.
  • Вы можете принудительно выполнить сброс данных, вызвав sp_xtp_flush_temporal_history.You can enforce a data flush by invoking sp_xtp_flush_temporal_history.
  • Если SYSTEM_VERSIONING = OFF или схема таблицы с системным управлением версиями изменяется (столбцы добавляются, удаляются или изменяются), все содержимое промежуточного внутреннего буфера перемещается в таблицу журнала на диске.When SYSTEM_VERSIONING = OFF or when schema of system-versioned table is modified by adding, dropping or altering columns, the entire contents of the internal staging buffer is moved into the disk-based history table.
  • Запрос данных журнала выполняется на уровне изоляции моментального снимка и всегда возвращает объединение промежуточного буфера в памяти и дисковой таблицы без дубликатов.Querying of historical data is effectively under SNAPSHOT isolation level and always returns a union between in-memory staging buffer and disk-based table without duplicates.
  • ОперацииALTER TABLE , которые изменяют схему таблицы внутренне, должны выполнить сброс данных, что может увеличить время выполнения операции.ALTER TABLE operations that change the table schema internally must perform a data flush, which may prolong the duration of the operation.

Внутренняя промежуточная таблица, оптимизированная для памятиThe Internal Memory-Optimized Staging Table

Внутренняя промежуточная таблица, оптимизированная для памяти, — это внутренний объект, созданный системой для оптимизации операций DML.The internal memory-optimized staging table is an internal object that is created by the system to optimize DML operations.

  • Имя таблицы создается в следующем формате: Memory_Optimized_History_Table_<ИД_объекта> , где <ИД_объекта>  — это идентификатор текущей темпоральной таблицы.The table name is generated in the following format: Memory_Optimized_History_Table_<object_id> where <object_id> is identifier of the current temporal table.
  • Таблица реплицирует схему текущей темпоральной таблицы, а также один столбец типа BIGINT.The table replicates the schema of current temporal table plus one BIGINT column. Этот дополнительный столбец гарантирует уникальность строк, перемещаемых во внутренний буфер.This additional column guarantees the uniqueness of the rows moved to internal history buffer.
  • Для имени дополнительного столбца используется следующий формат: Change_ID[_<суффикс>] , где _<suffix> добавляется в том случае, если в таблице уже есть столбец Change_ID.The additional column has the following name format: Change_ID[_< suffix>], where _<suffix> is optionally added in the case where the table already has a Change_ID column.
  • Максимальный размер строки таблицы с системным управлением версиями, оптимизированной для памяти, уменьшается на восемь байт из-за дополнительного столбца BIGINT в промежуточной таблице.The maximum row size for a system-versioned memory-optimized table is reduced by 8 bytes because of the additional BIGINT column in staging table. Новое максимальное значение — 8052 байт.The new maximum is now 8052 bytes.
  • Внутренняя промежуточная таблица, оптимизированная для памяти, не представлена в обозревателе объектов SQL Server Management Studio.The internal memory-optimized staging table is not represented in Object Explorer of SQL Server Management Studio.
  • Метаданные этой таблицы, а также ее связь с текущей темпоральной таблицей можно найти в sys.internal_tables (Transact-SQL).Metadata about this table as well as its connection with current temporal table can be found in sys.internal_tables (Transact-SQL).

Задачи сброса данныхThe Data Flush Task

Сброс данных — это регулярно выполняемая задача, которая проверяет, соответствует ли оптимизированная для памяти таблица условиям по размеру для перемещения данных.The data flush is a regularly activated task that checks whether any memory-optimized table meets a memory size-based condition for data movement. Перемещение данных начинается, когда потребление памяти внутренней промежуточной таблицы достигнет 8 % от потребления памяти текущей темпоральной таблицы.Data movement starts when memory consumption of internal staging table reaches 8% of memory consumption of current temporal table.

Задача сброса данных активируется регулярно по расписанию, которое меняется в зависимости от текущей рабочей нагрузки.The data flush task is activated regularly with a schedule that varies based on the existing workload. При высокой нагрузке она может выполняться каждые пять секунд, а при небольшой нагрузке — каждую минуту.With a heavy workload, as frequent as every 5 seconds, and with a light workload, as infrequent as every 1 minute. Для каждой внутренней промежуточной таблицы, оптимизированной для памяти, требующей сброса, создается один поток.One thread is spawned for each internal memory-optimized staging table that needs cleanup.

При сбросе данных удаляются все записи из внутреннего буфера в памяти, которые старше самой старой выполняемой в текущий момент транзакции, чтобы переместить эти записи в таблицу журнала на диске.Data flush deletes all records from in-memory internal buffer that are older than the oldest currently running transaction to move these records to the disk-based history table.

Можно принудительно выполнить сброс данных, вызвав sp_xtp_flush_temporal_history и указав схему и имя таблицы: **sys.sp_xtp_flush_temporal_history @schema_name, @object_name** .You can enforce a data flush by invoking sp_xtp_flush_temporal_history and specifying the schema and table name: **sys.sp_xtp_flush_temporal_history @schema_name, @object_name**. При выполнении этой команды пользователем происходит тот же процесс перемещения данных, что и при вызове сброса данных по внутреннему расписанию системы.With this user-executed command, the same data movement process is invoked as when data flush task is invoked by the system on internal schedule.

См. также:See Also