Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Эта шпаргалка содержит полезные советы и лучшие практики для создания решений пула SQL (ранее — хранилище данных SQL).
На следующем рисунке показан процесс проектирования хранилища данных с выделенным пулом SQL (ранее — хранилище данных SQL).
Запросы и операции в таблицах
Когда вы заранее знаете основные операции и запросы, которые будут выполняться в хранилище данных, вы можете определить приоритет архитектуры хранилища данных для этих операций. Эти запросы и операции могут включать:
- Присоединяйте одну или две таблицы фактов с таблицами измерений, фильтруя объединенную таблицу, а затем добавляя результаты в объект данных.
- Создание больших или небольших обновлений данных о ваших продажах.
- Добавление только данных в таблицы.
Знание типов операций заранее помогает оптимизировать структуру таблиц.
Миграция данных
Сначала загрузите данные в Azure Data Lake Storage или хранилище BLOB-объектов Azure. Затем используйте инструкцию COPY для загрузки данных в промежуточные таблицы. Используйте следующую конфигурацию:
| Дизайн | Рекомендация |
|---|---|
| Распределение | Циклический раунд |
| Индексирование | Куча |
| Секционирование | Отсутствует |
| Класс ресурсов | largerc или xlargerc |
Дополнительные сведения о миграции данных, загрузке данных и процессе извлечения, загрузки и преобразования (ELT).
Распределенные или реплицированные таблицы
Используйте следующие стратегии в зависимости от свойств таблицы:
| Тип | Отлично подходит для... | Берегитесь, если... |
|---|---|---|
| Реплицированные | * Небольшие таблицы измерений в звездчатой схеме с менее чем 2 ГБ хранилища после сжатия (~5x сжатия) | * Многие транзакции записи выполняются на таблице (например, insert, upsert, delete, update) * Вы часто изменяете настройку единиц хранилища данных (DWU) * Вы используете только 2-3 столбца, но таблица содержит множество столбцов. * Индексирование реплицированной таблицы |
| Циклический алгоритм (по умолчанию) | * Временная/промежуточная таблица * Нет очевидного ключа для объединения или хорошего столбца-претендента |
* Производительность замедляется из-за перемещения данных |
| хеш | * Таблицы фактов * Большие таблицы измерений |
* Невозможно обновить ключ распространения |
Советы:
- Начните с Round Robin, но стремитесь к стратегии хэш-распределения, чтобы воспользоваться преимуществами массовой параллельной архитектуры.
- Убедитесь, что общие хэш-ключи имеют одинаковый формат данных.
- Не распределяйте по формату varchar.
- Таблицы измерений с общим хэш-ключом к таблице фактов с частыми операциями соединения могут быть распределены хэшом.
- Используйте sys.dm_pdw_nodes_db_partition_stats для анализа любых отклонений в данных.
- Используйте sys.dm_pdw_request_steps для анализа перемещения данных за запросами, а также для мониторинга времени выполнения операций широковещательной передачи и перемещения данных. Это полезно для оценки вашей стратегии распространения.
Дополнительные сведения о реплицированных таблицах и распределенных таблицах.
Индексируйте таблицу
Индексирование полезно для быстрого чтения таблиц. Существует уникальный набор технологий, которые можно использовать на основе ваших потребностей:
| Тип | Отлично подходит для... | Осторожно, если... |
|---|---|---|
| Куча | * Промежуточная или временная таблица * Небольшие таблицы с небольшими поисками |
* Любой поиск сканирует полную таблицу |
| Кластеризованный индекс | * Таблицы с до 100 миллионов строк * Большие таблицы (более 100 миллионов строк) с только 1-2 столбцами, которые часто используются |
* Используется в реплицированной таблице * У вас есть сложные запросы, связанные с несколькими операциями соединения и группирования по * Вы вносите изменения в индексированные столбцы: это требует памяти. |
| Кластеризованный колоночный индекс (CCI) (по умолчанию) | * Большие таблицы (более 100 миллионов строк) | * Используется в реплицированной таблице * Вы выполняете массовые операции обновления в таблице * Вы переразбиваете вашу таблицу: группы строк не охватывают разные узлы распределения и секции. |
Советы:
- На вершине кластеризованного индекса может потребоваться добавить некластеризованный индекс в столбец, который сильно используется для фильтрации.
- Будьте осторожны при управлении памятью в таблице с CCI. При загрузке данных необходимо, чтобы пользователь (или запрос) воспользовались большим классом ресурсов. Не забудьте избежать обрезки и создания множества небольших сжатых групп строк.
- В 2-м поколения таблицы CCI кэшируются локально на вычислительных узлах, чтобы повысить производительность.
- Для CCI может наблюдаться низкая производительность из-за плохого сжатия групп строк. В этом случае перестройте или реорганизуйте ваш CCI. Требуется по крайней мере 100 000 строк в каждой сжатой группе строк. Идеальное значение — 1 миллион строк в группе строк.
- Автоматизируйте реорганизацию или перестроение индексов на основе частоты и размера инкрементной загрузки. Весенняя уборка всегда приносит пользу.
- Подходите стратегически, когда хотите сократить группу строк. Насколько большими являются открытые группы строк? Сколько данных вы ожидаете загрузить в ближайшие дни?
Дополнительные сведения об индексах.
Секционирование
Вы можете разбить на секции таблицу, если у вас большая таблица фактов (более 1 миллиарда строк). В 99 процентах случаев ключ раздела должен быть основан на дате.
В промежуточных таблицах, требующих ELT, можно воспользоваться секционированием. Это упрощает управление жизненным циклом данных. Будьте осторожны, чтобы не переделить факт или промежуточную таблицу, особенно в кластеризованном индексе columnstore.
Дополнительные сведения о секциях.
Инкрементная загрузка
Если вы собираетесь добавочно загрузить данные, сначала убедитесь, что вы выделяете большие классы ресурсов для загрузки данных. Это особенно важно при загрузке в таблицы с кластеризованными индексами columnstore. Дополнительные сведения см. в классах ресурсов .
Мы рекомендуем использовать PolyBase и ADF версии 2 для автоматизации конвейеров ELT в хранилище данных.
Для большого пакета обновлений в исторических данных рекомендуется использовать CTAS для записи данных, которые нужно сохранить в таблице, а не с помощью INSERT, UPDATE и DELETE.
Обеспечение статистики
Важно обновить статистику, так как со своими данными происходят значительные изменения. Смотрите статистику обновления, чтобы определить, произошли ли существенные изменения. Обновленная статистика оптимизирует планы запросов. Если вы обнаружите, что требуется слишком много времени для поддержания всех статистических данных, подходите более избирательно к тому, в каких столбцах содержатся статистические данные.
Можно также определить частоту обновлений. Например, может потребоваться обновить столбцы дат, где новые значения могут быть добавлены ежедневно. Вы получаете наибольшее преимущество за счет статистики по столбцам, участвующим в соединениях, столбцам, используемым в предложении WHERE, и столбцам, найденным в GROUP BY.
Дополнительные сведения о статистике.
Класс ресурсов
Группы ресурсов используются в качестве способа выделения памяти запросам. Если требуется больше памяти для повышения скорости запроса или загрузки, следует выделить более высокие классы ресурсов. С другой стороны, использование более крупных классов ресурсов влияет на конкурентность. Необходимо учитывать это перед перемещением всех пользователей в большой класс ресурсов.
Если вы заметили, что запросы занимают слишком много времени, убедитесь, что пользователи не запускают запросы в больших классах ресурсов. Большие классы ресурсов используют множество слотов параллелизма. Они могут заставить другие запросы выстраиваться в очередь.
Наконец, используя выделенный пул SQL 2-го поколения (ранее — хранилище данных SQL), каждый класс ресурсов получает 2,5 раза больше памяти, чем 1-го поколения.
Узнайте больше, как работать с классами ресурсов и параллелизмом.
Снижение затрат
Ключевым компонентом Azure Synapse является возможность управления вычислительными ресурсами. Вы можете приостановить выделенный пул SQL (ранее — хранилище данных SQL), если вы не используете его, что останавливает выставление счетов вычислительных ресурсов. Вы можете масштабировать ресурсы для удовлетворения требований к производительности. Чтобы приостановить, используйте портал Azure или PowerShell. Чтобы масштабировать, используйте портал Azure, PowerShell, T-SQL или REST API.
Настраивайте автомасштабирование на удобное время с Функциями Azure.
Оптимизация архитектуры для повышения производительности
Рекомендуется рассмотреть базу данных SQL и Службы Azure Analysis Services в архитектуре концентратора и периферийной архитектуры. Это решение может обеспечить изоляцию рабочей нагрузки между различными группами пользователей, а также использовать расширенные функции безопасности из базы данных SQL и Служб Azure Analysis Services. Это также способ обеспечить неограниченную одновременность для пользователей.
Дополнительные сведения о типичных архитектурах, использующих выделенный пул SQL (ранее — хранилище данных SQL) в Azure Synapse Analytics.
Развертывание периферийных компонентов в базах данных SQL из выделенного пула SQL (ранее — хранилище данных SQL):