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

Question

我对Azure存储相对来说比较陌生，现在已经实施了一段时间的解决方案。 我一直在碰撞障碍，让我觉得我没有为我存储的数据应用正确的存储类型。

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

• 我什么时候应该使用SQL Azure的？
• 什么时候应该使用Azure Table存储？
• 什么时候应该使用Azure Blobs？

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

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

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

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

因此，最终我觉得将我的所有数据放入Azure SQL并索引更大的数据，但将其保存为斑点会更好。 当然这并不完全正确，因为这会使表格存储没有真正的目的。

所以我想知道是否有任何指导什么时候使用哪种存储。

在我的情况下，我在一些地区的数据量非常大，其中一些消耗了相当多的空间（通常高于64KB），但我也需要非常频繁地访问数据，并且需要能够过滤并按特定值排序。

• 我真的需要索引我计划在SQL中访问的所有数据吗？
• 如果数据可能超过64KB，我会避免使用Table吗？

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

Answer 1

我一直得到的印象是，任何数据我计划定期访问不知道确切的RowKey和PartitionKey应该在Azure SQL中编入索引并存储在表中。它是否正确？

表存储不支持二级索引，所以任何有效的查询都应该包含RowKey和PartitionKey。可以有解决方法，例如使用不同的RowKeys在同一个表中保存相同的数据两次。然而，这很快就会变成一种痛苦。如果最终的一致性是好的，那么你可以做到这一点。你需要关心交易和回滚。

就我而言，我在某些领域的数据量非常大，其中一些消耗了相当大的空间（通常高于64KB），但我也需要非常频繁地访问数据，并且需要能够过滤并按特定值排序。

使用表存储实现基本的NoSQL功能并能够快速扩展。但是，如果您需要辅助索引和其他此类功能，则可能需要查看AWS上的DynamoDB等类似的功能，afaik似乎对二级索引等有更好的支持。如果您的数据具有复杂的关系（换言之，数据需要一个RDBMS与SQL Azure一起使用。

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

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

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

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

一些早期的Azure用户开始使用表存储而不理解NoSQL（在这种情况下是NoSQL的一个特别发育迟缓的版本）所需要的。

Answer 2

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

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

Answer 3

我可以做的最好的建议基本上是“尽量不要使用Azure表存储”。正如其他人已经指出的那样，它不仅仅是一个“无SQL”数据存储，它是一个非SQL存储的特别发育迟缓，有障碍且功能非常低的实例。关于它的唯一好处是，您可以非常快速地将大量和大量数据加入其中，并且只需极少的存储费用。但是，除非足够幸运地拥有奇迹般匹配分区键/行键存储模型的用例，否则基本上不能希望再次获取这些数据。如果你不这样做 - 而且我怀疑很少有人会这样做 - 你将会进行大量的分区扫描，并自己处理数据。

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

现在，我知道Scott Guthrie是一位高素质的人，所以我希望Table Storage的所有这些停滞都是Azure修复它的前奏，并且提供了一些非常酷的东西。这是我的希望（尽管我没有这方面的证据）。但现在，除非你没有选择，否则我强烈建议不要使用Azure Table Storage。使用Azure SQL;使用您自己的MongoDB实例或其他一些非SQL数据库;或使用Amazon DynamoDB。但不要使用Azure表格存储。

编辑：2014-10-09 - 已被迫进入需要使用它的场景，我稍微修改了我对Azure Table Storage的看法。事实上，我确实有上述所有令人遗憾的限制，但它也有其（有限的）用途。我在博客文章here上进行了一些讨论。

编辑：2017-02-09 - Nah，ATS仍然很糟糕。避开它。它在7年以上没有显着改善，MS显然希望它会消失。它可能应该 - 他们大概只是为了让原本打赌的人犯错。