9

我对 Azure 存储比较陌生，并且已经实施了一段时间的解决方案。而且我不断遇到障碍，让我觉得我没有为我正在存储的数据应用正确的存储类型。

所以这更像是一个整体问题：

  • 什么时候应该使用 Azure SQL？
  • 何时应使用 Azure 表存储？
  • 何时应使用 Azure Blob？

到目前为止，我一直在使用表存储，现在我正在为此付费。随着解决方案需求的增长，我发现自己无法根据需要访问数据。

例如，我需要获取表中的 50 个最新条目，但我不能在查询中使用 OrderBy。我需要获取条目的总数，但不能使用 Count。

我一直觉得，我计划定期访问的任何数据，但不知道确切的 RowKey 和 PartitionKey 都应该在 Azure SQL 中建立索引，并存储在表中。这个对吗？

我还发现自己将对象重新创建为实体对象，但是由于数据类型的非常严格的限制，我经常最终只是将对象序列化为字节数组。尽管一个表行最多可以容纳 1MB，但该行上的字节数组可能只能容纳 64KB，此时我最终改用 Blob 存储。

所以最后我觉得我最好将所有数据放在 Azure SQL 中并索引更大的数据，但将其保存为 blob。当然，这感觉不太对劲，因为那样会使表存储没有真正的用途。

所以我想知道是否有关于何时使用哪种存储的指南。

就我而言，我在某些区域有非常大量的数据，其中一些占用了相当多的空间（通常超过 64KB），但我还需要非常频繁地访问数据，并且需要能够对其进行过滤和排序通过某些值。

  • 我真的需要索引我计划在 SQL 中访问的所有数据吗？
  • 对于任何可能超过 64KB 的数据，我最好避免使用 Table 吗？

我觉得有些事情我做的不对。我不明白的东西。我在这里想念什么？

4

3 回答 3

5

我能提出的最佳建议基本上是“尽量不要使用 Azure 表存储”。正如其他人所指出的，它不仅仅是一个“No-SQL”数据存储，它是一个特别发育不良、残障且功能非常低的 No-SQL 存储实例。关于它的唯一好处是您可以非常快速地将大量数据放入其中，并且存储费用最低。但是，除非您足够幸运地拥有一个神奇地匹配其分区键/行键存储模型的用例，否则您基本上不能希望再次获取该数据。如果您不这样做 - 我怀疑很少有人这样做 - 您将进行大量分区扫描，并自己处理数据。

除此之外，Azure 表存储在发展方面似乎处于死胡同。如果您查看 Azure 反馈论坛 ( https://feedback.azure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes ) 上的“支持二级索引”请求，您可以看到对二级指数早在 2011 年就已承诺，但没有取得任何进展。对表存储的任何其他最高请求也没有任何进展。

现在，我知道 Scott Guthrie 是一个有质量的人，所以我希望表存储方面的所有这些停滞不前是 Azure 修复它并提出一些非常酷的东西的序言。这是我的希望（尽管我的证据为零）。但就目前而言，除非您别无选择，否则我强烈建议您不要使用 Azure 表存储。使用 Azure SQL；使用您自己的 MongoDB 实例或其他 No-SQL DB；或使用 Amazon DynamoDB。但不要使用 Azure 表存储。

编辑：2014-10-09 - 被迫进入需要使用它的场景，我稍微修改了对 Azure 表存储的看法。事实上，它确实有我上面提到的所有令人遗憾的限制，但它也有它的（有限的）用途。我在这里的一篇博文中对它们有所了解。

编辑：2017-02-09 - 不，ATS 仍然很糟糕。避开它。它在 7 年多的时间里没有显着改善，MS 显然希望它会消失。它可能应该 - 他们大概只为那些最初犯下错误投注的人保留它。

于 2013-09-20T21:50:23.470 回答
1

看看这个：Windows Azure 表存储和 Windows Azure SQL 数据库 - 比较和对比

不包括斑点，但无论如何都很好读...

于 2013-05-11T02:37:44.913 回答
1

我一直觉得，我计划定期访问的任何数据，但不知道确切的 RowKey 和 PartitionKey 都应该在 Azure SQL 中建立索引，并存储在表中。这个对吗？

表存储不支持二级索引，因此任何有效的查询都应该包含 RowKey 和 PartitionKey。可以有一些变通方法，例如使用不同的 RowKey 在同一个表中保存相同的数据两次。然而，这很快就会成为一种痛苦。如果最终的一致性是好的，那么你可以这样做。您需要处理事务和回滚。

就我而言，我在某些区域有非常大量的数据，其中一些占用了相当多的空间（通常超过 64KB），但我还需要非常频繁地访问数据，并且需要能够对其进行过滤和排序通过某些值。

将表存储用于基本的 NoSQL 功能和快速扩展的能力。但是，如果您想要二级索引和其他此类功能，您可能需要查看 AWS 上的 DynamoDB 之类的东西，afaik 似乎对二级索引等有更好的支持。如果您的数据具有复杂的关系，换句话说，数据需要与 SQL Azure 一起使用的 RDBMS。

现在，就您在 Azure 上的选择而言，我认为您需要将所有内容存储在 SQL Azure 上，并将大型对象存储为 blob 或表存储。

我真的需要索引我计划在 SQL 中访问的所有数据吗？

很难说。如果每个分区只包含 100 行，那么您可以按分区键和任何列进行查询。此时分区扫描将非常快。但是，如果您有一百万行，那么这可能是一个问题。

我觉得有些事情我做的不对。我不明白的东西。我在这里想念什么？

一群早期的 Azure 用户开始使用表存储时并不了解 NoSQL（在这种情况下是一个特别发育不良的 NoSQL 版本）的含义。

于 2013-05-11T04:22:22.707 回答