最佳实践Azure DB Scaling

时间:2015-08-18 06:06:59

标签: database azure synchronization azure-sql-database

我在azure云中运行了一个web应用程序。目前我们只使用Region" West Europe"但我们现在也将美国列为一个地区。

现在我正在考虑数据库...... 目前,我在西欧地区拥有Azure SQL数据库。 它是一个非常小的数据库,不包含大量数据。其中大部分只有关系,用户数据和其他内容。

那么现在将它扩展到多个区域的最佳做法是什么?

我认为我有以下选择:

  • 在该区域中放置数据库并从其他区域连接到同一个数据库(这里我担心主要是延迟问题)
  • 为每个区域创建数据库并使用数据库同步

关于数据库同步,我找不到可以解释在以下情况下会发生什么的答案:

初始状态(两者都是同步):

A区,表A

id值

1"测试"

2" test2"

3" test3"

B区,表A

id值

1"测试"

2" test2"

3" test3"

现在,数据已添加到两个数据库中:

A区,表A

id值

1"测试"

2" test2"

3" test3"

4" test4"

5" test5"

B区,表A

id值

1"测试"

2" test2"

3" test3"

4" test6"

5" test7"

在文档中,他们总是谈论一行是否已更新,然后特定规则" Hub获胜"或者"客户获胜"应用。但是在这种添加行的情况下会发生什么? 我相信同步后的最终结果将是(如果选择了hub wins并且Hub是A区的数据库):

4" test4"

5" test5"

因此,区域B中的所有更改都将被忽略。是对的吗? 该表中的PK是整数。也许这个问题可以解决,如果PK是Guid我猜......

我目前还不确定,什么是扩展数据库的最佳方式。我希望有人可以给我一个暗示。 有没有人已经体验过多个地区的Azure网络内部的延迟?

感谢您的帮助!

1 个答案:

答案 0 :(得分:0)

您在双向Azure数据库同步方面是正确的 - 在您的情况下,在同步之后,根据冲突解决方案设置,区域B将更新为与区域A相同。

要在允许主动 - 主动时展开您的应用,您需要确保每个地区的PK都是唯一的,例如:使用GUID或井分区。如果您的应用程序是读取密集型的,则另一个选项是将所有写入操作重定向到单个" master" DB,然后将更改推送到其他只读区域;它可以避免冲突,但需要改变app逻辑。

(顺便说一句,请注意,Azure数据同步是最终的一致性,但不是事务一致性,而是计划而不是连续。您最好评估您的应用是否可以容忍这些。)

关于跨区域的网络延迟,有一个第三方网站azurespeed.com具有良好的可视化效果,虽然不是专门针对Azure数据库,但可能有所帮助。