Dari ClickHouse ke RocksDB: Cara Kami Membangun Ulang Lapisan Arsip Solana

Apa Itu Arsip Solana dan Mengapa Ini Penting

Pada dasarnya, Solana adalah jaringan node yang berkomunikasi untuk menyepakati informasi baru tanpa harus saling percaya.

Node adalah komputer di Solana yang menjalankan klien (misalnya, Agave, Firedancer) dan mematuhi serangkaian aturan tertentu untuk membantu mencapai kesepakatan atas informasi baru. 

Validator adalah node Solana yang mengamankan jaringan dengan memproduksi blok (yaitu, menambahkan kelompok transaksi ke ledger Solana) dan memberikan suara atas validitas blok lain. 

Node RPC adalah validator yang tidak berpartisipasi dalam produksi blok atau pemungutan suara. Sebaliknya, node ini mengamati jaringan dan melacak semua informasi baru yang dihasilkannya. RPC memungkinkan pengguna meminta data tertentu dari jaringan menggunakan spesifikasi JSON-RPC. 

Namun, node ini tidak menyimpan data tersebut selamanya. 

Agar tetap memenuhi persyaratan perangkat keras Solana, blok, transaksi, dan status account lama dipangkas sehingga node hanya mempertahankan tampilan terbaru dari riwayat Solana. 

Hal ini menjadi masalah saat Anda ingin mencari signature transaksi dari setahun lalu, mengambil setiap signature yang pernah berinteraksi dengan wallet tertentu sepanjang keberadaannya, atau memindai seluruh riwayat eksekusi sebuah program.

Secara umum, arsip merujuk pada seluruh lapisan yang menyimpan data Solana sejak genesis. Lapisan ini mencatat dan mengindeks semua yang dihasilkan chain—setiap blok, transaksi, interaksi account, Cross Program Invocation (CPI), dan log transaksi—serta membuatnya tetap dapat dikueri melampaui jendela penyimpanan jangka pendek standar selama ~2 hari (yaitu, 1 epoch). 

Arsip memungkinkan kueri historis dilakukan.

Pendekatan default di Solana untuk menyimpan data arsip adalah Google BigTable. Anza mengelola instance BigTable yang dapat diakses penyedia RPC sesuai kebutuhan untuk melayani kueri historis.

Pendekatan ini berfungsi, tetapi BigTable mahal, biaya egress menyulitkan pengoperasian salinan sendiri, dan hampir tidak ada rekayasa yang dapat Anda lakukan untuk mempercepatnya—Anda bergantung pada penyimpanan Google, lengkap dengan seluruh struktur biayanya tetapi tanpa kendali. 

Old Faithful adalah kumpulan alat yang dikelola Triton One untuk menghasilkan Content Addressable Archives (CARs) dari arsip ledger RocksDB dan menyajikannya melalui antarmuka RPC dan gRPC standar Solana. Ini merupakan langkah penting menuju desentralisasi lapisan arsip Solana sekaligus menyediakan sumber riwayat redundan yang berharga dan dapat diverifikasi.

Namun, komprominya dalam hal pengalaman developer dan performa (misalnya, untuk memulai dibutuhkan alat kustom, bukan antarmuka yang dapat dijadikan fondasi oleh tim; sistem ini dioptimalkan untuk arsip tahan lama, bukan performa dan skala) membuatnya bukan alternatif yang layak bagi beban kerja sensitif terhadap latensi. 

Masalah inti arsip adalah Anda memiliki N petabyte data mentah. Dengan lebih dari 500 miliar transaksi, ~1,3 triliun baris indeks account-ke-transaksi, dan pola akses acak, bagaimana pencarian di bawah 10ms dapat dicapai? Seperti apa kueri end-to-end di bawah 50ms? Google BigTable maupun Old Faithful tidak menawarkan solusi untuk hal ini.

Selain itu, jika ingin membuat opsi pemfilteran dan pengurutan kustom, atau meningkatkan pengalaman developer dengan menawarkan sesuatu yang lebih kaya daripada metode JSON-RPC standar, Anda memerlukan indeks arsip sendiri. 

Jadi, kami membuatnya.

ClickHouse: Pilihan Awal yang Pragmatis

ClickHouse adalah pilihan paling pragmatis untuk mulai membangun sistem arsip baru kami. Ini merupakan jalur tercepat untuk meluncurkan produk yang sudah lebih baik daripada produk berbasis BigTable.

