RisingStar Sep 16 2013 at 10:56

Горизонтальное масштабирование базы данных реального проекта с помощью SQL Azure Federations. Часть 2: Исходные данные

4 min

8.1K

EPAM corporate blogMicrosoft Azure*

Tutorial

+12

Comments 5

m52 Sep 16 2013 at 12:18

Хех :3

SkidanovAlex Sep 18 2013 at 09:39

В вашем первом подходе запрос выполнится дважды, но он выполнится на двух разных серверах (или федерации в Federations не обязательно соответствуют физическим серверам?), и предположительно выполнит в два раза меньше работы на каждом. Это не обязательно плохо.

У меня есть такой вопрос по Azure Federations. Если я разбиваю данные на 200 шардов, мне надо указывать 199 интервалов, выбирая значения для границ интервалов самому, или есть какой-то способ это сделать более автоматически?

RisingStar Sep 18 2013 at 10:32

Каждый шард соответствует разному физическому серверу (если исходить из архитектуры SQL Azure). Действительно он выполнится на каждом шарде дважды, но быстрее. Я не говорю, что это плохо. Наоборот именно в этом и заключается преимущество горизонтального масштабирования. В примере, где будет разбиваться таблица Entity это плохо лишь потому, что данные одного пользователя могут оказать на разных шардах, а значит допустим получить список операций, которые он делал (Name, Description) придется с другого шарда, что для производительности не есть гуд.

Насколько мне известно, это необходимо все же делать руками. То есть средства позволяющего просто перетащить ползунок и сказать, что вместо 2-х шардов теперь хочу получить 8 нет. Возможно стоит организовать цикл вызова ALTER FEDERATION SPLIT.

silvercaptain Sep 23 2013 at 18:19

Выполнить запрос в целом, а не для каждой федерации возможно?

Или нужно union all делать для каждого подзапроса (запроса к каждой федерации)???

RisingStar Sep 24 2013 at 11:22

Нет, выполнить запрос «в целом» (через root) к сожалению нельзя. Вы должны сами объединить результаты одного запроса с другим. Вот кстати интересная ссылка на MSDN, где Microsoft описывает, о чем еще стоит подумать при работе с федерациями (раздел «Design Considerations»).