> ## 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.

# So werden Solana-Daten indexiert

> Erfahren Sie, wie Sie Solana-Indizes erstellen, auffüllen und aktuell halten.

## Übersicht

Die Solana-Blockchain speichert Daten in einem sequenziellen, nur anhängbaren Ledger. Dies ist großartig für die Datenintegrität und den Transaktionsdurchsatz, hat aber einen erheblichen Nachteil: Es macht das Abfragen von [historischen Daten](/docs/de/rpc/historical-data) sehr ineffizient und prohibitively langsam.

Komplexe Operationen umfassen oft das Filtern, Aggregieren oder Verknüpfen von Daten aus mehreren Quellen. In diesen Fällen sind direkte Abfragen an Solana für die meisten realen Anwendungen unpraktisch.

Um dies zu lösen, erstellen die meisten Unternehmen private Indizes der historischen Daten von Solana.

Dieses Handbuch behandelt den gesamten Lebenszyklus: Auffüllen historischer Daten mit [`getTransactionsForAddress`](/docs/de/rpc/gettransactionsforaddress) und anderen archivierten RPC-Methoden, Auswahl einer Datenbank und Halten des Indexes mit Echtzeit-Streaming aktuell.

## Wann dies zu verwenden ist

Erstellen Sie einen Index, wenn:

* Ihr Produkt schnelle, gefilterte Abfragen benötigt, für die direkte RPC-Aufrufe zu langsam sind (z. B. die Token-Konten und Salden einer Wallet oder die vollständige Geschichte eines Handelspaars)
* Sie benötigen, um On-Chain-Daten zu filtern, zu aggregieren oder zu verknüpfen, oder um sie mit Off-Chain-Daten zu kombinieren (CEX-Preise, KYC, Labels)
* Sie berechnen Dinge wie PnL, Inhaberanalysen oder NFT-Verkaufsgeschichte, die vorverarbeitete, abfragbare Daten erfordern
* Sie bedienen viele Benutzer und können sich keine Latenz pro Anfrage gegen die Kette leisten

