Sunucu tarafı SQLite’a tümüyle odaklanıyorum

xguru · 2022-05-16T10:31:14+09:00

Gömülü key-value DB olan BoltDB’nin yaratıcısı Ben Johnson, artık FlyIO’da Litestream geliştiriyor Full-stack uygulamaların sağduyulu yapısı n-Tier: uygulama sunucusu + DB sunucusu → Bu mimaride SQLite yalnızca birim testleri için kullanılırdı, ancak artık veri ve kalıcılık katmanı olarak fazlasıyla kullanılabilir Litestream, replikasyon yoluyla SQLite’ı full-stack uygulamalarda kullanılabilir hale getiren açık kaynaklı bir araç Uygulama veritabanlarının kısa tarihi 50 yıl uzun bir süre değil, ama yazılımın veriyi yönetme biçimi çok büyük değişim geçirdi → 70’lerde ilişkisel veritabanını tanımlayan “Codd’un kuralları” vardı → Tüm veriler tablolardaydı; CRUD, şema, SQL dili vb. → 80’ler ve 90’larda Oracle/DB2/Postgres/MySQL gibi SQL veritabanları patlama yaşadı → 2000’lerde XML veritabanları iyi değildi, aynı dönemde harika kolonlu DB’ler ortaya çıktı → 2010’larda büyük ölçekli açık kaynak dağıtık DB projeleri çıktı; artık herkes küme kurup terabayt ölçeğinde veriyi sorgulayabiliyor Veritabanları evrilirken, DB’yi uygulamaya bağlama stratejileri de gelişti → Codd’dan sonra katmanlara ayrıldı → İlk olarak veritabanı katmanı vardı → Sonra memcached ve Redis önbellek katmanı geldi → Arka plan iş katmanı (Sidekiq), yönlendirme katmanı (PgBouncer), dağıtım katmanı vb. → Pek çok eğitim buna 3-Tier gibi yaklaşsa da, kaç katman ekleneceği belli olmadığından buna n-Tier deniyor 50 yıl boyunca CPU, bellek ve disklerin yüzlerce kat hızlanıp ucuzladığını da gördük → 2010’lardaki veritabanı yeniliğini gerçekten tanımlayan kelime “big data” idi → Ama donanım gelişimi nedeniyle 2020’ye geldiğimizde bu kavramı sürdürmek bile zorlaştı → 1996’da 1GB’lık bir DB’yi yönetmek gerçekten büyük bir işti, ama 2022’de bunu bir dizüstünde ya da t3.micro üzerinde çalıştırmak bile yeterli Yeni DB mimarilerini düşünürken, ölçeklenebilirlik sınırları yüzünden adeta hipnotize oluyoruz → Petabayt, en azından terabayt ölçeğinde veri işleyemiyorsa sanki konuşmaya bile dahil olamıyor → Oysa çoğu uygulama başarılı olsa bile terabaytlarca veriye ulaşmıyor → Yani çivi çakmak için kırıcı delici kullanıyoruz SQLite’ın tatlı çıkışı Bu eğilimi çok iyi yansıtan bir veritabanı var Dünyanın en ünlü SQL DB’lerinden biri; ABD Kongre Kütüphanesi’nin resmi arşiv formatı; güvenilirliği, ölçülmesi zor büyüklükteki test paketi ve mükemmel performansıyla tanınıyor Bu noktada adını söylemeye gerek yok ama… arkada el kaldıranlar için… bu tabii ki SQLite SQLite gömülü bir DB’dir. Tipik mimari katmanlarda yer almaz; uygulama sunucusu sürecinize bağlanan sıradan bir kütüphanedir → Başka bir sunucuya bağımlı olmadan tek başına çalışan bir “tek süreçli uygulama” Ben veritabanı yapan biri olduğum için bu tür uygulamalarla ilgileniyorum Go ekosisteminde tanınan gömülü key/value DB olan BoltDB’yi ben yaptım BoltDB kararlıydı ve süreç içi bir DB’den bekleneceği gibi nitro takılmış oyuncak araba performansı veriyordu Ama BoltDB’nin kısıtları var → Şema Go kodunda tanımlandığı için DB migrasyonu zor. Araçları kendiniz yapmanız gerekiyor. Hatta bir REPL bile yok Dikkatli olursanız bu tür DB’lerle muazzam performans elde edebilirsiniz Ama genel amaçlı kullanım için böyle bir DB’yi işletmek istemezsiniz BoltDB’yi daha fazla uygulamada kullanılabilir hale getirmek için ne yapılması gerektiğini düşündüm ve vardığım sonuç şu oldu: “SQLite tam da bunun için yapılmış” SQLite’ın da elbette kısıtları var. En büyüğü, tek süreçli uygulamaların bir SPOF’a (Single Point of Failure) sahip olması: sunucuyu kaybederseniz veritabanını da kaybedersiniz. Bu SQLite’ın kusuru değil, tasarımının doğal sonucu Litestream sahneye çıkıyor İnsanların SQLite’ı varsayılan olarak kullanmamasının iki büyük nedeni var → Birincisi, depolama hatalarına karşı dayanıklılık (resilience) → İkincisi, büyük ölçekte eşzamanlılık (concurrency) Litestream’ın bu iki problem hakkında söyleyecek sözü var Litestream, SQLite’ın WAL (Write Ahead Log) modu günlüklemesini kontrol ederek çalışır WAL modunda yazma işlemleri, SQLite’ın ana DB dosyasına değil ayrı bir log dosyasına eklenir Okuyucular, sorguları karşılamak için hem WAL dosyasına hem ana DB’ye bakar Normalde SQLite, WAL’den ana DB’ye sayfaları otomatik checkpoint ile taşır Litestream bu araya girer; otomatik checkpoint’i engelleyen sonsuz bir okuma transaction’ı açar, WAL güncellemelerini doğrudan yakalayıp çoğaltır ve checkpoint’i kendisi tetikler Litestream hakkında anlaşılması gereken en önemli şey şu: bu, sadece SQLite’tır. Uygulama standart SQLite kullanır; ek bağımlılık eklenmez, sorgular analiz edilmez, proxy gibi davranılmaz. Sadece SQLite’ın kendi journaling ve concurrency özelliklerinden yararlanılır. Çoğu durumda kodunuz Litestream’ın varlığının farkına bile varmayabilir Karmaşık görünüyor olabilir ama aslında inanılmaz derecede basit. Kullandığınızda gerçekten “just works” olduğunu görüyorsunuz $ litestream replicate fruits.db s3://my-bukkit:9000/fruits.db $ litestream restore -o fruits-replica.db s3://my-bukkit:9000/fruits.db İnsanlar genelde bunu SQLite DB’yi replike edip S3’e kaydetmek için kullanıyor Operasyonel olarak büyük avantaj sağlıyor. DB’niz dayanıklı hale geliyor ve kolayca taşınabiliyor ya da migrate edilebiliyor Ama Litestream ile daha fazlası da yapılabilir Sonraki sürümde SQLite DB’ler arasında gerçek zamanlı replikasyon mümkün olacak; böylece dağıtık read replica ve write-leader DB kurmak mümkün hale gelecek → Read replica’lar write’ları yakalayıp leader’a yönlendirebilir → Pek çok uygulama read-heavy olduğu için bu kurulum, uygulamaya küresel ölçekte ölçeklenebilen bir DB sağlayabilir Bu seçeneği, yani SQLite’ı uygulama DB’si olarak kullanmayı daha ciddiye almalısınız İlk dönem IT işlerimden biri, 2000’lerin başında Oracle DBA olmaktı Oracle’ı öğrenmek için sayısız kitap ve belge okudum Yönetici kılavuzu neredeyse bin sayfaydı ve bu, yüzlerce belgeden sadece biriydi Sorgu optimize etmek ya da yazma performansını artırmak için ne yapmanız gerektiğini öğrenmek o zaman gerçekten büyük fark yaratıyordu Saniyede onlarca megabayt okuyan disklerde daha iyi indeks kullanımı, 5 dakikalık sorguyu 30 saniyeye indirebiliyordu Ama DB optimizasyonu, sıradan uygulamalar için giderek daha az önemli hale geliyor 1GB’lık bir DB’niz varsa, NVMe disk tümünü 1 saniyeden kısa sürede belleğe alabilir SQL sorgu optimizasyonunu sevsem de, birçok uygulama geliştirici için bu artık ölmekte olan bir beceri Düzgün ayarlanmamış sorgular bile birçok veritabanında 1 saniyeden kısa sürede çalışabiliyor Modern Postgres bir mucize. Yıllarca o kodu okuyarak çok şey öğrendim Sorgu optimizer’ı, satır düzeyi güvenlik politikaları, 6 tür indeks vb. Bu özelliklere ihtiyacınız varsa elbette gerekir, ama çoğu kişinin yok Ve eğer bu Postgres özelliklerini istemiyorsanız, buna rağmen sorumluluk size kalıyor Birden çok hesap kullanmasanız bile host tabanlı kimlik doğrulamayı yapılandırmanız ve firewall açmanız gerekiyor Daha fazla özellik, daha fazla dokümantasyon demek; dolayısıyla gerçekte işlettiğiniz yazılımı anlamak da zorlaşıyor Postgre14 dokümantasyonu neredeyse 3 bin sayfa SQLite, Postgres özelliklerinin bir alt kümesine sahip. Ama benim genelde istediğim şeylerin %99,9’unu sağlıyor Harika SQL desteği, window fonksiyonları, CTE, full-text search, JSON desteği vb. Bir özellik eksikse bile veri uygulamamın yanında olduğu için çekip işlemek çok az ek yük getiriyor Öte yandan gerçekten çözmemiz gereken karmaşık problemler, çekirdek veritabanı özellikleriyle çözülmüyor Bunun yerine sadece latency ve developer experience’ı optimize etmek istiyorum Dolayısıyla SQLite’ı ciddi biçimde düşünmeniz için bir neden de, işletiminin gerçekten çok basit olması Veritabanı katmanı tasarlamak yerine doğrudan uygulama kodu yazmaya zaman ayırmak mümkün Ama başka bir sorun daha var Işık fazla yavaş: The Light is Too Damn Slow Teorik sınırlara çarpmaya başlıyoruz. Boşlukta ışık 1 milisaniyede 186 mil gider; bu Philadelphia ile New York arası gidiş-dönüş mesafesine yakın Buna ağ anahtarları, firewall ve uygulama protokol katmanlarını ekleyince daha da yavaşlıyor Tek bir AWS region içinde bile Postgres sorgusunun latency ek yükü 1 milisaniyeye kadar çıkabiliyor Bu, Postgres’in yavaş olduğu anlamına gelmiyor; sadece veri taşıma hızının sınırına geliyoruz Modern uygulamalar bir HTTP isteğini işlerken, birkaç veritabanı sorgusu ve iş mantığı ya da render işleminden önce zaten 10ms harcıyor Uygulama latency’sinde sihirli bir sayı var: 100ms altındaki yanıtlar neredeyse anlık hissediliyor Hızlı tepki veren uygulamalar mutlu kullanıcılar yaratır 100ms çokmuş gibi görünür ama farkına varmadan kolayca tüketilir 100ms eşiği o kadar önemli ki insanlar latency’yi azaltmak için sayfaları önceden render ediyor ve CDN’e koyuyor Veriyi uygulamaya yaklaştırmak istiyoruz. Ne kadar? Gerçekten çok yakına SQLite yalnızca uygulamanızla aynı makinede bulunmaz; doğrudan uygulama sürecinizin içindedir Veriyi uygulamanın yanına koyarsanız sorgu başına latency’nin 10~20 mikrosaniyeye (μ) düştüğünü görebilirsiniz Yani aynı region içindeki bir Postgres sorgusundan 50~100x daha hızlı Ama dahası da var. Sorgu başına gecikmeyi fiilen ortadan kaldırdık. Uygulamamız artık hem daha hızlı hem daha basit Büyük sorguları daha küçük ve yönetilebilir parçalara bölebilir, yeni özellikler geliştirmek için N+1 sorgu desenlerini kullanmaya daha fazla zaman ayırabiliriz Latency’yi en aza indirmek yalnızca production için değil. Klasik istemci/sunucu DB ile entegrasyon testi yapmak yerelde kolayca dakikalara uzayabiliyor ve CI’ya ittiğinizde bu acı devam ediyor Kod değişikliğinden test tamamlanmasına kadar olan geri bildirim döngüsünü kısaltmak zaman kazandırır ve geliştirme sırasında odağı korumanıza yardımcı olur SQLite ile tek satırlık bir değişiklik, bellekte çalıştırılarak entegrasyon testlerinin saniyeler içinde tamamlanmasını sağlayabilir Küçük, hızlı, güvenilir, küresel olarak dağıtık: Bunlardan 4’ünü seçin Litestream dağıtık, replike ve en önemlisi anlaması kolay Cidden, “bir deneyin” — bilmeniz gereken çok az şey var Benim iddiam şu: SQLite için sağlam ve kullanımı kolay bir replikasyon kurarsanız, yalnızca SQLite üzerinde çalışan full-stack uygulamalar cazip hale gelir Eski “Rails ile Blog yapımı” eğitimlerinin yazıldığı dönemde bu seçenek göz ardı edilmişti; ama bugünün SQLite’ı çoğu uygulamanın yazma yükünü kaldırabiliyor ve kopyalar üzerinden çok sayıda instance’a okuma yükü dağıtabiliyor Litestream’ın da kısıtları var Tek düğümlü uygulamalar için tasarlandığından serverless platformlarda veya rolling deployment’larda iyi çalışmıyor Tüm değişiklikler sırayla geri yüklenmek zorunda olduğundan DB restore işlemi birkaç dakika sürebiliyor Gerçek zamanlı replikasyon üzerinde çalışıyoruz ama ayrı süreç modeli, replikasyon garantileri üzerinde ayrıntılı kontrol açısından kısıtlar getiriyor Daha iyisini yapabiliriz Son 1 yılda yaptığım şey, Litestream’ın çekirdeğini netleştirmek ve doğruluğa odaklanmak oldu Şu an geldiğimiz noktadan memnunum Basit bir streaming backup aracı olarak başladı ama giderek sağlam ve dağıtık bir veritabanına evriliyor Fly.io’daki işim bunu daha hızlı ve daha pürüzsüz hale getirmek Fly.io’dan bağımsız olarak Litestream’a daha fazla iyileştirme gelecek Litestream yeni yuvasını Fly.io’da buldu ama açık kaynak bir proje olmaya devam edecek Önümüzdeki birkaç yıldaki planım, uygulama nerede çalışırsa çalışsın bunu daha kullanışlı hale getirmek ve SQLite modelinin ne kadar ileri gidebileceğini görmek

