Azure表存储分区设计

Question

我有一些软件可以在很长一段时间内收集数据，大约每秒 200 个读数。它为此使用 SQL 数据库。我希望使用 Azure 将大量旧的“存档”数据移动到其中。

该软件使用多租户类型的体系结构，因此我计划每个租户使用一个 Azure 表。每个租户可能正在监视 10-20 个不同的指标，因此我计划使用 Metric ID (int) 作为分区键。

由于每个指标每分钟只有一个读数（最大值），我计划使用 DateTime.Ticks.ToString("d19") 作为我的 RowKey。

但是，我对这将如何扩展缺乏一点了解；所以希望有人能够解决这个问题：

为了性能，Azure 将/可能按 partitionkey 拆分我的表，以使事情保持良好和快速。在这种情况下，这将导致每个指标有一个分区。

但是，我的 rowkey 可能代表大约 5 年的数据，因此我估计大约有 250 万行。

Azure 是否足够聪明，可以根据行键进行拆分，还是我在设计未来的瓶颈？我通常知道不要过早地进行优化，但是像 Azure 这样的东西看起来不像平常那​​么明智！

正在寻找 Azure 专家，让我知道我是否在正确的路线上，或者我是否也应该将我的数据分区到更多表中。

Answer 1

几个cmets：

除了存储数据之外，您可能还想研究如何检索数据，因为这可能会极大地改变您的设计。您可能想问自己的一些问题：

• 当我检索数据时，我是否总是检索特定指标和日期/时间范围的数据？
• 或者我需要检索特定日期/时间范围内所有指标的数据？如果是这种情况，那么您正在查看全表扫描。显然，您可以通过执行多个查询（一个查询/PartitionKey）来避免这种情况
• 我是否需要先查看最新结果，或者我真的不在乎。如果是前者，那么您的 RowKey 策略应该类似于 (DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks).ToString("d19")。

此外，由于 PartitionKey 是一个字符串值，您可能希望将 int 值转换为带有一些“0”预填充的 string 值，以便您的所有 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。

更新 根据您下面的 cmets 和上面的一些信息，让我们尝试做一些数学运算。这是基于此处发布的最新可扩展性目标：http://blogs.msdn.com/b/windowsazurestorage/archive/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx。该文档指出：

单表分区——一个表分区是一个表中的所有实体 具有相同分区键值的表，通常表有很多 分区。单个表分区的吞吐量目标是：

• 每秒最多 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。

希望这会有所帮助。