SQLite-on-the-Server hakkındaki yanlış anlama: küçük ölçekten çok hiper ölçeğe daha uygun
(rivet.gg)- Birçok geliştirici sunucuda SQLite kullanmanın yalnızca küçük ölçekli uygulamalara uygun olduğunu düşünüyor
- Bunun nedenleri şunlar:
- Düşük altyapı maliyeti: Ayrı bir veritabanı sunucusu gerekmez (tek dosya olarak çalışır)
- Geliştirme ve test kolaylığı: Aynı DB dosyası istemci ve sunucuda kullanılabilir
- Minimum yönetim yükü: Karmaşık ayarlar veya daemon yönetimi gerekmez
- Yüksek güvenilirlik: SQLite dünyada en yaygın dağıtılan DB'dir ve güçlü dayanıklılığa sahiptir
- LiteFS, Litestream, rqlite, Dqlite, Bedrock gibi araçlar SQLite'a replikasyon (replication) ve yüksek erişilebilirlik (HA) ekleyerek onu küçük ölçekli dağıtımlar için uygun hale getirir
Ancak bu yazı, küçük ölçek değil hiper ölçekli uygulamalar için uygun SQLite olasılığını inceliyor
Mevcut büyük veritabanlarını ölçeklemenin sorunları
- Büyük uygulamalar genellikle PostgreSQL ve MySQL'i tek bir DB olarak sürdürmekte zorlandığı için sharding uygulanmış veritabanları kullanır
- Örnekler: Cassandra, ScyllaDB, DynamoDB, Vitess (sharding uygulanmış MySQL), Citus (sharding uygulanmış Postgres)
- Sharding uygulanmış DB'ler şu avantajlara sahiptir:
- Veri bölümleme sayesinde batch read optimizasyonu
- Yatay ölçeklenebilirlik (scalability)
- Yüksek hızlı yazma performansı
Ancak mevcut partitioning çözümlerinin şu dezavantajları var
- Katı şemalar (Rigid Schemas): MySQL veya Postgres gibi esnek sorguları desteklemez
- Şema değişiklikleri zordur: İndeks ekleme veya ilişkileri değiştirme sırasında operasyonel yük büyüktür
- Karmaşık cross-partition işlemleri: ACID transaction'ları korumak zordur ve two-phase commit (2PC) gibi karmaşık teknikler gerekir
- Veri tutarsızlığı sorunları: Partition'lar arasında güçlü veri kısıtları uygulamak zordur ve veri bütünlüğünün bozulma olasılığı yüksektir
SQLite tabanlı hiper ölçek veritabanının potansiyeli
- Cloudflare Durable Objects ve Turso, SQLite tabanlı hiper ölçekli uygulama tasarımının nasıl yapılabileceğini gösteriyor
- Bu sistemler şu güçlü yönleri sunuyor:
- Dinamik ölçekleme (Dynamic Scaling): Her entity için veritabanı oluşturarak altyapı karmaşıklığını azaltır
- Sınırsız sayıda düşük maliyetli veritabanı: Klasik sharding'deki gibi veri partitioning'ini zorlamadan gerektiğinde yeni SQLite instance'ları oluşturulabilir
- Küresel dağıtım (Global Distribution): Veritabanlarını kullanıcıya yakın konumlara yerleştirerek performansı artırır
- Yerleşik replikasyon ve dayanıklılık (Built-in Replication & Durability): Klasik SQLite'tan farklı olarak veriyi çoklu bölgede çoğaltarak yüksek erişilebilirlik sağlar
- SQLite kullanan bu sharding alternatifi yaklaşımı (Cloudflare Durable Objects & Turso kullanımı)
- Mevcut sharding yönteminde birden çok sohbet kaydı tek bir veritabanı partition'ında tutulur
- SQLite ile her kanal için bağımsız bir SQLite veritabanı oluşturmak mümkün olur ve böylece daha esnek şema kullanımı sağlanır
- Örnek yapı
- Mevcut sharding: sohbet kayıtları tablosu + partition key
- SQLite tabanlı: kanal başına ayrı SQLite DB (sohbet kayıtları, katılımcılar, tepki bilgileri dahil)
- SQLite kullanan bu yöntemin avantajları şunlardır:
- Yerel ACID transaction'larını korur: Cross-partition sorunları olmadan tek tek DB'ler içinde transaction yürütülebilir
- Yüksek performanslı I/O: SQLite tek dosyalı bir DB olduğu için okuma ve yazma performansı çok yüksektir
- SQL genişletme özelliklerinden yararlanma:
- FTS5 (Full-Text Search): arama performansını artırır
- JSON1: JSON verisini saklama ve sorgulama desteği
- R*Tree, SpatiaLite: uzamsal veri kullanımı
- SQL migration desteği: Prisma ve Drizzle gibi mevcut migration araçlarıyla uyumludur
- Yavaş (Lazy) şema migration desteği:
- Migration'ların hemen çalıştırılması gerekmez; SQLite instance'ı açılırken hafif migration'lar uygulanabilir
Sunucuda SQLite kullanmanın sınırlamaları
- Açık kaynaklı, self-host edilebilir çözüm eksikliği
- Cross-database sorgu desteği yok → analiz için ayrı bir data lake gerekir
- Sınırlı veritabanı tooling'i (SQL browser, ETL pipeline'ları, monitoring, backup)
- StarbaseDB bu sorunu Cloudflare Durable Objects + SQLite tabanlı olarak çözmeye çalışıyor
- Birleşik standart protokol eksikliği
- PostgreSQL, MySQL ve Cassandra standartlaşmış protokoller kullanır, ancak SQLite sunucuları için hâlâ standartlaşmış bir ağ protokolü eksiktir
- Hiper ölçekte SQLite kullanılan büyük ölçekli örneklerin azlığı
- Cassandra ve DynamoDB gibi örnek incelemeleri az olsa da bunun zamanla değişmesi mümkün
Sonuç: SQLite yalnızca basit bir yerel DB değil, hiper ölçekli uygulamalarda da güçlü bir seçenek
- SQLite, yalnızca küçük projeler için basit bir DB değil; hiper ölçekli uygulamalarda da mevcut sharding yaklaşımının yerini alabilecek güçlü bir araçtır
- Cloudflare Durable Objects & Turso ile veritabanını entity düzeyinde bölerek SQL'in güçlü özelliklerini ve ACID transaction'larını korurken ölçeklenmek mümkündür
- Geleneksel sharding uygulanmış veritabanlarına göre daha esnek ve yönetimi daha kolay bir alternatif olma potansiyeli yüksektir
2 yorum
Birinin, bu kadar çok isteği kaldıran hiper ölçekte SQLite’ı isteyerek kullanıp kullanmayacağını merak ediyorum...
Hacker News görüşleri
Bir kullanıcı, özel yapım veritabanını SQL ile değiştirmeyi düşünüyor
Bir kullanıcı yerel öncelikli bir web uygulaması geliştiriyor ve SQLite'ın uygun olduğunu düşünüyor
SQLite-Per-Partition yaklaşımının faydaları tartışılıyor
Çok kullanıcılı ortamlarda SQLite, MVCC eksikliği nedeniyle zorluk yaşıyor
Ruby on Rails'in 8.0 sürümünde SQLite desteği genişletildi
Vitess veya Citus'a aşina olmayan bir kullanıcı, makaledeki içeriği anlamakta zorlanıyor
Bir kullanıcı VPS barındırma istemediği için SQLite kullanan bir web sayfası yaptı
Ubiquiti controller kurmakta zorlanan bir kullanıcı SQLite kullanılmasını öneriyor
Apple'ın 2022 itibarıyla yaklaşık 300.000 Cassandra/ScyllaDB instance'ı işlettiği belirtiliyor
TDLib (Telegram veritabanı kütüphanesi) SQLite kullanıyor