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

# Cara Mengindeks Data Solana

> Pelajari cara membangun, mengisi data historis, dan menjaga indeks Solana tetap mutakhir.

## Gambaran umum

Blockchain Solana menyimpan data dalam ledger berurutan yang hanya dapat ditambahi. Pendekatan ini sangat baik untuk integritas data dan throughput transaksi, tetapi memiliki konsekuensi besar: kueri [data historis](/docs/id/rpc/historical-data) menjadi sangat tidak efisien dan sangat lambat.

Operasi kompleks sering kali melibatkan pemfilteran, agregasi, atau penggabungan data dari beberapa sumber. Dalam kasus ini, membuat kueri langsung ke Solana tidak praktis untuk sebagian besar aplikasi dunia nyata.

Untuk mengatasinya, sebagian besar bisnis membangun indeks privat untuk data historis Solana.

Panduan ini mencakup seluruh siklus proses: mengisi data historis dengan [`getTransactionsForAddress`](/docs/id/rpc/gettransactionsforaddress) dan metode RPC arsip lainnya, memilih basis data, serta menjaga indeks tetap mutakhir melalui streaming waktu nyata.

## Kapan harus menggunakannya

Bangun indeks jika:

* Produk Anda membutuhkan kueri terfilter yang cepat, sementara panggilan RPC langsung terlalu lambat (misalnya akun token dan saldo dompet, atau riwayat lengkap pasangan perdagangan)
* Anda perlu memfilter, mengagregasi, atau menggabungkan data on-chain, maupun menggabungkannya dengan data off-chain (harga CEX, KYC, label)
* Anda menghitung hal-hal seperti PnL, analitik pemegang, atau riwayat penjualan NFT yang memerlukan data praproses dan dapat dikueri
* Anda melayani banyak pengguna dan tidak dapat menanggung latensi per permintaan saat mengakses blockchain

