我有一些软件在很长一段时间内收集数据，大约每秒200个读数。它为此使用SQL数据库。我希望使用Azure将我的许多旧的"存档"数据迁移到。
该软件使用多租户类型架构，因此我计划每个租户使用一个Azure Table。每个租户可能正在监视10-20个不同的度量，因此我计划使用度量ID (int)作为分区键。
由于每个指标每分钟只有一个读数(最大)，我计划使用DateTime.Ticks.ToString("d19")作为我的RowKey。
我缺乏一点理解，这将如何扩大然而;所以我希望有人能澄清一下:
为了性能，Azure将/可能通过分区键拆分我的表，以保持事情的美观和快速。在这种情况下，这将导致每个指标一个分区。
然而，我的rowkey可能表示大约5年的数据，所以我估计大约有250万行。
Azure是否足够聪明，可以基于rowkey进行拆分，还是我在设计未来的瓶颈?我知道通常不会过早地优化，但像Azure这样的东西似乎不像正常那样明智!
寻找Azure专家让我知道我是否在正确的行，或者我是否应该将我的数据分区到更多的表
注释:
除了存储数据之外，您可能还需要考虑如何检索数据，因为这可能会大大改变您的设计。你可能想问自己一些问题:
- 当我检索数据时，我是否总是检索特定指标和日期/时间范围的数据?
- 或者我需要检索特定日期/时间范围内所有指标的数据?如果是这种情况，那么您将看到全表扫描。显然，您可以通过执行多个查询(一个查询/PartitionKey) 来避免此问题。
- 我需要先看到最新的结果吗?或者我真的不在乎。如果是前者，那么你的RowKey策略应该是
(DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks).ToString("d19")。
另外，由于PartitionKey是一个字符串值，您可能希望将int值转换为string值，并添加一些"0"前缀，以便所有id按顺序出现，否则您将获得1,10,11，…， 19, 2，…等
据我所知，Windows Azure仅基于PartitionKey而不是RowKey对数据进行分区。在一个分区内，RowKey作为唯一键。Windows Azure将尝试在同一节点中保留具有相同PartitionKey的数据，但由于每个节点都是一个物理设备(因此有大小限制)，数据也可能流向另一个节点。
你可能想阅读这篇来自Windows Azure存储团队的博客文章: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/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx。文档说明:
Single Table Partition—一个表分区是a中的所有实体表有相同的分区键值，通常表有很多分区。单个表分区的吞吐量目标是:
- 每秒多达2,000个实体
- 注意，这是针对单个分区，而不是单个表。因此，一个表具有良好的分区，可以处理到20,000个实体/秒，这是描述的总体帐户目标以上。
现在您提到您有10 - 20个不同的度量点，并且对于每个度量点，您将每分钟最多写入1条记录，这意味着您将最多写入20个实体/分钟/表，这远远低于2000个实体/秒的可伸缩性目标。
现在的问题仍然是阅读。假设用户每个分区最多读取24小时的数据(即24 * 60 = 1440点)。现在假设用户在1天内获取所有20个指标的数据，那么每个用户(因此每个表)最多将获取28,800个数据点。留给你的问题是你每秒能收到多少这样的请求来满足这个阈值。如果您能以某种方式推断这些信息，我认为您可以得出一些关于架构可伸缩性的结论。
我也推荐大家看这个视频:http://channel9.msdn.com/Events/Build/2012/4-004.