Windows Azure Storage Abstractions and their Scalability Targets博客帖子表明单个存储帐户有5,000个实体/秒的事务限制，单个表分区有500个实体/秒限制。为了达到第一个限制，应该使用多个帐户，对于分区限制，应该仔细设计它们的分区。
我想问一下对单个存储帐户有5000限制经验的其他人。现在，我正在设计一个博客/维基社区，并说有一天该网站变得流行并吸引了大量的流量。我应该将用户相关的表分成一个存储帐户和博客相关的表到另一个帐户，而将wiki相关的表拆分到另一个以防止此限制吗？或者我应该在需要时添加更多帐户，顺便提一下有办法将azure存储表从一个帐户转移到另一个帐户吗？文章说，当你达到这个限制时，你会得到“503服务器忙”的响应，有没有办法知道限制越来越近所以我可以提前做一些事情而不会导致503错误？
答案 0 :(得分：4)
我没有达到整体的帐户限制，但是我已经达到了Queue上的事务数限制，试图将从该队列读取的工作者角色数设置为荒谬的级别。
据我所知，没有“你即将达到极限”的警告。第一次知道你达到了极限时，你会得到503错误。
将数据从一个帐户传输到另一个帐户时，没有内置功能可以为您完成。您必须使用自己的解决方案来读取源表中的每一行并将其写入目标表，或者使用Cerebrata Cloud Storage Studio之类的内容，它允许您下载和上载表的内容或其CMDLTS。 3}}让你做同样的事情，但更便宜/自由。
如果您刚刚开始，并且您有逻辑方法跨存储帐户划分数据，并且它不会使代码过于复杂，那么就这样做。但在这个阶段我不会太担心。如果您的网站确实变得流行并且您开始达到交易限制，则可能来自您没有预料到的区域，或者可能来自太多交易到仅一个桌面的区域。正如你所说的那样，这是一个博客社区，可能获得最多交易的领域是你存储评论的地方。如果您的评论表每秒获得超过5000笔交易，则可能需要在多个存储帐户中对评论进行分区。当然，如果博客很受欢迎，那么你也有可能遇到其他问题。
答案 1 :(得分：1)
如果您正在使用可伸缩性，则可以考虑使用Sql Azure Federations而不是Azure Table Storage。联盟功能自2011年12月开始提供。您可以找到一个好的概述here。
使用Sql Azure Federations，您可以更好地控制所使用的资源量。在表存储中，建议您创建许多分区，以便底层引擎可以在某些时候将数据分布在多台计算机上，从而获得更高的吞吐量。但是，分区只是表存储引擎的提示。它不一定会将数据移动到新机器上。它可能会根据使用情况及其内部算法执行此操作，但您无法确定何时执行此操作。使用Sql Azure Federations，您可以控制正在使用的实例数。您将控制少量实例（=小成本）和大量实例（=大吞吐量）之间的平衡。
使用联盟，您仍然可以享受关系数据库带来的大部分好处。那就是你仍然可以拥有事务，联接，索引。实际上，您可以从独立的Sql Azure数据库中获得所有功能。唯一的限制是您一次只能对一个联合实例执行操作（此时联合实体中没有内置的跨实例选择支持）。
确实，您可以通过创建多个帐户来增加表存储的吞吐量，但您可以手动进行管理。您将负责在进行拆分时在帐户之间移动数据以及实现在搜索特定数据时将路由到正确帐户的应用程序级逻辑。这是使用联盟自动管理的。
考虑表存储的唯一原因可能与其价格/ GB有关，与Sql Azure相比要低得多（表格存储定价为here，Sql Azure定价描述为here）。因此，如果您正在考虑存储大量数据，那么您可能确实会考虑表存储（只要您能够忍受其限制）。
严格地说，从吞吐量角度来看，Sql Azure的单个实例可以提供与表存储帐户类似的性能。只要您可以获得良好的请求分布，使用联盟可以将单个数据库的吞吐量乘以已使用实例的总数。
如果您对某些数字感兴趣，几个月前我已经制定了一个基准测试并针对联合数据库运行它。结果可以找到here。