00:00:00Saat Anda memulai proyek baru dan butuh basis data, opsi apa yang pertama kali
00:00:03muncul di pikiran? SQLite? Mungkin SQLite, kan? Maksud saya, ini bagus, andal,
00:00:09tanpa konfigurasi, dan standar industri. Namun saat data lokal kita semakin berat dan kueri
00:00:14semakin kompleks, kita mulai mencapai batas maksimal dari kemampuan mesin
00:00:20pengunci file berulir tunggal (single-threaded). Tapi sekarang ada pemain baru yang mencoba mengatasi masalah ini.
00:00:25Namanya Stulab, mesin basis data yang ditulis seluruhnya dalam bahasa Rust dan baru saja merilis
00:00:31driver native Node.js yang sejujurnya menunjukkan performa yang sangat kuat. Basis
00:00:36data ini 138 kali lebih cepat daripada SQLite. Jadi di video ini, kita akan mengintip
00:00:43jeroan Stulab, melihat cara kerjanya, dan menjalankan uji tolok ukur (benchmarking) langsung untuk melihat apakah memang sekuat
00:00:50klaimnya. Ini akan sangat menyenangkan, jadi mari kita mulai. Jadi, apa sebenarnya Stulab itu?
00:01:00Pada intinya, Stulab adalah basis data OLAP (Online Analytical Processing) tertanam. Nah,
00:01:06jika Anda terbiasa dengan basis data standar seperti SQLite atau Postgres, itu biasanya OLTP
00:01:14atau Online Transactional Processing, yang sesuai namanya, dioptimalkan untuk transaksi. Namun
00:01:20Stulab berbeda. Ia dirancang untuk beban kerja analitis dan dibangun dari awal dengan Rust
00:01:27yang berfokus pada pemrosesan data kecepatan tinggi. Bayangkan ini memiliki portabilitas file SQLite,
00:01:33tapi dengan kekuatan analitis murni seperti DuckDB atau BigQuery. Namun hal yang paling keren
00:01:39adalah Anda kini bisa menggunakannya dengan Node.js berkat driver native Node miliknya. Saat saya bilang
00:01:45ini driver native, saya tidak bicara tentang wrapper standar. Biasanya saat basis data
00:01:49ditulis dalam bahasa berbeda seperti Rust atau C++, aplikasi Node.js Anda harus berkomunikasi lewat jembatan.
00:01:56Sering kali itu berarti mengonversi data Anda ke JSON atau format lain, mengirimnya melalui soket jaringan lokal,
00:02:02dan kemudian mengonversinya kembali di sisi lain. Itu disebut overhead serialisasi dan
00:02:08merupakan pembunuh performa yang masif. Tapi Stulab Node melakukan hal yang berbeda. Ia menggunakan NAPI-RS,
00:02:15kerangka kerja yang memungkinkan mesin Rust dikompilasi menjadi biner native yang dimuat
00:02:21langsung ke dalam proses Node.js Anda. Jadi tidak ada jembatan dan tidak ada penerjemah di antaranya. Saat Anda mengirim
00:02:27kueri, Node.js dan Rust pada dasarnya berbagi ruang memori yang sama. Dan ada tiga alasan besar
00:02:33mengapa Stulab sangat cepat. Pertama, ia menggunakan MVCC atau multi-version concurrency control.
00:02:40Berbeda dengan SQLite di mana satu penulis bisa mengunci seluruh basis data, Stulab memungkinkan banyak pembaca
00:02:47dan penulis bekerja secara bersamaan. Kedua, ia menggunakan eksekusi paralel. Stulab menggunakan penjadwal
00:02:53bernama Rayon. Dengan Rayon, saat Anda menjalankan kueri besar, alih-alih hanya berjalan di satu inti CPU, ia membagi
00:03:00kueri tersebut dan memanfaatkan setiap inti yang dimiliki mesin Anda. Dan ketiga, ia menggunakan pengoptimal
00:03:06berbasis biaya (cost-based optimizer). Jadi ia tidak hanya menjalankan SQL Anda secara buta, ia menganalisis data Anda,
00:03:13memperkirakan biaya dari berbagai jalur, dan memilih cara tercepat untuk mendapatkan hasilnya. Jadi itulah yang konon
00:03:19membuat Stulab menjadi opsi yang jauh lebih cepat daripada SQLite. Mari kita uji untuk melihat apakah itu benar.
00:03:25Untuk pengujian ini, kita akan menggunakan proyek Node.js sederhana dan kita akan menginstal Stulab serta
00:03:30SQLite sebagai dependensi. Salah satu kemenangan terbesar di mana Stulab benar-benar unggul adalah penggunaan count distinct.
00:03:37Jadi saya sangat penasaran apakah memang demikian. Saya menyiapkan skrip sederhana ini di mana kita menjalankan
00:03:43versi in-memory dari masing-masing basis data dan membuat tabel penjualan sederhana. Kita lalu mengisi tabel ini
00:03:49dengan 10.000 baris data penjualan acak di mana setiap baris mewakili penjualan dari pengguna yang ID-nya bervariasi
00:03:56dari 0 hingga 1.000 dan memiliki salah satu kategori tertentu. Kita akan memasukkan data tersebut secara massal (batch)
00:04:03ke kedua basis data dan menjalankan tolok ukur di mana kita memilih jumlah unik (distinct count) penjualan yang dilakukan
00:04:10oleh pengguna tertentu pada kategori tertentu dan menghitung performa masing-masing basis data. Sekarang, saya harus
00:04:16mencatat bahwa agak menjengkelkan karena saat ini paket yang diinstal tidak berfungsi. Jika kita jalankan
00:04:22uji tolok ukurnya sekarang, kita melihat ada keluhan tentang native binding yang hilang. Penulis proyek ini
00:04:28jelas lupa menambahkan biner atau menghubungkan biner yang benar ke paket tersebut. Jadi apa yang harus saya lakukan
00:04:34adalah membangunnya dari sumber (build from source). Jadi saya mengkloning repo-nya, menjalankan build di dalamnya, lalu kembali
00:04:39ke proyek tolok ukur saya dan menghubungkan direktori sumber saya sebagai dependensi. Ini agak
00:04:44melelahkan saat ini, jadi saya harap para pembuat proyek ini akan memperbaikinya di masa mendatang. Tapi
00:04:49meskipun begitu, setelah melakukannya, kita akhirnya bisa menjalankan tolok ukur tersebut. Mari kita lakukan sekarang.
00:04:54Seperti yang Anda lihat, operasi count distinct memang jauh lebih cepat di Stulab, meskipun tidak
00:05:01secepat yang diiklankan. Hanya empat kali lebih cepat. Jadi bagaimana jika kita tambahkan satu angka nol lagi pada jumlah
00:05:07data yang ingin kita isi dan menjalankan pengujian lagi dengan 1.000.000 baris? Mari kita coba sekarang.
00:05:12Jadi bahkan untuk satu juta baris, Stulab hanya enam kali lebih cepat, bukan 138 kali. Namun
00:05:20demikian, itu tetap hasil yang luar biasa. Itu tadi tes count distinct. Saya memutuskan untuk melakukan satu lagi
00:05:26uji tolok ukur untuk menguji operasi distinct + order by. Dan dalam pengujian kedua ini, saya menyiapkan skema
00:05:33di mana kita memasukkan beberapa log acak dengan alamat IP dan kode status yang berbeda, lalu mencoba mencari
00:05:39log unik berdasarkan pasangan alamat IP dan kode status, kemudian mengurutkannya berdasarkan IP secara naik (ascending)
00:05:47dan kode status secara turun (descending). Seperti yang Anda lihat, setelah kita jalankan tes ini, Stulab masih berperforma
00:05:53lebih baik daripada SQLite, tapi bukan 14 kali, melainkan hanya 1 hingga 1,5 kali lebih cepat. Jadi pengukuran yang
00:06:01tercantum di sini agak berlebihan menurut saya. Tapi bagaimanapun juga, Stulab memang lebih cepat dari SQLite.
00:06:08Agar adil, penulis juga menyebutkan area di mana SQLite masih berperforma lebih baik daripada Stulab.
00:06:13Terutama pada situasi di mana Anda melakukan operasi baris tunggal (single row). Jadi Stulab sangat bagus untuk
00:06:19kueri analitis dan kompleks. Jadi apakah Stulab adalah pembunuh SQLite? Sejujurnya, tidak. Keduanya dibuat
00:06:26untuk hal yang benar-benar berbeda. SQLite masih menjadi andalan harian Anda yang andal untuk transaksi,
00:06:32tapi Stulab mungkin menjadi mobil balap berperforma tinggi Anda untuk analisis data. Tapi fakta bahwa kita
00:06:38sekarang memiliki mesin analitis berbasis Rust murni yang bisa kita masukkan ke proyek Node.js dengan NAPI-RS
00:06:45itu sangat luar biasa. Pemilik proyek hanya perlu memastikan mereka menambal paket NPM mereka saat ini,
00:06:50sehingga kita tidak perlu membangunnya dari sumber. Jadi, begitulah kawan-kawan. Itulah Stulab secara singkat.
00:06:55Tapi bagaimana menurut Anda? Apakah peningkatan performanya sepadan untuk beralih ke Stulab, atau Anda tetap
00:07:01memilih keandalan SQLite? Beri tahu kami di kolom komentar di bawah. Dan kawan-kawan, jika menurut Anda
00:07:06video ini bermanfaat, tolong beri tahu saya dengan menekan tombol suka di bawah video. Dan juga jangan
00:07:11lupa untuk berlangganan saluran kami. Saya Andris dari Better Stack dan sampai jumpa di
00:07:17video-video berikutnya.