正确使用Azure存储.(何时使用SQL,表和Blob)

我对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吗？

我觉得我做得不对劲.我不明白的东西.我在这里错过了什么？

我可以提出的最佳建议基本上是“尽力不使用Azure表存储”。正如其他人指出的那样，它不仅是“ No-SQL”数据存储，它还是No-SQL存储的特技，残障和功能很低的实例。关于它的唯一好处是，您可以非常快速地将大量数据放入其中，而存储费用却很少。但是，除非您很幸运地拥有一个魔术匹配其Partition-Key / Row-Key存储模型的用例，否则您基本上不希望再次获得该数据。如果您不这样做（我怀疑很少有人这样做），那么您将要进行很多分区扫描，并自己处理数据。

除此之外，Azure表存储在开发方面似乎处于死胡同。如果您在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实例或其他一些No-SQL DB；或使用Amazon DynamoDB。但是不要使用Azure表存储。

编辑：2014-10-09-被迫进入需要使用它的方案后，我对Azure Table Storage的看法有所修改。实际上，它确实具有我上面提到的所有令人遗憾的限制，但它也有其（有限的）用途。我在这里的博客文章中对它们进行了一些探讨。

编辑：2017-02-09-不，ATS仍然很糟糕。避开它。在过去的7年中，它并没有明显改善，MS显然希望它会消失。而且可能应该-他们可能只是将其保留给那些最初将赌注错误的人保留下来。