Apa itu RocksDB? Penyimpanan Nilai-Kunci Tertanam

Apa itu RocksDB?

RocksDB adalah penyimpanan nilai-kunci persisten yang dapat ditanamkan dan dioptimalkan untuk penyimpanan cepat. RocksDB menerima kunci dan nilai sebagai array byte arbitrer, mempertahankan urutannya, dan menyimpannya secara persisten di disk. 

Hal terpenting yang perlu dipahami sejak awal adalah bahwa RocksDB merupakan library, bukan server. Tidak ada proses yang perlu dihubungkan, port yang perlu dibuka, ataupun bahasa kueri yang perlu dipelajari.

RocksDB terintegrasi dengan aplikasi dan berjalan dalam proses aplikasi tersebut, membaca serta menulis file pada disk lokal. Inilah yang membuat RocksDB cepat—tidak ada lompatan jaringan antara kode aplikasi dan data yang diprosesnya. RocksDB tetap minimal karena sengaja menyerahkan replikasi, sharding, dan kueri kepada sistem yang dibangun di atasnya.

Sederhananya, RocksDB adalah mesin penyimpanan—komponen yang menjadi fondasi database seperti TiDB dan YugabyteDB.

Apakah RocksDB sama dengan LevelDB?

Tidak, tetapi keduanya berasal dari basis kode yang sama. RocksDB dimulai pada 2012 sebagai fork dari LevelDB, penyimpanan nilai-kunci ringan yang dibuat oleh Jeff Dean dan Sanjay Ghemawat di Google. 

LevelDB dibuat untuk lingkungan berskala sederhana (misalnya, backend IndexedDB pada browser atau satu perangkat tertanam), dan berbagai keputusan desainnya disesuaikan dengan lingkungan tersebut, termasuk kompaksi single-thread, penggunaan memori yang konservatif, dan opsi penyesuaian yang terbatas.

Para engineer di Facebook, yang kini bernama Meta, menggunakan fondasi tersebut dan membangunnya kembali untuk beban kerja server. Tujuannya adalah memaksimalkan penggunaan hardware modern sambil menangani set data yang jauh lebih besar daripada memori di bawah tekanan penulisan berkelanjutan. 

RocksDB dijadikan open source pada 2013 dan sejak itu berkembang jauh dari LevelDB, dengan menghadirkan kompaksi multi-thread, column family, transaksi, pencadangan, operator penggabungan, gaya kompaksi yang dapat dipasang, serta daftar opsi penyesuaian yang terkenal sangat panjang.

LevelDB dan RocksDB memang memiliki kemiripan, tetapi menganggap keduanya dapat digunakan secara bergantian sudah tidak masuk akal sejak satu dekade lalu.

Bagaimana cara kerja RocksDB?

RocksDB dibangun di atas log-structured merge tree (LSM tree), yaitu struktur data yang mengorbankan kesederhanaan pembacaan demi throughput penulisan. 

Pada dasarnya, data masuk ditulis ke buffer dalam memori yang disebut memtable. Data tersebut secara bersamaan ditambahkan ke write-ahead log di disk untuk memastikan persistensi. 

Saat memtable penuh, memtable dibekukan dan dipindahkan ke disk sebagai file tetap yang terurut, yang disebut Sorted String Table (SST). File SST terakumulasi ke dalam hierarki berjenjang, sementara proses latar belakang bernama kompaksi terus menggabungkannya dan membuang nilai yang telah ditimpa serta kunci yang dihapus agar strukturnya tetap rapi, terurut, dan persisten.

Operasi baca memeriksa memtable terlebih dahulu, lalu menelusuri berbagai level file SST. Bloom filter memungkinkan RocksDB melewati file yang mustahil memuat kunci tersebut, sementara block cache menyimpan data yang sering diakses di dalam memori. Karena itu, sebagian besar operasi baca tidak pernah menyentuh lebih dari satu atau dua file.

Apa perbedaan antara LSM Tree dan B-tree?

B-tree, yaitu struktur yang digunakan oleh sebagian besar database tradisional, memperbarui data secara langsung di lokasi penyimpanannya. Artinya, penulisan acak tersebar di seluruh disk. LSM tree menambahkan dan mengelompokkan data sehingga menghasilkan penulisan sekuensial berukuran besar, sesuai dengan kebutuhan SSD dan beban kerja berintensitas penyerapan tinggi. Konsekuensinya, nilai terkini suatu kunci dapat tersebar di beberapa file. Kompaksi, Bloom filter, dan caching diperlukan untuk membatasi konsekuensi tersebut. 

Setiap keputusan desain dalam LSM tree pada akhirnya menyeimbangkan tiga tekanan:

