Microsoft已将Azure存储的体系结构更改为使用，例如。 SSD用于日志和10 Gbps网络（而不是标准硬盘和1G ps网络）。 Se http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx
在这里，您可以看到存储设计为“每秒最多20,000个实体/消息/ blob”。
我担心的是，20.000个实体（或表存储中的行）实际上不是很多。
我们有一个相当小的解决方案，其中包含一个1.000.000.000行的表。只有20.000个实体。第二，读取所有行需要半天以上。
我真的希望20.000个实体实际上意味着你可以做多达20.000个请求。第二
我很确定第一代允许最多5.000个请求。第二
所以我的问题是。是否存在第一代Azure存储实际上比第二代更具可扩展性的情况？
我们不应该升级任何其他原因（将我们的数据移动到新存储）？例如。我们试着得到~100行pr。分区，因为这是给我们最好的性能特征。第二代有不同的特点吗？或者，如果我们改变，是否有任何可能引入错误的变化？
答案 0 :(得分：1)
你必须仔细阅读。上述帖子的确切引用是：
交易 - 每秒最多20,000个实体/消息/ blob
这是每秒20k的交易量。你正确地希望做到这一点。我当然不希望将20k 1M文件上传到blob存储。但我确实希望能够执行20k REST调用。
对于表和表实体，您可以将它们组合在batches中。考虑到您的体积，我预计您已经在使用批次。单个实体组事务被计为单个事务，但可能包含多个实体。现在，而不是评估它是低还是高数字，你真的需要一个良好的设置和带宽来每秒利用这20k交易。
此外，第一代可扩展性目标大约是您提到的5k请求/秒。我没有看到Gen 1比Gen 2存储更具可扩展性的配置/场景。
第二代有不同的特点吗？
您引用的博文中概述了差异。
关于你最后的担忧：
或者，如果我们改变，是否有任何可能引入错误的更改？
确保没有这样的变化。 Azure存储服务行为在REST API Reference中定义。基于存储服务生成，API没有任何不同。它基于功能进行版本控制。