我一直在阅读如何对Azure表存储进行分区以确保高性能。我想知道我提出的策略是否能够为数据存储提供高效，可扩展的插入和简单查询。
我有1000个不同的进程，每30秒将一小段数据（~50个字节）上传到AZT。我的查询几乎总是简单地按流程和时间查询。例如，我想在给定日期从晚上7点到晚上9点查询所有进程A的日志。
我建议的策略是为每个进程创建一个表（1000个表），然后对行进行分区，使每个分区包含6个小时的数据（每天4个新分区，每个分区720个行）。分区键'NOV82012-0'将包含从11月8日午夜到早上6点的720行。 'NOV82012-1'将包含6 AM-Noon等...
这应该确保我在任何分区中总是少于1000行，这样我就不必担心持续令牌了。我也可以通过进程轻松“过滤”，因为每个进程的数据都有自己的表。
这是这种情况的理想策略吗？我错过了什么吗？
答案 0 :(得分：2)
实际上，如果您使用的是.NET SDK，则无需担心延续令牌。通过在查询上调用AsTableServiceQuery()，您将获得一个自动处理延续令牌的对象。
根据您的意思，您希望根据以下几个标准进行过滤：
我真的没有必要为每个进程创建一个表。您可以使用组合键对其进行分区：Process + Date。一个例子：
通过将流程名称与您可以坚持使用单个表格的日期相结合，只是为了简化操作。现在关于行，每个分区有超过1000个项目是可以的。在同一分区中拥有给定日期的所有行的优点是，您可以根据行键轻松选择该分区中的范围（这是半伪代码，不测试它 - 您可能希望改进rowkeys）。
from item in context.CreateQuery<XXX>("XXX")
where item.PartitionKey == "A_20121108" && item.RowKey.CompareTo("20121108120000") >= 0 && item.RowKey.CompareTo("20121108193000") <= 0
select item;
答案 1 :(得分：1)
我同意桑德里诺的建议，即在所有流程中使用单一表格。
ATS做得不好的一件事是支持删除。考虑到这一点，我建议按表级别的时间范围进行分区。这样，一旦您不需要该时间范围的数据，就可以删除该表。
然后可以使用键控结构
表名=前缀+ YYYYMM（年和月）
示例Process201211
PKey =处理+ DDHHMM（日期，小时和分钟）
例A081834，B122359等
RKey =秒或亚秒。
如果您无法保证亚秒的唯一性，请考虑附加GUID