> ## Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Solanaデータのインデックス方法

> Solanaインデックスの構築、バックフィル、最新状態の維持方法を学びます。

## 概要

Solanaブロックチェーンはデータを順序付きの追記専用台帳に格納します。これはデータの完全性とトランザクションスループットにおいて優れていますが、重大なコストが伴いま: [履歴データ](/ja/rpc/historical-data)のクエリが非常に非効率で遅いということです。

複雑な操作は、複数のソースからのデータのフィルタリング、集約、または結合を伴うことがよくあります。このような場合、多くの実世界のアプリケーションでSolanaに直接クエリを行うことは現実的でありません。

これを解決するため、ほとんどの企業はSolanaの履歴データのプライベートインデックスを構築します。

このガイドでは、履歴データを[`getTransactionsForAddress`](/ja/rpc/gettransactionsforaddress)や他のアーカイブRPCメソッドを用いてバックフィルし、データベースを選び、リアルタイムストリーミングでインデックスを最新に保つ全ライフサイクルをカバーします。

## これを使用する時

インデックスを構築する時:

* あなたの製品が高速なフィルタリングクエリを必要としているが、直接のRPCコールが遅すぎる場合（例：ウォレットのトークンアカウントや残高、取引ペアの完全な履歴）
* オンチェーンデータをフィルタリング、集約、結合、またはオフチェーンデータ（CEX価格、KYC、ラベル）と組み合わせる必要がある場合
* PnL、ホルダー分析、またはNFT販売履歴のような事前処理およびクエリ可能なデータが必要な計算を行う場合
* 多くのユーザーにサービスを提供しており、チェーンへのリクエストごとの遅延を許容できない場合