(fly.io)

32 puan yazan xguru 2022-05-16 | 6 yorum | WhatsApp'ta paylaş

Gömülü key-value DB olan BoltDB’nin yaratıcısı Ben Johnson, artık FlyIO’da Litestream geliştiriyor
Full-stack uygulamaların sağduyulu yapısı n-Tier: uygulama sunucusu + DB sunucusu
→ Bu mimaride SQLite yalnızca birim testleri için kullanılırdı, ancak artık veri ve kalıcılık katmanı olarak fazlasıyla kullanılabilir
Litestream, replikasyon yoluyla SQLite’ı full-stack uygulamalarda kullanılabilir hale getiren açık kaynaklı bir araç

Uygulama veritabanlarının kısa tarihi

50 yıl uzun bir süre değil, ama yazılımın veriyi yönetme biçimi çok büyük değişim geçirdi
→ 70’lerde ilişkisel veritabanını tanımlayan “Codd’un kuralları” vardı
→ Tüm veriler tablolardaydı; CRUD, şema, SQL dili vb.
→ 80’ler ve 90’larda Oracle/DB2/Postgres/MySQL gibi SQL veritabanları patlama yaşadı
→ 2000’lerde XML veritabanları iyi değildi, aynı dönemde harika kolonlu DB’ler ortaya çıktı
→ 2010’larda büyük ölçekli açık kaynak dağıtık DB projeleri çıktı; artık herkes küme kurup terabayt ölçeğinde veriyi sorgulayabiliyor
Veritabanları evrilirken, DB’yi uygulamaya bağlama stratejileri de gelişti
→ Codd’dan sonra katmanlara ayrıldı
→ İlk olarak veritabanı katmanı vardı
→ Sonra memcached ve Redis önbellek katmanı geldi
→ Arka plan iş katmanı (Sidekiq), yönlendirme katmanı (PgBouncer), dağıtım katmanı vb.
→ Pek çok eğitim buna 3-Tier gibi yaklaşsa da, kaç katman ekleneceği belli olmadığından buna n-Tier deniyor
50 yıl boyunca CPU, bellek ve disklerin yüzlerce kat hızlanıp ucuzladığını da gördük
→ 2010’lardaki veritabanı yeniliğini gerçekten tanımlayan kelime “big data” idi
→ Ama donanım gelişimi nedeniyle 2020’ye geldiğimizde bu kavramı sürdürmek bile zorlaştı
→ 1996’da 1GB’lık bir DB’yi yönetmek gerçekten büyük bir işti, ama 2022’de bunu bir dizüstünde ya da t3.micro üzerinde çalıştırmak bile yeterli
Yeni DB mimarilerini düşünürken, ölçeklenebilirlik sınırları yüzünden adeta hipnotize oluyoruz
→ Petabayt, en azından terabayt ölçeğinde veri işleyemiyorsa sanki konuşmaya bile dahil olamıyor
→ Oysa çoğu uygulama başarılı olsa bile terabaytlarca veriye ulaşmıyor
→ Yani çivi çakmak için kırıcı delici kullanıyoruz

