7

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

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

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

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

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

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

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

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

4

1 回答 1

19

几点评论：

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

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

此外，由于 PartitionKey 是一个字符串值，您可能希望将int值转换为string带有一些“0”预填充的值，以便您的所有 id 按顺序显示，否则您将获得 1、10、11、..、19、2、.. ..ETC。

据我所知，Windows AzurePartitionKey仅基于而不是基于RowKey. 在分区内，RowKey用作唯一键。Windows Azure 将尝试PartitionKey在同一个节点中保持相同的数据，但由于每个节点都是一个物理设备（因此具有大小限制），因此数据也可能会流向另一个节点。

您可能想阅读 Windows Azure 存储团队的这篇博文：http: //blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-天蓝色表.aspx。

更新 根据您在下面的评论和上面的一些信息，让我们尝试做一些数学运算。这是基于此处发布的最新可扩展性目标：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 。

希望这可以帮助。

于 2013-04-04T11:04:25.757 回答