Может ли SQL Azure масштабироваться без какой-либо конкретной техники или администрирования (разбиение / репликация ...)? - PullRequest
2 голосов
/ 17 марта 2011

Может ли SQL Azure масштабироваться без какой-либо конкретной техники или администрирования, таких как BigTable Google App Engine?Не требуется ручное разбиение или репликация?

Ответы [ 2 ]

4 голосов
/ 18 марта 2011

Вы имеете в виду масштабирование для удовлетворения растущего спроса или увеличение в размере для размещения дополнительных данных?

Что касается размера: вы выбираете «редакцию» базы данных (веб или бизнес) - оба имеют разные ограничения по размеру. Вам выставлен счет только по размеру. максимальный размер составляет 50 ГБ. После выбора издания емкость увеличится до максимально допустимой для размещения ваших данных. Вы ничего особенного не делаете.

Что касается масштабирования для удовлетворения требований к производительности ... вы абстрагированы от управления действительно всем, что связано с масштабируемостью с точки зрения SQL Azure ... Ваша база данных размещена вместе с другими базами данных на различных серверах SQL, работающих в данных MS центр. теоретически ваша база данных будет перемещена на менее загруженный сервер, если он станет слишком горячим ... однако SQL Azure не считается решением с высокой степенью масштабируемости (например, качество facebook / twitter).

Если вам нужна мега-масштабируемость, вам нужно использовать Azure Table Storage

1 голос
/ 30 марта 2011

Для большинства приложений SQL Azure будет отлично масштабироваться.

"Будет ли это масштабироваться?" Это вопрос, который многие из нас задаются вопросом о SQL Azure. Тем более, что вы не можете сказать, сколько Ram, процессорных ядер или реплицированных серверов с балансировкой нагрузки выделить. В Windows Azure вы можете указать, на каком ресурсе вы хотите разместить свое приложение, но это не так в SQL Azure. Для некоторых это может звучать очень плохо, но SQL Azure предназначен для «автоматического» масштабирования сервера базы данных в соответствии с вашими потребностями. Что это значит, я, честно говоря, не могу сказать, так как пока не нашел много официальной информации от Microsoft по этой теме.

Для сайтов с очень высоким трафиком, таких как Facebook и Twitter, было предложено, чтобы нереляционные базы данных (такие как хранилище таблиц Azure) могли масштабироваться лучше, поскольку база данных имеет меньше накладных расходов при запросе данных. Если вам нужны функции реляционной базы данных (например, отношения с внешним ключом и функции объединения SQL), то, возможно, вы захотите использовать SQL Azure.

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

Также можно использовать гибридное или смешанное решение как хранилища SQL Azure, так и хранилища таблиц Azure. Если у вас есть данные, требующие реляционных запросов, поместите их в SQL Azure. Если у вас есть данные, которые не требуют реляционной базы данных, вы можете поместить их в хранилище таблиц Azure.

Помните, что дизайн базы данных является частью общей архитектуры вашего приложения, и вы должны планировать ее так же, как вы планируете использовать TDD, IOC и Dependency Injection. В конце концов, если ваша база данных не может масштабироваться, не имеет значения, насколько хорош код приложения.

Кроме того, размышления над этой темой заставляют задуматься, что XBox Live и Bing Search используют для своих нужд в базе данных. Это реляционное, нереляционное или гибридное?

...