SQLite’ın tatlı çıkışı

Bu eğilimi çok iyi yansıtan bir veritabanı var
Dünyanın en ünlü SQL DB’lerinden biri; ABD Kongre Kütüphanesi’nin resmi arşiv formatı; güvenilirliği, ölçülmesi zor büyüklükteki test paketi ve mükemmel performansıyla tanınıyor
Bu noktada adını söylemeye gerek yok ama… arkada el kaldıranlar için… bu tabii ki SQLite

SQLite gömülü bir DB’dir. Tipik mimari katmanlarda yer almaz; uygulama sunucusu sürecinize bağlanan sıradan bir kütüphanedir
→ Başka bir sunucuya bağımlı olmadan tek başına çalışan bir “tek süreçli uygulama”

Ben veritabanı yapan biri olduğum için bu tür uygulamalarla ilgileniyorum
Go ekosisteminde tanınan gömülü key/value DB olan BoltDB’yi ben yaptım
BoltDB kararlıydı ve süreç içi bir DB’den bekleneceği gibi nitro takılmış oyuncak araba performansı veriyordu
Ama BoltDB’nin kısıtları var
→ Şema Go kodunda tanımlandığı için DB migrasyonu zor. Araçları kendiniz yapmanız gerekiyor. Hatta bir REPL bile yok

