Понимание Azure SQL Performance

Question

факты:

• 1 Azure SQL S0 экземпляра
• несколько столов один из них, содержащий ~ 8,6 млн Ряды и 1 PK

Запуск граф-запрос на эта таблица занимает около 30 минут (!) для завершения.

Upscaling экземпляр от S0 до S1 сокращает время запроса до 13 минут:

смотрит в Azure портал (новая версия) ресурс-использование-монитор показывает следующее:

Вопросы:

1. Рассматривает ли кто-нибудь еще 13 минут как rediculos для простого COUNT()?
2. Включает ли второй снимок экрана, что в течение 100% -го периода мой экземпляр не отвечает на другие запросы?
3. Почему мои метрики ограничены до 100% как в S0, так и S1? (см. look under "Which Service Tier is Right for My Database?": «Эти значения могут быть выше 100% (значительное улучшение над значениями в предварительном просмотре, которые были ограничены максимум 100).) Я ожидаю, что S0 будет выглядеть как на 150% или около того, если цитированное утверждение верно.

Я заинтересован в опыте использования баз данных с более чем 1000 записей или около того от других людей. Я не вижу, как S * -масштабированный Azure SQL для 22-55 евро в месяц может помочь мне в стратегиях масштабирования на данный момент.

Answer 1

Издания Azure SQL Database обеспечивают повышение уровня DTU от Basic -> Standard -> Premium levels (CPU, IO, Memory и других ресурсов - см. https://msdn.microsoft.com/en-us/library/azure/dn741336.aspx). Как только ваш запрос достигнет пределов DTU (100%) в любом из этих размеров ресурсов, он будет продолжать получать эти ресурсы на этом уровне (но не более) и может увеличить задержку при завершении запроса. Похоже, что в вашем сценарии выше запрос достигает своего предела DTU (10 DTU для S0 и 20 для S1). Вы можете увидеть проценты использования отдельных ресурсов (CPU, Data IO или Log IO), добавив эти показатели на один и тот же график или запросив DMV sys.dm_db_resource_stats.

Вот блог, в котором содержится дополнительная информация о том, как правильно оценивать уровни производительности вашей базы данных. http://azure.microsoft.com/blog/2014/09/11/azure-sql-database-introduces-new-near-real-time-performance-metrics/

Для конкретных вопросов

1) Как вы уже 8,6 миллиона строк, база данных должны сканировать записи индекса, чтобы получить счетчик обратно. Таким образом, он может попасть в предел IO для издания здесь.

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

3) Для более старых версий Web/Business вы можете увидеть, что значения показателей превышают 100% (они нормализованы до пределов уровня S2), так как они не имеют каких-либо конкретных ограничений и работают в среде с ресурсами с другими нагрузками клиента. Для новых выпусков метрики никогда не превысят 100%, потому что система гарантирует вам ресурсы до 100% от пределов этой версии, но не более того. Это обеспечивает предсказуемое, гарантированное количество ресурсов для вашей БД, в отличие от выпусков Web/Business, где вы можете получить очень мало или много ресурсов в разное время в зависимости от других конкурирующих рабочих нагрузок клиента, работающих на одном компьютере.

Надеюсь, что это поможет. - Srini