有很多小的Azure存储Blob容器（每个都有一些Blob）还是一个有很多Blob的真正大容器更好？

因此，情况如下：

我有一个Web服务的多个实例，该实例将一滴数据写入Azure存储。我需要能够将blob分组到一个容器（或虚拟目录）中，具体取决于何时接收。偶尔（每天在最坏的情况下）旧的Blob将得到处理，然后删除。

我有两个选择：

选项1

我制作了一个名为“ blobs”的容器（例如），然后将所有博客存储到该容器中。每个Blob将使用目录样式名称，其中目录名称为接收时间（例如“ hr0min0 / data.bin”，“ hr0min0 / data2.bin”，“ hr0min30 / data3.bin”，“ hr1min45 / data.bin”） ，...，“ hr23min0 / dataN.bin”等-每X分钟创建一个新目录）。处理这些Blob的事物将首先处理hr0min0 Blob，然后处理hr0minX，依此类推（并且在处理Blob时仍在写入它们）。

选项2

我有很多容器，每个容器都有一个基于到达时间的名称（因此，首先是一个名为blobs_hr0min0的容器，然后是blobs_hr0minX等），并且容器中的所有blob都是在指定时间到达的blob。处理这些博客的事物将一次处理一个容器。

所以我的问题是，哪个选项更好？选项2使我的并行化更好（因为容器可以位于不同的服务器中）还是选项1更好，因为许多容器会引起其他未知问题？

我认为这并不重要（从可伸缩性/并行性的角度来看），因为Win Azure Blob存储中的分区是在Blob级别而不是容器上完成的。分布在不同容器中的原因与访问控制（例如SAS）或总存储大小有关。

有关更多详细信息，请参见此处：http : //blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx

（向下滚动到“分区”）。

报价单：

Blob –由于分区键位于Blob名称之下，因此我们可以在多台服务器之间负载均衡对不同Blob的访问，以扩展对它们的访问。这使容器可以根据需要扩展到最大（在存储帐户空间限制内）。折衷方案是我们不提供跨多个Blob进行原子事务的功能。

每个人都为您提供了直接访问Blob的绝佳答案。但是，如果您需要列出容器中的Blob，则多容器模型可能会看到更好的性能。我刚刚与一家公司进行了交谈，该公司一直在一个容器中存储大量blob。他们经常列出容器中的对象，然后对这些Blob的子集执行操作。随着获取完整列表的时间越来越长，他们看到了性能下降。

这可能不适用于您的情况，但需要考虑一下...

从理论上讲，大量容器之间或少量具有更多斑点的容器之间应该没有区别。额外的容器可以作为额外的安全边界（例如，用于公共匿名访问或不同的SAS签名）。修剪时，额外的容器还可以使家务管理更加轻松（删除单个容器而不是针对每个blob）。由于这些原因，我倾向于使用更多的容器（不是出于性能考虑）。

从理论上讲，性能影响不应该存在。Blob本身（完整URL）是Windows Azure中的分区键（已经存在很长时间了）。这是从分区服务器实现负载平衡的最小方法。因此，您可能（并且经常会）在同一容器中有两个不同的Blob，由不同的服务器提供服务。

Jeremy指出，越来越多的容器之间存在性能差异。我还没有深入研究那些基准来解释为什么可能会出现这种情况，但是我怀疑其他因素（例如大小，测试持续时间等）来解释任何差异。

还有另外一个因素可以影响这一点。价钱！

当前操作“列表”和“创建”容器的价格相同：0,054美元/ 10.000个调用

实际上，写入Blob的价格相同。

因此，在极端情况下，如果您创建和删除许多容器，您可能需要支付更多费用

• 免费删除

您可以在此处查看计算器：https : //azure.microsoft.com/en-us/pricing/calculator/