Dikkatli olursanız bu tür DB’lerle muazzam performans elde edebilirsiniz
Ama genel amaçlı kullanım için böyle bir DB’yi işletmek istemezsiniz
BoltDB’yi daha fazla uygulamada kullanılabilir hale getirmek için ne yapılması gerektiğini düşündüm ve vardığım sonuç şu oldu: “SQLite tam da bunun için yapılmış”

SQLite’ın da elbette kısıtları var. En büyüğü, tek süreçli uygulamaların bir SPOF’a (Single Point of Failure) sahip olması: sunucuyu kaybederseniz veritabanını da kaybedersiniz. Bu SQLite’ın kusuru değil, tasarımının doğal sonucu

Litestream sahneye çıkıyor

İnsanların SQLite’ı varsayılan olarak kullanmamasının iki büyük nedeni var
→ Birincisi, depolama hatalarına karşı dayanıklılık (resilience)
→ İkincisi, büyük ölçekte eşzamanlılık (concurrency)
Litestream’ın bu iki problem hakkında söyleyecek sözü var

Litestream, SQLite’ın WAL (Write Ahead Log) modu günlüklemesini kontrol ederek çalışır
WAL modunda yazma işlemleri, SQLite’ın ana DB dosyasına değil ayrı bir log dosyasına eklenir
Okuyucular, sorguları karşılamak için hem WAL dosyasına hem ana DB’ye bakar
Reklam
Normalde SQLite, WAL’den ana DB’ye sayfaları otomatik checkpoint ile taşır
Litestream bu araya girer; otomatik checkpoint’i engelleyen sonsuz bir okuma transaction’ı açar, WAL güncellemelerini doğrudan yakalayıp çoğaltır ve checkpoint’i kendisi tetikler

