Azure удаляет базу данных cpu пределы слишком легко

Question

Фон в двух словах: - У нас есть решение SAAS со следующими основными компонентами. 1. У нас есть веб-портал, где администраторы могут редактировать данные. 2. У нас есть веб-API, который вызывается мобильными устройствами. Мобильные устройства отслеживают или сообщают о ходе обучения студентов

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

Пример вопроса: -

Так что, когда Azure запускает запрос вроде следующего: -

пики CPU

SELECT q.Category, COUNT(*) 
FROM Question q 
JOIN Answer a 
ON a.QuestionId = q.QuestionId 
GROUP BY q.Category 
ORDER BY q.Category 

SQL, выше 97% во всех следующих случаях: -
1. DTU - 50 и существует более одного одновременного вызова.
2. DTU - 1500 и есть 5 или более одновременных вызовов.
3. DTU - 4000 и 20 или более одновременных вызовов.

Итак, мы открыли телефонный звонок с Microsoft. Мы потратили больше недели на изучение вещей из статистики и индексов sql вплоть до уровней api-тарифов в Интернете. После всего этого мы все еще обнаружили доказательства того, что CPU достиг пика в базе данных SQL со сценариями, описанными выше.

Это приводит к неизбежному «переписыванию больших кусков вашей системы».

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

Это настолько разочаровывает, что для нас были рекомендованы бассейны с эластичными базами данных из-за поддержания производительности и повышения масштабируемости. В настоящее время мы запускаем 700 клиентов на одном виртуальном сервере; и ожидали создать одну базу данных осколков для каждого клиента. Идея состоит в том, что мы могли бы затем расширить масштабы от сотен клиентов до десятков тысяч клиентов. На самом деле мы боремся за то, чтобы заставить Azure-ткань работать где-нибудь рядом с тем уровнем производительности, который у нас есть на виртуальных серверах. Итак, этот вопрос заключается в том, чтобы спросить, есть ли кто-либо со значительным опытом в создании Azure для выполнения нетривиальных задач в разумном темпе? (предпочтительно без необходимости переписывать большие куски системы)

Answer 1

Так что в двух словах; выясняется, что способ работы SQL-пулов требует более оптимизированных запросов.

Способ измерения DTU означает, что любая действительно мудрая работа SQL shuold обрабатывается за пределами SQL-пулов sql; но манипуляции с данными внутри пулов данных должны быть максимально скользкими (индексированные, обновленные статистики, минимальные поля в объединениях).

Получается, что так работает Azure.

Answer 2

При переносе баз данных SQL в облако требуется переход.

В помещении мы привыкли к мощным машинам, которые достаточно крепки, чтобы справляться с интенсивными рабочими нагрузками. Это связано с тем, что физические машины построены с необходимыми ресурсами для обработки больших рабочих нагрузок с интенсивной обработкой (построенной для самой большой задачи, которую они должны обрабатывать, а не самой маленькой задачи). Из-за большей доступности ресурсов мы часто допускаем неэффективность работы с запросами и базовыми схемами. С избыточной доступностью ресурсов аффект часто является минимальным.

Но тогда вы пытаетесь переместить те же базы данных в Azure, и все не так хорошо работает. Помните, что Azure является моделью с оплатой за использование. Вы платите X за ресурсы Y, а когда вам нужно больше, вы платите больше X за более Y. Из-за этой модели вы должны учитывать, что все, что вы делаете в своей базе, эффективно обходится вам в деньгах. Каждый запрос стоит вам денег. Каждая неэффективность стоит вам все больше и больше денег. И т.д. И т. Д. При явной оплате ресурсов каждый месяц мы склонны покупать (как правило, для наименьшей задачи), потому что мы чувствуем, что в противном случае мы тратим деньги. Это означает, что, когда требуется выполнение одной большой задачи, у нас недостаточно ресурсов для ее обработки, а производительность ухудшается. Это заставляет нас думать, что Azure стоит дороже, но имеет худшую производительность.

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