En iyi performans için Rails üzerinde SQLite: nasıl ve neden

• Son 1 yıldır SQLite kullanarak Rails uygulamalarını yüksek performanslı ve kararlı şekilde çalıştırmanın yollarını derinlemesine anlamaya çalışıyordu
• Bu süreçte çeşitli dersler çıkardı ve bunları paylaşmak istiyor
• Sorunların nedenlerini ve çözüm yöntemlerini açıklayacak

SQLite ve Rails'in sorunları

• Varsayılan olarak SQLite kullanan bir Rails uygulaması kutudan çıktığı gibi kullanıma hazır değil
• Biraz ayar ve ince ayarla yüksek performanslı ve kararlı bir uygulama oluşturulabilir
• Rails 8'de hedef, yalnızca varsayılan ayarlarla bile üretime hazır bir duruma gelmek

Demo uygulama "Lorem News"

• Sorunları ve çözümleri açıklamak için "Lorem News" adlı demo uygulama kullanılacak
• Bu uygulama Hacker News'in bir klonu ve kullanıcılar gönderi ile yorum yazabiliyor

Performans testi

• Performans, oha yük testi CLI aracı ve uygulama içindeki benchmark yolu kullanılarak test ediliyor
• Tekil istekler ve eşzamanlı isteklerle performans ölçülüyor

Ana sorun: SQLITE_BUSY istisnası

• SQLite, aynı anda yalnızca tek bir yazma işlemine izin vermek için yazma kilidi kullanır
• Birden fazla bağlantı aynı anda yazma kilidini almaya çalıştığında SQLITE_BUSY istisnası oluşur
• Bu sorunu çözmek için immediate transaction kullanılmalı

Immediate transaction

• Varsayılan olarak SQLite deferred transaction modunu kullanır
• Immediate transaction kullanıldığında yazma kilidi hemen alınmaya çalışılır ve başarısız olursa yeniden denenebilir
• sqlite3-ruby gem'i kullanılarak varsayılan transaction modu immediate moda ayarlanabilir

Timeout ayarı

• database.yml dosyasındaki timeout ayarıyla SQLITE_BUSY istisnaları azaltılabilir
• SQLite'ın busy_timeout ayarı kullanılarak yazma kilidi yeniden denenebilir

GVL (Global VM Lock) sorunu

• sqlite3-ruby gem'i, SQLite'ın C kodunu çağırırken GVL'yi serbest bırakmaz
• Bu durum eşzamanlılık performansını düşürür
• busy_handler kullanılarak GVL serbest bırakılabilir ve performans iyileştirilebilir

busy_timeout yeniden uygulaması

• busy_timeout yeniden uygulanarak tüm sorguların aynı sıklıkta yeniden denenmesi sağlanır
• Bu, daha eski sorguların timeout'a düşmesini engeller

Performans iyileştirmeleri

• Performansı artırmak için şu ayarlar uygulanmalı
  • Immediate transaction kullanımı
  • Timeout ayarı
  • busy_handler kullanımı
  • WAL (Write-Ahead Logging) modu kullanımı
  • Okuma/yazma bağlantı havuzlarının ayrılması

GN⁺ özeti

• SQLite kullanan Rails uygulamalarındaki performans sorunları ve çözümleri ele alınıyor
• Immediate transaction, timeout ayarı, GVL'nin serbest bırakılması, WAL modu kullanımı ve okuma/yazma bağlantı havuzlarının ayrılması gibi yöntemlerle performans artırılabilir
• Bu yazı, SQLite ve Rails kullanan geliştiriciler için oldukça faydalı olacaktır
• Benzer özelliklere sahip diğer projeler olarak PostgreSQL ve MySQL öneriliyor

[GN⁺]

Hacker News yorumları