Litestream hakkında anlaşılması gereken en önemli şey şu: bu, sadece SQLite’tır. Uygulama standart SQLite kullanır; ek bağımlılık eklenmez, sorgular analiz edilmez, proxy gibi davranılmaz. Sadece SQLite’ın kendi journaling ve concurrency özelliklerinden yararlanılır. Çoğu durumda kodunuz Litestream’ın varlığının farkına bile varmayabilir

Karmaşık görünüyor olabilir ama aslında inanılmaz derecede basit. Kullandığınızda gerçekten “just works” olduğunu görüyorsunuz
$ litestream replicate fruits.db s3://my-bukkit:9000/fruits.db
$ litestream restore -o fruits-replica.db s3://my-bukkit:9000/fruits.db

İnsanlar genelde bunu SQLite DB’yi replike edip S3’e kaydetmek için kullanıyor
Operasyonel olarak büyük avantaj sağlıyor. DB’niz dayanıklı hale geliyor ve kolayca taşınabiliyor ya da migrate edilebiliyor

Ama Litestream ile daha fazlası da yapılabilir
Sonraki sürümde SQLite DB’ler arasında gerçek zamanlı replikasyon mümkün olacak; böylece dağıtık read replica ve write-leader DB kurmak mümkün hale gelecek
→ Read replica’lar write’ları yakalayıp leader’a yönlendirebilir
→ Pek çok uygulama read-heavy olduğu için bu kurulum, uygulamaya küresel ölçekte ölçeklenebilen bir DB sağlayabilir

