Вопросы производительности SQL Azure - PullRequest
2 голосов
/ 21 апреля 2011

Какие соображения производительности следует учитывать при планировании приложения SQL Azure?Хранилище Azure, а также рабочая и веб-роли выглядят очень масштабируемыми, но если в конце они используют одну базу данных ... это выглядит как узкое место.

Я пытался найти числа о:

  1. Сколько одновременных соединений поддерживает SQL Azure?
  2. Какая пропускная способность?

Но не повезло.

Например, яЯ планирую и применяю приложение, которое использует очень высокий уровень вставок, но мне нужно каждый раз возвращать результат агрегатной функции (например: сумму всех записей с одинаковым ключом в столбце), поэтому я не могу перейти с хранилищем таблиц.

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

Sharding - это еще один вариант, но даже когда количествоколичество вставок огромно, объем данных очень маленький, от 4 до 6 столбцов с одним PK и без FK.Таким образом, даже 1 ГБ БД будет перебором (и переплатой: D) для раздела.

Какие ключи производительности я должен иметь в виду, когда сталкиваюсь с такими приложениями?

Приветствия.

Ответы [ 2 ]

3 голосов
/ 25 апреля 2011

Достижение масштабируемости и производительности может быть очень сложным даже в облаке.Ваш вопрос касался в первую очередь масштабируемости, поэтому вы, возможно, захотите спроектировать свое приложение таким образом, чтобы ваши данные стали «в конечном итоге» согласованными, например, с использованием очередей.Рабочая роль будет прослушивать входящие запросы на вставку и будет выполнять вставку асинхронно.

Чтобы свести к минимуму количество обращений к базе данных и оптимизировать пул соединений, не забудьте также пакетировать ваши вставки.Таким образом, вы можете отправить 100 вставок в одном кадре.Также имейте в виду, что SQL Azure теперь поддерживает MARS (несколько активных наборов записей), так что вы можете вернуть несколько SELECT в одном пакете обратно в вызывающий код.Использование пакетной обработки и MARS должно сократить количество подключений к базе данных до минимума.

Черепок обычно помогает при операциях чтения;не так много для вставок (хотя я никогда не сравнивал вставки с шардингом).Так что я не уверен, что осколок поможет вам так много для ваших требований.

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

3 голосов
/ 22 апреля 2011

SQL Azure будет регулировать ваши соединения, если возникнет какая-либо форма конфликта ресурсов (это включает в себя большую нагрузку, но может также произойти, когда ваша база данных физически перемещается). Регулирование недетерминировано, то есть вы не можете предсказать, произойдет ли это и когда. При регулировании SQL Azure прервет ваше соединение, что потребует от вас повторных попыток. Количество поддерживаемых соединений и пропускная способность не публикуются «по проекту» из-за гибкого характера базовой инфраструктуры. Сказав это, установка оптимизирована для высокой доступности, а не высокой пропускной способности.

Если всплески происходят в известное время, вы можете рассмотреть вопрос о разбиении как раз во время этих всплесков и консолидации данных после того, как произошла посылка. Другой способ справиться с этим - начать очередь / пакетную запись, если и только если происходит регулирование. Для этого вы можете использовать очередь Azure и рабочую роль, чтобы позже очистить очередь. Этот «механизм переполнения» обладает тем преимуществом, что он автоматически включается в случае дросселирования.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...