Azure Blob 存储：虚拟文件夹结构与 Blob 索引标签

Question

当我对 blob 的创建有完全的编程控制时，我试图弄清楚索引标签与在 azure blob 存储中创建完整的虚拟文件夹树结构有什么好处。

Answer 1

虚拟文件夹结构与 Blob 索引标签

您要求我们比较 Azure Blob 存储的两个单独功能，就好像它们是互斥的一样，而实际上它们可以一起使用，并且组织 Blob 的选项不仅仅是这两个选项：

长话短说：

• Azure Blob 索引标签- Blob 上的任意可变标签。
• 虚拟文件夹结构- 这只是一种命名约定，其中您的 blob 使用斜杠分隔的“目录”名称进行命名。
• NFS 3.0 Blob 存储和 Data Lake Storage Gen2 - 这是 Azure Blob 存储的主要新版本（或修订版），使其行为几乎与传统磁盘文件系统完全相同（因此符合 NFS 3.0），但它（目前）存在重大缺点。

详细地：

• Azure Blob 索引标签 是 Azure Blob 存储最近推出的一项新功能：它于 2020 年 5 月进入预览版，并于 2021 年 6 月（截至撰写本文时为 2 个月前）退出预览阶段。

  • 您的存储帐户需要是“通用 v2” - 因此，如果您有旧式存储帐户，则需要更新它。
  • 优点：
    • 它内置于 Azure Blob 存储中，因此您无需维护自己的索引基础设施（这是我们过去必须做的事情：我将自己的 Blob 索引存储在同一存储帐户的 Azure 表存储中的表中） ，并且有一个每晚在一次性 Azure VM 上运行的进程来索引新的 blob）。
    • 由于它是一个标记系统，这意味着您可以拥有自己的分类法，而不必像虚拟文件夹那样将命名法强制纳入单个层次结构中。
    • 标签是可变的：您可以根据需要添加/删除/编辑它们。
  • 缺点：

    • 与维护自己的 blob 索引一样，索引更新不是即时的（与 RDBMS 不同，RDBMS 的索引始终是最新的）。博客文章对此进行了链接，说道：

      并且帐户索引引擎不久后就会公开新的 blob 索引。”

      ...请注意，他们没有定义“很快”的含义。

    • 截至 2021 年 8 月，Azure 每 10,000 个标签收费 0.03 美元（无论使用哪个存储层）。因此，如果您有 1,000,000 个 Blob，每个 Blob 有 3 个标签，则费用为 9 美元/月。

      • 无论如何，这并不是一个很大的成本，但每个信息理论单元的成本有点高，这令人失望。

• “虚拟文件夹树结构” - 我假设您的意思是提供 blob 的分层命名系统并使用 Azure Blob 存储的 blob-name-prefix 搜索过滤器。

  • 优点：
    • 经过尝试和测试。简单的。
    • 不花你任何钱。
    • 无索引延迟。
  • 缺点：
    • 它仍然像按字典顺序枚举 blob 一样慢。
    • 从概念上讲，您无法移动或重命名 blob。
      • （从技术上讲，您可以通过执行复制+删除来提供源和目标位于同一个容器中，并且复制操作应该是即时的，因为我知道 Blob 存储使用COW进行相同容器的复制，但它仍然不完美：客户端API 仍然将其公开为具有无限复制时间的异步操作，而不是提供硬性保证）
      • 十年来，这一直是 Azure Blob 存储的限制，这一事实现在让我完全困惑。

• NFS 3.0 Blob 存储- 2020/2021 年新增的 Blob 索引标签是 NFS 3.0 Blob 存储，它为您的 Blob 提供完整的“真实”分层文件系统。

  • 分层命名空间功能由 Azure Data Lake Storage Gen 2 提供支持。我不知道这方面的任何技术细节，所以我不能说什么。
  • 优点：
    • 兼容 NFS 3.0（太强大了！），因此 Linux 客户端甚至可以直接安装它。
    • 它比普通的 blob 存储便宜（whaaaaat？！）：
      • 在 West US 2 中，NFS+LRS+Hot 的价格为 0.018 美元/GB，而带有 LRS+Hot 的老式平面命名空间的价格为 0.0184 美元/GB。
      • 在其他 Azure 位置和使用其他冗余选项时，NFS 可能会稍微昂贵一些，但除此之外它们通常彼此相差 0.01 美元以内。
  • 缺点：
    • 显然，您仅限于块 blob：而不是页 blob 或追加 blob 。
  • 已知问题页面的注释：
    • NFS 只能与新帐户一起使用：您无法更新现有帐户。一旦启用它，您也无法禁用它。
    • 您（当前）无法锁定 blob/文件 - 尽管这看起来会在未来版本中出现。
    • 您不能在同一个存储帐户中同时使用 Blob 索引标签和 NFS - 或者事实上Blob 存储的大多数功能（哦！）。
    • 专门针对分层命名空间 blob 的操作的文档仅列出Set Blob Expiry- 似乎（仍然）没有同步/原子“移动 blob”或“重命名 blob”操作，相反，协议支持页面暗示重命名 NFS 的操作文件将在幕后转换为原始 blob 存储操作...所以我很好奇他们是如何原子地做到这一点的。

      当您的应用程序使用 NFS 3.0 协议发出请求时，该请求将转换为块 blob 操作的组合。例如，NFS 3.0 读取远程过程调用 (RPC) 请求会转换为 Get Blob 操作。NFS 3.0 写入 RPC 请求被转换为 Get Block List、Put Block 和 Put Block List 的组合。

• 替代概念：内容可寻址存储

  • 因为 Blob 无法原子/同步重命名，所以几年前我干脆放弃了尝试提出一个经得起时间考验的完美Blob 命名法，因为业务需求总是在变化。
  • 相反，我注意到我的 blob 总是不可变的：一旦它们被上传到存储，它们就永远不会更新，或者当它们更新时，它们会保存到新的、单独的 blob - 这意味着内容可寻址的命名策略适合我的项目完美。
  • 简而言之：为不可变的 blob 指定一个名称，该名称是其内容的哈希值的字符串表示形式，并将其哈希值存储在传统的 RDBMS 中，在传统的 RDBMS 中，您可以在索引和引用方式方面拥有更大的灵活性（并且理想情况下：性能）由系统的其余部分决定。
    • 就我而言，我将 Blob 的名称设置为其 SHA-256 哈希值的 Base-16 表示形式。
  • 优点：
    • 您可以免费获得重复数据删除：具有相同内容的 blob 将具有相同的哈希值，因此您可以避免两次上传/下载相同的巨大 blob。
    • 您可以免费获得完整性检查：如果您下载了一个 blob 并且其哈希值与其 blob 名称不匹配，那么您的存储帐户可能已被黑客入侵）
  • 缺点：
    • 您仍然需要在 RDBMS 中维护自己的索引（如果适用） - 但您仍然可以将 Blob 索引标签与内容可寻址存储一起使用。