Redka - Redis yang Diimplementasikan Ulang dengan SQLite

• Redka bertujuan untuk mengimplementasikan kembali keunggulan Redis di atas SQLite sambil tetap kompatibel dengan API Redis
• Fitur utama:
  • Data tidak perlu muat dalam ukuran RAM
  • Mendukung transaksi ACID
  • Memperkuat kemampuan kueri data dan pelaporan melalui view SQL
  • Mendukung server in-process (Go API) maupun standalone (RESP)
  • Mendukung perintah dan protokol yang kompatibel dengan Redis
• Saat ini masih dalam pengembangan, dan status dukungan serta roadmap dapat dilihat pada dokumen di bawah

Perintah yang Didukung

• Redka menargetkan dukungan untuk lima tipe data inti Redis: String, List, Set, Hash, dan Sorted Set
• String, Hash, pengelolaan Key, dan perintah transaksi sudah didukung, sementara List, Set, dan Sorted Set masih dalam pengembangan
• Untuk daftar perintah yang lebih rinci, lihat sumber asli

Cara Instalasi

Server standalone

• Unduh file biner yang sesuai dengan OS dari halaman Release lalu jalankan
• Jika menggunakan Docker, unduh image dengan docker pull nalgeon/redka

Modul Go

• Instal modul dengan go get github.com/nalgeon/redka
• Gunakan github.com/mattn/go-sqlite3 atau modernc.org/sqlite sebagai driver SQLite

Cara Penggunaan

Server standalone

• Jalankan file biner yang telah diunduh dalam bentuk redka [-h host] [-p port] [db-path]
  • Nilai bawaan: host localhost, port 6379, tanpa path DB (in-memory)
• Jika memakai Docker, jalankan dengan perintah docker run. Untuk opsi lebih rinci, lihat sumber asli
• Setelah server berjalan, koneksi dapat dilakukan dengan klien yang kompatibel dengan Redis seperti redis-cli, redis-py, atau go-redis

Server in-process

• Buat objek DB dengan fungsi redka.Open(). Import driver wajib dilakukan
• Jalankan berbagai perintah dengan memanggil method pada objek redka.DB
• Tangani transaksi dengan method View (read-only) dan Update (dapat menulis)

Persistensi

• Redka menyimpan data di database SQLite menggunakan tabel rkey, rstring, dan rhash
• Data dapat diambil lewat SQL melalui view untuk tiap tipe data (vstring, vhash, dll.)

Performa

• Performa Redis dan Redka dibandingkan menggunakan alat redis-benchmark
  • Redka sekitar 6 kali lebih lambat untuk SET, dan sekitar 2 kali lebih lambat untuk GET
  • Meski begitu, tetap menunjukkan performa sekitar 23K writes/detik dan 57K reads/detik
• Saat dijalankan di container, performa bisa menurun

Roadmap

• Pada rilis 1.0, implementasi direncanakan berfokus pada fitur utama era Redis 2.x
  • Dukungan untuk String, Hash, pengelolaan Key, dan transaksi sudah selesai
  • Sorted Set sedang dikembangkan
  • List dan Set direncanakan untuk dikembangkan
• Pada versi mendatang, tipe data seperti Stream, HyperLogLog, Geo, serta fitur Pub/Sub akan ditambahkan
• Lua scripting, autentikasi/ACL, multi-DB, Watch/Unwatch, dan lainnya tidak direncanakan untuk diimplementasikan
• Fitur cluster dan sentinel juga tidak akan diimplementasikan

Pendapat GN⁺

