Azure слишком легко выходит за пределы базы данных
Краткая справка: - У нас есть решение SAAS со следующими основными компонентами. 1. У нас есть веб-портал, где администраторы могут редактировать данные. 2. У нас есть веб-API, который вызывается мобильными устройствами. Мобильные устройства отслеживают или сообщают о прогрессе чтения студентов
До настоящего времени решение размещалось на виртуальных серверах. Теперь мы переносим решение в среду Azure, чтобы мы могли воспользоваться масштабируемостью эластичных пулов баз данных. Мы используем темы событий для обработки больших объемов сообщений с мобильных устройств, когда сообщения могут обрабатываться асинхронно, но есть некоторые сообщения, которые необходимо обрабатывать синхронно, и мы обнаруживаем, что структура Azure работает очень медленно, когда речь идет о нескольких одновременных подключениях,
Пример вопроса: -
Поэтому, когда 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. Кроме того, производительность автономной базы данных, похоже, не конкурирует с производительностью виртуального сервера.
Это очень расстраивает, потому что пулы баз данных Elastic были рекомендованы для нас из соображений поддержания производительности и увеличения масштабируемости. В настоящее время у нас более 700 клиентов на одном виртуальном сервере; и ожидали создать одну базу данных шардов для каждого клиента. Идея заключалась в том, что мы могли бы масштабироваться от сотен клиентов до десятков тысяч клиентов. На самом деле мы боремся за то, чтобы фабрика Azure работала практически так же, как у виртуальных серверов. Таким образом, этот вопрос состоит в том, чтобы спросить, есть ли кто-то со значительным опытом в том, чтобы заставить Azure выполнять нетривиальные задачи в разумном темпе? (желательно без необходимости перезаписывать большие фрагменты системы)
3 ответа
При переносе ваших баз данных SQL в облако требуется изменение мышления.
В локальном мире мы привыкли к мощным машинам, которые достаточно мощные, чтобы выдерживать интенсивные нагрузки. Это связано с тем, что физические машины построены с необходимыми ресурсами для обработки больших рабочих нагрузок с интенсивной обработкой (созданной для выполнения самой большой задачи, а не самой маленькой задачи). Из-за чрезмерной доступности ресурсов мы часто допускаем неэффективность работы с запросами и базовыми схемами. При избыточной доступности ресурсов влияние часто бывает минимальным.
Но затем вы пытаетесь переместить те же базы данных в Azure, и все работает не так хорошо. Помните, что Azure - это модель с оплатой за использование. Вы платите X за ресурсы Y, а когда вам нужно больше, вы платите больше X за больше Y. Из-за этой модели вы должны учитывать, что все, что вы делаете в своей базе данных, эффективно стоит ваших денег. Каждый запрос стоит вам денег. Каждая неэффективность стоит вам все больше и больше денег. И т. Д. И т. Д. При явной оплате ресурсов каждый месяц мы склонны недооценивать (как правило, для самой маленькой задачи), потому что мы чувствуем, что тратим деньги в противном случае. Это означает, что когда иногда требуется выполнить крупную задачу, у нас недостаточно ресурсов для ее выполнения, и производительность снижается. Это заставляет нас думать, что Azure стоит дороже, но производительность хуже.
Поэтому, чтобы улучшить свою ситуацию, вы всегда можете увеличить свои ресурсы в Azure, если вы готовы за это платить. Или вы можете делать то, что другие предлагают и оптимизировать ваши запросы и базовые схемы, и получать экономию средств каждый раз, когда вы делаете это.
Если вы создаете эластичные таблицы с помощью nvarchar(max) или varchar(max) в исходной таблице, это значительно замедлит работу, если запрос содержит эти поля. Единственное решение - ограничить эти поля до varchar (x), где x - максимальная длина данных. Это ОГРОМНО изменило мои эластичные запросы с 35 минут до 12 секунд.
Итак, в двух словах; Оказывается, для работы SQL-пулов требуются более оптимизированные запросы.
То, как измеряются DTU, означает, что любая действительно сложная работа SQL должна обрабатываться вне SQL-пулов данных; но манипулирование данными внутри пулов данных должно быть как можно более плавным (проиндексировано, статистика обновлена, наименьшее количество возможных полей в объединениях).
Оказывается, именно так работает Azure.