ClickHouse adalah database kolumnar yang matang dengan alat dan dokumentasi yang sangat baik. Database ini mengompresi data deret waktu dengan baik, yang sangat berguna untuk Solana karena data bloknya pada dasarnya diurutkan berdasarkan waktu.

Membuat database, menulis SQL untuknya, mengiterasi skema, dan mengoptimalkan waktu peluncuran dapat dilakukan dengan mudah, sehingga pelanggan bisa mendapatkan produk dalam waktu relatif singkat.

ClickHouse tidak melayani traffic sendirian. ClickHouse merupakan lapisan terbawah dari stack penyimpanan kami, yang disusun berdasarkan kebaruan data. 

Data terbaru (yaitu, sekitar satu atau dua menit terakhir, atau beberapa ratus slot) berada dalam penyimpanan in-memory. Data dari sekitar dua minggu terakhir berada di Postgres. ClickHouse menyimpan sisa riwayat Solana.

Router cerdas berada di depan ketiga sumber tersebut agar pencarian titik dikirim ke lapisan terpanas yang menyimpan data, sedangkan kueri rentang dibagi ke beberapa lapisan lalu digabungkan kembali menjadi satu hasil.

ClickHouse bekerja relatif baik untuk beban kerja yang memang dirancang untuk ditanganinya. Misalnya, “berikan setiap blok dalam rentang slot ini” atau “pindai aktivitas account ini dari waktu ke waktu.” 

Kueri deret waktu berjalan baik. Kami dapat melakukan backfill, menjalankan analitik ad hoc, dan menjawab sebagian besar pertanyaan yang secara historis dibutuhkan penyedia RPC. Sisi ingest tidak pernah kewalahan; kami hanya menulis ~10MB/s ke indeks melalui LaserStream.

Kesalahan dalam memilih ClickHouse bukanlah karena kami memilih ClickHouse, melainkan karena kami berasumsi bahwa bentuk beban kerja kami akan tetap dapat ditangani ClickHouse pada skala besar. 

Titik Kegagalan ClickHouse

Tidak semua metode historis Solana yang penting bagi kami merupakan deret waktu. Signature di Solana (yaitu, pengidentifikasi transaksi universal) pada dasarnya adalah 64 byte data acak. 

Saat seseorang memanggil getTransaction untuk signature tertentu, itu merupakan pencarian titik acak seragam. Tidak ada slot, rentang waktu, ataupun lokalitas yang bisa dimanfaatkan. 

Hal yang sama berlaku untuk kueri lain, seperti “ambil semua signature yang berinteraksi dengan account ini,” karena key account juga secara efektif acak. Masalah ini muncul setiap kali primary key berupa UUID, hash, atau pengidentifikasi berentropi tinggi lainnya.

Mesin kolumnar tidak dirancang untuk menyelesaikan masalah ini. 

ClickHouse menyimpan data dalam bagian-bagian terurut dan menggunakan indeks primer yang jarang. Artinya, tidak banyak yang dapat dipangkas untuk pencarian key acak. Pada akhirnya, Anda akan membaca lebih banyak granula daripada yang diinginkan. Satu pencarian signature dapat menyentuh 20 granula—sekitar 10.000 baris dan ~60 I/O disk—bahkan sebelum binary search atau overhead CPU. 

Dari I/O saja, satu pencarian memerlukan sekitar 5ms. Karena penyimpanannya bersifat kolumnar, membaca satu transaksi berarti membaca ~15 kolom sebagai I/O terpisah dalam granula berisi 512 baris.

Artinya, panggilan getTransactionsForAddress yang meminta detail transaksi lengkap, misalnya, menyebar menjadi hingga 100 pencarian tersebut. Ini menempatkan batas bawah latensi mendekati 100ms sebelum satu byte pun diserialisasi. 

Batch besar getTransaction (yaitu, hingga 1.000) mendorong batas bawah tersebut mendekati satu detik penuh.

Abstraksi yang mempercepat pemindaian (misalnya, eksekusi tervektorisasi, materialisasi tertunda) tidak sepenuhnya mengatasi masalah ini. Pencarian tersebut sudah dioptimalkan semaksimal mungkin. Kami tidak kekurangan indeks. Tidak ada proyeksi yang dapat ditambahkan. 

Sederhananya, tata letak data dasarnya salah untuk tugas yang kami minta.

Metode termahal yang kami tambahkan (misalnya, getTransactionsForAddress, getTransfersByAddress) adalah pola key acak yang paling buruk ditangani ClickHouse. 

