Размер, масштабирование и организация очереди в хранилище SQL
В этой статье объясняется поведение размера кластера, очереди и автоматического масштабирования хранилищ SQL.
Изменение размера бессерверного хранилища SQL
Всегда начинайте с большего размера футболки для вашего бессерверного хранилища SQL, чем вы думаете, что вам потребуется и размер по мере тестирования. Не начинайте с небольшого размера футболки для вашего бессерверного хранилища SQL и идти вверх. Как правило, начните с одного бессерверного хранилища SQL и использует Azure Databricks для правильного размера с бессерверными кластерами, приоритетами рабочих нагрузок и быстрых операций чтения данных. См . бессерверные автомасштабирование и очередь запросов.
- Чтобы уменьшить задержку запросов для данного бессерверного хранилища SQL:
- Если запросы сбрасываются на диск, увеличьте размер футболки.
- Если запросы очень параллелизуются, увеличьте размер футболки.
- Если одновременно выполняется несколько запросов, добавьте дополнительные кластеры для автомасштабирования.
- Чтобы сократить затраты, попробуйте уйти в размер футболки без разлива на диск или значительно увеличить задержку.
- Чтобы помочь правильному размеру бессерверного хранилища SQL, используйте следующие средства:
- Страница мониторинга: посмотрите на число пиковых запросов. Если пиковая очередь обычно превышает одну, добавьте кластеры. Максимальное количество запросов в очереди для всех типов хранилища SQL — 1000. См. раздел "Мониторинг хранилища SQL".
- Журнал запросов. См . журнал запросов.
- Профили запросов (поиск байтов, разливаемых на диск выше 1). См. раздел Профиль запроса.
Примечание.
Для бессерверных хранилищ SQL размеры кластера могут в некоторых случаях использовать разные типы экземпляров, отличные от перечисленных в документации по хранилищам pro и классических хранилищ SQL для эквивалентного размера кластера. Как правило, соотношение цен и производительности размеров кластера для бессерверных хранилищ SQL аналогично значениям для хранилищ pro и классических хранилищ SQL.
Автоматическое масштабирование бессерверных серверов и очередь запросов
Интеллектуальное управление рабочими нагрузками (IWM) — это набор функций, которые повышают способность бессерверных хранилищ SQL обрабатывать большое количество запросов быстро и экономично. Он динамически управляет рабочими нагрузками с помощью моделей машинного обучения для прогнозирования потребностей ресурсов входящих запросов при мониторинге доступной вычислительной емкости хранилища в режиме реального времени. Отслеживание этих и других сигналов в хранилище позволяет IWM реагировать на изменения требований рабочей нагрузки.
Это динамическое управление позволяет IWM выполнять следующие действия:
- Быстрое масштабирование вычислений для поддержания низкой задержки.
- Предоставьте доступ к запросу по тарифам ближе к ограничению оборудования.
- Быстрое снижение масштаба, чтобы минимизировать затраты при низком спросе.
Когда запрос поступает в хранилище, IWM прогнозирует ее стоимость. В то же время IWM отслеживает доступную вычислительные мощности хранилища в режиме реального времени. Затем с помощью моделей машинного обучения IWM прогнозирует, есть ли входящий запрос необходимые вычислительные ресурсы, доступные для существующих вычислений. Если у него нет необходимых вычислений, запрос добавляется в очередь. Если у него есть необходимые вычислительные ресурсы, запрос начинает выполняться немедленно.
IWM отслеживает очередь примерно каждые 10 секунд. Если очередь не уменьшается достаточно быстро, автомасштабирование запускается, чтобы быстро получить больше вычислений. После добавления новой емкости запросы в очереди допускаются к новым вычислительным ресурсам. Благодаря бессерверным хранилищам SQL новые вычислительные ресурсы можно быстро добавлять. Максимальное количество запросов в очереди для всех типов хранилища SQL — 1000.
Размеры кластера для профессиональных и классических хранилищ SQL
В таблице в этом разделе сопоставлены размеры кластера хранилища SQL с размером драйвера Azure Databricks и количеством рабочих ролей. Размер драйвера применяется только к хранилищам pro и классического SQL.
| Размер кластера | Тип экземпляра для драйвера (применяется только к хранилищам pro и классического SQL) | Количество рабочих ролей |
|---|---|---|
| 2X-Small | Standard_E8ds_v4 | 1 x Standard_E8ds_v4 |
| X-Small | Standard_E8ds_v4 | 2 x Standard_E8ds_v4 |
| Небольшой | Standard_E16ds_v4 | 4 x Standard_E8ds_v4 |
| Средняя | Standard_E32ds_v4 | 8 x Standard_E8ds_v4 |
| Большой | Standard_E32ds_v4 | 16 x Standard_E8ds_v4 |
| Очень крупный | Standard_E64ds_v4 | 32 x Standard_E8ds_v4 |
| 2X-Large | Standard_E64ds_v4 | 64 x Standard_E8ds_v4 |
| 3X-Large | Standard_E64ds_v4 | 128 x Standard_E8ds_v4 |
| 4X-Large | Standard_E64ds_v4 | 256 x Standard_E8ds_v4 |
Размер экземпляра всех рабочих ролей — Standard_E8ds_v4.
К каждому драйверу и рабочей роли подключено 8 управляемых дисков LRS уровня "Стандартный" по 128 ГБ. Подключенные диски оплачиваются почасово.
Требуемая квота виртуального ЦП Azure для классических и профессиональных хранилищ SQL
Чтобы запустить классическое или pro хранилище SQL, необходимо иметь достаточную квоту виртуального ЦП Azure для Standard_E8ds_v4 экземпляров в учетной записи Azure. Чтобы определить требуемую квоту виртуальных ЦП, следуйте приведенным ниже рекомендациям.
- Если у вас есть только одно или два хранилища SQL, убедитесь, что для каждого ядра в кластере доступно 8 виртуальных ЦП Azure. В таком случае в вашем распоряжении будет достаточно виртуальных ЦП Azure, чтобы учитывать повторную подготовку хранилища, которая выполняется примерно каждые 24 часа. Если хранилища SQL используют автоматическое масштабирование или балансировку нагрузки между несколькими кластерами, может потребоваться увеличить множитель.
- По мере увеличения количества хранилищ SQL используйте от 4 до 8 виртуальных ЦП Azure для каждого ядра в кластере. Databricks рекомендует начать с большего числа и отслеживать стабильность.
- Виртуальные ЦП Azure, используемые хранилищами SQL, в дополнение к виртуальным ЦП Azure, используемым кластерами, используемыми Обработка и анализ данных и инженерией или рабочими нагрузками, не использующий Databricks.
Чтобы запросить дополнительную квоту виртуальных ЦП Azure, см. статью Стандартная квота: увеличение ограничений для различных серий виртуальных машин в документации Azure.
Примечание.
Сведения в этой таблице могут отличаться в зависимости от доступности продукта или региона и типа рабочей области.
Очереди и автоматическое масштабирование для pro и классических хранилищ SQL
Azure Databricks ограничивает количество запросов к кластеру, назначенному хранилищу SQL, с учетом затрат на вычисление их результатов. Увеличение числа кластеров на каждое хранилище основано на пропускной способности запросов, частоте входящих запросов и размере очереди. Azure Databricks рекомендует кластер для каждых 10 одновременных запросов. Максимальное количество запросов в очереди для всех типов хранилища SQL — 1000.
Azure Databricks добавляет кластеры в зависимости от времени, необходимого для обработки всех текущих запросов, всех очередных запросов и входящих запросов, ожидаемых в течение следующих двух минут.
- Если менее 2 минут, не масштабируемые.
- Если 2–6 минут, добавьте 1 кластер.
- Если 6–12 минут, добавьте 2 кластера.
- Если 12–22 минуты, добавьте 3 кластера.
В противном случае Azure Databricks добавляет 3 кластера плюс 1 кластер для каждых 15 минут ожидаемой загрузки запроса.
Кроме того, хранилище всегда масштабируется, если запрос ожидает 5 минут в очереди.
При низкой загрузке в течение 15 минут Azure Databricks уменьшает количество кластеров для хранилища SQL. Сохраняется достаточное количество кластеров, чтобы справиться с пиковой нагрузкой за последние 15 минут. Например, если пиковая нагрузка составляла 25 параллельных запросов, Azure Databricks сохранит 3 кластера.
Очередь запросов для профессиональных и классических хранилищ SQL
Azure Databricks помещает запросы в очередь, если все назначенные хранилищу кластеры выполняют запросы с полной нагрузкой или если хранилище находится в состоянии STARTING. Максимальное количество запросов в очереди для всех типов хранилища SQL — 1000.
Запросы к метаданным (например, DESCRIBE <table>) и запросы с изменением состояния (например SET) никогда не ставятся в очередь, если хранилище не находится в состоянии STARTING.