Bu seçeneği, yani SQLite’ı uygulama DB’si olarak kullanmayı daha ciddiye almalısınız

İlk dönem IT işlerimden biri, 2000’lerin başında Oracle DBA olmaktı
Oracle’ı öğrenmek için sayısız kitap ve belge okudum
Yönetici kılavuzu neredeyse bin sayfaydı ve bu, yüzlerce belgeden sadece biriydi

Sorgu optimize etmek ya da yazma performansını artırmak için ne yapmanız gerektiğini öğrenmek o zaman gerçekten büyük fark yaratıyordu
Saniyede onlarca megabayt okuyan disklerde daha iyi indeks kullanımı, 5 dakikalık sorguyu 30 saniyeye indirebiliyordu

Ama DB optimizasyonu, sıradan uygulamalar için giderek daha az önemli hale geliyor
1GB’lık bir DB’niz varsa, NVMe disk tümünü 1 saniyeden kısa sürede belleğe alabilir
SQL sorgu optimizasyonunu sevsem de, birçok uygulama geliştirici için bu artık ölmekte olan bir beceri
Düzgün ayarlanmamış sorgular bile birçok veritabanında 1 saniyeden kısa sürede çalışabiliyor

Modern Postgres bir mucize. Yıllarca o kodu okuyarak çok şey öğrendim
Sorgu optimizer’ı, satır düzeyi güvenlik politikaları, 6 tür indeks vb.
Bu özelliklere ihtiyacınız varsa elbette gerekir, ama çoğu kişinin yok

