azure-sql-database - 正确使用Azure存储。 (何时使用SQL，表和Blob)

Question

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

因此，这更多是一个总体问题:

我应何时使用Azure SQL？

什么时候应该使用Azure表存储？

什么时候应该使用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表存储在开发方面似乎处于死胡同。如果您在Azure反馈论坛(https://feedback.azure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes)上查看“支持二级索引”请求，则可以看到，对二级索引的支持早在2011年就已 promise ，但尚未取得任何进展。在其他任何对“表存储”的最高要求上也没有取得任何进展。

现在，我知道Scott Guthrie是一个高素质的人，所以我希望Table Storage方面的所有停滞都是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显然希望它会消失。而且可能应该-他们可能只是将其保留给那些最初将赌注错误的人保留下来。