Повышение производительности пропускной способности в Базе данных SQL Azure из Azure Stream Analytics

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

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

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

Azure Stream Analytics

  • Наследование секционирования — этот параметр конфигурации выходных данных SQL позволяет наследовать схему секционирования предыдущего шага запроса или входных данных. Включив это, вы можете ожидать улучшения пропускной способности при записи в таблицу на основе диска и наличии полной параллельной топологии для вашего задания. Эта секционирование уже выполняется автоматически для многих других выходных данных. Блокировка таблицы (TABLOCK) также отключена для массовых вставок, сделанных с помощью этого параметра.

    Замечание

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

  • Размер пакета — конфигурация вывода SQL позволяет указать максимальный размер пакета в выходных данных SQL Azure Stream Analytics на основе характера целевой таблицы или рабочей нагрузки. Размер пакета — это максимальное количество записей, которые отправляются с каждой транзакцией массовой вставки. В кластеризованных индексах columnstore размер пакета около 100K позволяет повысить параллелизацию, минимальное ведение журнала и оптимизацию блокировки. В таблицах на основе дисков 10K (по умолчанию) или ниже может быть оптимальным для вашего решения, так как более высокие размеры пакетов могут активировать эскалацию блокировки во время массовой вставки.

  • Настройка входных сообщений — если вы оптимизировали, используя наследуемое секционирование и размер пакета, увеличение количества входных событий на сообщение в раздел помогает еще больше повысить пропускную способность записи. Настройка входных сообщений позволяет увеличить размер пакета в Azure Stream Analytics до указанного размера пакета, тем самым повышая пропускную способность. Это можно сделать с помощью сжатия или увеличения размера входных сообщений в EventHub или BLOB-объекте.

SQL Azure

  • Секционированные таблицы и индексы . Использование секционированных таблиц SQL и секционированных индексов в таблице с тем же столбцом, что и ключ секции (например, PartitionId), может значительно сократить количество конфликтов между секциями во время записи. Для секционируемой таблицы необходимо создать функцию секционирования и схему секционирования в файловой группе PRIMARY. Это также увеличит доступность существующих данных во время загрузки новых данных. Ограничение операций ввода-вывода журнала может быть исчерпано в зависимости от количества разделов, которые можно увеличить, обновив SKU.

  • Избегайте нарушений уникальных ключей. Если в журнале действий Azure Stream Analytics возникает несколько предупреждений о нарушении уникальных ключей, убедитесь, что задание не подвергается нарушениям уникальных ограничений, которые могут происходить во время восстановления. Это можно избежать, задав параметр IGNORE_DUP_KEY для индексов.

Фабрика данных Azure и таблицы In-Memory

  • Таблица In-Memory как временная таблица — In-Memory таблицы позволяют выполнять очень быстрые загрузки данных, но данные должны умещаться в памяти. Тесты показывают, что массовая загрузка из оперативной памяти в таблицу, расположенную на диске, примерно в 10 раз быстрее, чем прямая массовая вставка с использованием одного процесса записи в таблицу на диске со столбцом идентификаторов и кластеризованным индексом. Чтобы использовать эту производительность массовой вставки, настройте задание копирования с помощью фабрики данных Azure , которая копирует данные из таблицы в памяти в таблицу на диске.

Предотвращение ошибок производительности

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

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

  • Создайте триггер INSTEAD OF, чтобы использовать простую вставку для каждой строки.
  • Используйте временную таблицу в памяти, как описано в предыдущем разделе.

Другой такой сценарий возникает при записи в некластеризованный индекс columnstore (NCCI), где небольшие массовые вставки могут создавать слишком много сегментов, что может завершить работу индекса. В этом случае рекомендуется использовать кластеризованный индекс Columnstore.

Сводка

В конечном итоге использование функции разбиения на секции в Azure Stream Analytics для SQL-выхода, параллелизация работы с секционированной таблицей в Azure SQL должно существенно увеличить производительность. Использование Azure Data Factory для оркестрации перемещения данных из таблицы In-Memory в дисковые таблицы может значительно увеличить пропускную способность. Если это возможно, улучшение плотности сообщений также может быть основным фактором в улучшении общей пропускной способности.

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

  • Last updated on