正确使用Azure存储。 （何时使用SQL，表和Blob）

Question

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

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

• 我应该何时使用Azure SQL？
• 我应该何时使用Azure Table存储？
• 我应该何时使用Azure Blob？

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

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

我一直认为，我计划在不知道确切的RowKey和PartitionKey的情况下定期访问的任何数据应该在Azure SQL中编制索引，并存储在表中。这是对的吗？

我也发现自己将对象重新创建为Entity对象，但是由于对数据类型的严格限制，我经常最终只是将对象序列化为字节数组。虽然表行最多可容纳1MB，但该行上的字节数组可能只能容纳64KB，此时我最终会使用Blob存储。

所以最后我觉得如果把所有数据放在Azure SQL中并将较大的数据编入索引但将其保存为blob会更好。 当然，这感觉不太对，因为这会使Table存储没有真正的目的。

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

在我的情况下，我在某些区域拥有非常大量的数据，其中一些占用了相当大的空间（通常高于64KB），但我还需要非常频繁地访问数据，并且需要能够过滤并按某些值排序。

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

我觉得我做得不对劲。我不明白的东西。我在这里缺少什么？

Answer 1

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

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

现在，我知道Scott Guthrie是一个优秀的人，所以我希望桌面存储方面的所有这些停滞都是Azure修复它并提出一些非常酷的前言。这是我的希望（虽然我没有证据证明是这种情况）。但是现在，除非你没有选择，否则我强烈建议不要使用Azure Table Storage。使用Azure SQL;使用您自己的MongoDB实例或其他一些No-SQL DB;或使用Amazon DynamoDB。但是不要使用Azure表存储。

编辑：2014-10-09 - 我被迫进入需要使用它的场景，我稍微修改了我对Azure Table Storage的看法。事实上它确实具有我在上面归于它的所有令人遗憾的限制，但它也有其（有限的）用途。我在博客here上稍微介绍了一下。

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

Answer 2

看看这个：Windows Azure Table Storage and Windows Azure SQL Database - Compared and Contrasted

不包括blob，但无论如何都是一个很好的阅读...

Answer 3

我一直认为，我计划在不知道确切的RowKey和PartitionKey的情况下定期访问的任何数据应该在Azure SQL中编制索引，并存储在表中。这是正确的吗？

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

在我的情况下，我在某些区域拥有非常大量的数据，其中一些占用了相当大的空间（通常高于64KB），但我还需要非常频繁地访问数据需要能够按特定值对其进行过滤和排序。

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

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

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

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

我觉得我做得不对劲。我不明白的东西。我在这里缺少什么？

一群早期的Azure用户开始使用Table Storage而不了解NoSQL（在这种情况下是NoSQL特别令人沮丧的版本）的含义。