这是 Network Indexer 博文系列的第二篇博文。在这篇文章中，我们将深入探讨网络索引器如何工作的更多细节。在这里找到我们以前的帖子：网络索引器简介。
今年早些时候，Protocol Labs 推出了第一个生产网络索引器，可以搜索存储提供商提供的内容可寻址数据，例如 Filecoin 和 IPFS 网络上的数据。我们现在已经索引了 6B 内容 ID (CID)，超过 140 个存储提供商将他们的数据发布到 Indexer，4 个生产索引器节点与我们的合作伙伴一起运行。随着 Indexer 节点跨 Filecoin 和 IPFS 处理越来越多的内容，客户端可以查询 Indexer 以了解在哪里检索由这些 CID 标识的内容。
概述
Filecoin 存储了大量数据，但如果没有适当的索引，客户端将无法执行有效的检索。为了提高 Filecoin 内容的可发现性，开发了 Indexer 节点来存储 CID 多哈希到内容提供者记录的映射。客户端使用 CID 或多重哈希来查找提供程序记录，然后使用该提供程序记录从存储提供程序检索数据。简而言之，索引器就像专门为以下两组用户提供的键值对存储：
在这篇文章中，我们将研究索引器组件如何相互交互，以及索引如何在网络中被摄取、存储和共享。
索引器交互
那么，这两种用户类型如何与 Indexer 交互呢？
首先，达成存储协议，数据由存储提供商存储。存储提供商将通过在 gossip pubsub 上发布广告记录的 CID 来宣布新内容可用，通常由主网节点中继。或者，它可以通过 HTTP 直接发送到 Indexer。索引器节点也可以相互中继。
然后，Indexer 将同步来自存储提供商的新内容，方法是将链中的广告直到最后已经看到或链的末端。它还将获取每个新广告的 contextID、元数据和内容多哈希块链。
一旦内容被索引，检索客户端就可以使用他们想要检索的数据的 CID 或多重散列来查找提供者数据。索引器将响应查找到的每个 CID 的提供者记录列表以及最新的提供者地址。
接下来，客户端使用 p 中指示的协议从存储提供程序检索内容提供者记录（例如图形同步或位交换）。然后客户端将提供者记录发送给存储提供者，后者使用 contextID 和元数据来查找内容。
此图总结了索引器生态系统中的不同参与者，以及它们如何相互交互：
索引摄取
索引摄取由两部分组成：
Announce Message 通知索引器有关广告的可用性。它通过 gossip pubsub（在大多数情况下）或通过 HTTP 从发布者发送到索引器。公告消息包含广告的 CID 和发布者的地址（从哪里检索广告）。如果索引器已经对广告进行了索引，则索引器将忽略该通告。
广告按顺序处理，并签名（包括链接）以创建类似区块链的结构。它必须由提供者或允许的发布者签名。
在广告中，ContextID 唯一地标识提供者的特定元数据。 ContextID 用于更新元数据、将多哈希映射添加到提供者记录，或删除提供者记录和对其的多哈希映射。元数据包含协议标识符以及在检索数据时转发给存储提供者的附加数据。 SP 使用元数据查找要检索的数据，它可能包含交易 ID、内部记录键等。
下图说明了广告和多哈希数据的结构：
数据存储
在 Indexer 数据存储设计中，许多多重哈希映射到相对较少的提供者记录。多重哈希用于查找描述由多重哈希标识的内容在何处可用的提供者记录。提供者 ID 和上下文 ID 用于查找唯一的提供者记录。
提供者数据可以独立于映射到它的多重哈希进行更新和删除。提供者数据由提供者 ID 和上下文 ID 唯一标识。上下文 ID 作为提供程序数据值的一部分提供给索引器核心。更新提供者数据对象时，所有后续多哈希查询都将返回该数据的新值。
唯一的提供者记录由提供者键查找，该键是提供者 ID 和记录的上下文 ID 的散列。多重哈希可以映射到多个提供商记录，因为相同的内容可能由不同的提供商存储并且是同一提供商的单独交易的一部分。 Indexer 核心将每个多重哈希映射到提供者密钥列表，并将每个提供者密钥映射到提供者记录。
此图显示了索引器数据存储的 2 级映射设计：
数据共享
此外，索引器可以在配置为这样做时相互共享各种类型的数据。
资源
如果您有兴趣参与 Indexer 网络或了解有关 Indexer 的更多信息，您可能会发现这些资源很有帮助：
| 留言与评论（共有 0 条评论） “” |