Sebagian kueri ini memerlukan 2-3 detik, padahal seharusnya hanya beberapa milidetik. Kami menerima peringatan tentang penurunan performa pada beban kerja yang secara fundamental tidak dapat kami perbaiki. 

Mengingat institusi dan pelanggan Enterprise menggunakan Helius dalam skala besar, kondisi ini sama sekali tidak dapat diterima dalam jangka panjang.

Menskalakan ClickHouse untuk beban kerja ini berarti menambah jumlah mesin dan, pada skala kami, melipatgandakan beban kerja beberapa kali. Mengandalkan pengeluaran untuk perangkat keras saja tidak akan menyelesaikan masalah.

Stack RPC Solana makin matang. Ekosistem telah mencapai titik balik ketika metode JSON-RPC standar tidak lagi memadai. Pelanggan membutuhkan kueri historis yang kaya, dan tidak ada pihak lain yang akan membangunnya di atas BigTable. 

Jika ingin mendorong batas tersebut, kami harus mengubah lapisan penyimpanan. 

RocksDB: Bukan Database

Terlepas dari namanya, RocksDB bukanlah database. RocksDB adalah library.

Tidak ada bahasa kueri, protokol klien/server, mesin SQL, join, atau indeks dalam pengertian database tradisional. Antarmukanya mengatakan, “Ini sebuah key (beberapa byte), ini sebuah value (juga beberapa byte), simpan ke disk; nanti, kembalikan value untuk key ini.” Hanya itu.

Ini adalah primitif. Bisa dibilang, primitif utama untuk membangun mesin penyimpanan. 

Semua yang diharapkan dari database tradisional (misalnya, perencana kueri, protokol wire, replikasi, observabilitas) harus dibangun.

Ini terdengar seperti kekurangan sampai Anda memahami manfaat yang diberikannya. Penyimpanan key-value murni yang didukung struktur Log-Structured Merge (LSM) di disk adalah bentuk yang tepat untuk pencarian key acak seragam dengan throughput tinggi. Tidak ada perencana kueri yang menambah overhead, asumsi tata letak kolumnar yang harus diselaraskan, atau frontend SQL yang perlu diakomodasi.

Anda menyimpan byte, membacanya kembali, lalu menempatkan bloom filter dan cache di lokasi yang tepat agar pembacaan acak tetap murah.

Di sinilah narasi antipola tersebut runtuh sepenuhnya. 

Kami tidak mengganti ClickHouse dengan RocksDB—kami mengganti ClickHouse dengan database kustom yang menggunakan RocksDB sebagai mesin penyimpanannya. Keduanya sangat berbeda.

Ini juga merupakan pola yang digunakan sebagian besar database produksi di balik layar. Misalnya, CockroachDB, TiKV, MyRocks, dan penyimpanan status Kafka Streams semuanya dibangun di atas RocksDB.

Perbedaannya, mereka terlebih dahulu membungkusnya dalam database lain, sedangkan kami membangun sendiri database di sekelilingnya dan menyesuaikannya dengan pola akses yang benar-benar dibutuhkan arsip.

Cara RocksDB Mengatasi Kekurangan ClickHouse

Jadi, bagaimana tepatnya penyimpanan key-value menyelesaikan masalah key acak yang tidak dapat ditangani mesin kolumnar? Semuanya bergantung pada cara byte disimpan di disk.

RocksDB menggunakan pemadatan bertingkat. Penulisan baru masuk ke level 0, tempat penampungan yang tidak terurut—secara efektif sama dengan situasi di ClickHouse—tempat bagian-bagian dalam suatu partisi tidak diurutkan secara global. 

Namun, level 1 hingga N merupakan rangkaian yang sepenuhnya terurut. Setelah data dipadatkan, metadata min/maks benar-benar memangkas pencarian, bahkan untuk key acak seragam, karena level tersebut diurutkan secara global. Dalam arti tertentu, semua yang ada di ClickHouse berperilaku seperti level 0 RocksDB.

Kami memanfaatkan hal ini untuk backfill. 

Saat membangun indeks signature, kami mengurutkan seluruh riwayat sejak awal dan langsung memuatnya ke level terbawah. Setelah itu, hanya data baru yang masuk ke level 0, lalu data tersebut dengan cepat digabungkan ke bawah. 

Hasilnya, hampir setiap pencarian membaca dari satu rangkaian terurut. Kami secara efektif telah mengurutkan data acak dengan RocksDB.

Yang Kami Bangun di Atasnya

