azure - Window Azure 表存储查询性能

Question

因此，我请求运行基于 azure 表存储的报告，经过漫长的提炼报告过程后，我获得了数据。然而，当我完成控制台应用程序的重构后，有些事情让我感到不舒服。我使用 azure 的时间并不长，但我有一个基本概念:您选择用作 PartitionKey 和 RowKey 的内容要么会创建一个表，要么会破坏一个表(最终)。

我运行的查询使用时间戳(对我使用此字段的原因有限制)作为过滤器来拉回一天的数据，因为 PartitionKey 和 RowKey 未知。据我了解，如果运行没有 PK 和 RK 的查询，这将导致查询运行整个表(如果我错了，请纠正我)。导致查询的获取时间非常短。

使用时间戳让我感到紧张，因为它属于表，并且每次该条目发生变化时都会不断更新。现在考虑到这一点，报告可能需要几个小时才能运行。这引出了我的主要问题。

如果在查询过程中一系列条目在提取过程中发生更改，会发生什么情况？

以这个场景为例:

• 我的表格中有 100 个条目。
• 我目前排在第 50 名。

当我访问第 50 个条目时，条目 1-20 已更新，条目 80-100 已更改。

我会得到什么类型的数据？(我相信我得到了 80-100 的更新条目，但仍然保留 1-20 的旧数据)。

Answer 1

如果我错了，请纠正我，但是在没有 PK 和 RK 的情况下运行查询会导致查询的获取时间非常糟糕。

这是一个严重的反模式。最有效的查询是对 PK 和 RK 的点查询。提供 PK 至少会强制查询进入一个分区或计算节点。提供两者都不能保证全表扫描。与许多 NoSQL 存储一样，围绕查询性能设计数据模型至关重要。通过对 PK 和 RK 的控制，您可以将时间戳注入(inject)其中，同时保持了解另一个反模式仅附加写入到单个分区的情况。例如，如果您将 PK 基于每日或每小时存储桶并且仅将数据插入到单个存储桶中，就会发生这种情况。