问题描述
|
我有一个Windows Azure应用程序，其中对TableA的所有读取查询都在单个分区上针对一定范围的行键执行。实际上，促进此存储方案的分区键实际上是分层结构中对象的名称，因此分区键的格式类似于“ 0”。我可以理解，通过在表的命名中使用分区键的根维度（将分区键变为A1ѭ），将一个大的TableA分成许多表可能会有什么好处。
我想做的是尽可能从同一时间从尽可能多的连接中快速访问此数据。如果我能弄清楚这些限制是什么或者应该是什么，那也将是不可思议的。
有关我建议的更改的更具体的问题：
这是否会在可伸缩性方面有所不同，即在不显着提高性能的情况下可以满足的同时数据访问请求的数量？可以同时服务吗？
这会影响平均表现吗？潜在的表现？
解决方法
如果每个查询都指定一个分区键，那么这些分区分布在多少个表上就没有关系。换句话说，以下内容是等效的：一个表具有一千个分区，而一千个表具有一个分区。
我可以考虑考虑拆分成多个表的主要原因是，您可以在单个操作/事务中删除整个表，而不能在同一表中使用多个分区来删除整个表。这意味着对于日志之类的东西，您可能希望在一段时间后删除较旧的那些，通常最好在不同的时间范围内使用不同的表。
, +1为史蒂夫的答案。
一些要添加的东西
可能值得考虑使用多个存储帐户-因为当前是可扩展性的存储帐户-每个存储帐户的官方目标是每秒约5000个实体/事务，因此，如果您想要高于此数目，则需要使用多个帐户。
关于如何查询数据，性能上有一些微妙的细节-如果项目不在同一个分区中，则通常可以更快地执行单独的并行查询，而不是使用复杂的where参数执行单个查询。
您可能会发现存储团队博客上的博客帖子特别有用-http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows- azure-tables.aspx和http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx
您可能还需要了解这些费用-每100万次点击大约1美元。