我使用Azure表存储作为时间序列数据库。数据库不断扩展，有更多行（每个分区大约每秒20行）。每天我都会为当天的数据创建新分区，以便所有分区都具有相似的大小，并且永远不会太大。
到目前为止，一切工作都完美无缺，当我想从特定分区检索数据时，1000个值的时间绝对不会超过2.5秒，平均需要1秒。
当我尝试查询分区的所有数据时，虽然事情变得非常慢，但在程序的中间，每个查询需要30-40秒才能获得1000个值。
所以我取消了这个程序只是为了重新启动它的范围更小。但现在所有查询都需要很长时间。从一开始，所有查询都需要15-30秒。这是否意味着数据以非有效的方式重新排列，这就是为什么我看到性能急剧下降的原因？如果是，是否有办法处理这种重新排列？
答案 0 :(得分：3)
我肯定会建议你仔细阅读Jason上面提到的链接。你没有提供太多关于如何生成分区键的详细信息，但是从它的声音来看，你会陷入几种反模式。包括在单个分区中应用Append（或Prepend）和太多实体。我建议你减少分区大小，并在分区键中加上哈希或随机前缀，这样它们就不会按字典顺序排列。
Azure存储在后台遵循范围分区方案，因此即使您选择的分区键是唯一的，如果它们是顺序的，它们将落入相同的范围并可能由单个分区服务器提供服务，这会妨碍总体来说，天蓝色存储服务能够实现负载平衡并扩展存储请求。
你应该想到的另一个方面是你如何回读实体，最好的建议是用分区键和行键进行点查询，最差的是没有PK和RK的全表扫描，中间你有分区扫描哪种情况下由于您的分区大小，性能也会非常糟糕。
答案 1 :(得分：2)
时间序列数据的挑战之一是您最终可以将所有数据写入单个分区，从而防止Table Storage分配额外资源以帮助您扩展。类似地，对于读取操作，您可能会将所有数据放在一个分区中，这意味着您的数据限制为每秒2000个实体 - 而如果您将数据分布在多个分区中，则可以并行化查询并产生更大的规模。
您是否启用了存储分析？我很想知道你是否受到了所有人的扼杀或可能发生的其他潜在问题。有关详细信息，请查看Storage Monitoring, Diagnosing and Troubleshooting指南。
如果您仍然无法找到所需信息，请发送电子邮件至AzTableFeedback@microsoft.com，我们很乐意与您联系。
Azure Storage Table Design Guide讨论了一般可扩展性指南以及模式/反模式（参见附加反模式以获得良好的概述），值得一看。