Лазурные федерации устарели. Какие у меня варианты?
Фон:
У нас есть приложение, основным субъектом которого является клиент. Вся информация в этом приложении начинается с клиента. Мы подумали, что было бы неплохо, если бы мы могли использовать это для какого-то разделения. Мы разработали сервис с базой данных SQL Azure в качестве бэкэнда.
Наши таблицы выглядят так (для краткости оставлена только соответствующая часть):
TABLE dbo.Orders
(
CustomerId INT NOT NULL DEFAULT( FEDERATION_FILTERING_VALUE( 'FEDERATION_BY_CUSTOMER' ) ),
OrderId INT NOT NULL,
....,
CONSTRAINT PK_Orders PRIMARY KEY CLUSTERED ( CustomerId, OrderId )
) FEDERATED ON ( FEDERATION_BY_CUSTOMER = CustomerId );
Теперь это позволило нам сделать некоторые сумасшедшие вещи. Наша точка входа ко всему, что связано с SQL, всегда содержит следующую команду:
USE FEDERATION GroupFederation( FEDERATION_BY_CUSTOMER = 1 ) WITH RESET, FILTERING = ON
В этом случае это утверждение:
SELECT * FROM Orders
или же
INSERT INTO Orders ( OrderId ) VALUES ( 10 );
будет работать без проблем, работая только по данным данного заказчика. CustomerId COLUMN всегда будет выведен из системной функции FEDERATION_FILTERING_VALUE;
Теперь мы можем без проблем разместить всех наших клиентов в одной базе данных, и они будут изолированы друг от друга. Если когда-нибудь в будущем один из них станет слишком большим, мы могли бы РАЗДЕЛИТЬ федерацию по этому конкретному идентификатору клиента, и нам не нужно ничего менять в нашем коде для его поддержки.
Черт, мы могли бы иметь каждого клиента в отдельной базе данных федерации, и служба, использующая ее, не будет знать об этом ни одной вещи.
Мы были очень довольны нашим решением, и я подумал, что очень умно его выбрал. До недавнего времени Microsoft объявляла об отказе от функции федераций Azure с появлением новых выпусков баз данных Azure. Узнайте больше об этом здесь и здесь.
Я надеюсь, что вы видите мою проблему. Как вы думаете, мои альтернативы? Используете ли вы федерации Azure и как вы собираетесь перейти?
Спасибо.
3 ответа
Мы видели, что решения по индивидуальному разделению обычно дают лучшие результаты в отношении масштабируемости, гибкости и производительности по сравнению с федерациями. Вы можете найти больше информации о Федерациях и пользовательских шардерах здесь: http://msdn.microsoft.com/en-us/library/dn495641.aspx. Это одна из причин объявления об отмене Федераций вместе с веб-версиями и версиями для бизнеса в базе данных SQL Azure Windows.
Я бы посоветовал вам взглянуть на самоотдачу в качестве альтернативы. В прошлом году команда CAT опубликовала хорошее руководство по шаблонам самообороны по адресу http://social.technet.microsoft.com/wiki/contents/articles/17987.cloud-service-fundamentals.aspx и другие подобные материалы. будет приходить в ближайшее время.
Не стесняйтесь обращаться ко мне, чтобы обсудить ваши варианты миграции существующего приложения Федераций. Я являюсь частью команды разработчиков продукта Azure DB, и вы можете связаться со мной по адресу torsteng (at) microsoft.com
Спасибо,
Торстен
Ваш единственный вариант - переписать ваше программное обеспечение. Microsoft лжет, когда говорят, что решение для индивидуального шардинга лучше. На самом деле они годами рассказывали, почему вы ДОЛЖНЫ отдавать предпочтение федерациям по отношению к пользовательским сегрегациям, и они предоставили для этого очень веские аргументы: пул соединений, отсутствие простоев при масштабировании, нет специального кода для управления вашими сегментами и т. Д. Однако теперь Microsoft хочет получить гораздо больше денег. из Azure, поэтому они решили предоставлять клиентам только очень дорогие планы, и федерациям больше нет места, потому что они очень дешевые и легко масштабируемые.
Если у вас нет сверхвысокой скорости транзакций, вы можете попробовать Amazon RDS. Нет никакого шардинга, но они предоставляют вам до 30000 транзакций в секунду, что много даже для очень больших веб-сайтов. Мы переписали наше программное обеспечение для PostgreSQL RDS, и мы очень довольны им. Он имеет гораздо больше функций, чем SQL Server, таких как встроенная поддержка JSON, массивы, несколько путей CASCADE и т. Д.
Если вам недостаточно 30000 транзакций в секунду, просто увеличьте количество серверов и разделите ваши данные на основе имени пользователя или любого другого свойства, например:
Username starts with letter
a-d | connect to Server 1
e-g | connect to Server 2
h-s | connect to Server 3
t-z | connect to Server 4
В приведенном выше примере вы сможете выполнять 120000 транзакций в секунду, и у вас не должно возникнуть проблем с пулом подключений, поскольку в нем всего 4 сервера.
MS только что выпустила утилиту для миграции из Федерации
http://code.msdn.microsoft.com/vstudio/Federations-Migration-ce61e9c1
http://channel9.msdn.com/Blogs/Windows-Azure/Azure-SQL-Database-Federations-Migration