標準のウォレットまたは資産データのみが必要な場合、独自のインデックスを運用するよりもマネージドAPIの方が簡単かもしれません。以下の[補完的オプション](#next-steps)を参照してください。

## Solanaデータのインデックス化とは何ですか？

インデックス化とは、Solanaブロックチェーンからのデータをクエリし、それをバックエンドデータベース（例：PostgreSQL、ClickHouse）に格納するプロセスです。これにより、[Solana RPCコール](/ja/api-reference/rpc/http-methods)を使用して直接ブロックチェーンにクエリを行うことなく、顧客のリクエストにすぐに対応できます。

インデクサーは通常、次の4つのことを行います：

1. **履歴データのバックフィル:** [アーカイブRPCメソッド](/ja/rpc/guides/overview#historical-data-archival)を使用してすべての履歴データをクエリする
2. **新しいデータをストリーム:** ネットワークによって確認されたときに新しいブロックを処理する
3. **データの解析と変換:** 確認済みブロックから関連データを抽出 (例：トランザクション、状態の変化など)
4. **データをデータベースに整理:** 新しいデータでインデックスを更新する

### ほとんどの企業がSolanaインデックスを構築する理由

企業は、ネイティブRPCが提供しない特定目的のブロックチェーンデータへの迅速なリアルタイムアクセスを提供することがビジネスに依存しているため、Solanaインデックスを構築します (例：NFT販売履歴)。

企業はまた、オンチェーンデータとオフチェーンデータ（例：中央集権取引所の価格、KYC情報など）を組み合わせるためにカスタムインデックスを活用します。

#### ウォレットの例

例えば、Solanaウォレットがすぐにユーザーのトークンアカウントと残高を返す必要がある場合、[`getTokenAccountsByOwner`](/ja/api-reference/rpc/http/gettokenaccountsbyowner)および[`getTokenAccountBalance`](/ja/api-reference/rpc/http/gettokenaccountbalance)でSolanaに直接クエリを行うことは遅すぎて製品が使えなくなる可能性があります。これに代わり、ウォレットは通常、顧客アドレス、トークン、およびアカウント残高の独自のインデックスを維持します。

#### トレーディングの例

同様に、暗号取引会社は特定の取引ペア（例：[SOL-USDC](https://orbmarkets.io/address/So11111111111111111111111111111111111111112/markets?sort_by=volume24h\&sort_type=desc)）または特定の[市場](https://orbmarkets.io/)で発生するすべての取引活動をログに記録し、トレーディングアルゴリズムをバックテストしたいと考えるかもしれません。

このデータを取得するためにブロックチェーンを直接クエリすることは、実用的な取引分析にはあまりにも遅すぎます。代わりに、量的トレーダーはSOL-USDC市場のインデックスを構築し、[LaserStream](/ja/laserstream)などのリアルタイムストリーミング製品を使用して最新の取引で更新することを選ぶかもしれません。

#### フィルタリングの例

ユーザーがフロントエンドアプリケーションで特定の基準でトランザクションをフィルタリングしたいとしましょう（例：トークンタイプ、転送額、日付、ウォレットアドレス）。

インデクサーがなければ、アプリケーションは何百万ものトランザクションを調べ、フィルタ基準に基づいて各1つを確認する必要があります。

このプロセスは、現代の製品ユーザー体験には遅すぎます。

#### PnLの例

トレーダーの利益と損失（PnL）を計算するには、次のことを行う必要があります：

* 特定の期間におけるウォレットに関連するすべてのトランザクションを見つける
* スワップトランザクションをフィルタリングして、買いまたは売りとしてラベルを付ける
* 各スワップでユーザーが支払った手数料を判定する
* 各トレード時点での各トークンの過去価格データを取得する
* 各トランザクションのPnLを集計して、トレーダーの合計PnLを計算する

これをリアルタイムで計算することは実用的でなく、より高速でスケーラブルなソリューションを必要とします。

インデックスを使用すると、このすべての情報がすでに処理されてクエリ可能なデータベースに格納されています。したがって、トレーダーのPnLを計算するのが瞬時に提供される単一のAPIコールになります。

Solanaインデックスをバックフィルし、それを最新の状態に保つための3つのアプローチについて見ていきます。

## ステップ1: 履歴データを取得する

Solanaインデックスを構築する最初のステップは、関心のあるすべての履歴データを取得することです。

これを行うには主に3つの方法があります：

1. [**getTransactionsForAddress**](/ja/rpc/gettransactionsforaddress) （推奨）
2. [**getSignaturesForAddress**](/ja/rpc/guides/getsignaturesforaddress) および [**getTransaction**](/ja/rpc/guides/gettransaction)
3. [**getBlock**](/ja/rpc/guides/getblock)

### 方法1: getTransactionsForAddress（推奨）

[`getTransactionsForAddress`](/ja/rpc/gettransactionsforaddress) RPCメソッドを使用すると、任意のブロックチェーンデータセグメントの完全なトランザクション詳細を取得できます。その強力なフィルタリング能力により、インデックスに必要のないデータを取得するために時間を無駄にすることがなく、逆検索機能によりトランザクションを時系列順に取得できます。

#### この方法を使用する手順

* 必要なデータの時間範囲を決定し、フィルタを設定する
* `transactionDetails`を`full`に設定して、すべてのトランザクション詳細を取得する
* 必要に応じて、関連するトークンアカウントトランザクションを含めるよう`tokenAccounts`フィルタを設定する
* `paginationToken`を使用して結果をページネーションする
* 各イテレーションで、必要なデータを抽出し、データベースに保存する

#### getTransactionsForAddressを使用する利点

[gTFAエンドポイント](/ja/api-reference/rpc/http/gettransactionsforaddress)を使用する主な利点は、速度とシンプルさです。スロットおよび時間ベースのフィルタ、トークンアカウントサポート、逆検索、ページネーションを使用すると、複雑なループやリトライロジックなしで、Solanaの歴史上の任意の時間から任意のデータを取得できます。[`getSignaturesForAddress`](/ja/rpc/guides/getsignaturesforaddress)と異なり、アドレスが所有する関連トークンアカウントを含むトランザクションも含めることができます。

あなたのインデックスが特にトークンとネイティブSOLの移動（支払い、台帳、残高調整）に関するものである場合、[`getTransfersByAddress`](/ja/rpc/gettransfersbyaddress)は、完全なトランザクションの代わりにパースされた、調整可能な転送行を返すため、パースのステップを省けることがあります。

### 方法2: getSignaturesForAddressとgetTransaction

gTFAのリリース前、履歴データをクエリする標準的なアプローチは、[`getSignaturesForAddress`](/ja/rpc/guides/getsignaturesforaddress)を使用して（最新から最も古いものまで）再帰的に署名をループし、[`getTransaction`](/ja/rpc/guides/gettransaction)を呼び出して完全なトランザクション詳細を抽出することでした。

#### この方法を使う手順

この方法を使うための基本的な手順は次のとおりです：

* `getSignaturesForAddress`を呼び出す
* このコールで受け取った最後のトランザクションの署名を保存する
* 次の`getSignaturesForAddress`の呼び出しには、この署名を`before`パラメータに設定する
* 必要に応じてこのままループする
* この方法で取得した各トランザクション署名について、`getTransaction`を呼び出して、その完全なトランザクション詳細を取得する
* 関連データをデータベースに挿入する

#### この方法の欠点

残念ながら、この方法を使用するには以下が必要です：

* 最新のトランザクションから始めて後戻りする
* 各トランザクションに対して追加のRPCを呼び出す
* 同時処理を扱うスレッドセーフなキューを構築する
* データを見逃したりレート制限されないようにリトライとバックオフのためのロジックを構築する
* アドレスが所有する関連トークンアカウントを含むトランザクションは含まない

この方法は機能しますが、より複雑で柔軟性がなく、より多くの[クレジット](/ja/billing/credits)を消費します。トークンアカウントを含む完全なウォレット履歴には、[`getTransactionsForAddress`](/ja/rpc/gettransactionsforaddress)を代わりに使用してください。

### 方法3: getBlockを使用

[`getBlock`](/ja/rpc/guides/getblock)方法は、ターゲットブロック内のトランザクションの高い割合が分析に関連する場合、特に効果的です。たとえば、DFlowのアグリゲーターやPump.funプログラム、またはSolanaのトークンプログラムなどの[頻繁に使用されるSolanaプログラム](/ja/orb/explore-programs)のトランザクションをインデックスする場合です。

#### この方法を使う手順

`getBlock`で履歴データをクエリするための基本的なプロセスは次のとおりです：

* クエリする時間範囲を決定する
* この時間範囲をスロット番号に変換する
* 対応するブロックを順次（順方向か逆方向か）取得する
* 各ブロックでインデックスに関連するトランザクションをフィルタする
* それらからの関連情報をインデックスに保存する

ほとんどのユースケースでは、この方法は本質的に無駄です。というのも、通常、ブロック内のすべてのトランザクションを取得するためです。

この方法を使用するのは、頻繁に使用されるプログラムのトランザクションを調べる場合や、アドレスベースのフィルタリングで対象データをキャプチャできない場合のみです。

## ステップ2: Solanaデータをデータベースと同期

履歴データを取得した後、それを変換し、効率的にデータベースに格納する必要があります。

**ストレージの選択は特定のユースケースに合わせるべきです** — 万能なソリューションはありません。適切なデータベースは、データセットのサイズ、遅延要求、クエリパターン、チームの専門知識に依存します。

### オプション1: SQLデータベース

Solanaデータのリレーショナルデータベース（PostgreSQLなど）への格納は、ほとんどのユースケースで推奨されます。SQLは柔軟で普及しており、学びやすいです。現代のリレーショナルデータベースは、1億行以上にも拡張可能でありながら、ACIDへの準拠、複雑な結合、強力な二次インデックスの利点を提供します。

**SQLite**をプロトタイピング、ローカル開発、または単一ファイルのデータベースでゼロ構成を希望する場合に使用してください。データセットが数ギガバイト以下に保たれている場合に理想的です。

**PostgreSQL**を使用して、複数のクライアントからのデータレプリケーションまたは同時アクセスが必要な本番アプリケーションに使用してください。

ほとんどのプロダクションレベルのSolanaインデクサーには、PostgreSQLが私たちの推奨する選択です。

#### 実装例：

例として、PostgreSQLデータベースにトークン転送を格納する方法を示します。

最初にテーブルを作成します：

```sql theme={"system"}
CREATE TABLE token_transfers (
    id BIGSERIAL PRIMARY KEY,
    slot BIGINT NOT NULL,
    timestamp TIMESTAMP NOT NULL,
    signature BYTEA NOT NULL UNIQUE,
    token_mint BYTEA NOT NULL,
    source_address BYTEA NOT NULL,
    destination_address BYTEA NOT NULL,
    amount BIGINT NOT NULL,
    decimals SMALLINT NOT NULL,
    program_id BYTEA
);
```

次に、頻繁にクエリされる列にインデックスを追加します：

```sql theme={"system"}
CREATE INDEX idx_source_address ON token_transfers (source_address);
CREATE INDEX idx_destination_address ON token_transfers (destination_address);
CREATE INDEX idx_token_mint ON token_transfers (token_mint);
```

頻繁にクエリされるデータのサブセットにのみインデックスを作成する場合に部分インデックスを作成することもできます。

高価値の転送のインデックスを作成する方法は次のとおりです：

```sql theme={"system"}
CREATE INDEX idx_large_transfers ON token_transfers(amount) WHERE amount > 1000000;
```

データをバックフィルする際、最適な書き込み速度のためにバルクINSERTと準備済みステートメントを使用してください。

### オプション2: 列指向データベース

列指向データベースは分析クエリ、集約、高容量タイムシリーズデータのために最適化されています。数十億のトランザクションをインデックス化する必要がある場合、ClickHouseやCassandraなどの列指向データベースが最適です。

**ClickHouse**を使用して、大規模データセットのリアルタイム分析クエリが必要な場合 — 高速な読み取り、集約、タイムシリーズ分析に最適化されています。

**Cassandra**を使用して、非常に高い書き込みスループット、無労力の水平スケーリング、高い耐障害性が必要な場合です。これにより、Solanaデータの大量連続インジェストに理想的です。

#### 実装例：

ClickHouseデータベースにトークン転送を格納する方法を示します。

この目的のために、[MergeTreeテーブルエンジン](https://clickhouse.com/docs/engines/table-engines/mergetree-family/mergetree)を使用するテーブルを作成します。これは高いインジェストレートのために設計されているので、インデックス化に最適です。

このコマンドを使用します：

```sql theme={"system"}
CREATE TABLE token_transfers (
    block_time DateTime,
    slot UInt64,
    signature FixedString(64),
    token_mint FixedString(32),
    source_address FixedString(32),
    destination_address FixedString(32),
    amount UInt64,
    decimals UInt8,
    program_id FixedString(32),
    date Date DEFAULT toDate(block_time)
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(date)
ORDER BY (token_mint, date)
SETTINGS index_granularity = 8192;
```

このセットアップでは、`(token_mint, date)`が主キーおよびソートキーの両方として設定されています。ClickHouseはデータをディスク上でソートキーに基づいて順序付けます。最適なのは単一の[token mint](/ja/orb/explore-mint-addresses)をクエリし、日付範囲で応答を絞り込むことです。

サンプルクエリはこちらです：

```sql theme={"system"}
SELECT date, signature, source_address, destination_address, amount
FROM token_transfers
WHERE token_mint = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v'
AND block_time BETWEEN '2025-01-01' AND '2025-01-31'
```

トランザクション署名とアドレスは\[`FixedString(N)`]データフォーマットを使用して保存され、ちょうどNバイトを保存します。ClickHouseは自動的にデータを圧縮し、これがストレージコストを10から20倍削減し、クエリパフォーマンスを改善します。

クエリパフォーマンスを最適化するために、一般的な集約を事前に計算するMaterialized Viewsを使用します。

例えば、ダッシュボードのボリューム関連グラフで使用するトークンの日次転送ボリュームを事前計算できます。

### オプション3: データレイク

データレイクは、大量の生データおよび処理済みブロックチェーンデータを長期的にアーカイブおよび分析クエリに保管するのに最適です。

シンプルな実装では、Amason Athenaと共にParquetデータフォーマットを使用します。

**Parquet**は効率的なデータストレージおよびリトリーバルのために設計された列指向データファイルフォーマットです。

**Amazon Athena**は標準SQLを使用してAmazon S3に保存されたデータを分析するインタラクティブなクエリサービスで、インフラストラクチャを設定したりデータを別のデータベースにロードする必要はありません。

<Warning>
  データレイクは、構造化されていない大規模なデータのクエリが必要な場合のみ推奨されます。ほとんどのユースケースには、SQLデータベース（オプション1）の使用をお勧めします。
</Warning>

#### 実装例：

トークン転送のアーカイブを作成し、それをクエリしたいと考えています。

まず、S3にそれらを保管する必要があります：`solana_index`という名前のバケットを作成し、このキー構造を使用してトークン転送データを時間で分割します：

```text theme={"system"}
s3://solana_index/token_transfers/YYYY/MM/DD/part-00000.parquet
```

各日の転送は対応する日付フォルダーの個別のParquetファイルに保存されます。

Solanaからの転送を処理する際、それらをParquetフォーマットに変換し、適切なS3オブジェクトに書き込みます。

その後、Athenaで[テーブルを作成](https://docs.aws.amazon.com/athena/latest/ug/step-2-create-a-table.html)し、それをバケットに接続します。これにより、バケット内のデータに対してこのような直接クエリが可能になります：

```sql theme={"system"}
SELECT block_time, signature, source_address, destination_address, amount
FROM token_transfers
WHERE token_mint = 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' AND block_time BETWEEN TIMESTAMP '2025-01-01 00:00:00' AND TIMESTAMP '2025-01-31 23:59:59';
```

### インデックスフレームワークの使用

[**Carbon**](https://github.com/sevenlabs-hq/carbon) および同様のフレームワークを使用して、ボイラープレートコードを作成することなく、インデクサーを数日で設定します。

#### 主な機能:

* 人気のプログラム（トークンプログラム、DeFiプロトコル、Metaplex）のための事前構築されたデコーダー
* 設定可能なデータソース（RPC, LaserStream, 強化WebSockets）
* バックフィルとリアルタイムストリーミングの両方をサポート
* 複数のストレージバックエンドへの出力（Postgresは標準で提供されます）
* 完全にカスタマイズ可能：独自のデータソース、デコーダー、データシンクをセットアップできます

## **ステップ3: インデックスを最新の状態に保つ**

履歴データをバックフィルした後、新しいブロックチェーンアクティビティでインデックスを最新に保つためのリアルタイムストリーミングソリューションが必要です。これがないと、インデックスは古くなります。

### 方法1: LaserStream（推奨）

すべてのプロダクションインデックスユースケースのデフォルトの選択肢として[LaserStream gRPC](/ja/laserstream/grpc)をお勧めします。これは信頼性が高く、超低遅延で耐障害のデータストリーミングを目的に設計されています。

LaserStreamを使用するいくつかの利点は次のとおりです：

* **24時間の履歴再生**：インデクサーが切断されても、LaserStreamは切断された場所からすべての未処理トランザクションを[自動的に再生](/ja/laserstream/historical-replay)します
* **自動再接続**：私たちの[LaserStream SDK](/ja/laserstream/clients)（Rust、Go、JS/TS）はネットワークの中断をシームレスに処理します
* \*\*ノードフ

ェイルオーバー\*\*：LaserStream接続は複数のノードから同時にデータを集約し、最大の稼働時間を保証します

速度と信頼性を兼ね備えているLaserStreamは、リアルタイムアプリケーション、ライブトランザクションフィード、取引ダッシュボード、インスタント残高更新に最適です。

#### インデックス化におけるLaserStreamの使用方法

ブロックチェーンイベントを購読するために[`subscribe`](/ja/api-reference/laserstream/grpc/subscribe)メソッドを使用します。

いくつかのベストプラクティスを以下に示します：

* **フィルタをできるだけ絞り込む**：索引に実際に必要なデータにのみ登録して、帯域幅の消費と必要な処理を最小限に抑える。
* **`confirmed`のコミットメントレベルを使用する**：これにより遅延と最終化のバランスが取れます。 `processed`レベルは信頼性が低すぎ、 `finalized`は約13秒の遅延を加えます。
* **`failed: false`を設定する**：失敗したトランザクションを追跡する必要がない場合。
* **投票トランザクションを除外する** (`vote: false`): インデックス化には関連しません。

例を見てみましょう。

すべての新しいトークン転送をインデックス化するために以下のサブスクリプションを使用します：

```ts theme={"system"}
{
  transactions: {
    "transfers": {
      vote: false,
      failed: false,
      accountsInclude: [
        '​​TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA',
        'TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb'
      ]
    }
  },
  commitment: CommitmentLevel.CONFIRMED,
  accounts: {},
  slots: {},
  transactionsStatus: {},
  blocks: {},
  blocksMeta: {},
  entry: {},
  accountsDataSlice: []
}
```

### 方法2: LaserStream WebSocketを使用

[LaserStream WebSocket](/ja/rpc/websocket) — LaserStreamのWebSocketバリアントで、Helius特有の`transactionSubscribe`拡張を含みます — LaserStream gRPCと同じバックエンドで動作し、gRPCが必要でない場合のコスト効果の高いリアルタイムストリーミングの代わりです。

LaserStream WebSocketを使用するべき場合：

* アプリケーションが時折のデータギャップを許容できる場合
* リアルタイムアップデートが重要だが、ミッションクリティカルでない場合
* 既存のインフラストラクチャがあり、欠落したデータの検出とバックフィルができる場合
* 予算の制約が大きく、ストリーミングコストを最小限に抑える必要がある場合
* LaserStreamの採用前にプロトタイプまたはテスト中の場合

ただし、WebSocketsを選ぶ際にはいくつかのトレードオフを考慮する必要があります：

* **速度**：LaserStream WebSocketはLaserStream gRPCと同じバックエンドで動作しますが、WebSocketプロトコルにはJSONフレーミングとメッセージごとのオーバーヘッドがあります。最低遅延を求めるなら[LaserStream gRPC](/ja/laserstream)を使用してください。
* **信頼性**：履歴の再生保証はありません。WebSocketが切断された場合、自動で検出し、RPCメソッドを使用して手動でギャップを埋める必要があります。
* **複雑性**：データ完全性を保証するために追加の監視インフラストラクチャが必要です。

#### WebSocketsを使ったインデックス化の方法

すべてのトークン転送を格納するインデックスを更新するには、[`transactionSubscribe`](/ja/rpc/websocket/transaction-subscribe)に次のように購読します：

```ts theme={"system"}
{
  jsonrpc: '2.0',
  id: 1,
  method: 'transactionSubscribe',
  params: [
    {
      failed: false,
      accountInclude: [
        '​​TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA',
        'TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb'
      ]
    },
    {
      commitment: 'confirmed',
      encoding: 'jsonParsed',
      transactionDetails: 'full',
      maxSupportedTransactionVersion: 0
    }
  ]
}
```

## 始める

堅牢なSolanaインデックスを構築し、データをバックフィルするためには、3つのコア課題を解決する必要があります：

1. 効率的な履歴データの取得
2. データを迅速に取得するための変換と保存
3. インデックス化されたSolanaデータをリアルタイムで更新し続けること

私たちの新しい[最先端のアーカイブシステム](https://www.helius.dev/blog/introducing-gettransactionsforaddress)、[`getTransactionsForAddress`](/ja/rpc/gettransactionsforaddress)のようなアーカイブコール、LaserStreamのような業界をリードするデータストリーミングソリューションを使用することで、Solanaインデックスの構築はこれまで以上に簡単で実用的になりました。

## 補完的オプション

独自のインデックスを運用することは完全な制御を提供しますが、それが常に必要であるわけではありません。一般的なニーズには、マネージドHelius APIがカスタムインデックスを置き換えるか、補完することがあります：

* **[DAS API](/ja/das-api)** ー NFT、代替可能トークン、圧縮資産（メタデータ、所有権、残高、オーナー／コレクション／クリエイターごとのクエリ）をインデックス化せずにクエリします。
* **[ウォレット API](/ja/wallet-api/overview)** ー ウォレットの残高、履歴、転送、アイデンティティに関する高レベルRESTエンドポイント、USD換算値、シンプルな応答形。

多くのチームがこれらをポートフォリオ、トークン、ウォレットデータのために使用し、マネージドAPIsがカバーしない特定目的のデータにカスタムインデックスを使用しています。

## 次のステップ

* [無料Heliusアカウントに登録](https://www.helius.dev)してAPIアクセスを取得
* [getTransactionsForAddressガイド](/ja/rpc/gettransactionsforaddress)を読んでバックフィル
* [LaserStream概要](/ja/laserstream)を探ってリアルタイムストリーミングを実現
* すべてのアーカイブ方法に関する[履歴データの概要](/ja/rpc/historical-data)を確認