Ve eğer bu Postgres özelliklerini istemiyorsanız, buna rağmen sorumluluk size kalıyor
Birden çok hesap kullanmasanız bile host tabanlı kimlik doğrulamayı yapılandırmanız ve firewall açmanız gerekiyor
Daha fazla özellik, daha fazla dokümantasyon demek; dolayısıyla gerçekte işlettiğiniz yazılımı anlamak da zorlaşıyor
Postgre14 dokümantasyonu neredeyse 3 bin sayfa

SQLite, Postgres özelliklerinin bir alt kümesine sahip. Ama benim genelde istediğim şeylerin %99,9’unu sağlıyor
Harika SQL desteği, window fonksiyonları, CTE, full-text search, JSON desteği vb.
Bir özellik eksikse bile veri uygulamamın yanında olduğu için çekip işlemek çok az ek yük getiriyor

Öte yandan gerçekten çözmemiz gereken karmaşık problemler, çekirdek veritabanı özellikleriyle çözülmüyor
Bunun yerine sadece latency ve developer experience’ı optimize etmek istiyorum

Dolayısıyla SQLite’ı ciddi biçimde düşünmeniz için bir neden de, işletiminin gerçekten çok basit olması
Veritabanı katmanı tasarlamak yerine doğrudan uygulama kodu yazmaya zaman ayırmak mümkün
Ama başka bir sorun daha var

Işık fazla yavaş: The Light is Too Damn Slow

Teorik sınırlara çarpmaya başlıyoruz. Boşlukta ışık 1 milisaniyede 186 mil gider; bu Philadelphia ile New York arası gidiş-dönüş mesafesine yakın
Buna ağ anahtarları, firewall ve uygulama protokol katmanlarını ekleyince daha da yavaşlıyor

Tek bir AWS region içinde bile Postgres sorgusunun latency ek yükü 1 milisaniyeye kadar çıkabiliyor
Bu, Postgres’in yavaş olduğu anlamına gelmiyor; sadece veri taşıma hızının sınırına geliyoruz
Modern uygulamalar bir HTTP isteğini işlerken, birkaç veritabanı sorgusu ve iş mantığı ya da render işleminden önce zaten 10ms harcıyor

Uygulama latency’sinde sihirli bir sayı var: 100ms altındaki yanıtlar neredeyse anlık hissediliyor
Hızlı tepki veren uygulamalar mutlu kullanıcılar yaratır
100ms çokmuş gibi görünür ama farkına varmadan kolayca tüketilir
100ms eşiği o kadar önemli ki insanlar latency’yi azaltmak için sayfaları önceden render ediyor ve CDN’e koyuyor

Veriyi uygulamaya yaklaştırmak istiyoruz. Ne kadar? Gerçekten çok yakına

SQLite yalnızca uygulamanızla aynı makinede bulunmaz; doğrudan uygulama sürecinizin içindedir
Veriyi uygulamanın yanına koyarsanız sorgu başına latency’nin 10~20 mikrosaniyeye (μ) düştüğünü görebilirsiniz
Yani aynı region içindeki bir Postgres sorgusundan 50~100x daha hızlı

Ama dahası da var. Sorgu başına gecikmeyi fiilen ortadan kaldırdık. Uygulamamız artık hem daha hızlı hem daha basit
Büyük sorguları daha küçük ve yönetilebilir parçalara bölebilir, yeni özellikler geliştirmek için N+1 sorgu desenlerini kullanmaya daha fazla zaman ayırabiliriz

