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

Оптимизация производительности с помощью технологий обработки в памяти в управляемых экземплярах SQL в Azure

  • Статья

Область применения: Управляемый экземпляр SQL Azure

Технологии в памяти позволяют повысить производительность приложения и снизить затраты на управляемый экземпляр SQL. OLTP в памяти доступен на уровне службы Критически важные бизнес-процессы в Управляемом экземпляре Azure SQL.

Когда следует использовать технологии в памяти

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

  • Транзакционная (онлайн-обработка транзакций(OLTP)), где большинство запросов считывают или обновляют меньший набор данных, например операции создания, чтения и обновления и удаления (CRUD).
  • Аналитика (интерактивная аналитическая обработка (OLAP)), где большинство запросов имеют сложные вычисления для создания отчетов, а также регулярно запланированные процессы, выполняющие операции загрузки (или массовая загрузка) и /или записи изменений данных в существующие таблицы. Часто рабочие нагрузки OLAP периодически обновляются из рабочих нагрузок OLTP.
  • Смешанные (гибридная транзакционная и аналитическая обработка, HTAP), где запросы OLTP и OLAP выполняются в одном наборе данных.

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

Обзор

Управляемый экземпляр SQL Azure поддерживает следующие технологии в памяти:

  • OLTP в памяти увеличивает количество транзакций в секунду и снижает задержку при обработке транзакций. Сценарии, которые пользуются преимуществами OLTP в памяти: обработка транзакций с высокой пропускной способностью, например торговля и игры, прием данных от событий или устройств Интернета вещей, кэширование, загрузка данных и временные сценарии таблиц и переменных таблиц.
  • Кластеризованные индексы columnstore снижают требования к вместимости хранилища (иногда до 10 раз) и повышают производительность запросов для отчетов и аналитики. Вы можете использовать его с таблицами фактов в ваших витринах данных, чтобы разместить больше данных в вашей базе данных и улучшить производительность. Вы также можете использовать её с историческими данными в рабочей базе данных, чтобы архивировать и иметь возможность запрашивать в 10 раз больше данных.
  • Некластеризованные columnstore индексы для гибридной транзакционно-аналитической обработки позволяют вам получать информацию о вашем бизнесе в режиме реального времени, запрашивая данные напрямую из операционной базы данных без необходимости затратных процессов извлечения, преобразования и загрузки (ETL) и ожидания, пока данные будут занесены в хранилище. Некластеризованные индексы columnstore позволяют быстро выполнять аналитические запросы к базе данных OLTP, практически не оказывая влияния на рабочую нагрузку.
  • Использование оптимизированных для памяти индексов columnstore для HTAP позволит ускорить для одного набора данных одновременно и обработку транзакций, и выполнение аналитических запросов.

Индексы Columnstore и OLTP в памяти были представлены в SQL Server в 2012 и 2014 годах соответственно. База данных SQL Azure, управляемый экземпляр SQL Azure и SQL Server используют одну и ту же реализацию технологий в памяти.

Примечание.

Подробное пошаговое руководство по демонстрации преимуществ производительности технологии OLTP в памяти с использованием AdventureWorksLT примера базы данных и ostress.exe смотрите в разделе Пример использования технологии в памяти в Управляемом экземпляре SQL Azure.

Преимущества технологии в памяти

Благодаря более эффективной обработке запросов и транзакций технологии обработки в оперативной памяти также помогут снизить затраты. Попав в уровень Business Critical в SQL Managed Instance в Azure, обычно нет необходимости обновлять управляемый экземпляр SQL, чтобы достичь прироста производительности. В некоторых случаях технологии обработки в оперативной памяти предусматривают даже переход на более низкую ценовую категорию без снижения производительности.

В этой статье описываются аспекты In-Memory OLTP и columnstore индексов, относящиеся к Управляемому экземпляру SQL Azure, а также примеры:

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

Дополнительные сведения о OLTP в памяти в SQL Server см. в следующем разделе:

OLTP в памяти

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

  • Формат memory-optimized rowstore, где каждая строка является отдельным объектом в памяти. Это классический формат OLTP в памяти, оптимизированный для высокопроизводительных рабочих нагрузок OLTP. Существует два типа таблиц с оптимизацией для работы в памяти, которые можно использовать в формате оптимизированного для памяти хранилища строк.

    • Устойчивые таблицы (SCHEMA_AND_DATA), где строки, помещенные в память, сохраняются после перезапуска сервера. Этот тип таблицы ведет себя как стандартная таблица rowstore, но дает дополнительные преимущества оптимизации в памяти.
    • Неуверенные таблицы (SCHEMA_ONLY), в которых строки не сохраняются после перезапуска. Этот тип таблицы предназначен для временных данных (например, замены временных таблиц) или таблиц, когда необходимо быстро загрузить данные, прежде чем переместить их в сохраненную таблицу (так называемые промежуточные таблицы).

  • Формат columnstore с оптимизацией памяти, где данные организованы в виде столбцов. Эта структура предназначена для сценариев HTAP, где необходимо выполнять аналитические запросы над той же структурой данных, где выполняется рабочая нагрузка OLTP.