• Amplifikasi penulisan
• Amplifikasi pembacaan
• Amplifikasi ruang

Meningkatkan dua aspek biasanya akan memperburuk aspek ketiga. 

Segitiga ini adalah model mental terpenting untuk memahami penyesuaian RocksDB. 

Untuk apa RocksDB digunakan?

RocksDB digunakan ketika aplikasi membutuhkan penyimpanan nilai-kunci yang cepat, persisten, dan terurut di disk lokal tanpa overhead menjalankan server database terpisah. Contoh nyata memperjelas pola ini dengan lebih baik daripada sekadar kategori.

Kafka Streams menyimpan status setiap tugas pemrosesan—agregasi berjalan, join, dan komputasi berbasis jendela—dalam penyimpanan RocksDB lokal. Dengan demikian, status dapat berkembang melampaui kapasitas memori dan bertahan setelah proses dimulai ulang tanpa menambahkan perjalanan bolak-balik jaringan untuk setiap pencarian.

ZippyDB milik Meta membungkus RocksDB dengan lapisan replikasi, pengelolaan shard, dan layanan konfigurasi untuk menyediakan penyimpanan nilai-kunci terdistribusi yang dikelola sepenuhnya. Pembagian tugasnya jelas: RocksDB menyediakan penyimpanan, sedangkan semua komponen terkait server dibangun di sekelilingnya.

Lapisan penyimpanan TiDB menjalankan RocksDB pada setiap node sebagai mesin di bawah database SQL terdistribusi, dengan mengodekan struktur tabel ke dalam prefiks kunci sehingga pemindaian tabel menjadi satu operasi baca berkelanjutan atas kunci yang terurut.

Setiap validator Solana berbasis Agave menulis ledger ke RocksDB dengan slot sebagai kunci, sehingga data ledger yang berurutan tersimpan berdekatan di disk.

Dua contoh terakhir menarik karena kunci disimpan secara terurut—berdasarkan byte secara default atau menggunakan komparator khusus—sehingga pemindaian rentang dan pencarian prefiks menjadi efisien.

Sebagian besar desain skema dalam sistem berbasis RocksDB di dunia nyata pada akhirnya bergantung pada pemanfaatan urutan tersebut.

Siapa yang menggunakan RocksDB?

Selain sistem di atas, RocksDB menjadi fondasi bagi sistem apa pun yang membutuhkan mesin penyimpanan tertanam yang telah teruji, matang, dan dioptimalkan untuk penulisan. Tim memilihnya karena dapat memanfaatkan hasil penguatan RocksDB selama satu dekade dalam lingkungan produksi Meta, alih-alih membuat mesin sendiri dari nol.

Beberapa contoh penting:

• Kafka Streams menggunakannya sebagai mesin default untuk penyimpanan status
• Apache Flink menawarkan backend status RocksDB untuk status dengan checkpoint yang terlalu besar untuk disimpan dalam memori
• MyRocks menanamkannya sebagai mesin penyimpanan MySQL, yang dikembangkan di Meta untuk mengurangi kebutuhan ruang penyimpanan pada beberapa armada MySQL terbesar yang ada
• Lapisan penyimpanan TiDB, TiKV, menggunakan RocksDB dengan instans terpisah untuk log Raft dan data nilai-kunci
• Penyimpanan dokumen YugabyteDB, DocDB, menggunakan RocksDB
• BlueStore milik Ceph menggunakan RocksDB untuk metadata penyimpanan objek
• ArangoDB telah menggunakan RocksDB sebagai mesin penyimpanan default sejak versi 3.4, dan sebagai satu-satunya mesin sejak versi 3.7

RocksDB terutama digunakan untuk beban kerja intensif penulisan yang ukurannya melampaui kapasitas memori pada SSD, sebuah poin yang akan dibahas kembali nanti dalam artikel ini.

Bagaimana Solana menggunakan RocksDB?

Solana adalah blockchain Proof of Stake berperforma tinggi dan berlatensi rendah yang dikenal karena fokusnya pada kecepatan, efisiensi, dan aplikasi konsumen. Ledger Solana tersimpan di RocksDB. Klien validator Agave menyimpan ledger dalam Blockstore, sebuah komponen yang berisi database RocksDB yang dibagi ke beberapa ruang kunci independen dan dapat disesuaikan. 

Column family terpisah menyimpan data shred dan pengodean penghapusan shred (yaitu unit mentah data ledger saat tiba melalui jaringan), status transaksi, indeks alamat-ke-tanda-tangan, dan berbagai metadata.

