- SQLite çok hızlıdır. Tek bir sıradan sunucuda (~40€/ay) aynı anda yaklaşık 168.000 okuma ve yaklaşık 8.000 yazmayı sürdürebilir
- Gömülü sistemler, telefonlar, masaüstü uygulamaları gibi istemci tarafı uygulamalar için tasarlanmış gömülü bir kütüphane olduğu için SQLite veritabanı uygulama sunucusuyla birlikte bulunmalıdır ve ağa üzerinden erişilemez
- Peki birden fazla makine gereken durumlarda SQLite nasıl kullanılabilir?
- Hafta sonu projesi patlayıcı bir popülerlik kazanıp hızla ölçeklenmek zorunda kalabilir
- CTO'nun gereksinimlerinden biri, yüksek erişilebilirlikli hizmeti en az 2 farklı veri merkezine dağıtmak olabilir
- Son birkaç yılda SQLite'ı backend uygulamaları için bir backend veritabanına dönüştürmeye çalışan bazı projeler ortaya çıktı
- Bu yazı, bunun kurumların daha iyi kullanıcı deneyimini daha hızlı sunmasını sağlayan bir paradigma değişimi mi, yoksa şirketlerin "benzersiz satış teklifi (Unique Selling Proposition)"ni şişirmek için ittiği bir pazarlama abartısı mı olduğunu inceliyor
SQLite'ı edge veritabanı olarak kullanmak
- SQLite, yalnızca basit bir backend veritabanı olarak değil, bir edge veritabanı olarak da pazarlanıyor
- En öne çıkan oyuncular Cloudflare D1, LiteFS kullanan fly.io ve Turso
- SQLite türevi ürünlerin çoğu benzer şekilde çalışır
- Bir yerde yazmaları kabul eden birincil veritabanı vardır ve bu veriler diğer bölgelere eşzamansız olarak çoğaltılır
- Çoğaltma çoğunlukla veritabanında yürütülen tüm işlemlerin günlüğünü, SQLite'ın Write-Ahead Log'unu akış halinde ileterek yapılır
- Bu mimaride teorik olarak okumalar edge veri merkezlerinde işlenebilir, ancak yazmaların yine de merkezi bir konuma iletilmesi gerekir
- Pratikte ise, müşterinin e-ticaret uygulamasında siparişi tamamladığı, birincil SQLite veritabanında siparişin onaylandığı ama bölgesel okuma replikasının geride kaldığı ve henüz güncellenmiş veriyi almadığı için "bulunamadı" hata mesajı gösterildiği bir durum istemezsiniz
- "Acı verici eventual consistency dünyasına" hoş geldiniz
LiteFS'nin çözümü ve sınırları
- LiteFS, hack benzeri bir çözüm önerir. Uygulama, bölgesel replikadaki son işlemi izlemek için
__txidçerezini ayarlar ve replika fazla gerideyse okuma sorgusunu temel veritabanına yönlendirir - Artık uygulama, veritabanı ve reverse proxy ile sıkı şekilde bağlı hale gelir
- LiteFS, saniyede yalnızca yaklaşık 100 yazmayı desteklediği gerçeğinden bahsetmez
Çoğu dağıtık SQLite sisteminin temel dezavantajları
- Dağıtık SQLite sistemlerinin çoğu, bir işlemin farklı sorguları arasında bazı hesaplamalar yapan etkileşimli transaction'ları desteklemez
- Aynı anda yalnızca tek bir yazma transaction'ı etkin olabilir. Normal bir SQLite veritabanında çoğu yazma onlarca mikrosaniyeden uzun sürmediği için bu genelde sorun olmaz
- Ancak uygulama ile SQLite veritabanı arasına ağ gecikmesi eklerseniz sistem bozulur. Veritabanı, transaction'ın gidiş-dönüş süresi boyunca kilitli kalır ve saniyede yalnızca birkaç yazmayla sınırlanır
- Turso bunu batch ile "çözer". Birden fazla sorgu batch içinde gruplanıp tek bir transaction olarak çalıştırılabilir. Cloudflare D1 ise sorunu batch ve stored procedure'lerle "çözer"
Ya daha basit bir çözüm varsa?
- Web uygulamaları için dünyada her yerde çok hızlı olmayı sağlayan çok basit ve güçlü bir yöntem zaten var:
Cache-ControlveETagbaşlıklarıyla HTTP önbellekleme - HTTP önbellekleme kullanıldığında, zayıf tutarlılıklı veritabanlarına benzer tekniklere ihtiyaç kalmaz; böylece web uygulamaları aşırı karmaşık hale gelmez ve yarış koşullarına açık olmaz
- Bu yazının yazarı, yeni kitabı "Cloudflare for Speed and Security"de yalnızca web uygulamalarını hızlandırmakla kalmayıp, aynı zamanda minimum kaynakla çok sayıda eşzamanlı kullanıcıyı kaldırabilen çeşitli önbellekleme stratejilerini anlatmaya geniş yer ayırıyor
Bir soyutlama olarak veritabanı
- Gecikme, dağıtık SQLite'ın çözmeye çalıştığı tek sorun değildi. Bir diğeri operasyonel karmaşıklıktı
- Ağla bağlı sunucu kümelerini yönetmek zordur ve çoğu zaman kesintilere ve gelir kaybına yol açar. 2017'de GitLab'ın yaşadığı gibi felaketlerden kaçınmak için sürekli yönetim ve güçlü bir güvenlik kültürü gerektiren veritabanı yönetiminden bahsetmiyorum bile
- Bu yüzden fikir, veritabanını uygulamayla birlikte paketleyip her şeyi tek bir sunucuya yerleştirmektir
- Tek geliştirici olduğunda kulağa hoş gelebilir, ancak büyük organizasyonlarda veritabanı sunucularının bakımına adanmış kişi veya ekipler zaten vardır
- Gömülü kütüphaneler yerine soket üzerinden erişilen veritabanlarının iyi bir soyutlama olmasının nedeni tam da budur: bu aslında teknik değil, organizasyonel bir soyutlamadır. Geliştirme sırasında bu, geliştiricinin makinesinde çalışan basit bir container olabilir; üretimde ise uygulamayla aynı sunucuda çalışan bir container'dan ağ üzerinden erişilen dağıtık bir kümeye kadar her şey olabilir. Geliştiricinin yapması gereken tek şey
DATABASE_URLadlı tek yapılandırma değişkenini değiştirmektir; gerisini operasyon ekibi halleder - Buna karşılık geleneksel Unix dosya sistemi, dağıtık hesaplama için uygun olmayan bir soyutlamaydı. Elbette NFS (Network File System) var, ancak Unix dosya sistemi tek makineden erişim için tasarlandığı için performansı oldukça zayıf kalır. Buna karşılık S3 protokolü, büyük miktarda yapılandırılmamış veriyi verimli, ölçeklenebilir ve güvenilir biçimde depolamak için oldukça iyi bir soyutlamadır. Geliştirici S3 uyumlu bir SDK kullanır ve gerisini düşünmez; performans, dayanıklılık, güvenilirlik ve diğer her şeyi operasyon ekibi ya da bulut sağlayıcısı yönetir
Sonuç
- SQLite gerçekten olağanüstü bir veritabanı, ancak ekiplerin çoğu için SQLite'tan kaçınıp onun yerine PostgreSQL seçmek daha iyi olur
- PostgreSQL'i en iyi backend veritabanı yapmak için sayısız mühendislik saati harcandı. SQLite'ı seçtiğinizde, PostgreSQL'in uzun süredir sahip olduğu şeyleri kaçınılmaz olarak kırılgan ve hataya açık biçimde yeniden icat etmeniz gerekir
- Şu anda SQLite'ı bir backend veritabanına dönüştürme yönündeki hareket, bana göre edge computing altyapısı satan ve hesaplamanın veri deposu olmadan hiçbir şey olmadığını fark eden şirketlerin bir pazarlama darbesinden ibaret. Onlara yönelik (istenmemiş) tavsiye, CDN inşa edip uygulamaya karmaşıklık dayatmak yerine HTTP önbelleklemeye yatırım yapmalarıdır. Bu çok daha iyi sonuçlar verir
- Oluşturduğu karmaşıklık nedeniyle backend uygulamalarının %99,9'u edge'e taşınmaktan hiçbir fayda görmeyecektir; bunun yerine dünya genelinde 100 ms'nin altında harika bir deneyim sunmak için iyi önbellekleme stratejileri dağıtmaya odaklanmalıdır
- Sunucu tarafı uygulamalar için SQLite deneyinin bittiği yer de tam olarak burasıdır. Kazanan PostgreSQL'dir
-
"Amatörler taktikleri tartışır, profesyoneller lojistiği tartışır. (Amateurs discuss tactics. Professionals discuss logistics.)"
Başarı için, sahadaki taktik kararların kendisinden çok bu kararları mümkün kılan destekleyici sistemler ve süreçler, yani lojistik ve yönetim daha önemlidir
GN⁺ görüşü
- Yazarın iddia ettiği gibi, çoğu backend uygulamasında SQLite kullanmak pratik bir fayda sağlamaktan çok yalnızca karmaşıklığı artırıyor gibi görünüyor. PostgreSQL gibi zaten kanıtlanmış ve olgun bir veritabanını kullanmak daha iyi bir seçim olacaktır
- Edge computing altyapı sağlayıcılarının SQLite'ı öne çıkarması, teknik üstünlükten çok pazarlama stratejisinin bir parçası gibi görünüyor. Bunların HTTP önbellekleme ve CDN'e daha fazla yatırım yapması uygulama geliştiricileri için daha faydalı olacaktır
- Backend uygulamalarının çoğu, uygun bir önbellekleme stratejisiyle zaten yeterince hızlı ve ölçeklenebilir hizmet sunabilir. Edge computing gerçekten gerekli değilse aşırı karmaşıklıktan kaçınmak daha iyidir
- Dağıtık SQLite belirli kullanım senaryolarında faydalı olabilir, ancak genel amaçlı bir çözüm olarak kullanılabilmesi için hâlâ sınırlamaları var gibi görünüyor. Geliştirme kolaylığı, performans ve tutarlılığı aynı anda sağlamak kolay olmayacaktır
- Sonuçta en önemli şey, uygulamanın gereksinimlerine ve ekibin yetkinliğine uygun teknolojiyi seçmektir. Trendlere kapılmak yerine artı ve eksileri dikkatle analiz edip temkinli karar vermek gerekir
- Yazar, SQLite'ın backend veritabanı olarak kullanılabilmesi için hâlâ birçok eksiği olduğunu vurgulasa da, SQLite'ın güçlü yanlarından yararlanılabilecek başka kullanım senaryoları olabilir; bu yüzden onu tamamen dışlamak gerekmiyor gibi görünüyor
3 yorum
Postgres ile SQLite arasında hangisinin en iyisi olduğundan ziyade,
benim durumuma ikisinden hangisinin daha uygun olduğunu düşünmek daha iyi olmaz mı?
Çünkü en iyi seçenek duruma göre değişir.
Hacker News görüşleri