我正在 Azure 上创建一个非常大的图像数据库，有几个 TB。这些图像按大约 150,000 张图像分组。每个图像都是金字塔和平铺的，这意味着每个图像大约有 60 个 block 。每组大约有 1,000,000 个 block 。
永远不会完整地访问图像，只能根据所需的分辨率(金字塔级别)和图像的感兴趣区域(图 block )访问特定的 block 。
对于那些对 Azure Blob 进行过广泛实验的人，您会建议:
(A) 保留一个 50GB 的大 blob，并在外部(SQL 数据库)跟踪每个 block 的位置和长度，以便您稍后可以检索所需的 block ...
-或-
(B) 在一个容器中为整个集合创建 1,000,000 个约 8KB 的 blob，并使用 blob URI 根据约定检索正确的 block 。
B 对我来说更有吸引力，但我担心 Azure 对这些 Blob 的索引会导致检索在 1,000,000 个 Blob 中随机访问的 Blob 时出现一些延迟？
有什么想法吗？
最佳答案
(B) Create a 1,000,000 blobs of about 8KB in one container for the whole set and use the blob URI to retrieve the right chunk per convention.
这也是我的偏好。以下是我这样做的原因:
- 可扩展性:每个存储帐户在读取和写入方面都有一些可扩展性目标，并且拥有单独的 blob 将能够以更好的方式管理可扩展性。对于多个 Blob，如果需要满足可扩展性目标，您可以将它们分布在多个存储帐户中。
- 可维护性:采用单独的 blob 方法，更容易维护。您只需上传 blob、更新数据库即可完成。对于单个 blob 并将范围存储在其他地方，维护它可能会出现问题。让我们考虑一个示例:为了简单起见，我们假设您只有 2 个 blob - 1.png 和 2.png。首先，它们的大小都是 8KB。因此，您创建一个 blob(例如 blob.png)并将范围(0-8KB 和 8KB-16KB)存储在数据库中。现在假设您必须更新 1.png，这次大小为 10KB。您根本无法将该 blob 写入更大的 blob，因为现在您需要推回 2.png，因为它的起点现在是 10KB 标记。现在将其扩展到 1000 个 blob。在这种情况下，更新 blob 可能会变得非常麻烦，我不确定这样做是否值得。
B is more attractive to me but I worry that the indexing of those blobs by Azure will cause some lag to retrieve the blobs randomly accessed among 1,000,000's of them?
关于您关于索引的评论，Azure 按 blob 名称索引 blob，因此只要您通过 URL 直接访问 blob，就不会遇到索引问题。
您可能会发现本文对于了解 Azure 存储可扩展性和性能目标很有用:https://azure.microsoft.com/en-in/documentation/articles/storage-scalability-targets/ .
关于 azure 的 Blob - 几个大的或多个小的，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39041100/