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

  • Статья

Применимо к:База данных 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.

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

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

Используя OLTP в памяти, кворум бизнес-решения смогли удвоить рабочую нагрузку при улучшении единиц DTU на 70 %. Дополнительные сведения см. в База данных SQL Azure в памяти OLTP.

Примечание.

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

Существует программный способ понять, поддерживает ли данная база данных в памяти 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 не обязательно должны помещаться в памяти. Поэтому для размера индексов применяется только одно ограничение — на максимальный общий размер базы данных. См. подробнее о моделях приобретения на основе единиц DTU и виртуальных ядер.

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

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

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

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

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

Если у вас есть кластеризованный индекс columnstore, после понижения вся таблица станет недоступной. Удалите все кластеризованные индексы columnstore (и замените кластеризованными индексами rowstore) перед понижением уровня базы данных до неподдерживаемого уровня или уровня.

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