Cara Mengindeks Data Solana

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 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 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 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. Pengindeks biasanya melakukan empat hal:

Mengisi data historis: gunakan metode RPC arsip untuk membuat kueri atas semua data historis
Melakukan streaming data baru: proses blok baru ketika dikonfirmasi oleh jaringan
Mengurai dan mentransformasi data: ekstrak data yang relevan dari blok yang telah dikonfirmasi (misalnya transaksi, perubahan status, dan sebagainya)
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 dan 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) atau pasar 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.

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:

getTransactionsForAddress (direkomendasikan)
getSignaturesForAddress dan getTransaction
getBlock

Metode 1: getTransactionsForAddress (direkomendasikan)

Metode 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 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, 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 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 (dari yang terbaru hingga terlama), lalu memanggil 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. Untuk riwayat dompet lengkap yang mencakup akun token, gunakan getTransactionsForAddress.

Metode 3: Gunakan getBlock

Metode getBlock paling efektif ketika persentase tinggi transaksi dalam blok target relevan dengan analisis Anda, seperti saat mengindeks transaksi program Solana yang sering digunakan, 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:

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:

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:

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. Mesin ini dirancang untuk laju penyerapan tinggi sehingga ideal untuk pengindeksan. Gunakan perintah ini:

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 dan mempersempit respons berdasarkan rentang tanggal. Berikut contoh kuerinya:

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.

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

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:

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 di Athena dan menghubungkannya ke bucket. Dengan demikian, Anda dapat menjalankan kueri seperti ini secara langsung pada data dalam bucket:

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 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 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 semua transaksi yang terlewat mulai dari posisi terakhir Anda
Penyambungan ulang otomatis: SDK LaserStream 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 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:

{
  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 — 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
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 seperti ini:

{
  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:

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

Dengan sistem arsip mutakhir baru kami, panggilan arsip seperti 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 — buat kueri atas NFT, token fungibel, dan aset terkompresi (metadata, kepemilikan, saldo, berdasarkan pemilik/koleksi/kreator) tanpa mengindeks sendiri data aset.
Wallet API — 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 guna memperoleh akses API
Baca panduan getTransactionsForAddress untuk mengisi data historis
Jelajahi gambaran umum LaserStream untuk streaming waktu nyata
Tinjau gambaran umum data historis untuk semua metode arsip

​Gambaran umum

​Kapan harus menggunakannya

​Apa arti pengindeksan data Solana?

​Mengapa sebagian besar perusahaan membangun indeks Solana?

​Contoh Dompet

​Contoh Perdagangan

​Contoh Pemfilteran

​Contoh PnL

​Langkah 1: Dapatkan data historis

​Metode 1: getTransactionsForAddress (direkomendasikan)

​Langkah-langkah menggunakan metode ini

​Manfaat menggunakan getTransactionsForAddress

​Metode 2: getSignaturesForAddress dan getTransaction

​Langkah-langkah menggunakan metode ini

​Kekurangan metode ini

​Metode 3: Gunakan getBlock

​Langkah-langkah menggunakan metode ini

​Langkah 2: Sinkronkan data Solana dengan basis data Anda

​Opsi 1: Basis Data SQL

​Contoh implementasi:

​Opsi 2: Basis Data Kolumnar

​Contoh implementasi:

​Opsi 3: Data Lake

​Contoh implementasi:

​Gunakan Kerangka Kerja Pengindeksan

​Fitur utama:

​Langkah 3: Jaga indeks Anda tetap mutakhir

​Metode 1: LaserStream (direkomendasikan)

​Cara Menggunakan LaserStream untuk Pengindeksan

​Metode 2: Gunakan LaserStream WebSocket

​Cara Menggunakan WebSocket untuk Pengindeksan

​Mulai

​Opsi pelengkap

​Langkah berikutnya

Gambaran umum

Kapan harus menggunakannya

Apa arti pengindeksan data Solana?

Mengapa sebagian besar perusahaan membangun indeks Solana?

Contoh Dompet

Contoh Perdagangan

Contoh Pemfilteran

Contoh PnL

Langkah 1: Dapatkan data historis

Metode 1: getTransactionsForAddress (direkomendasikan)

Langkah-langkah menggunakan metode ini

Manfaat menggunakan getTransactionsForAddress

Metode 2: getSignaturesForAddress dan getTransaction

Langkah-langkah menggunakan metode ini

Kekurangan metode ini

Metode 3: Gunakan getBlock

Langkah-langkah menggunakan metode ini

Langkah 2: Sinkronkan data Solana dengan basis data Anda

Opsi 1: Basis Data SQL

Contoh implementasi:

Opsi 2: Basis Data Kolumnar

Contoh implementasi:

Opsi 3: Data Lake

Contoh implementasi:

Gunakan Kerangka Kerja Pengindeksan

Fitur utama:

Langkah 3: Jaga indeks Anda tetap mutakhir

Metode 1: LaserStream (direkomendasikan)

Cara Menggunakan LaserStream untuk Pengindeksan

Metode 2: Gunakan LaserStream WebSocket

Cara Menggunakan WebSocket untuk Pengindeksan

Mulai

Opsi pelengkap

Langkah berikutnya