Примечание.

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

Размер данных и ограничение хранилища для OLTP в памяти

В памяти OLTP содержатся оптимизированные для памяти таблицы, которые используются для хранения пользовательских данных. Эти таблицы должны умещаться в памяти. Эта идея называется хранилищем OLTP в памяти.

Для бизнес-критичного уровня обслуживания предусмотрен определенный объем Max In-Memory OLTP memory, определяемый количеством vCores.

Следующие элементы учитываются в отношении лимита хранилища OLTP в памяти:

  • Активные строки пользовательских данных в оптимизированных для памяти таблицах и переменных таблиц. Старые версии строк не учитываются в отношении предела.
  • Индексы оптимизированных для памяти таблиц.
  • Операционные затраты на операции ALTER TABLE.

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

Дополнительные сведения о мониторинге использования хранилища OLTP в памяти и настройке оповещений при почти достижении ограничения см. в разделе "Мониторинг в памяти".

Изменение конфигурации оборудования или количества виртуальных ядер

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

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

Определение наличия объектов в памяти

Существует программный способ понять, поддерживает ли данная база данных в управляемом экземпляре SQL в памяти OLTP. Для этого выполните следующий запрос Transact-SQL:

SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');

Если запрос возвращает 1, в этой базе данных поддерживается технология OLTP в памяти.

Следующие запросы определяют все объекты с помощью технологии в памяти:

SELECT * FROM sys.tables WHERE is_memory_optimized=1
SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1

Колонковое хранилище в памяти

Технология columnstore в памяти позволяет хранить и запрашивать большой объем данных в таблицах. Она использует формат хранения по столбцам данных и пакетную обработку запросов, позволяя до 10 раз увеличить производительность запросов в рабочих нагрузках OLAP относительно традиционного хранилища, основанного на строках. Также, можно добиться 10-кратного сжатия данных относительно несжатых данных.

Существует два типа моделей columnstore, которые можно использовать для организации данных.

  • Кластеризованная columnstore, где все данные в таблице организованы в колонном формате. В этой модели все строки в таблице помещаются в табличном формате, который существенно сжимает данные и допускает выполнение аналитических запросов и отчетов в таблице. В зависимости от характера данных снижение объема может составлять от 10x до 100x. Модель кластеризованного columnstore также обеспечивает быстрое прием больших объемов данных (массовая загрузка), так как большие пакеты данных, превышающие 100 000 строк, сжимаются перед их хранением на диске. Эта модель хорошо подходит для сценариев данных классического хранилища.
  • Хранилище columnstore без кластеризации, где данные хранятся в стандартной таблице rowstore, а также есть индекс в формате columnstore, который используется для аналитических запросов. Эта модель допускает гибридную транзакционную аналитическую обработку (HTAP): возможность запускать аналитику в реальном времени с высокой производительностью на транзакционной рабочей нагрузке. Запросы OLTP выполняются в таблице rowstore, которая оптимизирована для доступа к небольшому числу строк, тогда как запросы OLAP выполняются в индексе columnstore, который лучше подходит для сканирования и анализа. Оптимизатор запросов динамически выбирает формат rowstore или columnstore на основе запроса. Некластеризованные индексы columnstore не снижают размер данных, так как исходный набор данных хранится в исходной таблице rowstore без каких-либо изменений. Тем не менее размер дополнительного индекса колонночного хранилища будет на порядок меньше, чем эквивалентный индекс B-дерева.

Примечание.

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

Размер данных и объем хранилища для индексов columnstore

Индексы сolumnstore не обязательно должны помещаться в памяти. Таким образом, единственным ограничением размера индексов является максимальный общий размер базы данных. Дополнительные сведения см. в разделе Ограничения ресурсов Управляемого экземпляра Azure SQL. Управляемый экземпляр SQL Azure поддерживает индексы columnstore во всех уровнях.

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

Например, если для базы данных установлен максимальный размер 1 терабайт (ТБ), а с помощью технологии columnstore удастся добиться 10-кратного сжатия, вы сможете хранить в этой базе данных 10 ТБ пользовательских данных.

При использовании некластеризованных индексов columnstore базовая таблица по-прежнему хранится в традиционном формате rowstore, поэтому экономия места в хранилище будет не столь значительной, как с применением кластеризованных индексов сolumnstore. Однако если вы заменяете множество традиционных некластеризованных индексов одним индексом columnstore, вы по-прежнему можете увидеть общую экономию в объеме хранилища для таблицы.

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