3

Microsoft 更改了 Azure 存储的体系结构以使用例如。SSD 用于日志和 10 Gbps 网络（而不是标准硬盘和 1G ps 网络）。搜索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 个实体 pr。其次，读取所有行需要半天以上的时间。

我真的希望 20.000 个实体实际上意味着您最多可以执行 20.000 个请求。第二。

我很确定第一代最多允许 5.000 个请求。第二。

所以我的问题是。是否存在第一代 Azure 存储实际上比第二代更具可扩展性的场景？

还有任何其他我们不应该升级的原因（将我们的数据移动到新的存储）？例如。我们试图获得约 100 行公关。分区，因为这给了我们最好的性能特征。2代有不同的特点吗？或者如果我们进行更改，是否有任何更改可能会引入错误？

4

1 回答 1

1

你必须更仔细地阅读。提到的帖子的确切报价是：

事务– 每秒最多 20,000 个实体/消息/blob

这是每秒 20k 事务。你希望哪一个是正确的。我当然不希望有 20k 1M 文件上传到 blob 存储。但我确实希望能够执行 20k REST 调用。

至于表和表实体，可以批量组合。鉴于您拥有的数量，我希望您已经在使用批次。有单个实体组交易被视为单个交易，但可能包含多个实体。现在，与其评估它是低还是高，您确实需要一个良好的设置和带宽来利用每秒 20k 的事务。

此外，第一代可扩展性目标大约是您提到的 5k 请求/秒。我没有看到第 1 代存储比第 2 代存储更具可扩展性的配置/场景。

2代有不同的特点吗？

您参考的博客文章中概述了这些差异。

至于你的最后一个问题：

或者如果我们进行更改，是否有任何更改可能会引入错误？

确保没有这样的变化。Azure 存储服务行为在REST API 参考中定义。API 基于存储服务生成没有任何不同。它基于功能进行版本控制。

于 2012-11-05T10:56:03.823 回答