Лазурные федерации устарели. Какие у меня варианты?

Фон:

У нас есть приложение, основным субъектом которого является клиент. Вся информация в этом приложении начинается с клиента. Мы подумали, что было бы неплохо, если бы мы могли использовать это для какого-то разделения. Мы разработали сервис с базой данных 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

Другие вопросы по тегам