• Pendekatan Redka yang tetap kompatibel dengan sebagian besar Redis sambil menyediakan persistensi terasa menarik. Dukungan transaksi ACID juga tampak menjadi nilai plus.
• Dari sisi performa memang belum menyamai Redis, tetapi jika yang dibutuhkan adalah persistensi, ini tampak cukup layak dipertimbangkan sebagai alternatif.
• Namun karena masih berada pada tahap awal pengembangan, stabilitasnya masih perlu diamati lebih lanjut, dan cukup banyak fitur yang tidak masuk roadmap perlu dipertimbangkan saat adopsi nyata.
• Untuk penggunaan in-memory, tentu sulit menyaingi Redis, tetapi sebagai lapisan persistensi berbasis SQLite, Redka tampaknya bisa berguna.
• Belakangan ini permintaan terhadap stack yang ringan di lingkungan edge computing meningkat, dan di area seperti itu Redka mungkin bisa dicoba sebagai pengganti Redis.

[yangeok]

Sepertinya akan berguna dipakai saat scheduler perlu terhubung ke Redis, hehe

[GN⁺]

Komentar Hacker News

• Ada pertimbangan tentang sejauh mana mengikuti model Redis yang "semuanya diserialkan dalam satu thread", tanpa konkurensi
• Performa yang lebih baik bisa didapat dari SQLite dengan menggunakan library tingkat rendahnya, mengaktifkan WAL, memakai koneksi per goroutine baca, dan mengirim batch penulisan melalui channel/queue ber-buffer ke thread writer khusus
• Dengan cara ini, mutex bawaan SQLite per koneksi dapat dimatikan, sambil tetap menjaga keamanan thread karena tiap koneksi hanya digunakan oleh satu thread pada satu waktu
• Menggunakan buffer besar bergaya arena, seperti menyalin byte parameter yang masuk dari permintaan jaringan/soket ke buffer, atau menyalin langsung dari SQLite ke soket, bisa sangat menghemat waktu dengan mengurangi alokasi dan penerusan string individual
• Ini adalah tips yang berasal dari pengalaman mencoba mendapatkan throughput tulis maksimum dari SQLite di Go
• Saya menyukai Redis dan SQLite, jadi saya memutuskan untuk menggabungkan keduanya. SQLite tampaknya cocok karena sangat dioptimalkan untuk banyak query kecil, sehingga mesin relasionalnya sudah sedekat mungkin dengan Redis
• Saya menunggu seseorang mengganti state machine TigerBeetle untuk mengimplementasikan API Redis
• Akan menyenangkan jika ada alternatif Redis yang tidak mengharuskan kita memikirkan apakah dataset muat di memori atau tidak
• Seluruh proposisi nilai Redis adalah berjalan di memori dan memberikan performa seperti memori. Jika dipindahkan ke disk, hampir tidak ada alasan untuk memakai Redis
• Begitu network I/O ditambahkan, banyak dari performa fantastis Redis hilang. Jika memakai layanan Redis hosting SaaS, performanya akan terkena dampak besar. Jika lebih mudah menjalankan key/value store kompatibel Redis di klaster sendiri, itu merupakan keuntungan
• Penasaran apakah ini atau Garnet mendukung lebih banyak perintah Redis. Saya ingin menanamkan subset fitur kompatibel Redis ke dalam program untuk keperluan debugging lokal, dengan API di tengah agar bisa melindungi dari perintah Redis yang tidak didukung
• Ketika Foursquare membuat MongoDB terkenal, seseorang pernah memposting PoC database NoSQL yang diimplementasikan di atas MySQL, tetapi itu tidak menjadi tren. Namun hal itu membuat saya berpikir tentang seberapa banyak performa yang telah dikorbankan agar kita tidak perlu menemukan kembali SQL setiap kali membutuhkan database. Saya menyukai eksperimen seperti ini, dan kadang-kadang itu berujung pada proyek baru
• Saya menggunakan Redis sebagai lapisan cache di depan database. Saya tidak mengerti konsep ini
• Ngomong-ngomong, meskipun menggunakan SetMaxConnections(1), dalam mode WAL (yang sedang dipakai), SQLite mendukung penulisan yang tidak memblokir pembacaan, jadi mungkin ada manfaat jika konkurensi baca diizinkan