ClickHouse menyediakan banyak hal secara bawaan: mesin kueri, protokol wire, klien, dan cara menyajikan data. RocksDB tidak menyediakan opsi tersebut; RocksDB hanya menyimpan byte. Kami harus membangun semua yang lain.

Jadi, kami membangun database sendiri di atas RocksDB, yang dikhususkan untuk pola akses arsip Solana.

Saat ini, dua indeks berada di RocksDB:

1. Signature -> Lokasi (yaitu, indeks signature yang memetakan signature 64 byte sebuah transaksi ke slot dan posisinya di dalam blok).
2. Slot -> Blok (yaitu, indeks slot-ke-blok yang memetakan lokasi di atas ke data transaksi).

Yang penting, tidak ada jalur langsung dari signature ke data transaksinya. Mengatasi hal tersebut merupakan alasan utama keberadaan kedua indeks ini. 

Signature pada dasarnya adalah pengidentifikasi acak 64 byte. Informasi yang benar-benar menunjukkan lokasi transaksi adalah slot dan indeksnya di dalam blok tersebut. Jadi, pengambilan transaksi membutuhkan dua lompatan (yaitu, satu untuk memetakan signature ke lokasi tertentu dan satu lagi untuk mengambil detail transaksi dari lokasi tersebut), sedangkan pengambilan blok hanya membutuhkan satu lompatan karena pemanggil sudah memberikan slot.

Bersama-sama, indeks ini mendukung sejumlah metode terberat yang disajikan Helius (misalnya, getBlock, getTransaction, dan getTransactionsForAddress, terutama saat details diatur ke full).

Jalur baca tampak hampir sama seperti di ClickHouse. Permintaan masuk, klien internal kami melakukan panggilan database, lalu hasilnya kembali. Yang berubah adalah mesin di baliknya. Setiap metode memiliki jalur hardcoded yang disesuaikan secara manual. Saat pengguna meminta transaksi, jalur getTransaction yang dibuat khusus langsung menuju byte terkait.

Jalur ini cepat karena kami mengendalikan setiap lapisannya. Kami menggunakan io_uring untuk I/O file dan jaringan guna melakukan streaming data keluar dari RocksDB. Jika data berada di disk tanpa kompresi, kami menyalinnya langsung dari disk ke kartu jaringan tanpa memutar melalui userspace.

Metodenya hardcoded, I/O disesuaikan secara end-to-end, dan tidak ada komponen yang tidak diperlukan di antaranya.

Hasilnya terlihat jelas dalam produksi. 

Baru-baru ini, kami mempertahankan traffic getBlock sebesar 150 Gbit/s selama lima hingga enam jam berturut-turut sambil memenuhi kapasitas sebagian besar kartu jaringan kami. Tanpa masalah, tanpa peringatan, dan performa mentah tetap sama. 

Secara keseluruhan,

• Penyimpanan terkompresi berkurang hampir separuh, dari ~330TB menjadi ~190TB
• Latensi P95 untuk panggilan getTransaction turun dari 7ms menjadi 1ms
• Latensi P95 untuk panggilan getTransactionsForAddress turun dari 350ms menjadi 30ms
• Latensi P95 untuk panggilan getBlock turun dari 50ms menjadi 35ms

Panggilan getBlock mengalami peningkatan paling kecil, sesuai perkiraan. ClickHouse sudah menyimpan transaksi dalam potongan berisi 512 baris, yang mengamortisasi penalti kolumnar untuk pembacaan seukuran blok. Sebagian besar waktu end-to-end getBlock digunakan untuk encoding Base58 dan JSON serta menyusun ulang blok, sehingga mengganti mesin penyimpanan tidak akan mempercepat proses tersebut.

Kisah yang lebih mendalam—tentang cara kami membuat io_uring, Rust asinkron, dan library sinkron seperti RocksDB bekerja sama dalam beban kerja jaringan ber-throughput tinggi—layak dibahas dalam postingan tersendiri di masa mendatang.

Namun, bagian berikut membahas beberapa optimasi yang kami anggap berguna saat bekerja dengan RocksDB. 

Mengoptimalkan RocksDB untuk Skala Besar

Tidak ada satu konfigurasi RocksDB yang universal untuk menjadi “cepat”. Pengaturan yang tepat sepenuhnya bergantung pada pola akses indeks yang disesuaikan.

Indeks signature -> lokasi dan indeks slot -> blok kami berjalan dalam proses dan perangkat keras yang sama, tetapi kebutuhan penyesuaiannya hampir berlawanan sepenuhnya.

