Поделиться через

Производительность темпоральной таблицы, оптимизированной для памяти

  • Статья

Область применения: SQL Server 2016 (13.x) и более поздних версий База данных SQL Azure Управляемый экземпляр SQL Azure

В этой статье рассматриваются некоторые конкретные аспекты производительности при использовании системных оптимизированных для памяти временных таблиц.

При добавлении системного управления версиями в существующую не временную таблицу ожидается влияние производительности на операции обновления и удаления, так как таблица журнала обновляется автоматически.

Замечания, связанные с быстродействием

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

  • Не выполняйте массовые удаления из текущей таблицы на одном шаге. Рассмотрите возможность удаления данных в нескольких пакетах, при этом вручную вызывается очистка данных между sp_xtp_flush_temporal_history или в то время SYSTEM_VERSIONING = OFF.

  • Не выполняйте массовые обновления таблиц одновременно, так как это может привести к потреблению памяти в два раза больше памяти, необходимой для обновления непорпоральной таблицы, оптимизированной для памяти. Это временное потребление памяти, так как задача очистки данных работает регулярно для поддержания потребления памяти внутренних промежуточных таблиц в проецируемых границах в устойчивом состоянии. Граница составляет 10 процентов потребления памяти текущей темпоральной таблицы. Рассмотрите возможность выполнения массовых обновлений в нескольких пакетах или в то время SYSTEM_VERSIONING = OFFкак использование обновлений для задания значений по умолчанию для недавно добавленных столбцов.

Период активации задачи очистки данных не настраивается, но вы можете вручную выполнить sp_xtp_flush_temporal_history по мере необходимости.

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

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