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

Рекомендации по производительности Хранилища данных Synapse в Microsoft Fabric

  • Статья

Область применения: хранилище в Microsoft Fabric

Это рекомендации, которые помогут вам понять производительность хранилища в Microsoft Fabric. В этой статье вы найдете рекомендации и важные статьи, на которые следует сосредоточиться. Хранилище в Microsoft Fabric — это платформа SaaS, где такие действия, как управление рабочими нагрузками, параллелизм и управление хранилищами, управляются внутренне платформой. Помимо этого внутреннего управления производительностью, вы по-прежнему можете повысить производительность, разрабатывая выполняемые запросы к хорошо разработанным хранилищам.

Производительность холодного запуска (холодный кэш)

Кэширование с локальным SSD и памятью выполняется автоматически. Первые 1-3 выполнения запроса выполняются заметно медленнее последующих выполнений. Если у вас возникают проблемы с производительностью холодного запуска, ниже приведены некоторые действия, которые могут повысить производительность холодного запуска:

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

  • Если используется Power BI, используйте режим Direct Lake по возможности.

Метрики для мониторинга производительности

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

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

Мониторинг выполнения запросов с помощью динамических административных представлений (DMV)

Динамические административные представления (DMV) можно использовать для мониторинга состояния подключения, сеанса и запроса в хранилище.

Статистика

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

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

Дополнительные сведения о статистике и способах расширения автоматически созданной статистики см. в разделе "Статистика в хранилище данных Fabric".

Рекомендации по приему данных

Существует четыре варианта приема данных в хранилище:

  • COPY (Transact-SQL)
  • Конвейеры данных
  • Потоки данных
  • Прием между складами

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

Группирование инструкций INSERT в пакеты (избегайте вставок)

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

INSERT INTO MyLookup VALUES (1, 'Type 1')

Рекомендации по обработке этих сценариев простой нагрузки см . в рекомендациях по приему данных.

Уменьшение размера транзакций

Инструкции INSERT, UPDATE и DELETE выполняются в транзакции. В случае сбоя их нужно откатить. Чтобы сократить время выполнения отката, необходимо по возможности уменьшить размеры транзакций. Это можно сделать, разделив инструкции INSERT, UPDATE и DELETE на части. Например, если вы ожидаете, что операция INSERT будет выполняться 1 час, ее можно разделить на четыре части. Таким образом, время каждого выполнения сократится до 15 минут.

Рекомендуется использовать CTAS (Transact-SQL) для записи данных, которые вы хотите сохранить в таблице, а не с помощью DELETE. Если CTAS занимает то же время, это безопаснее выполняться, так как оно имеет минимальное ведение журнала транзакций и может быть отменено быстро при необходимости.

Объединение клиентских приложений и Microsoft Fabric

Если вы используете клиентские приложения, убедитесь, что вы используете Microsoft Fabric в регионе, близком к клиентскому компьютеру. Примеры клиентских приложений включают Power BI Desktop, SQL Server Management Studio и Azure Data Studio.

Использование структуры данных схемы Star

При схеме типа "звезда" данные упорядочиваются в таблицы фактов и измерений. Схема звездочек упрощает аналитическую обработку путем отмены нормализации данных из высоко нормализованных систем OLTP, приема транзакционных данных и корпоративных основных данных в общую, очищаемую и проверенную структуру данных, которая минимизирует JOINS во время запроса, сокращает количество строк чтения и упрощает агрегирование и группирование.

Дополнительные рекомендации по проектированию хранилища см. в таблицах в хранилище данных.

Уменьшение размера результирующих наборов запросов

Сокращение размеров результирующих наборов запросов помогает избежать проблем на стороне клиента, вызванных большими результатами запроса. Наборы результатов редактора SQL-запросов ограничены первыми 10 000 строками, чтобы избежать этих проблем в этом пользовательском интерфейсе на основе браузера. Если вам нужно вернуть более 10 000 строк, используйте SQL Server Management Studio (SSMS) или Azure Data Studio.

Выбор оптимального типа данных для производительности

При определении таблиц используйте наименьший тип данных, поддерживающий данные, так как это позволит повысить производительность запросов. Эта рекомендация важна для столбцов CHAR и VARCHAR. Если самое длинное значение в столбце состоит из 25 знаков, столбец необходимо определить как VARCHAR(25). Избегайте определения всех столбцов символов с большой длиной по умолчанию.

По возможности используйте целочисленные типы данных. Операции SORT, JOIN и GROUP BY выполняются быстрее на основе целых чисел, чем на основе символьных данных.

Поддерживаемые типы данных и дополнительные сведения см. в разделе "Типы данных".

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