네트워크 인덱서 작동방법

HOME

IPFS 뉴스

네트워크 인덱서 작동방법

이은혜 기자
|
입력 2022-08-03 15:24
|
수정 2022-08-03 15:24

▲네트워크 인덱서 작동방법

이 블로그는 네트워크 인덱서(Network Indexer) 블로그 포스트 시리즈의 두 번째이다. 이 게시물에서는 네트워크 인덱서의 작동 방식에 대해 자세히 알아보았다. 여기에서 이전 게시물을 찾으십시오: Network Indexer 소개.

올해 초, 프로토콜 랩스(Protocol Labs)는 파일코인 및 IPFS 네트워크에서와 같이 스토리지 공급업체에서 제공하는 콘텐츠 주소 지정 가능 데이터를 검색할 수 있는 최초의 프로덕션 네트워크 인덱서를 출시했다. 현재 60억 개 이상의 CIDs (콘텐츠 ID, Contents IDs)를 인덱싱했으며, 140개 이상의 스토리지 제공업체가 인덱서에 데이터를 게시하고 4개의 프로덕션 인덱서 노드가 파트너와 함께 실행된다. 인덱서 노드가 파일코인 및 IPFS에서 점점 더 많은 콘텐츠를 처리함에 따라 클라이언트는 인덱서를 쿼리하여 해당 CID로 식별된 콘텐츠를 검색할 수 있는 위치를 알 수 있다.

개요

파일코인은 많은 양의 데이터를 저장하지만, 인덱싱 없이는 클라이언트가 효율적인 검색을 수행할 수 없다. 콘텐츠 검색 가능성을 개선하기 위해 인덱서 노드는 콘텐츠 제공자 레코드에 대한 CID 다중 해시 매핑을 저장하도록 개발되었다. 클라이언트는 CID 또는 다중 해시를 사용하여 공급자 레코드를 조회한 다음 해당 공급자 레코드를 사용하여 저장소 공급자에서 데이터를 검색한다. 즉, 인덱서는 다음 두 그룹의 사용자를 위한 특수키-값 저장소처럼 작동한다.

저장소 공급자는 인덱서에 데이터를 저장하여 사용할 수 있는 콘텐츠를 알린다. 이 작업은 인덱서의 수집 논리에 의해 처리된다.
검색 클라이언트는 인덱서를 쿼리하여 콘텐츠가 있는 스토리지 공급자와 검색 방법(예: 그래프 동기화(graphsync), 비트스왑 등)을 찾는다. 이 작업은 인덱서의 찾기 논리에 의해 처리된다.

이 게시물에서는 인덱서 구성 요소가 상호 작용하는 방식과 네트워크를 통해 인덱스를 수집, 저장 및 공유하는 방법에 대해 살펴보겠다.

인덱서 상호 작용

그렇다면 이 두 가지 사용자 유형은 인덱서와 어떻게 상호 작용하는가?

먼저 스토리지 거래가 이루어지고 데이터 스토리지 공급자에 의해 저장된다. 스토리지 제공자는 일반적으로 메인넷 노드에 의해 중계되는 가십 펍서브(gossip pubsub)를 통해 광고 레코드의 CID를 게시하여 새로운 콘텐츠를 사용할 수 있음을 발표할 예정이다. 또는 HTTP를 통해 인덱서로 직접 보낼 수 있다. 인덱서 노드는 서로 릴레이 할 수도 있다.

그런 다음 인덱서는 이미 마지막으로 본 또는 체인의 끝까지 체인의 광고를 가져와 저장소 공급자의 새 콘텐츠를 동기화한다. 또한 각각의 새 광고에 대해 컨텍스트 ID, 메타데이터 및 콘텐츠 다중 해시 청크 체인을 가져온다.

콘텐츠가 인덱싱되면 검색 클라이언트는 검색하려는 데이터의 CID 또는 다중 해시를 사용하여 공급자 데이터를 찾을 수 있다. 인덱서는 최신 공급자 주소와 함께 조회된 각 CID에 대한 공급자 레코드 목록으로 응답합니다.

다음으로 클라이언트는 공급자 레코드에 표시된 프로토콜(예: 그래프 동기화 또는 비트스왑)을 사용하여 스토리지 공급자에서 콘텐츠를 검색한다. 그런 다음 클라이언트는 CID와 메타데이터를 사용하여 콘텐츠를 찾는 저장소 공급자에게 공급자 레코드를 보낸다.

이 다이어그램은 인덱서 생태계의 다양한 행위자와 이들이 상호 작용하는 방식을 요약했다.

인덱스 수집

인덱스 수집은 두 부분으로 구성된다.

게시 - 인덱서에 알림 메시지를 게시하여 인덱스 광고의 사용 가능 여부를 알린다.
동기화 - 해당 데이터의 게시자로부터 인덱스 데이터를 가져오는 중이며 인덱서를 게시된 인덱스 데이터와 동기화한다.

알림 메시지는 인덱서에 광고의 사용 가능 여부를 알려준다. 가십 펍서브(대부분의 경우) 또는 HTTP를 통해 게시자에서 인덱서로 전송된다. 알림 메시지에는 광고의 CID와 게시자의 주소(광고를 검색할 위치)가 포함된다. 인덱서는 이미 광고를 인덱싱한 경우 알림을 무시한다.

광고는 순서대로 처리되고 서명(링크 포함)되어 블록체인과 같은 구조를 만든다. 공급자 또는 허용된 게시자가 서명해야 한다.

광고에서 CID는 공급자에 대한 특정 메타데이터를 고유하게 식별한다. CID는 메타데이터를 업데이트하거나, 공급자 레코드에 다중 해시 매핑을 추가하거나, 공급자 레코드와 이에 대한 다중 해시 매핑을 삭제하는 데 사용된다. 메타데이터에는 프로토콜 식별자와 데이터를 검색할 때 스토리지 제공자에게 전달되는 추가 데이터가 포함된다. SP는 메타데이터를 사용하여 검색할 데이터를 찾는다. 여기에는 거래 ID, 내부 레코드키 등이 포함될 수 있다.

다음 다이어그램은 광고 및 다중 해시 데이터의 구조를 보여준다.

데이터 저장소

인덱서 데이터 저장소 디자인에서 많은 다중 해시는 상대적으로 적은 수의 공급자 레코드에 매핑된다. 다중 해시는 해당 다중 해시로 식별된 콘텐츠가 사용할 수 있는 위치를 설명하는 공급자 레코드를 조회하는 데 사용된다. 공급자 ID 및 CID는 고유한 공급자 레코드를 검색하는 데 사용된다.

공급자 데이터는 매핑되는 다중 해시와 독립적으로 업데이트 및 제거할 수 있다. 제공자 데이터는 제공자 ID와 컨텍스트 ID로 고유하게 식별된다. 컨텍스트 ID는 공급자 데이터값의 일부로 인덱서 코어에 제공됩니다. 공급자 데이터 개체가 업데이트되면 이후의 모든 다중 해시 쿼리는 해당 데이터에 대한 새 값을 반환한다.

고유한 공급자 레코드는 공급자 키(공급자 ID와 레코드의 컨텍스트 ID의 해시)에 의해 조회됩니다. 다중 해시는 동일한 콘텐츠가 다른 제공자에 의해 저장되고 동일한 제공자의 개별 거래의 일부가 될 수 있기 때문에 여러 제공자 레코드에 매핑될 수 있다. 인덱서 코어는 각 다중 해시를 공급자 키 목록에 매핑하고 각 공급자 키를 공급자 레코드에 매핑한다.

다음 다이어그램은 인덱서 저장소의 2단계 매핑 디자인을 보여준다.