拥有许多小型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,那么使用many-container模型可能会看到更好的性能.我刚刚和一家公司谈过,他们在一个容器中存放了大量的blob.它们经常列出容器中的对象,然后对这些blob的子集执行操作.由于检索完整列表的时间越来越长,他们看到了性能损失.

这可能不适用于您的方案,但需要考虑......

从理论上讲,许多容器或更少的容器与更多的容器之间应该没有区别.额外的容器可以作为额外的安全边界(例如,用于公共匿名访问或不同的SAS签名).修剪时,额外的容器也可以使管理变得更容易(删除单个容器而不是针对每个blob).由于这些原因,我倾向于使用更多的容器(而不是性能).

从理论上讲,性能影响不应该存在.blob本身(完整URL)是Windows Azure中的分区键(已经很长时间了).这是从分区服务器进行负载均衡的最小的东西.因此,您可以(通常会)在不同服务器提供的同一容器中有两个不同的blob.

Jeremy表示容器之间的性能差异越来越大.我没有足够深入地解释为什么会出现这种情况,但我会怀疑其他因素(如大小,测试持续时间等)来解释任何差异.