Блог

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

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

Пример проблемы: —

Поэтому, когда Azure выполняет запрос, подобный следующему: —

 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. После всего этого мы все же получили доказательства того, что ЦП достиг максимума в базе данных SQL в сценариях, описанных выше.

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

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

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

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

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

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

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

Если вы создаете эластичные таблицы с nvarchar(max) или varchar(max) в исходной таблице, это значительно замедлит работу, когда запрос содержит эти поля. Единственное решение — ограничить эти поля значением varchar (x), где x — ваша максимальная длина данных. Это СИЛЬНО повлияло на мои эластичные запросы: от 35 минут до 12 секунд.

Итак, в двух словах; оказывается, способ работы пулов данных sql требует более оптимизированных запросов.

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

Оказывается, именно так работает Azure.