Jadi, alih-alih memberikan file konfigurasi berisi pengaturan yang belum tentu sesuai untuk beban kerja Anda, bagian ini membahas cara kami mempertimbangkan kompromi yang dapat diterapkan secara umum.

Sesuaikan per indeks, bukan per database

Setiap indeks kami merupakan column family tersendiri dengan opsinya masing-masing. Satu indeks menangani pencarian titik acak seragam; indeks lainnya menangani value besar yang dapat dikompresi dan diambil secara berurutan. Memperlakukan keduanya secara identik akan menyia-nyiakan banyak peluang optimasi performa. Hampir setiap keputusan di bawah ini harus dibaca sebagai “untuk pola akses ini, lakukan X.”

Tentukan apakah Anda benar-benar membutuhkan WAL

Data arsip dapat dibangun ulang. Artinya, data tersebut dialirkan dari LaserStream dan berasal dari chain itu sendiri.

Kami menulis dengan Write Ahead Log (WAL) dinonaktifkan, sehingga kami tidak perlu menanggung biaya durabilitas write-ahead-log yang tidak dibutuhkan. 

Nuansanya, menonaktifkan WAL juga menonaktifkan konsistensi crash default RocksDB di seluruh column family, sehingga konsistensi harus dipulihkan dengan cara lain. Pelajarannya adalah pengaturan durabilitas harus sesuai dengan kemampuan pemulihan data Anda. Data yang dapat dibangun ulang dari sumber upstream memiliki standar yang sangat berbeda dari system of record.

Sesuaikan bloom filter dengan rasio hit/miss Anda

Bloom filter mengimbangi penggunaan memorinya dengan menjawab secara murah apakah suatu key tidak ada dalam pencarian. Artinya, filter ini hanya membantu saat terjadi miss. 

Pencarian signature pada dasarnya selalu menghasilkan hit karena pemanggil memiliki signature dan menginginkan data transaksi yang sesuai.

Level LSM terbawah menyimpan sebagian besar data kami. Ketika mayoritas data Anda berada di satu level dan beban kerja didominasi hit, filter pada level tersebut memakai memori paling banyak tetapi melakukan pekerjaan paling sedikit. Dalam situasi itu, patut dipertanyakan apakah filter tersebut dibutuhkan di sana.

Kompres data yang dapat dikompresi, bukan data yang sering diakses

Kompresi merupakan keputusan per indeks. Data berentropi tinggi, seperti signature 64 byte, tidak dapat dikompresi hingga rasio di bawah 1,0. Artinya, kompresi hanya akan menambah biaya dekompresi ke hot path setiap pencarian. Karena itu, kami mengatur kompresi ke None.

Sebaliknya, data blok dapat dikompresi dengan baik karena lebih besar dan lebih repetitif. Karena itu, indeks slot -> blok kami menggunakan zstd. Perhatikan bahwa kedua indeks menggunakan database yang sama, tetapi mendapatkan manfaat dari pilihan berbeda. Keputusan ini sepenuhnya ditentukan oleh apakah byte dapat dikompresi dan apakah indeks dibatasi oleh latensi atau penyimpanan.

Pemisahan per indeks ini menjadi alasan utama kami dapat mengurangi kebutuhan penyimpanan dari ~330TB menjadi ~190TB tanpa mengorbankan latensi pencarian titik.

Pertimbangkan I/O langsung

Kami membaca dengan I/O langsung serta menggunakannya untuk flush dan pemadatan. Pada skala ini, page cache OS bersaing dengan block cache kami untuk RAM yang sama. Untuk pencarian titik acak, caching ganda tersebut sebagian besar sia-sia—kami lebih memilih satu block cache besar yang memberikan latensi konsisten.

Perhatikan bahwa hal ini bergantung pada beban kerja:

I/O langsung dapat merugikan konfigurasi yang sarat pemindaian atau kekurangan sumber daya. Karena itu, sebaiknya lakukan pengujian A/B daripada mengadopsinya begitu saja. 

Pilih cache yang tahan terhadap kontensi

Di bawah beban serentak yang berat pada hot key, cache LRU bersama standar menjadi bottleneck akibat kontensi lock. Kami menggunakan HyperClockCache RocksDB untuk indeks yang sering diakses. Cache ini bertahan jauh lebih baik saat banyak thread mengakses entri populer yang sama secara bersamaan.

Paralelkan pencarian multi-key, jangan menserialisasikannya

