背景:
我们有一个主要实体是客户的应用程序。此应用程序中的所有信息均从客户处开始。我们认为如果我们可以将它用于某种分区,那将是非常好的。我们使用Azure SQL数据库作为后端设计了该服务。
我们的表格看起来像这样(只有相关部分是为了简洁起见):
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中推断出来;
现在我们可以将所有客户都放在一个数据库中而不会出现问题,并且它们会相互隔离。如果将来某个时候,其中一个太大了,我们可以在该特定客户ID上拆分联邦,我们不必更改代码中的任何内容来支持它。
哎呀,我们可以让每个客户都在分离的联邦数据库中,而使用它的服务也不会对它有任何了解。
我们对我们的解决方案非常满意,我认为我非常聪明地想出来。直到最近,当微软宣布他们正在使用即将推出的新的azure数据库版本弃用azure联合功能时。详细了解here和here。
我希望你能看到我的问题。您认为我的替代方案是什么?您是否使用Azure Federations以及如何转换?
谢谢。
答案 0 :(得分:3)
我们已经看到,与联盟相比,自定义分片解决方案通常可以在可扩展性,灵活性和性能方面获得更好的结果。您可以在此处找到有关联盟和自定义分片的更多信息:http://msdn.microsoft.com/en-us/library/dn495641.aspx。这是宣布退出联盟以及Windows Azure SQL数据库中的Web和Business Edition的部分原因。
我鼓励你研究自我分片作为替代方案。去年,CAT团队在http://social.technet.microsoft.com/wiki/contents/articles/17987.cloud-service-fundamentals.aspx处围绕自我分片模式发布了很好的指导,很多这样的材料很快就会出现。
请随时与我联系,讨论迁移现有联盟应用程序的替代方案。我是Azure DB产品团队的一员,您可以通过torsteng(at)microsoft.com与我联系
谢谢,
的Torsten
答案 1 :(得分:2)
您唯一的选择是重写您的软件。当他们说自定义分片解决方案更好时,微软就撒谎了。实际上他们多年来告诉你,为什么你应该更喜欢联合自定义分片,他们为此提供了非常可靠的要点:连接池,缩放时没有停机时间,没有自定义代码来管理你的分片等等。但是,现在微软希望获得更多的钱来自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个服务器。
答案 2 :(得分:1)