Wenn Sie nur standardmäßige Wallet- oder Asset-Daten benötigen, kann eine verwaltete API einfacher sein als das Ausführen eines eigenen Indexes. Siehe [Ergänzende Optionen](#nächste-schritte) unten.

## Was bedeutet Solana-Daten zu indexieren?

Indexierung ist der Prozess des Abfragens von Daten aus der Solana-Blockchain und deren Speicherung in einer Backend-Datenbank (z. B. PostgreSQL, ClickHouse), die dann verwendet werden kann, um Kundenanfragen ohne direkte Abfrage der Blockchain mit [Solana-RPC-Aufrufen](/docs/de/api-reference/rpc/http-methods) schnell zu bedienen.

Ein Indexer führt in der Regel vier Dinge aus:

1. **Historische Daten auffüllen:** Verwenden Sie [Archiv-RPC-Methoden](/docs/de/rpc/guides/overview#historische-daten-archiv), um alle historischen Daten abzufragen
2. **Neue Daten streamen:** Verarbeiten Sie neue Blöcke, wenn sie vom Netzwerk bestätigt werden
3. **Daten parsen und transformieren:** Extrahieren Sie relevante Daten aus den bestätigten Blöcken (z. B. Transaktionen, Zustandsänderungen usw.)
4. **Daten in eine Datenbank organisieren:** Aktualisieren Sie den Index mit den neuen Daten

### Warum erstellen die meisten Unternehmen Solana-Indizes?

Unternehmen erstellen Solana-Indizes, weil ihr Geschäft darauf angewiesen ist, schnellen, Echtzeitzugriff auf spezifische Blockchain-Daten zu bieten, die native RPCs nicht bieten (z. B. NFT-Verkaufsgeschichte).

Unternehmen nutzen auch benutzerdefinierte Indizes, um Off-Chain-Daten (z. B. Preise von zentralisierten Börsen, KYC-Informationen usw.) mit ihren On-Chain-Daten zu kombinieren.

#### Wallet-Beispiel

Wenn eine Solana-Wallet beispielsweise schnell die Token-Konten und Salden eines Benutzers zurückgeben muss, ist das Abfragen von Solana direkt mit [`getTokenAccountsByOwner`](/docs/de/api-reference/rpc/http/gettokenaccountsbyowner) und [`getTokenAccountBalance`](/docs/de/api-reference/rpc/http/gettokenaccountbalance) zu langsam und könnte ihr Produkt unbenutzbar machen. Stattdessen pflegen Wallets in der Regel eigene Indizes der Kundenadressen, Token und Kontostände.

#### Handelsbeispiel

Ähnlich könnte ein Krypto-Handelsunternehmen alle Handelsaktivitäten protokollieren wollen, die bei einem bestimmten Handelspaar (z. B. [SOL-USDC](https://orbmarkets.io/address/So11111111111111111111111111111111111111112/markets?sort_by=volume24h\&sort_type=desc)) oder einem bestimmten [Markt](https://orbmarkets.io/) auftreten, um ihre Handelsalgorithmen rückzutesten.

Das direkte Abfragen der Blockchain nach diesen Daten wäre viel zu langsam für jede praktische Handelsanalyse. Stattdessen könnten Quant-Trader entscheiden, Indizes für den SOL-USDC-Markt zu erstellen und ihn mit den neuesten Trades unter Verwendung von Echtzeit-Streaming-Produkten wie [LaserStream](/docs/de/laserstream) auf dem neuesten Stand zu halten.

#### Filterbeispiel

Stellen Sie sich vor, ein Benutzer möchte Transaktionen nach bestimmten Kriterien in seiner Frontend-Anwendung filtern (z. B. nach Tokentyp, Transferhöhe, Datum oder Wallet-Adresse).

Ohne einen Indexer müsste Ihre App Millionen von Transaktionen über Hunderttausende von Blöcken scannen und jeden gegen die Filterkriterien prüfen.

Dieser Prozess ist zu langsam für moderne Produkterlebnisse.

#### PnL-Beispiel

Um den Gewinn und Verlust (PnL) eines Traders zu berechnen, müssten Sie:

* Jede Transaktion in einem bestimmten Zeitraum, die mit seiner Wallet in Verbindung steht, finden
* Swap-Transaktionen herausfiltern und als Käufe oder Verkäufe markieren
* Bestimmen, wie viele Gebühren der Benutzer während jedes Swaps gezahlt hat
* Die historischen Preisdaten für jedes Token zum Zeitpunkt jedes Trades abrufen
* Den PnL jeder Transaktion aggregieren, um den Gesamterlös des Traders zu berechnen

Dies alles in Echtzeit zu berechnen, ist unpraktisch und erfordert eine schnellere, skalierbarere Lösung.

Mit einem Index sind all diese Informationen bereits verarbeitet und in einer abfragbaren Datenbank gespeichert. Jetzt wird das Berechnen des PnL eines Traders zu einem einzigen API-Aufruf, der sofort bedient wird.

Schauen wir uns drei Ansätze zum Auffüllen eines Solana-Indexes und dessen Aktualisierung an.

## Schritt 1: Holen Sie sich die historischen Daten

Der erste Schritt beim Erstellen eines Solana-Indexes besteht darin, alle historischen Daten zu erhalten, die Sie interessieren.

Es gibt drei Hauptwege, dies zu tun:

1. [**getTransactionsForAddress**](/docs/de/rpc/gettransactionsforaddress) (empfohlen)
2. [**getSignaturesForAddress**](/docs/de/rpc/guides/getsignaturesforaddress) und [**getTransaction**](/docs/de/rpc/guides/gettransaction)
3. [**getBlock**](/docs/de/rpc/guides/getblock)

### Methode 1: getTransactionsForAddress (empfohlen)

Die [`getTransactionsForAddress`](/docs/de/rpc/gettransactionsforaddress) RPC-Methode ermöglicht es Ihnen, die vollständigen Transaktionsdetails für ein beliebiges Segment von Blockchain-Daten abzurufen. Aufgrund ihrer leistungsstarken Filterfunktionen verschwenden Sie keine Zeit damit, Daten abzurufen, die für Ihren Index nicht benötigt werden. Und durch die umgekehrte Suchfunktion können Sie Transaktionen in chronologischer Reihenfolge abrufen.

#### Schritte zur Verwendung dieser Methode

* Bestimmen Sie den Zeitraum, für den Sie Daten benötigen, und setzen Sie den Filter entsprechend
* Setzen Sie `transactionDetails` auf `full`, um alle Transaktionsdetails abzurufen
* Konfigurieren Sie den `tokenAccounts` Filter, um bei Bedarf Transaktionen mit zugehörigen Token-Konten einzuschließen
* Paginieren Sie durch die Ergebnisse mithilfe von `paginationToken`
* Extrahieren Sie bei jeder Iteration die benötigten Daten und speichern Sie sie in Ihrer Datenbank

#### Vorteile der Verwendung von getTransactionsForAddress

Die Hauptvorteile der Verwendung des [gTFA-Endpunkts](/docs/de/api-reference/rpc/http/gettransactionsforaddress) sind Geschwindigkeit und Einfachheit. Mit slot- und zeitbasierten Filtern, Unterstützung von Token-Konten, umgekehrter Suche und Paginierung können Sie alle Daten abrufen, die Sie möchten, aus jeder Zeit in der Solana-Geschichte, alles mit einem einzigen Aufruf ohne komplexe Schleifen oder Wiederholungslogik. Im Gegensatz zu [`getSignaturesForAddress`](/docs/de/rpc/guides/getsignaturesforaddress) kann es auch Transaktionen mit zugehörigen Token-Konten enthalten, die der Adresse gehören.

Wenn sich Ihr Index speziell mit der Bewegung von Token und nativem SOL befasst (Zahlungen, Kontenabgleiche, Saldenabstimmung), gibt [`getTransfersByAddress`](/docs/de/rpc/gettransfersbyaddress) geparste, abgleichbereite Transferzeilen anstelle von vollständigen Transaktionen zurück, was Ihnen einen Parsing-Schritt ersparen kann.

### Methode 2: getSignaturesForAddress und getTransaction

Vor der Veröffentlichung von gTFA war der Standardansatz zur Abfrage historischer Daten, rekursiv über Signaturen mit [`getSignaturesForAddress`](/docs/de/rpc/guides/getsignaturesforaddress) (von neu nach alt) zu schleifen und dann [`getTransaction`](/docs/de/rpc/guides/gettransaction) aufzurufen, um die vollständigen Transaktionsdetails zu extrahieren.

#### Schritte zur Verwendung dieser Methode

Hier sind die grundlegenden Schritte zur Verwendung dieser Methode:

* Aufruf von `getSignaturesForAddress`
* Speichern der Signatur der letzten empfangenen Transaktion dieses Aufrufs
* Für den nächsten Aufruf von `getSignaturesForAddress`, setzen Sie den `before` Parameter auf diese Signatur
* Wiederholen Sie dies in einer Schleife, solange es erforderlich ist
* Für jede auf diese Weise abgerufene Transaktionssignatur rufen Sie `getTransaction` auf, um die vollständigen Transaktionsdetails zu erhalten
* Die relevanten Daten in Ihrer Datenbank einfügen

#### Nachteile dieser Methode

Leider müssen Sie bei Verwendung dieser Methode:

* Bei der neuesten Transaktion beginnen und rückwärts arbeiten
* Einen zusätzlichen RPC-Aufruf für jede Transaktion machen
* Eine threadsichere Warteschlange für die gleichzeitige Verarbeitung aufbauen
* Logik für Wiederholungen und Zurücksetzungen aufbauen, um verpasste Daten zu vermeiden und nicht rate-limitiert zu werden
* Transaktionen mit zugehörigen Token-Konten, die der Adresse gehören, nicht einschließen

Obwohl diese Methode funktioniert, ist sie komplizierter, weniger flexibel und verbraucht viel mehr [Credits](/docs/de/billing/credits). Für eine vollständige Wallet-Geschichte, einschließlich Token-Konten, verwenden Sie [`getTransactionsForAddress`](/docs/de/rpc/gettransactionsforaddress) stattdessen.

### Methode 3: Verwendung von getBlock

Die [`getBlock`](/docs/de/rpc/guides/getblock) Methode ist am effektivsten, wenn ein hoher Prozentsatz der Transaktionen in Ihren Zielblöcken für Ihre Analyse relevant ist, wie z. B. das Indexieren der Transaktionen von [häufig verwendeten Solana-Programmen](/docs/de/orb/explore-programs) wie DFlows Aggregator, das Pump.fun-Programm oder Solanas Token-Programm.

#### Schritte zur Verwendung dieser Methode

Der grundlegende Prozess zum Abfragen historischer Daten mit `getBlock` umfasst:

* Entscheiden Sie sich für einen Zeitrahmen, den Sie abfragen möchten
* Konvertieren Sie diesen Zeitrahmen in Slot-Nummern
* Abrufen der entsprechenden Blöcke sequentiell (vorwärts oder rückwärts)
* Filtern Sie für jeden Block die Transaktionen, die für Ihren Index relevant sind
* Speichern Sie die relevanten Informationen daraus in Ihrem Index

Für die meisten Anwendungsfälle ist diese Methode von Natur aus verschwenderisch, da Sie alle Transaktionen in einem Block abrufen, während in der Regel nur ein kleiner Bruchteil für Ihre Analyse relevant ist.

Verwenden Sie diese Methode nur dann, wenn Sie die Transaktionen häufig verwendeter Programme untersuchen oder wenn die Adress-basierte Filterung Ihre Ziel-Daten nicht erfassen kann.

## Schritt 2: Synchronisieren Sie Solana-Daten mit Ihrer Datenbank

Nach dem Abrufen historischer Daten müssen Sie diese transformieren und effizient in einer Datenbank speichern.

**Ihre Speicherwahl sollte auf Ihren spezifischen Anwendungsfall zugeschnitten sein** — es gibt keine Universallösung. Die richtige Datenbank hängt von der Größe Ihres Datensatzes, den Latenzanforderungen, den Abfragemustern und der Expertise Ihres Teams ab.

### Option 1: SQL-Datenbanken

Es wird empfohlen, Solana-Daten in relationalen Datenbanken wie PostgreSQL zu speichern, da SQL flexibel, allgegenwärtig und einfach zu erlernen ist. Moderne relationale Datenbanken können auf über 100 Mio.+ Zeilen skaliert werden und bieten Ihnen dennoch die Vorteile von ACID-Konformität, komplexen Joins und leistungsstarken sekundären Indizes.

Verwenden Sie **SQLite** für Prototyping, lokale Entwicklung oder wenn Sie keine Konfiguration mit einer Ein-Datei-Datenbank möchten. Sie ist ideal, wenn Ihr Datensatz unter ein paar Gigabyte bleibt.

Verwenden Sie **PostgreSQL** für produktionsreife Anwendungen, die Datenreplikation, gleichzeitigen Zugriff von mehreren Clients oder erweiterte Funktionen wie Volltextsuchen und JSON-Operatoren benötigen.

Für die meisten produktionsfähigen Solana-Indexer ist PostgreSQL unsere empfohlene Wahl.

#### Implementierungsbeispiel:

Als Beispiel zeigen wir, wie Token-Transfers in einer PostgreSQL-Datenbank gespeichert werden.

Erstellen Sie zunächst eine Tabelle:

```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
);
```

Fügen Sie dann Indizes auf häufig abgefragten Spalten hinzu:

```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);
```

Sie können auch Teilindizes erstellen, falls nur ein Teil der Daten häufig abgefragt wird.

So erstellen Sie beispielsweise einen Index nur für hochpreisige Transfers:

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

Stellen Sie beim Auffüllen von Daten sicher, dass Sie Bulk INSERTs und vorbereitete Anweisungen für optimale Schreibgeschwindigkeit verwenden.

### Option 2: Säulendatenbanken

Säulendatenbanken sind für analytische Abfragen, Aggregationen und umfangreiche Zeitreihendaten optimiert. Wenn Sie mehrere Milliarden Transaktionen indexieren müssen, sind Säulendatenbanken wie ClickHouse oder Cassandra die beste Option.

Verwenden Sie **ClickHouse**, wenn Sie Echtzeitanalysen auf großen Datensätzen benötigen — es ist optimiert für schnelle Lesezugriffe, Aggregationen und Zeitreihenanalysen.

Verwenden Sie **Cassandra**, wenn Sie extrem hohen Schreibdurchsatz, mühelose horizontale Skalierung und hohe Fehlertoleranz benötigen. Dies macht es ideal für die kontinuierliche Aufnahme massiver Volumen von Solana-Daten.

#### Implementierungsbeispiel:

Wir zeigen, wie man Token-Transfers in einer ClickHouse-Datenbank speichert.

Erstellen Sie zu diesem Zweck eine Tabelle, die die [MergeTree-Tabellen-Engine](https://clickhouse.com/docs/engines/table-engines/mergetree-family/mergetree) verwendet. Sie ist auf hohe Ingest-Raten ausgelegt, daher ideal zum Indexieren.

Verwenden Sie diesen Befehl:

```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;
```

In diesem Setup wird `(token_mint, date)` sowohl als Primärschlüssel als auch als Sortierschlüssel gesetzt. ClickHouse ordnet die Daten auf der Festplatte entsprechend Ihrem Sortierschlüssel. Dies ist optimal zum Abfragen eines einzelnen [Token-Mints](/docs/de/orb/explore-mint-addresses) und zum Eingrenzen der Antwort nach Datumsbereichen.

Hier ist eine Beispielabfrage:

```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'
```

Transaktionssignaturen und -adressen werden mit dem `FixedString(N)`-Datenformat gespeichert, das genau N Bytes speichert. ClickHouse komprimiert Daten automatisch, was die Speicherkosten um 10-20x reduziert und die Abfrageleistung verbessert.

Um die Abfrageleistung zu optimieren, verwenden Sie materialisierte Ansichten, um häufige Aggregationen vorab zu berechnen.

Sie können beispielsweise das tägliche Transfer-Volumen von Tokens vorab berechnen, das von volumenbezogenen Diagrammen auf einem Dashboard verwendet wird.

### Option 3: Datenseen

Datenseen sind ideal zum Speichern riesiger Mengen roher und verarbeiteter Blockchain-Daten für langfristige Archivierung und analytische Abfragen geeignet.

Eine einfache Implementierung verwendet das Parquet-Datenformat mit Amazon Athena.

**Parquet** ist ein spaltenorientiertes Dateiformat, das für effiziente Datenspeicherung und -abruf entwickelt wurde.

**Amazon Athena** ist ein interaktiver Abfrageservice, der es Ihnen ermöglicht, Daten, die in Amazon S3 gespeichert sind, mithilfe von Standard-SQL zu analysieren, ohne Infrastruktur einzurichten oder die Daten in eine separate Datenbank zu laden.

<Warning>
  Datenseen werden nur empfohlen, wenn Sie große Mengen unstrukturierter Daten abfragen müssen. Für die meisten Anwendungsfälle empfehlen wir die Verwendung einer SQL-Datenbank (Option 1).
</Warning>

#### Implementierungsbeispiel:

Wir möchten ein Archiv von Token-Transfers erstellen und abfragen.

Zuerst müssen wir sie in S3 speichern: Erstellen Sie einen Bucket namens `solana_index` und partitionieren Sie Ihre Token-Transfer-Daten nach Zeit mit dieser Schlüsselstruktur:

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

Die Transfers jedes Tages werden in einer separaten Parquet-Datei in ihrem entsprechenden Datumsordner gespeichert.

Während Sie Transfers von Solana verarbeiten, transformieren Sie sie in das Parquet-Format und schreiben Sie sie in das jeweilige S3-Objekt.

Später [erstellen Sie eine Tabelle](https://docs.aws.amazon.com/athena/latest/ug/step-2-create-a-table.html) in Athena und verbinden diese mit dem Bucket. Dies ermöglicht es Ihnen, Abfragen wie diese direkt auf den Daten im Bucket auszuführen:

```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';
```

### Verwenden Sie Indexierungs-Frameworks

Verwenden Sie [**Carbon**](https://github.com/sevenlabs-hq/carbon) und ähnliche Frameworks, um Boilerplate-Code zu vermeiden und Ihren Indexer in Stunden statt Tagen einzurichten.

#### Hauptmerkmale:

* Vorgefertigte Decoder für beliebte Programme (Token-Programm, DeFi-Protokolle, Metaplex)
* Konfigurierbare Datenquellen (RPC, LaserStream, erweiterte WebSockets)
* Eingebauter Support für sowohl Auffüllen als auch Echtzeit-Streaming
* Ausgaben an mehrere Speichersysteme (Postgres ist bereits integriert)
* Vollständig anpassbar: Sie können Ihre eigenen Datenquellen, Decoder und Data Sinks einrichten

## **Schritt 3: Halten Sie Ihren Index auf dem neuesten Stand**

Nach dem Auffüllen historischer Daten benötigen Sie eine Echtzeit-Streaming-Lösung, um Ihren Index mit neuen Blockchain-Aktivitäten auf dem neuesten Stand zu halten. Andernfalls wird Ihr Index veraltet.

### Methode 1: LaserStream (empfohlen)

Wir empfehlen [LaserStream gRPC](/docs/de/laserstream/grpc) als Standardwahl für alle produktionsrelevanten Indexierungsfälle. Es ist speziell für zuverlässiges, extrem latenzarmes und fehlertolerantes Datenstreaming entwickelt.

Einige Vorteile der Nutzung von LaserStream sind:

* **24-Stunden-Wiederholung**: Wenn Ihr Indexer die Verbindung verliert, spielt LaserStream [automatisch alle verpassten Transaktionen](/docs/de/laserstream/historical-replay) vom letzten Stand ab
* **Automatische Wiederverbindung**: Unsere [LaserStream SDKs](/docs/de/laserstream/clients) (Rust, Go, JS/TS) handhaben Netzwerkunterbrechungen nahtlos für Sie
* **Node-Failover**: Ihre LaserStream-Verbindung aggregiert Daten von mehreren Nodes gleichzeitig, um maximale Betriebszeit sicherzustellen

Durch die Kombination aus Geschwindigkeit und Zuverlässigkeit ist LaserStream ideal für Echtzeitanwendungen wie Live-Transaktionsfeeds, Handels-Dashboards und sofortige Saldenaktualisierungen.

#### Wie man LaserStream für die Indexierung verwendet

Verwenden Sie die [`subscribe`](/docs/de/api-reference/laserstream/grpc/subscribe) Methode, um sich bei Blockchain-Ereignissen zu abonnieren.

Hier einige bewährte Verfahren:

* **Verfeinern Sie Ihren Filter so weit wie möglich**: Abonnieren Sie nur die Daten, die Sie tatsächlich indexieren müssen, um den Bandbreitenverbrauch und die erforderliche Verarbeitung zu minimieren.
* **Verwenden Sie das `confirmed`-Verpflichtungsniveau**: Dies balanciert Latenz und Finalität. Das `processed` Niveau könnte zu unzuverlässig sein, während `finalized` etwa 13 Sekunden Latenz hinzufügt
* **Setzen Sie `failed: false`**, es sei denn, Sie müssen gescheiterte Transaktionen verfolgen
* **Schließen Sie Abstimmungstransaktionen** (`vote: false`) aus, da sie nicht für das Indexieren relevant sind

Schauen wir uns ein Beispiel an.

Verwenden Sie das folgende Abonnement, um alle neuen Token-Transfers zu indexieren:

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

### Methode 2: Verwenden von LaserStream WebSocket

[LaserStream WebSocket](/docs/de/rpc/websocket) — die WebSocket-Variante von LaserStream, einschließlich der Helius-spezifischen `transactionSubscribe`-Erweiterung — läuft auf dem gleichen Backend wie LaserStream gRPC und ist eine kostengünstige Echtzeit-Streaming-Alternative, wenn Sie kein gRPC benötigen.

Sie sollten LaserStream WebSocket verwenden, wenn:

* Ihre Anwendung gelegentliche Datenlücken tolerieren kann
* Echtzeit-Updates wichtig, aber nicht geschäftskritisch sind
* Sie bereits vorhandene Infrastruktur haben, um fehlende Daten zu erkennen und aufzufüllen
* Budgetbeschränkungen erheblich sind und Sie die Streaming-Kosten minimieren müssen
* Sie Prototyping oder Tests durchführen, bevor Sie sich für LaserStream entscheiden

Es gibt jedoch einige Kompromisse, die berücksichtigt werden müssen, wenn Sie sich für WebSockets entscheiden:

* **Geschwindigkeit**: LaserStream WebSocket läuft auf dem gleichen Backend wie LaserStream gRPC, aber das WebSocket-Protokoll fügt JSON-Framing und Overhead pro Nachricht hinzu — für die niedrigstmögliche Latenz bei den gleichen Daten verwenden Sie [LaserStream gRPC](/docs/de/laserstream)
* **Zuverlässigkeit**: Keine Garantie für die wiederholte Wiedergabe. Wenn Ihre WebSocket-Verbindung getrennt wird, müssen Sie manuell Lücken mit Hilfe von RPC-Methoden erkennen und auffüllen
* **Komplexität**: Erfordert zusätzliche Überwachungsinfrastruktur, um die Vollständigkeit der Daten sicherzustellen

#### Wie man WebSockets für die Indexierung verwendet

Um einen Index zu aktualisieren, der alle Token-Transfers speichert, würden Sie sich bei [`transactionSubscribe`](/docs/de/rpc/websocket/transaction-subscribe) wie folgt abonnieren:

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

## Erste Schritte

Der Aufbau eines robusten Solana-Index und das Auffüllen von Daten erfordert die Lösung von drei zentralen Herausforderungen:

1. Effizientes Abrufen historischer Daten
2. Transformieren und Speichern von Daten für schnelle Abrufe
3. Halten Sie indexierte Solana-Daten in Echtzeit auf dem neuesten Stand

Mit unserem neuen [hochmodernen Archival-System](https://www.helius.dev/blog/introducing-gettransactionsforaddress), Archivaufrufe wie [`getTransactionsForAddress`](/docs/de/rpc/gettransactionsforaddress) und branchenführenden Daten-Streaming-Lösungen wie LaserStream ist das Erstellen eines Solana-Index einfacher und praktikabler als je zuvor.

## Ergänzende Optionen

Der Betrieb eines eigenen Indexes gibt Ihnen die volle Kontrolle, ist jedoch nicht immer notwendig. Für gemeinsame Bedürfnisse kann eine verwaltete Helius-API einen benutzerdefinierten Index ersetzen oder ergänzen:

* **[DAS API](/docs/de/das-api)** — Abfrage von NFTs, Fungible Tokens und komprimierten Assets (Metadaten, Eigentum, Salden, nach Eigentümer/Sammlung/Ersteller), ohne Asset-Daten selbst indexieren zu müssen.
* **[Wallet API](/docs/de/wallet-api/overview)** — High-Level-REST-Endpunkte für Wallet-Salden, Verlauf, Übertragungen und Identität, mit USD-Werten und einer einfacheren Antwortform.

Viele Teams verwenden diese für Portfolio-, Token- und Wallet-Daten und reservieren einen benutzerdefinierten Index für zweckbezogene Daten, die die verwalteten APIs nicht abdecken.

## Nächste Schritte

* [Melden Sie sich für ein kostenloses Helius-Konto an](https://www.helius.dev), um API-Zugriff zu erhalten
* Lesen Sie den [getTransactionsForAddress-Leitfaden](/docs/de/rpc/gettransactionsforaddress) zum Auffüllen
* Erkunden Sie die [LaserStream-Übersicht](/docs/de/laserstream) für Echtzeit-Streaming
* Überprüfen Sie die [Übersicht über historische Daten](/docs/de/rpc/historical-data) für alle Archivierungsmethoden