有关Azure可伸缩性目标和使用多个Azure存储帐户的问题？

Question

Windows Azure Storage Abstractions and their Scalability Targets的博客文章指出，单个存储帐户的事务限制为5,000个实体/秒，单个表分区的事务限制为500个实体/秒。为了满足第一个限制，一个人应该使用多个帐户，对于分区限制，一个人应该仔细设计他们的分区。

我想问其他谁有经验的5000限制到一个单一的存储帐户。现在，我正在设计一个博客/维基社区，假设有一天这个网站变得流行起来，吸引了大量的流量。我是否应该将用户相关的表拆分到一个存储帐户，将博客相关的表拆分到另一个帐户，并将wiki相关的表拆分到另一个帐户，以防止现在出现这种限制？或者我应该在需要时添加更多的帐户，顺便问一下，有没有办法将azure存储表从一个帐户转移到另一个帐户？这篇文章说，当你达到这个限制时，你会得到“503服务器忙”的响应，有没有办法知道限制正在接近，这样我就可以提前做一些事情，而不会导致503错误？

Answer 1

我还没有达到总体的帐户限制，但我已经达到了队列上的事务数量限制，因为我试图将从队列中读取的工作者角色的数量设置为一个荒谬的级别。

据我所知，没有“你即将达到极限”的警告。当你第一次知道你已经达到了极限，你就会得到503错误。

在将数据从一个帐户转移到另一个帐户时，没有内置的功能可以为您完成此操作。您要么必须使用自己的解决方案来读取源表中的每一行并将其写入目标表，要么使用类似于Cerebrata Cloud Storage Studio的东西，它允许您下载和上传表的内容或它们的CMDLTS，让您可以做同样的事情，但更便宜/免费。

如果你刚刚开始，并且你有合理的方式在存储帐户之间划分数据，并且它不会使代码太复杂，那么就去做吧。但在这个阶段，我不会太担心它。如果您的站点确实变得流行起来，并且您开始达到事务限制，那么它很可能来自一个您没有预料到的区域，或者可能来自于一个表的太多事务。正如你所说的，这是一个博客社区，最有可能获得最多交易的区域是你存储评论的地方。如果您的comments表每秒获得超过5000个事务，则可能需要跨多个存储帐户对注释进行分区。当然，如果博客如此受欢迎，你也有可能有其他问题要处理。

Answer 2

如果您追求的是可伸缩性，那么您可以考虑Sql Azure联合，而不是Azure表存储。联邦功能已经从2011年12月开始可用。你可以找到一个很好的概述here。

使用Sql Azure Federations，您可以更好地控制您正在使用的资源量。在表存储中，鼓励您创建多个分区，以便底层引擎可以在某一时刻将您的数据分布到多台机器上，从而提高吞吐量。但是，分区只是对表存储引擎的一个提示。它不一定会将数据移动到新机器上。根据使用情况和内部算法，它可能会这样做，但您永远不能确定它何时会这样做。使用Sql Azure Federations，您可以控制您正在使用的实例的数量。您将控制少量实例(=小成本)和大量实例(=大吞吐量)之间的平衡。

使用联邦，您仍然可以享受到关系数据库的大部分好处。也就是说，您仍然可以拥有事务、连接和索引。事实上，您可以拥有来自独立Sql Azure数据库的所有功能。唯一的限制是您一次只能操作一个联合实例(目前没有内置的跨实例选择联合内的支持)。

确实，您可以通过创建多个帐户来提高表存储的吞吐量，但您必须手动进行管理。您将负责在进行拆分时在帐户之间移动数据，并负责实现应用程序级逻辑，以便在搜索某些数据时路由到正确的帐户。这是由联邦自动管理的。

考虑表存储的唯一原因可能是它的每GB价格比Sql Azure低得多(表存储定价描述为here，Sql Azure定价描述为here)。因此，如果您正在考虑存储大量数据，那么您确实可以考虑表存储(只要您能接受它的限制)。

严格地从吞吐量的角度来看，Sql Azure的单个实例可以提供与Table Storage帐户类似的性能。只要您能够获得请求的良好分布，使用联邦，您就可以将单个数据库的吞吐量乘以所用实例的总数。

如果您对一些数字感兴趣，几个月前我做了一个基准测试，并在联邦数据库上运行它。结果可以在here上找到。