azure - Azure表存储分区设计

Question

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

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

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

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

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

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

Azure 是否足够聪明，可以根据行键进行拆分，还是我在设计 future 的瓶颈？我知道通常不要过早优化，但使用像 Azure 这样的东西似乎并不像平常那​​样明智!

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

Answer 1

一些评论:

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

• 当我检索数据时，我是否总是检索特定指标和日期/时间范围的数据？
• 或者我需要检索特定日期/时间范围内所有指标的数据？如果是这种情况，那么您正在考虑全表扫描。显然，您可以通过执行多个查询(一个查询/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 .

更新根据您下面的评论和上面的一些信息，让我们尝试做一些数学计算。这是基于此处发布的最新可扩展性目标: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 table partition are all of the entities in a table with the same partition key value, and usually tables have many partitions. The throughput target for a single table partition is:

• Up to 2,000 entities per second
• Note, this is for a single partition, and not a single table. Therefore, a table with good partitioning, can process up to the 20,000 entities/second, which is the overall account target described above.

现在您提到您有 10 - 20 个不同的指标点，对于每个指标点，您每分钟最多写入 1 条记录，这意味着您每分钟/表最多写入 20 个实体，即远低于每秒 2000 个实体的可扩展性目标。

现在的问题仍然是阅读。假设用户最多可以读取每个分区 24 小时的数据(即 24 * 60 = 1440 点)。现在假设用户获取 1 天的所有 20 个指标的数据，则每个用户(因此每个表)最多将获取 28,800 个数据点。我想留给您的问题是每秒可以收到多少个这样的请求才能满足该阈值。如果您能够以某种方式推断此信息，我认为您可以得出有关架构的可扩展性的一些结论。

我还建议您观看此视频:http://channel9.msdn.com/Events/Build/2012/4-004 .

希望这有帮助。