Latency’yi en aza indirmek yalnızca production için değil. Klasik istemci/sunucu DB ile entegrasyon testi yapmak yerelde kolayca dakikalara uzayabiliyor ve CI’ya ittiğinizde bu acı devam ediyor
Kod değişikliğinden test tamamlanmasına kadar olan geri bildirim döngüsünü kısaltmak zaman kazandırır ve geliştirme sırasında odağı korumanıza yardımcı olur
SQLite ile tek satırlık bir değişiklik, bellekte çalıştırılarak entegrasyon testlerinin saniyeler içinde tamamlanmasını sağlayabilir

Küçük, hızlı, güvenilir, küresel olarak dağıtık: Bunlardan 4’ünü seçin

Litestream dağıtık, replike ve en önemlisi anlaması kolay
Cidden, “bir deneyin” — bilmeniz gereken çok az şey var

Benim iddiam şu:
- SQLite için sağlam ve kullanımı kolay bir replikasyon kurarsanız, yalnızca SQLite üzerinde çalışan full-stack uygulamalar cazip hale gelir
- Eski “Rails ile Blog yapımı” eğitimlerinin yazıldığı dönemde bu seçenek göz ardı edilmişti; ama bugünün SQLite’ı çoğu uygulamanın yazma yükünü kaldırabiliyor ve kopyalar üzerinden çok sayıda instance’a okuma yükü dağıtabiliyor

Litestream’ın da kısıtları var
- Tek düğümlü uygulamalar için tasarlandığından serverless platformlarda veya rolling deployment’larda iyi çalışmıyor
- Tüm değişiklikler sırayla geri yüklenmek zorunda olduğundan DB restore işlemi birkaç dakika sürebiliyor
- Gerçek zamanlı replikasyon üzerinde çalışıyoruz ama ayrı süreç modeli, replikasyon garantileri üzerinde ayrıntılı kontrol açısından kısıtlar getiriyor

Daha iyisini yapabiliriz
- Son 1 yılda yaptığım şey, Litestream’ın çekirdeğini netleştirmek ve doğruluğa odaklanmak oldu
- Şu an geldiğimiz noktadan memnunum
- Basit bir streaming backup aracı olarak başladı ama giderek sağlam ve dağıtık bir veritabanına evriliyor
- Fly.io’daki işim bunu daha hızlı ve daha pürüzsüz hale getirmek
- Fly.io’dan bağımsız olarak Litestream’a daha fazla iyileştirme gelecek

Litestream yeni yuvasını Fly.io’da buldu ama açık kaynak bir proje olmaya devam edecek
Önümüzdeki birkaç yıldaki planım, uygulama nerede çalışırsa çalışsın bunu daha kullanışlı hale getirmek ve SQLite modelinin ne kadar ileri gidebileceğini görmek

6 yorum

nicewook 2022-09-27

Bir kez daha dikkatlice okuyasım geldi.

johngrib 2022-05-17

Ben de benzer şeyler düşünmüştüm ama bu çok daha kapsamlı ve ciddi. Okurken hayran kaldım. Litestream'i de denemek istiyorum.

japansea 2022-05-16

Uzaktan sorgu gönderilebilse daha da iyi olurdu... TT

mrchypark 2022-05-16

Elixir’in akla geldiği an bu. Gömülü dağıtık veritabanı ve orkestrasyonun dil seviyesinde sunulduğu bir araç, ama bunun gelecek olup olmadığından pek emin değilim.

nicewook 2022-05-16

Keyifle okudum!

xguru 2022-05-16

Kısaca okuyup özetlemeyi düşünmüştüm ama işin içine girince eğlenceli geldi ve biraz uzadı.

Litestream - SQLite akış çoğaltma aracı

SQLite'ı birincil veritabanı olarak kullanan var mı? sorusuyla birlikte bakarsanız iyi olabilir.

Birkaç gün önce duyurulan Cloudflare, Workers için SQL veritabanı D1'i tanıttı ile de bir bağlantısı var gibi görünüyor.

HN yorumlarına da göz atın: https://news.ycombinator.com/item?id=31318708