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

Оптимизация производительности с помощью технологий в памяти в База данных 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, компания Quorum Business Solutions смогла вдвое увеличить свои рабочие нагрузки, при этом улучшив показатели DTU на 70 %. Дополнительные сведения см. в разделе OLTP в памяти в База данных SQL Azure.

Примечание.

OLTP в памяти доступен на уровнях служб "Премиум" (DTU) и критически важный для бизнеса (vCore) База данных SQL Azure. Уровень служб Гипермасштабирования поддерживает подмножество объектов OLTP в памяти. Дополнительные сведения см. в разделе об ограничениях гипермасштабирования.

Индексы Columnstore доступны во всех уровнях служб, кроме уровня "Базовый", и уровня "Стандартный", если цель службы ниже S3. Дополнительные сведения см. в разделе "Изменение уровней служб" баз данных, содержащих индексы columnstore.

В этой статье описываются аспекты индексов 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 в памяти.

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

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

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

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

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

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

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

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

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

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

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

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

При масштабировании критически важный для бизнеса или базы данных класса Premium данные в оптимизированных для памяти таблицах должны соответствовать хранилищу OLTP в памяти, доступном в целевой цели службы базы данных или эластичного пула. Если вы пытаетесь уменьшить масштаб базы данных или эластичного пула или переместить базу данных в эластичном пуле, а цель целевой службы не имеет достаточно доступного хранилища 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 строк, сжимаются до их хранения на диске. Этот тип индекса является хорошим выбором для классических сценариев хранилища данных.
  • Некластичное хранилище столбцов , в котором данные хранятся в традиционной таблице rowstore, и есть дополнительный индекс в формате columnstore, который используется для аналитических запросов. Этот тип индекса позволяет гибридной обработке транзакций и аналитики (HTAP): возможность быстро выполнять аналитику в режиме реального времени в рабочей нагрузке транзакций. Запросы OLTP выполняются в таблице rowstore, которая оптимизирована для доступа к небольшому числу строк, тогда как запросы OLAP выполняются в индексе columnstore, который лучше подходит для сканирования и анализа. Оптимизатор запросов динамически выбирает формат rowstore или columnstore на основе запроса. Некластеризованные индексы columnstore не снижают размер данных, так как исходный набор данных хранится в исходной таблице rowstore без каких-либо изменений. Однако размер дополнительного индекса columnstore меньше, чем эквивалентный индекс B-дерева.

Примечание.

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

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

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

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

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

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

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

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

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

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