SubQueryディクショナリの仕組みは？

一般的なディクショナリプロジェクトの全体のアイデアは、ブロックチェーンからすべてのデータをインデックス化し、イベント、外部関数、そのタイプ（モジュールとメソッド）をブロック順にデータベースに記録することです。 別のプロジェクトは、マニフェスト ファイルで定義されたデフォルトの network.endpoint の代わりに、この network.dictionary のエンドポイントを照会できます。

network.dictionary エンドポイントはオプションのパラメータで、存在すればSDKは自動的に検出し使用します。 network.endpoint は必須であり、存在しない場合はコンパイルされません。

SubQuery dictionary プロジェクトを例にとると、schema ファイルでは、extrinsic、events、specVersion の 3 つのエンティティを定義しています。 これら3つのエンティティは、それぞれ6、4、2フィールドを含んでいます。 このプロジェクトを実行すると、これらのフィールドがデータベースのテーブルに反映されます。

ブロックチェーンからのデータは、これらのテーブルに格納され、パフォーマンスのためにインデックスが付けられます。 その後、プロジェクトは SubQuery Projects でホストされ、API エンドポイントをマニフェスト ファイルに追加することが可能になります。

あなたのプロジェクトにディクショナリを組み込むには？

マニフェストファイルのネットワーク セクションに dictionary: https://api.subquery.network/sq/subquery/dictionary-polkadot を追加します。 例:

network:
  endpoint: wss://polkadot.api.onfinality.io/public-ws
  dictionary: https://api.subquery.network/sq/subquery/dictionary-polkadot

ディクショナリを使わないと、どうなるのか？

ディクショナリを使用しない場合、インデクサは、batch-sizeフラグ（デフォルトでは100）に従って、polkadot API経由ですべてのブロックデータを取得し、処理のためにバッファに格納します。 その後、インデクサはこれらのブロックをすべてバッファから取り出し、ブロックデータを処理しながら、これらのブロックのイベントと外部関数がユーザー定義のフィルタに一致するかどうかをチェックします。

ディクショナリを使うとどうなるのか？

ディクショナリが使用される場合、インデクサはまず呼び出しとイベントフィルタをパラメータとして受け取り、これをGraphQLクエリーにマージします。 次に、ディクショナリのAPIを使用して、特定のイベントと外部関数を含む関連するブロック順のリストのみを取得します。 デフォルトで使用する場合は、100より大幅に少なくなることが多い。

例えば、転送イベントのインデックスを作成する状況を想像してください。 すべてのブロックにこのイベントがあるわけではありません（下の画像では、ブロック3と4には転送イベントがありません）。

ディクショナリでは、プロジェクトが転送イベントを各ブロックで探すのではなく、ブロック1、2、5だけにスキップすることができます。 これは、ディクショナリが各ブロックのすべての呼び出しとイベントの事前計算された参照であるためである。

つまり、ディクショナリを使うことで、インデクサがチェーンから取得するデータ量を減らし、ローカルバッファに格納される「不要な」ブロックの数を減らすことができるのです。 しかし、従来の方法と比較すると、ディクショナリのAPIからデータを取得するステップが追加されます。

ディクショナリが役に立たないのはどんなときか？

ブロック ハンドラを使用してチェーンからデータを取得する場合、すべてのブロックが処理される必要があります。 したがって、この場合にディクショナリを使用しても利点はなく、インデクサは自動的にデフォルトの非ディクショナリアプローチに切り替わります。

また、timestamp.setのようにブロックごとに発生・存在するイベントや外部関数を扱う場合、ディクショナリを使用してもそれ以上の利点はないでしょう。