Cara dan Alasan Menggunakan SQLite di Rails untuk Performa Optimal

• Selama satu tahun terakhir, penulis berupaya memahami secara mendalam cara menjalankan aplikasi Rails dengan SQLite agar berkinerja baik dan stabil
• Dalam prosesnya, ada banyak pelajaran yang didapat dan ingin dibagikan
• Artikel ini akan menjelaskan penyebab masalah dan cara mengatasinya

Masalah SQLite dan Rails

• Secara default, aplikasi Rails yang menggunakan SQLite belum benar-benar siap dipakai begitu saja
• Dengan sedikit penyesuaian dan fine-tuning, aplikasi bisa dibuat memiliki performa yang baik dan stabil
• Di Rails 8, targetnya adalah agar konfigurasi bawaan saja sudah cukup untuk siap produksi

Aplikasi demo "Lorem News"

• Penjelasan masalah dan solusi akan menggunakan aplikasi demo bernama "Lorem News"
• Aplikasi ini adalah klon Hacker News, tempat pengguna bisa membuat postingan dan komentar

Pengujian performa

• Performa diuji menggunakan CLI load test oha dan rute benchmarking di dalam aplikasi
• Kinerja diukur lewat permintaan tunggal dan permintaan konkuren

Masalah utama: pengecualian SQLITE_BUSY

• SQLite menggunakan write lock untuk memastikan hanya satu operasi tulis yang diizinkan pada satu waktu
• Jika beberapa koneksi mencoba mengambil write lock secara bersamaan, akan muncul pengecualian SQLITE_BUSY
• Untuk mengatasi masalah ini, perlu menggunakan immediate transaction

Immediate transaction

• Secara default, SQLite menggunakan mode deferred transaction
• Dengan immediate transaction, upaya mengambil write lock dilakukan segera dan bisa diulang jika gagal
• Gem sqlite3-ruby dapat digunakan untuk mengatur mode transaksi default menjadi mode immediate

Pengaturan timeout

• Pengaturan timeout di file database.yml dapat mengurangi pengecualian SQLITE_BUSY
• Pengaturan busy_timeout milik SQLite dapat digunakan untuk mencoba ulang write lock

Masalah GVL (Global VM Lock)

• Gem sqlite3-ruby tidak melepaskan GVL saat memanggil kode C milik SQLite
• Hal ini menurunkan performa konkurensi
• Dengan busy_handler, GVL bisa dilepas dan performa dapat ditingkatkan

Implementasi ulang busy_timeout

• busy_timeout diimplementasikan ulang agar semua kueri mencoba ulang dengan frekuensi yang sama
• Ini mencegah kueri yang lebih lama mengalami timeout

Peningkatan performa

• Untuk meningkatkan performa, perlu menerapkan pengaturan berikut
  • menggunakan immediate transaction
  • mengatur timeout
  • menggunakan busy_handler
  • menggunakan mode WAL (Write-Ahead Logging)
  • memisahkan connection pool baca/tulis

Ringkasan GN⁺

• Membahas masalah performa aplikasi Rails yang menggunakan SQLite beserta solusinya
• Performa dapat ditingkatkan melalui immediate transaction, pengaturan timeout, pelepasan GVL, penggunaan mode WAL, dan pemisahan connection pool baca/tulis
• Artikel ini akan sangat berguna bagi pengembang yang menggunakan SQLite dan Rails
• Untuk proyek lain dengan fungsi serupa, PostgreSQL dan MySQL direkomendasikan

[GN⁺]

Komentar Hacker News

• Memperkenalkan proyek Litestack dari Oldmoe

  • Orang yang menggunakan SQLite dan Rails perlu melihat proyek Litestack dari Oldmoe
  • Litestack adalah gem Ruby yang menyediakan infrastruktur data aplikasi web dengan memanfaatkan kekuatan SQLite
  • Menyediakan database SQL, cache cepat, antrean tugas yang kuat, message broker yang andal, mesin pencarian teks lengkap, dan platform metrik dalam satu paket
  • Saat ini sedang digunakan di proyek, dan sangat memuaskan

• Terima kasih untuk artikel yang ditulis dengan rinci

  • Informasinya berguna bagi orang yang ingin menskalakan aplikasi web SQLite
  • Bisa diterapkan juga di framework lain di luar Rails
  • Terima kasih kepada penulis

• Direkomendasikan bagi siapa pun yang bekerja dengan SQLite

  • Siapa pun yang bekerja dengan SQLite sebaiknya membaca artikel ini, terlepas dari bahasa atau framework yang digunakan
  • Artikel ini membahas masalah-masalah yang beberapa tahun lalu harus diselesaikan sendiri
  • Terima kasih kepada penulis

• Pertanyaan tentang sistem analitik FOSS

  • Sedang membuat sistem analitik FOSS yang mudah dipasang
  • Ingin mengirim data event ke database SQLite terpisah agar terisolasi dari data aplikasi utama
  • Ada kekhawatiran tentang skalabilitas untuk menangani lebih dari 1000 event per detik
  • Sedang mempertimbangkan cara menyimpan event di memori server dan menulisnya secara batch sekali per detik
  • Meminta pendapat apakah ini pendekatan yang masuk akal untuk mengatasi banyak masalah penulisan DB di SQLite

• Masalah GVL pada gem sqlite3-ruby

  • Gem sqlite3-ruby tidak melepaskan GVL saat memanggil SQLite
  • Ini tampaknya keputusan yang masuk akal dalam banyak kasus
  • Bisa jadi ekstensi Python dirancang dengan cara yang berbeda
  • Gem extralite melepaskan GVL saat blocking, umumnya lebih cepat, dan tidak memiliki masalah konkurensi

• Pengaturan layanan web pribadi

  • Beberapa pengaturan yang digunakan pada layanan web pribadi:
    • PRAGMA journal_mode = WAL
    • PRAGMA busy_timeout = 5000
    • PRAGMA synchronous = NORMAL
    • PRAGMA cache_size = 1000000000
    • PRAGMA foreign_keys = true
    • PRAGMA temp_store = memory
    • Menggunakan transaksi BEGIN IMMEDIATE

• Pertanyaan tentang Django

  • Artikel ini luar biasa
  • Ingin tahu apakah ada solusi serupa untuk Django
  • ArchiveBox menggunakan SQLite melalui Django dan sering mengalami masalah yang disebutkan pada Rails
  • Akan bagus jika ada solusi di lapisan SQLite yang tidak menserialisasi semua penulisan melalui channel lain di aplikasi

• Pertanyaan tentang pengaturan default busy_timeout

  • Artikel ini sangat informatif dan ditulis dengan baik
  • Ingin tahu mengapa metode busy_timeout default memiliki penundaan yang menghukum kueri yang lebih lama
  • Ingin tahu mengapa ini masuk akal sebagai pengaturan default

• Pendapat tentang penggunaan SQLite dan Rails

  • Menyukai SQLite dan Rails, tetapi ini mirip seperti menggunakan MS Access di lingkungan produksi

• Terima kasih atas penyelesaian masalah integrasi Rails

  • Selalu senang melihat masalah integrasi diselesaikan dan orang lain dibantu
  • Berharap perbaikan-perbaikan ini dimasukkan ke pengaturan default Rails
  • Menjalankan aplikasi Rails, dan beberapa tahun lalu beralih ke Postgres dengan hasil yang sangat memuaskan
  • Tetap bagus bahwa masih ada alternatif, dan SQLite digunakan untuk pekerjaan lain