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

Применимо к:Управляемому экземпляру Базы данныхSQL Azure SQL Azure

Технологии в памяти позволяют повысить производительность приложения и, возможно, снизить затраты на базу данных.

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

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

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

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

Обзор

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

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

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

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

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

Используя выполняющуюся в памяти OLTP, компания Quorum Business Solutions смогла вдвое увеличить свои рабочие нагрузки, при этом улучшив показатели DTU на 70 %. Дополнительные сведения см. в этой записи блога: Выполняющаяся в памяти OLTP.

Примечание.

Технологии в памяти доступны на уровнях "Премиум" и "критически важный для бизнеса".

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

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

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

Выполняющаяся в памяти OLTP

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

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

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

Примечание.

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

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

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

Если запрос возвращает 1, база данных поддерживает In-Memory 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

Ограничения на объем данных и емкость хранилища для In-Memory OLTP

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

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

При расчете емкости хранилища для выполняющейся в памяти OLTP используются следующие параметры.

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

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

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

О пулах эластичных баз данных

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

  • Установите для баз данных значение Max-eDTU или MaxvCore ниже, чем значение eDTU или число виртуальных ядер для пула в целом. Это новое ограничение eDTU на емкость хранилища выполняющейся в памяти OLTP будет действовать в отношении любой базы данных в пуле.
  • Установите для баз данных значение Min-eDTU или MinvCore больше нуля. Это минимальное значение гарантирует, что каждая база данных в пуле получит определенный объем хранилища для выполняющейся в памяти OLTP в соответствии с указанным значением Min-eDTU или vCore.

Изменение уровней служб баз данных, которые используют технологии OLTP в памяти

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

Учтите, что понижение уровня может отрицательно повлиять на базу данных. Такое влияние при переходе от критически важного для бизнеса уровня до уровня общего назначения (или с класса "Премиум" на "Стандартный" или "Базовый") будет особенно заметно, если база данных содержит объекты выполняющейся в памяти OLTP. После понижения ценовой категории или уровня оптимизированные для памяти таблицы станут недоступными (даже если останутся видимыми). Эти замечания относятся и к переходу на более низкую ценовую категорию для пула эластичных баз данных, а также к перемещению баз данных, использующих технологии обработки в оперативной памяти, в пул эластичных баз данных уровня "Стандартный" или "Базовый".

Важно!

OLTP в памяти не поддерживается базами данных класса "Стандартный" или "Базовый". Поэтому невозможно изменить уровень базы данных, содержащей любые объекты выполняющейся в памяти OLTP, на "Стандартный" или "Базовый".

Прежде чем понижать базу данных до уровней "Стандартный" или "Базовый", удалите все оптимизированные для памяти таблицы и типы таблиц, а также все модули T-SQL, скомпилированные в собственном коде.

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

Технология columnstore в памяти

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

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

Примечание.

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

Подробные видеоролики об этих технологиях

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

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

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

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

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

Изменение уровней служб базы данных, содержащей индексы columnstore

Понижение уровня отдельной базы данных до базового или стандартного может оказаться невозможным, если ваш целевой уровень ниже S3. Индексы columnstore поддерживаются только в ценовой категории "Премиум" и "Критически важный для бизнеса" или "Стандартный" (S3 и выше), но не в ценовой категории "Базовый". При переходе базы данных на неподдерживаемую ценовую категорию или уровень, индексы columnstore становятся недоступными. Система сохранит ваш индекс columnstore, но не будет его использовать. Если вы позднее перейдете на поддерживаемую ценовую категорию или уровень, индекс columnstore будет немедленно готов к использованию.

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

Примечание.

Управляемый экземпляр SQL поддерживает индексы Columstore на всех уровнях.

Дальнейшие действия

Дополнительные ресурсы

Подробные сведения

Проектирование приложений

Инструменты