• Oldmoe'nin Litestack projesine giriş

  • SQLite ve Rails kullananların Oldmoe'nin Litestack projesine göz atması gerekiyor
  • Litestack, SQLite'ın gücünden yararlanarak web uygulamaları için veri altyapısı sağlayan bir Ruby gem'i
  • SQL veritabanı, hızlı önbellek, güçlü iş kuyruğu, güvenilir mesaj aracısı, tam metin arama motoru ve metrik platformunu tek pakette sunuyor
  • Şu anda projede kullanıyorum ve oldukça memnunum

• Ayrıntılı makale için teşekkür

  • SQLite web uygulamalarını ölçeklendirmek isteyenler için faydalı bilgiler içeriyor
  • Rails'in ötesinde diğer framework'lerde de uygulanabilir
  • Yazara teşekkürler

• SQLite ile çalışanlara tavsiye

  • Kullandıkları dil veya framework'ten bağımsız olarak SQLite ile çalışan herkes bu makaleyi okumalı
  • Birkaç yıl önce elle çözmek zorunda kaldığım sorunları ele alıyor
  • Yazara teşekkürler

• FOSS analitik sistemi hakkında soru

  • Kurulumu kolay bir FOSS analitik sistemi yapıyorum
  • Olay verilerini ana uygulamanın verilerinden ayırmak için ayrı bir SQLite veritabanına göndermeyi düşünüyorum
  • Saniyede 1000'den fazla olayı işleyebilecek ölçeklenebilirlik konusunda endişelerim var
  • Olayları sunucu belleğinde tutup her saniye toplu olarak yazma yöntemini değerlendiriyorum
  • Bunun, SQLite'ın çok sayıdaki DB yazımı sorununu çözmek için makul bir yöntem olup olmadığına dair görüş arıyorum

• sqlite3-ruby gem'inin GVL sorunu

  • sqlite3-ruby gem'i, SQLite çağrıları sırasında GVL'yi serbest bırakmıyor
  • Bu çoğu durumda makul bir karar gibi görünüyor
  • Python eklentileri farklı şekilde tasarlanmış olabilir
  • extralite gem'i bloklama sırasında GVL'yi serbest bırakıyor; genelde daha hızlı ve eşzamanlılık sorunları da yaşamıyor

• Kişisel web hizmeti ayarları

  • Kişisel web hizmetimde kullandığım bazı ayarlar:
    • PRAGMA journal_mode = WAL
    • PRAGMA busy_timeout = 5000
    • PRAGMA synchronous = NORMAL
    • PRAGMA cache_size = 1000000000
    • PRAGMA foreign_keys = true
    • PRAGMA temp_store = memory
    • BEGIN IMMEDIATE transaction kullanımı

• Django hakkında soru

  • Bu makale harika
  • Django için benzer bir çözüm olup olmadığını merak ediyorum
  • ArchiveBox, Django üzerinden SQLite kullanıyor ve Rails tarafında bahsedilen sorunları sık sık yaşıyor
  • Uygulamanın diğer kanalları üzerinden tüm yazmaları serileştirmeyen bir SQLite katmanı çözümü olsa güzel olurdu

• busy_timeout varsayılan ayarı üzerine soru

  • Çok bilgilendirici ve iyi yazılmış bir makale
  • Varsayılan busy_timeout yönteminin neden eski sorguları cezalandıran bir gecikmeye sahip olduğunu merak ediyorum
  • Bunun neden varsayılan ayar olarak mantıklı olduğunu merak ediyorum

• SQLite ve Rails kullanımı hakkında görüş

  • SQLite ve Rails'i seviyorum ama bu, üretim ortamında MS Access kullanmaya benziyor

• Rails entegrasyon sorunlarının çözülmesine teşekkür

  • Entegrasyon sorunlarını çözüp başkalarına yardım ettiğini görmek her zaman sevindirici
  • Bu düzeltmelerin varsayılan Rails ayarlarına dahil edilmesini isterim
  • Bir Rails uygulaması çalıştırıyorum; birkaç yıl önce Postgres'e geçtim ve bundan çok memnunum
  • Yine de alternatiflerin olması güzel ve başka işler için SQLite kullanıyorum