SQL Azure - Как измерить текущую рабочую нагрузку, чтобы оценить, когда произойдет регулирование - PullRequest
2 голосов
/ 06 июля 2011

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

У меня есть база данных SQL Azure, которая обеспечивает работу социальной сети. Миллионы транзакций происходят каждый день от очень простых до сложных SELECTS, которые сортируют десятки тысяч пользователей по расстоянию и т. Д.

Число пользователей растет с каждым днем, и я знаю (верю), что в какой-то момент мне потребуется внедрить шардинг или использовать федерацию SQL Azure для поддержания работоспособности моего приложения из-за ограниченности ресурсов 1 SQL Azure. но мой вопрос в том, как мне понять, когда мне понадобится это сделать?

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

Если я знаю, что мне выпадает 80% от того, что мне разрешено, то я знаю, что мне нужно расставить приоритеты для решения, которое поможет мне масштабироваться, но если я использую только 10%, то я знаю, что могу отложить это на задний план и разобраться с этим позже.

Я не могу найти какой-либо способ или даже упомянуть, как это измерить?

Есть предложения?

Спасибо,

Стивен

Ответы [ 3 ]

1 голос
/ 20 июля 2011

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

Статья Technet: управление соединением SQL Azure

Спасибо за упоминание библиотеки Enzo, кстати (отказ от ответственности: я ее написал)!

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

Спасибо, Эрве

1 голос
/ 06 июля 2011

Я не знаю ни одного встроенного способа измерить это. Если кто-то это сделает, мне было бы очень интересно узнать об этом.

Тем не менее, есть отличная библиотека от команды Microsoft AppFabric CAT Best Practices, которая представляет собой временную среду обработки ошибок. Смотрите здесь

Это делает несколько вещей, включая обработку логики повторов для открытия соединений и выполнения запросов. Вы можете использовать это, но немного расширить его, чтобы регистрировать, когда вас душит SQL Azure.

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

Исходя из приведенных вами цифр, я бы сейчас определенно начал рассматривать шардинг.

0 голосов
/ 16 июля 2011

лучшие методы борьбы с регулированием 1) старайтесь делать запросы как можно короче 2) запускать рабочие нагрузки пакетами 3) использовать механизмы повторов.

Я также хотел бы указать вам на пару ресурсов.1) sql Azure коды причины дросселирования и декодирования: http://msdn.microsoft.com/en-us/library/ff394106.aspx#throttling 2) http://geekswithblogs.net/hroggero/archive/2011/05/26/cloud-lesson-learned-exponential-backoff.aspx

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