Alih-alih menserialisasikan N pembacaan, RocksDB dapat menerbitkan banyak I/O secara serentak melalui io_uring dan membiarkannya selesai secara paralel. Untuk metode seperti getTransactionsForAddress, yang menyebar menjadi banyak pencarian titik di bawahnya, inilah perbedaan antara latensi yang meningkat seiring jumlah key dan latensi yang tetap kurang lebih sama.

RocksDB menyediakan seluruh pilihan, tetapi tidak membuat asumsi tentang data Anda. Keberhasilan kami berasal dari pemahaman terhadap pola akses dan penyesuaian setiap indeks menurut karakteristiknya, bukan dari pencarian satu konfigurasi global yang unggul dalam segala hal.

Arah Pengembangan Kami

Saat ini, arsip beroperasi dari region kami yang lebih besar, seperti EWR, FRA, dan Tokyo. Setelah mesin penyimpanan mampu mengembalikan hasil pencarian dalam hitungan mikrodetik dan memenuhi kapasitas kartu jaringan kami, database bukan lagi hal yang membuat kami terbangun pada malam hari; menyelesaikan satu bottleneck biasanya akan mengungkap bottleneck berikutnya.

Setelah pencarian secara efektif tidak memerlukan biaya, biaya dominan beralih dari software ke jarak antara pengguna dan mesin. Permintaan tetap harus bergerak dari lokasi pengguna ke lokasi backend kami, lalu kembali. Pada titik itu, Anda melawan hukum fisika.

Itulah masalah yang ditangani Gatekeeper.

Gatekeeper adalah edge gateway internal kami, ditulis dalam Rust di atas Hyper, yang menghentikan koneksi di dekat pengguna dan mengarahkan setiap permintaan ke backend melalui jalur terpendek yang tersedia. Di sinilah pertarungan latensi kini berlangsung: connection pooling, penyesuaian TLS dan socket, routing yang mempertimbangkan kedekatan dan kesehatan, serta deployment tanpa downtime di seluruh fleet global kami. Semuanya dilakukan untuk memangkas beberapa milidetik dari jalur menuju byte yang sudah disajikan arsip dalam hitungan mikrodetik.

Mempercepat satu permintaan adalah masalah database. Mempercepat setiap permintaan dari mana pun di dunia, tanpa jendela pemeliharaan dan tanpa koneksi terputus, merupakan masalah yang sama sekali berbeda. Masalah itulah yang akan menjadi fokus kami berikutnya. 

Inilah yang kami maksud dengan berinovasi pada lapisan baca Solana: menyempurnakan setiap lapisan, mulai dari mesin penyimpanan yang menjawab pencarian hingga edge gateway yang menentukan seberapa cepat jawaban tersebut mencapai pengguna akhir.

Pada akhirnya, arsip bergantung pada pencarian titik dengan key acak. Pola akses inilah yang merusak mesin kolumnar karena alasan struktural. Ini bukan masalah penyesuaian, sharding, atau cara view diurutkan. Kendala yang kami hadapi dengan ClickHouse melekat pada pilihan ini dan bukan sekadar akibat konfigurasi. Beban kerja historis Solana ditentukan oleh pola aksesnya yang paling sulit, bukan yang paling mudah. 

Pada skala jaringan yang berupaya menjadi lapisan settlement bagi keuangan global, lapisan baca tidak bisa sekadar menjadi versi yang disesuaikan lebih baik dari sistem yang telah kami lampaui. Institusi dan aplikasi yang bergantung pada kueri historis kaya membutuhkan metode, cakupan, dan latensi yang tidak dapat disediakan stack default. Lapisan baca Solana harus dibangun di atas fondasi yang sejak awal sesuai untuk kasus sulit. Itulah pertaruhan kami dengan RocksDB, dan itulah standar yang kami terapkan pada semua hal lainnya.

Jika Anda tertarik membangun masa depan keuangan dalam skala besar, mari membangunnya bersama kami. Solana tengah berpacu untuk menjadi lapisan settlement keuangan global, dan arsip hanyalah satu bagian dari teka-teki yang jauh lebih besar. Jika Anda tertarik pada pemadatan LSM dan penyesuaian per indeks, atau menyelesaikan masalah sistem yang sulit pada sejumlah perangkat keras terbaik yang dapat dibeli, Anda akan merasa cocok di sini.

Kami membuka lowongan di seluruh tim engineering. Lihat semua posisi yang tersedia di helius.dev/careers.