Pola penulisan validator sangat ekstrem dibandingkan dengan sebagian besar beban kerja database. Validator harus menyerap shred secara terus-menerus, menggunakan nomor slot yang meningkat hampir secara monoton sebagai kunci, pada kecepatan penuh jaringan, selamanya. Arsip ledger yang tidak dipangkas jauh melampaui ratusan terabyte dan setidaknya bertambah puluhan terabyte setiap tahun.

Dengan kompaksi berjenjang, column family shred menghasilkan begitu banyak pekerjaan kompaksi latar belakang sehingga validator mulai mengalami penghentian penulisan, yaitu mekanisme bawaan RocksDB untuk memperlambat penyerapan saat proses kompaksi tertinggal. 

Sekitar 2021, column family shred dialihkan ke kompaksi FIFO, gaya minimal yang hanya menghapus file terlama ketika batas ukuran tercapai. FIFO biasanya tidak aman untuk beban kerja umum. Namun, karena kunci shred tiba dengan urutan slot yang hampir monoton, validator dapat menghapus file terlama karena file tersebut memuat slot tertua. Hal ini menyesuaikan gaya kompaksi dengan bentuk beban kerja secara nyaris sempurna.

Optimalisasi kompaksi berjenjang berikutnya mengurangi amplifikasi I/O hingga FIFO tidak lagi memberikan keuntungan. Karena itu, jalur FIFO dinyatakan usang pada Juni 2024 dan dihapus pada November tahun tersebut.

Firedancer, klien validator Solana milik Jump Crypto yang ditulis dalam C, tidak menggunakan RocksDB sama sekali dan memilih lapisan penyimpanan internal yang dibuat khusus.

Apakah mesin penyimpanan yang dibuat dari nol dapat melampaui hasil penguatan dan penyesuaian RocksDB selama satu dekade masih menjadi pertanyaan terbuka yang menarik dalam rekayasa validator.

Kapan RocksDB bukan pilihan yang tepat?

RocksDB lebih sering menjadi pilihan yang keliru daripada yang tersirat dari penggunaannya yang luas. Cakupan penyesuaiannya sangat besar, dengan ratusan opsi yang interaksinya tidak mudah dipahami. Akibatnya, konfigurasi yang kurang tepat justru menjadi hasil umum, bukan pengecualian. 

Lebih buruk lagi, konfigurasi default RocksDB hanya cukup masuk akal, bukan optimal. Developer harus memahami kompromi amplifikasi yang dijelaskan di atas untuk memperoleh peningkatan performa nyata. Penyerapan berat yang berkelanjutan dapat melampaui kecepatan kompaksi latar belakang dan memicu penghentian penulisan, yang biasanya terjadi saat sistem sedang berada pada beban tertinggi.

Selain itu, RocksDB adalah library, bukan server. Semua fitur yang biasanya disediakan oleh server database (misalnya, replikasi, sharding, pencadangan, kontrol akses, lapisan kueri, dan alat operasional) harus dibangun sendiri.

Bentuk beban kerja juga sangat berpengaruh. 

RocksDB adalah mesin berorientasi baris untuk pencarian titik dan pemindaian rentang. Beban kerja analitis yang memindai bagian data yang luas dan melakukan agregasi lintas kolom lebih cocok menggunakan penyimpanan kolumnar seperti ClickHouse.

Semua ini bukan alasan untuk menghindari RocksDB. Sebaliknya, ini adalah alasan untuk memilihnya secara sadar. Kami di Helius mengevaluasi risiko tersebut secara langsung ketika mendesain ulang lapisan arsip kami dan tetap memilih RocksDB, karena bentuk beban kerjanya memang sesuai dengan tujuan RocksDB: pencarian titik dan pemindaian rentang sempit pada set data besar yang didominasi operasi penambahan. 

Kesimpulan

RocksDB adalah penyimpanan nilai-kunci tertanam, persisten, dan terurut yang mengorbankan kemudahan operasional demi performa murni pada disk lokal. RocksDB berasal dari LevelDB, diperkuat di Meta untuk SSD dan mesin multi-core, dan kini digunakan dalam berbagai sistem di seluruh dunia, mulai dari pemroses stream dan database SQL terdistribusi hingga klaster penyimpanan dan ledger Solana.

Jika menangani konfigurasi RocksDB berperforma tinggi dalam skala besar terdengar menarik, bergabunglah untuk membangunnya bersama kami.

Solana bergerak cepat untuk menjadi lapisan penyelesaian transaksi bagi keuangan global, dan infrastruktur di bawahnya berjalan menggunakan mekanisme yang dijelaskan dalam seri ini. Selesaikan masalah sistem yang kompleks menggunakan beberapa hardware terbaik yang dapat dibeli, dalam skala global.

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