Azure Blob 存储：虚拟文件夹结构与 Blob 索引标签
Azure Blob Storage : Virtual Folder structure vs Blob Index Tags
当我对 blob 的创建有完全的编程控制时，我试图弄清楚索引标签与在 azure blob 存储中创建完整的虚拟文件夹树结构有什么好处。
Virtual Folder structure vs Blob Index Tags
你要求我们比较 Azure Blob 存储的两个独立功能，就好像它们是互斥的，而实际上它们可以一起使用，而且组织 blob 的选项不仅仅是这两个选项:
长话短说：
- Azure Blob 索引标签 - blob 上的任意 mutable 标签。
- 虚拟文件夹结构 - 这只是一个命名约定，其中您的 blob 以斜杠分隔的“目录”名称命名。
- NFS 3.0 Blob 存储和 Data Lake Storage Gen2 - 这是 Azure Blob 存储的一个主要新版本（或修订版），它的行为几乎完全一样 类似于传统的磁盘文件系统（因此符合 NFS 3.0），但它（目前）有重大缺点。
详细：
Azure Blob Index Tags is a recently introduced new feature to Azure Blob Storage: it entered preview in May 2020 并于 2021 年 6 月（撰写本文时 2 个月前）离开了预览阶段。
- 您的存储帐户必须是“通用 v2”- 因此，如果您有旧式存储帐户，则需要对其进行更新。
- 优点：
- 它内置于 Azure Blob 存储中，因此您无需维护自己的索引基础结构（这是我们过去必须做的：我将自己的 blob 索引存储在 table在 Azure Table 存储在同一个存储帐户中，并且有一个进程 运行 每晚在一次性 Azure VM 上索引新的 blob）。
- 由于它是一个标记系统，这意味着您可以拥有自己的分类法，而不必像使用虚拟文件夹那样将您的命名法强加到一个层次结构中。
- 标签是 mutable: 你可以 add/remove/edit 随意。
- 缺点：
与维护您自己的 blob 索引一样，索引更新不是即时的（与索引始终保持最新的 RDBMS 不同）。博客文章链接了这一点，说：
and the account indexing engine exposes the new blob index shortly after."
...请注意，他们没有定义“不久”的含义。
截至 2021 年 8 月，Azure 对每 10,000 个标签收取 0.03 美元的费用（无论使用何种存储层）。因此，如果您有 1,000,000 个 blob，每个 blob 有 3 个标签，那么就是 9 美元/月。
- 无论如何，这都不是显着的成本，但每信息理论单位的成本有点高，令人失望。
"Virtual Folder tree structure" - 我假设你的意思是提供 blob 的分层命名系统并使用 Azure Blob Storage 的 blob-name-prefix 搜索过滤器。
- 优点：
- 久经考验。简单。
- 不需要任何费用。
- 无索引延迟。
- 缺点：
- 它仍然像按字典顺序枚举 blob 一样慢。
- 您不能概念上移动或重命名 blob。
- （从技术上讲，您可以通过执行复制+删除在同一个容器中提供源和目标，并且复制操作应该是即时的，因为我知道 Blob 存储使用 COW 相同的容器副本，但它仍然不完美：客户端 API 仍然将其公开为具有无限复制时间的异步操作，而不是提供硬 gua运行tees)
- 十年来这一直是 Azure Blob 存储的限制这一事实让我感到非常困惑。
NFS 3.0 Blob 存储 - 2020/2021 年也新增了 Blob 索引标签 is NFS 3.0 Blob Storage，它为您提供了完整的“真实”层次结构blob 的文件系统。
- 分层命名空间功能由 Azure Data Lake Storage Gen 2 提供支持。我不知道这方面的任何技术细节，所以我不能说什么。
- 优点：
- NFS 3.0 兼容（那是巨大的！）因此 Linux 客户端甚至可以直接挂载它。
- It's cheaper than normal blob storage（whaaaaat？！）：
- 在美国西部 2，NFS+LRS+Hot 是 0.018 美元/GB，而带有 LRS+Hot 的老式平面命名空间是 0.0184 美元/GB。
- 在其他 Azure 位置和具有其他冗余选项的情况下，NFS 可能 稍微 更贵，但除此之外它们通常在 0.01 美元以内。
- 缺点：
- 显然 you're limited to only block-blobs：不是页面 blob 或追加 blob。
- 来自 the Known Issues page 的注释：
- NFS 只能用于新帐户：您不能更新现有帐户。启用后也无法禁用它。
- 您不能（当前）锁定 blobs/files - 虽然这看起来会出现在未来的版本中。
- 您不能在同一个存储帐户中同时使用 Blob 索引标签和 NFS - 或者事实上 Blob 存储的大多数 功能（噢噢！）。
- The documentation for operations exclusively to Hierarchical namespace blobs only lists
Set Blob Expiry - there (still) doesn't seem to be a synchronous/atomic "move blob" or "rename blob" operation, instead the Protocol Support page implies 重命名 NFS 文件的操作将被 t运行 安排到幕后的原始 blob 存储操作中......所以我很好奇他们是如何原子地做到这一点的.
When your application makes a request by using the NFS 3.0 protocol, that request is translated into combination of block blob operations. For example, NFS 3.0 read Remote Procedure Call (RPC) requests are translated into Get Blob operation. NFS 3.0 write RPC requests are translated into a combination of Get Block List, Put Block, and Put Block List.
替代概念：Content-addressable-storage
- 因为 blob 无法 atomically/synchronously 重命名，所以几年前我 干脆放弃了 试图想出一个 完美 经得起时间考验的 blob 命名法，因为业务需求总是在变化。
- 相反，我注意到我的 blob 总是 immutable：一旦它们被上传到存储，它们就永远不会更新，或者当它们被更新时它们被保存到新的、单独的 blob 中——这意味着内容可寻址的命名策略非常适合我的项目。
- 简而言之：给您的 immutable blob 一个名称，该名称是其内容散列的字符串表示形式，并将其散列存储在传统的 RDBMS 中，这样您就有更大的灵活性（理想情况下：性能）以及它们如何被系统的其余部分索引和引用。
- 就我而言，我将 blob 的名称设置为其 SHA-256 哈希的 Base-16 表示形式。
- 优点：
- 您可以免费进行重复数据删除：具有相同内容的 blob 将具有相同的哈希值，因此您可以避免 uploading/downloading 相同的巨大 blob 两次。
- 您可以免费获得完整性检查：如果您下载了一个 blob，并且它的哈希值与它的 blob 名称不匹配，那么您的存储帐户可能被黑了）
- 缺点：
- 您仍然需要在 RDBMS 中维护您自己的索引（如果适用）- 但如果您愿意，您可以仍然使用具有内容可寻址存储的 Blob 索引标签。
当我对 blob 的创建有完全的编程控制时，我试图弄清楚索引标签与在 azure blob 存储中创建完整的虚拟文件夹树结构有什么好处。
Virtual Folder structure vs Blob Index Tags
你要求我们比较 Azure Blob 存储的两个独立功能，就好像它们是互斥的，而实际上它们可以一起使用，而且组织 blob 的选项不仅仅是这两个选项:
长话短说：
- Azure Blob 索引标签 - blob 上的任意 mutable 标签。
- 虚拟文件夹结构 - 这只是一个命名约定，其中您的 blob 以斜杠分隔的“目录”名称命名。
- NFS 3.0 Blob 存储和 Data Lake Storage Gen2 - 这是 Azure Blob 存储的一个主要新版本（或修订版），它的行为几乎完全一样 类似于传统的磁盘文件系统（因此符合 NFS 3.0），但它（目前）有重大缺点。
详细：
Azure Blob Index Tags is a recently introduced new feature to Azure Blob Storage: it entered preview in May 2020 并于 2021 年 6 月（撰写本文时 2 个月前）离开了预览阶段。
- 您的存储帐户必须是“通用 v2”- 因此，如果您有旧式存储帐户，则需要对其进行更新。
- 优点：
- 它内置于 Azure Blob 存储中，因此您无需维护自己的索引基础结构（这是我们过去必须做的：我将自己的 blob 索引存储在 table在 Azure Table 存储在同一个存储帐户中，并且有一个进程 运行 每晚在一次性 Azure VM 上索引新的 blob）。
- 由于它是一个标记系统，这意味着您可以拥有自己的分类法，而不必像使用虚拟文件夹那样将您的命名法强加到一个层次结构中。
- 标签是 mutable: 你可以 add/remove/edit 随意。
- 缺点：
与维护您自己的 blob 索引一样，索引更新不是即时的（与索引始终保持最新的 RDBMS 不同）。博客文章链接了这一点，说：
and the account indexing engine exposes the new blob index shortly after."
...请注意，他们没有定义“不久”的含义。
截至 2021 年 8 月，Azure 对每 10,000 个标签收取 0.03 美元的费用（无论使用何种存储层）。因此，如果您有 1,000,000 个 blob，每个 blob 有 3 个标签，那么就是 9 美元/月。
- 无论如何，这都不是显着的成本，但每信息理论单位的成本有点高，令人失望。
"Virtual Folder tree structure" - 我假设你的意思是提供 blob 的分层命名系统并使用 Azure Blob Storage 的 blob-name-prefix 搜索过滤器。
- 优点：
- 久经考验。简单。
- 不需要任何费用。
- 无索引延迟。
- 缺点：
- 它仍然像按字典顺序枚举 blob 一样慢。
- 您不能概念上移动或重命名 blob。
- （从技术上讲，您可以通过执行复制+删除在同一个容器中提供源和目标，并且复制操作应该是即时的，因为我知道 Blob 存储使用 COW 相同的容器副本，但它仍然不完美：客户端 API 仍然将其公开为具有无限复制时间的异步操作，而不是提供硬 gua运行tees)
- 十年来这一直是 Azure Blob 存储的限制这一事实让我感到非常困惑。
- 优点：
NFS 3.0 Blob 存储 - 2020/2021 年也新增了 Blob 索引标签 is NFS 3.0 Blob Storage，它为您提供了完整的“真实”层次结构blob 的文件系统。
- 分层命名空间功能由 Azure Data Lake Storage Gen 2 提供支持。我不知道这方面的任何技术细节，所以我不能说什么。
- 优点：
- NFS 3.0 兼容（那是巨大的！）因此 Linux 客户端甚至可以直接挂载它。
- It's cheaper than normal blob storage（whaaaaat？！）：
- 在美国西部 2，NFS+LRS+Hot 是 0.018 美元/GB，而带有 LRS+Hot 的老式平面命名空间是 0.0184 美元/GB。
- 在其他 Azure 位置和具有其他冗余选项的情况下，NFS 可能 稍微 更贵，但除此之外它们通常在 0.01 美元以内。
- 缺点：
- 显然 you're limited to only block-blobs：不是页面 blob 或追加 blob。
- 来自 the Known Issues page 的注释：
- NFS 只能用于新帐户：您不能更新现有帐户。启用后也无法禁用它。
- 您不能（当前）锁定 blobs/files - 虽然这看起来会出现在未来的版本中。
- 您不能在同一个存储帐户中同时使用 Blob 索引标签和 NFS - 或者事实上 Blob 存储的大多数 功能（噢噢！）。
- The documentation for operations exclusively to Hierarchical namespace blobs only lists
Set Blob Expiry- there (still) doesn't seem to be a synchronous/atomic "move blob" or "rename blob" operation, instead the Protocol Support page implies 重命名 NFS 文件的操作将被 t运行 安排到幕后的原始 blob 存储操作中......所以我很好奇他们是如何原子地做到这一点的.When your application makes a request by using the NFS 3.0 protocol, that request is translated into combination of block blob operations. For example, NFS 3.0 read Remote Procedure Call (RPC) requests are translated into Get Blob operation. NFS 3.0 write RPC requests are translated into a combination of Get Block List, Put Block, and Put Block List.
替代概念：Content-addressable-storage
- 因为 blob 无法 atomically/synchronously 重命名，所以几年前我 干脆放弃了 试图想出一个 完美 经得起时间考验的 blob 命名法，因为业务需求总是在变化。
- 相反，我注意到我的 blob 总是 immutable：一旦它们被上传到存储，它们就永远不会更新，或者当它们被更新时它们被保存到新的、单独的 blob 中——这意味着内容可寻址的命名策略非常适合我的项目。
- 简而言之：给您的 immutable blob 一个名称，该名称是其内容散列的字符串表示形式，并将其散列存储在传统的 RDBMS 中，这样您就有更大的灵活性（理想情况下：性能）以及它们如何被系统的其余部分索引和引用。
- 就我而言，我将 blob 的名称设置为其 SHA-256 哈希的 Base-16 表示形式。
- 优点：
- 您可以免费进行重复数据删除：具有相同内容的 blob 将具有相同的哈希值，因此您可以避免 uploading/downloading 相同的巨大 blob 两次。
- 您可以免费获得完整性检查：如果您下载了一个 blob，并且它的哈希值与它的 blob 名称不匹配，那么您的存储帐户可能被黑了）
- 缺点：
- 您仍然需要在 RDBMS 中维护您自己的索引（如果适用）- 但如果您愿意，您可以仍然使用具有内容可寻址存储的 Blob 索引标签。