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

  • Статья

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

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

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

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

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

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

Обзор

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

Следующие элементы учитываются в соответствии с ограничением хранилища 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 в памяти

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

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

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

Примечание.

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

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

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

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

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

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

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