Jika Anda hanya memerlukan data dompet atau aset standar, API terkelola mungkin lebih sederhana daripada menjalankan indeks sendiri. Lihat [Opsi pelengkap](#langkah-berikutnya) di bawah.

## Apa arti pengindeksan data Solana?

Pengindeksan adalah proses membuat kueri data dari blockchain Solana dan menyimpannya dalam basis data backend (misalnya PostgreSQL, ClickHouse), yang kemudian dapat digunakan untuk langsung melayani permintaan pelanggan tanpa perlu membuat kueri langsung ke blockchain menggunakan [panggilan RPC Solana](/docs/id/api-reference/rpc/http-methods).

Pengindeks biasanya melakukan empat hal:

1. **Mengisi data historis:** gunakan [metode RPC arsip](/docs/id/rpc/guides/overview#data-historis-arsip) untuk membuat kueri atas semua data historis
2. **Melakukan streaming data baru:** proses blok baru ketika dikonfirmasi oleh jaringan
3. **Mengurai dan mentransformasi data:** ekstrak data yang relevan dari blok yang telah dikonfirmasi (misalnya transaksi, perubahan status, dan sebagainya)
4. **Mengatur data ke dalam basis data:** perbarui indeks dengan data baru

### Mengapa sebagian besar perusahaan membangun indeks Solana?

Perusahaan membangun indeks Solana karena bisnis mereka bergantung pada penyediaan akses cepat dan waktu nyata ke data blockchain dengan tujuan khusus yang tidak disediakan oleh RPC native (misalnya riwayat penjualan NFT).

Perusahaan juga memanfaatkan indeks khusus untuk menggabungkan data off-chain (misalnya harga Bursa Terpusat, informasi KYC, dan sebagainya) dengan data on-chain mereka.

#### Contoh Dompet

Misalnya, jika dompet Solana perlu menampilkan akun token dan saldo pengguna dengan cepat, membuat kueri langsung ke Solana dengan [`getTokenAccountsByOwner`](/docs/id/api-reference/rpc/http/gettokenaccountsbyowner) dan [`getTokenAccountBalance`](/docs/id/api-reference/rpc/http/gettokenaccountbalance) terlalu lambat dan dapat membuat produk tidak dapat digunakan. Sebagai gantinya, dompet biasanya memelihara indeksnya sendiri untuk alamat pelanggan, token, dan saldo akun.

#### Contoh Perdagangan

Demikian pula, perusahaan perdagangan kripto mungkin ingin mencatat semua aktivitas perdagangan yang terjadi pada pasangan perdagangan tertentu (misalnya [SOL-USDC](https://orbmarkets.io/address/So11111111111111111111111111111111111111112/markets?sort_by=volume24h\&sort_type=desc)) atau [pasar](https://orbmarkets.io/) tertentu untuk menguji ulang algoritma perdagangannya.

Membuat kueri langsung ke blockchain untuk data ini akan terlalu lambat bagi analisis perdagangan praktis apa pun. Sebagai gantinya, pedagang kuantitatif dapat memilih untuk membangun indeks bagi pasar SOL-USDC dan terus memperbaruinya dengan perdagangan terbaru menggunakan produk streaming waktu nyata seperti [LaserStream](/docs/id/laserstream).

#### Contoh Pemfilteran

Bayangkan seorang pengguna ingin memfilter transaksi berdasarkan kriteria tertentu dalam aplikasi frontend mereka (misalnya berdasarkan jenis token, jumlah transfer, tanggal, atau alamat dompet).

Tanpa pengindeks, aplikasi Anda harus memindai jutaan transaksi di ratusan ribu blok dan memeriksa masing-masing transaksi berdasarkan kriteria filter.

Proses ini terlalu lambat untuk pengalaman pengguna produk modern.

#### Contoh PnL

Untuk menghitung laba dan rugi (PnL) pedagang, Anda perlu:

* Menemukan setiap transaksi yang terkait dengan dompet mereka dalam rentang waktu tertentu
* Memfilter transaksi swap dan melabelinya sebagai pembelian atau penjualan
* Menentukan jumlah biaya yang dibayar pengguna selama setiap swap
* Mendapatkan data harga historis untuk setiap token pada saat masing-masing perdagangan
* Mengagregasikan PnL setiap transaksi untuk menghitung total PnL pedagang

Menghitung semua ini secara waktu nyata tidak praktis dan memerlukan solusi yang lebih cepat serta lebih skalabel.

Dengan indeks, semua informasi ini telah diproses dan disimpan dalam basis data yang dapat dikueri. Kini, penghitungan PnL pedagang cukup dilakukan melalui satu panggilan API yang dilayani seketika.

Mari kita lihat tiga pendekatan untuk mengisi data historis indeks Solana dan menjaganya tetap mutakhir.

## Langkah 1: Dapatkan data historis

Langkah pertama untuk membangun indeks Solana adalah mendapatkan semua data historis yang Anda perlukan.

Ada tiga cara utama untuk melakukannya:

1. [**getTransactionsForAddress**](/docs/id/rpc/gettransactionsforaddress) (direkomendasikan)
2. [**getSignaturesForAddress**](/docs/id/rpc/guides/getsignaturesforaddress) dan [**getTransaction**](/docs/id/rpc/guides/gettransaction)
3. [**getBlock**](/docs/id/rpc/guides/getblock)

### Metode 1: getTransactionsForAddress (direkomendasikan)

Metode RPC [`getTransactionsForAddress`](/docs/id/rpc/gettransactionsforaddress) memungkinkan Anda mengambil detail transaksi lengkap untuk segmen data blockchain mana pun. Berkat kemampuan pemfilterannya yang andal, Anda tidak akan membuang waktu untuk mengambil data yang tidak diperlukan oleh indeks. Selain itu, fungsi pencarian terbaliknya memungkinkan Anda mendapatkan transaksi dalam urutan kronologis.

#### Langkah-langkah menggunakan metode ini

* Tentukan rentang waktu data yang Anda perlukan dan atur filternya
* Atur `transactionDetails` menjadi `full` untuk mendapatkan semua detail transaksi
* Konfigurasikan filter `tokenAccounts` untuk menyertakan transaksi akun token terkait jika diperlukan
* Lakukan paginasi hasil menggunakan `paginationToken`
* Pada setiap iterasi, ekstrak data yang Anda perlukan dan simpan dalam basis data

#### Manfaat menggunakan getTransactionsForAddress

Keunggulan utama penggunaan [endpoint gTFA](/docs/id/api-reference/rpc/http/gettransactionsforaddress) adalah kecepatan dan kesederhanaan. Dengan filter berbasis slot dan waktu, dukungan akun token, pencarian terbalik, serta paginasi, Anda dapat memperoleh data apa pun yang diinginkan dari kapan pun dalam riwayat Solana, semuanya dengan satu panggilan tanpa perulangan kompleks atau logika percobaan ulang. Tidak seperti [`getSignaturesForAddress`](/docs/id/rpc/guides/getsignaturesforaddress), metode ini juga dapat menyertakan transaksi yang melibatkan akun token terkait milik alamat tersebut.

Jika indeks Anda secara khusus berkaitan dengan pergerakan token dan SOL native (pembayaran, ledger, rekonsiliasi saldo), [`getTransfersByAddress`](/docs/id/rpc/gettransfersbyaddress) menampilkan baris transfer yang telah diurai dan siap direkonsiliasi, bukan transaksi lengkap. Dengan demikian, Anda dapat menghemat satu langkah penguraian.

### Metode 2: getSignaturesForAddress dan getTransaction

Sebelum gTFA dirilis, pendekatan standar untuk membuat kueri data historis adalah melakukan perulangan rekursif atas tanda tangan menggunakan [`getSignaturesForAddress`](/docs/id/rpc/guides/getsignaturesforaddress) (dari yang terbaru hingga terlama), lalu memanggil [`getTransaction`](/docs/id/rpc/guides/gettransaction) untuk mengekstrak detail transaksi lengkap.

#### Langkah-langkah menggunakan metode ini

Berikut langkah-langkah dasar untuk menggunakan metode ini:

* Panggil `getSignaturesForAddress`
* Simpan tanda tangan transaksi terakhir yang diterima dari panggilan ini
* Untuk panggilan `getSignaturesForAddress` berikutnya, atur parameter `before` ke tanda tangan ini
* Ulangi dalam perulangan selama diperlukan
* Untuk setiap tanda tangan transaksi yang diambil dengan cara ini, panggil `getTransaction` guna mendapatkan detail transaksi lengkapnya
* Masukkan data yang relevan ke dalam basis data

#### Kekurangan metode ini

Sayangnya, untuk menggunakan metode ini Anda perlu:

* Memulai dari transaksi terbaru dan bergerak mundur
* Membuat satu panggilan RPC tambahan untuk setiap transaksi
* Membuat antrean yang aman untuk thread guna menangani pemrosesan serentak
* Membuat logika percobaan ulang dan backoff untuk mencegah data terlewat dan terkena pembatasan laju
* Tidak menyertakan transaksi yang melibatkan akun token terkait milik alamat tersebut

Meskipun metode ini berfungsi, metode ini lebih rumit, kurang fleksibel, dan menghabiskan jauh lebih banyak [kredit](/docs/id/billing/credits). Untuk riwayat dompet lengkap yang mencakup akun token, gunakan [`getTransactionsForAddress`](/docs/id/rpc/gettransactionsforaddress).

### Metode 3: Gunakan getBlock

Metode [`getBlock`](/docs/id/rpc/guides/getblock) paling efektif ketika persentase tinggi transaksi dalam blok target relevan dengan analisis Anda, seperti saat mengindeks transaksi [program Solana yang sering digunakan](/docs/id/orb/explore-programs), misalnya Aggregator milik DFlow, program Pump.fun, atau program Token Solana.

#### Langkah-langkah menggunakan metode ini

Proses dasar untuk membuat kueri data historis dengan `getBlock` meliputi:

* Tentukan rentang waktu yang akan dikueri
* Konversikan rentang waktu ini menjadi nomor slot
* Ambil blok yang sesuai secara berurutan (maju atau mundur)
* Untuk setiap blok, filter transaksi yang relevan dengan indeks Anda
* Simpan informasi yang relevan dari transaksi tersebut dalam indeks

Untuk sebagian besar kasus penggunaan, metode ini pada dasarnya boros karena Anda mengambil semua transaksi dalam suatu blok, padahal biasanya hanya sebagian kecil yang relevan dengan analisis.

Gunakan metode ini hanya saat Anda memeriksa transaksi program yang sering digunakan atau ketika pemfilteran berbasis alamat tidak dapat menangkap data target.

## Langkah 2: Sinkronkan data Solana dengan basis data Anda

Setelah mengambil data historis, Anda perlu mentransformasi dan menyimpannya secara efisien dalam basis data.

**Pilihan penyimpanan harus disesuaikan dengan kasus penggunaan spesifik Anda** — tidak ada satu solusi yang cocok untuk semuanya. Basis data yang tepat bergantung pada ukuran set data, persyaratan latensi, pola kueri, dan keahlian tim.

### Opsi 1: Basis Data SQL

Menyimpan data Solana dalam basis data relasional seperti PostgreSQL direkomendasikan untuk sebagian besar kasus penggunaan. SQL fleksibel, tersedia luas, dan mudah dipelajari. Basis data relasional modern dapat diskalakan hingga lebih dari 100 juta baris, sekaligus tetap menawarkan manfaat kepatuhan ACID, penggabungan kompleks, dan indeks sekunder yang andal.

Gunakan **SQLite** untuk pembuatan prototipe, pengembangan lokal, atau ketika Anda menginginkan konfigurasi nol dengan basis data satu file. SQLite ideal jika set data Anda tetap berukuran di bawah beberapa gigabita.

Gunakan **PostgreSQL** untuk aplikasi produksi yang memerlukan replikasi data, akses serentak dari beberapa klien, atau fitur lanjutan seperti pencarian teks lengkap dan operator JSON.

Untuk sebagian besar pengindeks Solana tingkat produksi, PostgreSQL adalah pilihan yang kami rekomendasikan.

#### Contoh implementasi:

Sebagai contoh, kami akan menunjukkan cara menyimpan transfer token dalam basis data PostgreSQL.

Pertama, buat tabel:

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

Kemudian, tambahkan indeks pada kolom yang sering dikueri:

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

Anda juga dapat membuat indeks parsial jika hanya sebagian data yang sering dikueri.

Berikut cara membuat indeks khusus untuk transfer bernilai tinggi:

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

Saat mengisi data historis, pastikan Anda menggunakan INSERT massal dan pernyataan yang telah disiapkan untuk memperoleh kecepatan penulisan optimal.

### Opsi 2: Basis Data Kolumnar

Basis data kolumnar dioptimalkan untuk kueri analitis, agregasi, dan data deret waktu bervolume tinggi. Jika Anda perlu mengindeks beberapa miliar transaksi, basis data kolumnar seperti ClickHouse atau Cassandra adalah pilihan terbaik.

Gunakan **ClickHouse** saat Anda memerlukan kueri analitis waktu nyata pada set data besar — ClickHouse dioptimalkan untuk pembacaan cepat, agregasi, dan analisis deret waktu.

Gunakan **Cassandra** saat Anda memerlukan throughput penulisan yang sangat tinggi, penskalaan horizontal yang mudah, dan toleransi kesalahan tinggi. Hal ini menjadikannya ideal untuk terus menyerap data Solana dalam volume sangat besar.

#### Contoh implementasi:

Kami akan menunjukkan cara menyimpan transfer token dalam basis data ClickHouse.

Untuk tujuan ini, buat tabel yang menggunakan [mesin tabel MergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/mergetree). Mesin ini dirancang untuk laju penyerapan tinggi sehingga ideal untuk pengindeksan.

Gunakan perintah ini:

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

Dalam konfigurasi ini, `(token_mint, date)` ditetapkan sebagai kunci primer sekaligus kunci pengurutan. ClickHouse akan mengurutkan data pada disk sesuai dengan kunci pengurutan Anda. Cara ini optimal untuk membuat kueri atas satu [pencetakan token](/docs/id/orb/explore-mint-addresses) dan mempersempit respons berdasarkan rentang tanggal.

Berikut contoh kuerinya:

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

Tanda tangan dan alamat transaksi disimpan menggunakan format data `FixedString(N)`, yang menyimpan tepat N bita. ClickHouse mengompresi data secara otomatis, sehingga mengurangi biaya penyimpanan sebanyak 10–20 kali dan meningkatkan kinerja kueri.

Untuk mengoptimalkan kinerja kueri, gunakan Materialized Views guna menghitung sebelumnya agregasi yang umum.

Misalnya, Anda dapat menghitung sebelumnya volume transfer harian token yang akan digunakan oleh bagan terkait volume pada dasbor.

### Opsi 3: Data Lake

Data lake ideal untuk menyimpan data blockchain mentah dan hasil pemrosesan dalam jumlah sangat besar untuk pengarsipan jangka panjang serta kueri analitis.

Implementasi sederhana menggunakan format data Parquet dengan Amazon Athena.

**Parquet** adalah format file data berorientasi kolom yang dirancang untuk penyimpanan dan pengambilan data secara efisien.

**Amazon Athena** adalah layanan kueri interaktif yang memungkinkan Anda menganalisis data yang disimpan di Amazon S3 menggunakan SQL standar tanpa perlu menyiapkan infrastruktur atau memuat data ke basis data terpisah.

<Warning>
  Data lake hanya direkomendasikan jika Anda perlu membuat kueri atas data tidak terstruktur dalam jumlah besar. Untuk sebagian besar kasus penggunaan, kami merekomendasikan basis data SQL (Opsi 1).
</Warning>

#### Contoh implementasi:

Kita ingin membuat arsip transfer token dan menguerinya.

Pertama, kita perlu menyimpannya di S3: Buat bucket bernama `solana_index` dan partisi data transfer token Anda berdasarkan waktu menggunakan struktur kunci ini:

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

Transfer setiap hari disimpan dalam file Parquet terpisah di folder tanggal yang sesuai.

Saat memproses transfer dari Solana, transformasikan data tersebut ke format Parquet dan tulis ke objek S3 yang sesuai.

Kemudian, Anda [membuat tabel](https://docs.aws.amazon.com/athena/latest/ug/step-2-create-a-table.html) di Athena dan menghubungkannya ke bucket. Dengan demikian, Anda dapat menjalankan kueri seperti ini secara langsung pada data dalam bucket:

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

### Gunakan Kerangka Kerja Pengindeksan

Gunakan [**Carbon**](https://github.com/sevenlabs-hq/carbon) dan kerangka kerja serupa untuk menghindari penulisan kode boilerplate dan menyiapkan pengindeks Anda dalam hitungan jam, bukan hari.

#### Fitur utama:

* Dekoder siap pakai untuk program populer (program Token, protokol DeFi, Metaplex)
* Sumber data yang dapat dikonfigurasi (RPC, LaserStream, Enhanced WebSockets)
* Dukungan bawaan untuk pengisian data historis dan streaming waktu nyata
* Output ke beberapa backend penyimpanan (Postgres langsung tersedia)
* Dapat disesuaikan sepenuhnya: Anda dapat menyiapkan sumber data, dekoder, dan tujuan data sendiri

## **Langkah 3: Jaga indeks Anda tetap mutakhir**

Setelah mengisi data historis, Anda memerlukan solusi streaming waktu nyata agar indeks selalu mutakhir dengan aktivitas blockchain baru. Tanpa solusi ini, indeks Anda akan menjadi usang.

### Metode 1: LaserStream (direkomendasikan)

Kami merekomendasikan [LaserStream gRPC](/docs/id/laserstream/grpc) sebagai pilihan default Anda untuk semua kasus penggunaan pengindeksan produksi. Solusi ini dirancang khusus untuk streaming data yang andal, berlatensi sangat rendah, dan toleran terhadap kesalahan.

Beberapa manfaat penggunaan LaserStream meliputi:

* **Pemutaran ulang riwayat selama 24 jam**: jika pengindeks Anda terputus, LaserStream [secara otomatis memutar ulang](/docs/id/laserstream/historical-replay) semua transaksi yang terlewat mulai dari posisi terakhir Anda
* **Penyambungan ulang otomatis**: [SDK LaserStream](/docs/id/laserstream/clients) kami (Rust, Go, JS/TS) menangani gangguan jaringan untuk Anda secara mulus
* **Failover node**: koneksi LaserStream Anda mengagregasi data dari beberapa node secara bersamaan, sehingga memastikan waktu aktif maksimal

Dengan menggabungkan kecepatan dan keandalan, LaserStream ideal untuk aplikasi waktu nyata seperti umpan transaksi langsung, dasbor perdagangan, dan pembaruan saldo instan.

#### Cara Menggunakan LaserStream untuk Pengindeksan

Gunakan metode [`subscribe`](/docs/id/api-reference/laserstream/grpc/subscribe) untuk berlangganan peristiwa blockchain.

Berikut beberapa praktik terbaik:

* **Persempit filter Anda semaksimal mungkin**: Hanya berlangganan data yang benar-benar perlu Anda indeks untuk meminimalkan konsumsi bandwidth dan pemrosesan yang diperlukan.
* **Gunakan tingkat commitment `confirmed`**: Tingkat ini menyeimbangkan latensi dan finalitas. Tingkat `processed` mungkin terlalu tidak andal, sedangkan `finalized` menambahkan latensi sekitar \~13 detik
* **Atur `failed: false`** kecuali Anda secara khusus perlu melacak transaksi yang gagal
* **Kecualikan transaksi voting** (`vote: false`) karena tidak relevan untuk pengindeksan

Mari kita lihat sebuah contoh.

Gunakan langganan berikut untuk mengindeks semua transfer token baru:

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

### Metode 2: Gunakan LaserStream WebSocket

[LaserStream WebSocket](/docs/id/rpc/websocket) — varian WebSocket dari LaserStream, termasuk ekstensi `transactionSubscribe` khusus Helius — berjalan pada backend yang sama dengan LaserStream gRPC dan menjadi alternatif streaming waktu nyata yang hemat biaya saat Anda tidak memerlukan gRPC.

Anda sebaiknya menggunakan LaserStream WebSocket jika:

* Aplikasi Anda dapat menoleransi kekosongan data sesekali
* Pembaruan waktu nyata penting, tetapi tidak bersifat sangat kritis
* Anda memiliki infrastruktur yang sudah tersedia untuk mendeteksi dan mengisi data yang hilang
* Keterbatasan anggaran cukup besar dan Anda perlu meminimalkan biaya streaming
* Anda sedang membuat prototipe atau melakukan pengujian sebelum berkomitmen menggunakan LaserStream

Namun, ada beberapa kompromi yang perlu dipertimbangkan saat memilih WebSocket:

* **Kecepatan**: LaserStream WebSocket berjalan pada backend yang sama dengan LaserStream gRPC, tetapi protokol WebSocket menambahkan framing JSON dan overhead per pesan — untuk memperoleh latensi serendah mungkin pada data yang sama, gunakan [LaserStream gRPC](/docs/id/laserstream)
* **Keandalan**: Tidak ada jaminan pemutaran ulang riwayat. Jika WebSocket Anda terputus, Anda harus mendeteksi dan mengisi kekosongan data secara manual menggunakan metode RPC
* **Kompleksitas**: Memerlukan infrastruktur pemantauan tambahan untuk memastikan kelengkapan data

#### Cara Menggunakan WebSocket untuk Pengindeksan

Untuk memperbarui indeks yang menyimpan semua transfer token, Anda perlu berlangganan [`transactionSubscribe`](/docs/id/rpc/websocket/transaction-subscribe) seperti ini:

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

## Mulai

Membangun indeks Solana yang tangguh dan mengisi data historis memerlukan penyelesaian tiga tantangan utama:

1. Mengambil data historis secara efisien
2. Mentransformasi dan menyimpan data agar dapat diambil dengan cepat
3. Menjaga data Solana yang telah diindeks tetap diperbarui secara waktu nyata

Dengan [sistem arsip mutakhir](https://www.helius.dev/blog/introducing-gettransactionsforaddress) baru kami, panggilan arsip seperti [`getTransactionsForAddress`](/docs/id/rpc/gettransactionsforaddress), dan solusi streaming data terdepan di industri seperti LaserStream, membangun indeks Solana kini lebih mudah dan lebih praktis daripada sebelumnya.

## Opsi pelengkap

Menjalankan indeks sendiri memberi Anda kendali penuh, tetapi tidak selalu diperlukan. Untuk kebutuhan umum, Helius API terkelola dapat menggantikan atau melengkapi indeks khusus:

* **[DAS API](/docs/id/das-api)** — buat kueri atas NFT, token fungibel, dan aset terkompresi (metadata, kepemilikan, saldo, berdasarkan pemilik/koleksi/kreator) tanpa mengindeks sendiri data aset.
* **[Wallet API](/docs/id/wallet-api/overview)** — endpoint REST tingkat tinggi untuk saldo, riwayat, transfer, dan identitas dompet, lengkap dengan nilai USD serta struktur respons yang lebih sederhana.

Banyak tim menggunakan opsi ini untuk data portofolio, token, dan dompet, lalu menggunakan indeks khusus hanya untuk data bertujuan khusus yang tidak dicakup oleh API terkelola.

## Langkah berikutnya

* [Daftar untuk mendapatkan akun Helius gratis](https://www.helius.dev) guna memperoleh akses API
* Baca [panduan getTransactionsForAddress](/docs/id/rpc/gettransactionsforaddress) untuk mengisi data historis
* Jelajahi [gambaran umum LaserStream](/docs/id/laserstream) untuk streaming waktu nyata
* Tinjau [gambaran umum data historis](/docs/id/rpc/historical-data) untuk semua metode arsip