SQLite: Dosya sisteminden %35 daha hızlı

• SQLite, küçük Blob'ları (ör. küçük resim görselleri) tek tek dosyalarda fread() veya fwrite() ile okuyup yazmaktan %35 daha hızlı okuyup yazabiliyor
• Ayrıca 10KB Blob'ları depolayan tek bir SQLite veritabanı, Blob'ları ayrı dosyalar olarak depolamaya kıyasla yaklaşık %20 daha az disk alanı kullanıyor
• Performans farkı, SQLite veritabanında çalışırken open() ve close() sistem çağrılarının yalnızca bir kez yapılmasına karşın, ayrı dosyalardaki Blob'larda her Blob için birer kez open() ve close() çağrılması nedeniyle ortaya çıkıyor gibi görünüyor. open() ve close() ek yükü, veritabanı kullanmanın ek yükünden daha büyük görünüyor
• Boyut küçülmesi, ayrı dosyaların dosya sistemi blok boyutunun bir sonraki katına kadar doldurulmasına karşın, Blob'ların SQLite veritabanına daha sıkı paketlenmesinden kaynaklanıyor

Dikkat edilmesi gerekenler

• %35 rakamı yaklaşık bir değerdir. Gerçek zamanlamalar donanım, işletim sistemi ve deney ayrıntılarına göre değişir; ayrıca gerçek donanımda rastgele performans dalgalanmaları vardır
• %35 rakamı, yazarın kolayca erişebildiği tüm sistemlerde testi çalıştırmasının sonucudur. Bazı inceleyiciler kendi sistemlerinde SQLite'ın doğrudan G/Ç'den daha yüksek gecikmeye sahip olduğunu bildirmiştir. Bu fark henüz anlaşılmış değildir
• SQLite'ın, soğuk dosya sistemi önbelleği ile deneyler çalıştırıldığında doğrudan G/Ç kadar iyi performans göstermediği görülmüştür
• Bu belge, ilişkisel veritabanlarının doğrudan dosya sistemi G/Ç'sinden daha yavaş olması gerektiğine dair yaygın varsayımı çürütmektedir
• 2022 tarihli bir araştırmaya göre, gerçek iş yüklerinde SQLite'ın Linux'taki Btrfs ve Ext4'e kıyasla yaklaşık 2 kat daha hızlı olduğu görülmüştür

Ölçüm yöntemi

• G/Ç performansı, SQLite kaynak ağacındaki kvtest.c programı kullanılarak ölçülmüştür
• Bu test programını derlemek için, SQLite birleşik kaynak dosyaları sqlite3.c ve sqlite3.h ile birlikte kvtest.c kaynak dosyasını bir dizinde toplayın, ardından Unix'te aşağıdakine benzer bir komut çalıştırın
• Ortaya çıkan kvtest programı, her biri 8.000 bayt ile 12.000 bayt arasında olan 100.000 rastgele sıkıştırılmamış Blob'dan oluşan bir test veritabanı oluşturmak için kullanılır
• Tüm Blob'ların bir kopyasını dizindeki ayrı dosyalar olarak oluşturmak için, export komutunu --tree komut satırı seçeneğiyle çalıştırabilirsiniz
• Veritabanından Blob okuma ile ayrı dosyalardan Blob okuma performansını ölçmek için aşağıdaki komutlar kullanılır
• --blob-api seçeneği kullanıldığında, SQLite SQL ifadeleri çalıştırmak yerine Blob içeriğini yüklemek için sqlite3_blob_read() işlevini kullanabilir; bu da okuma testlerinde biraz daha hızlı çalışmasını sağlar

Okuma performansı ölçümü

• Windows 10'da, SQLite veritabanından içerik okumak, içeriği doğrudan diskten okumaktan yaklaşık 5 kat daha hızlıdır
• Android'de SQLite, diskten okumaya göre yaklaşık %35 daha hızlıdır
• Bellek eşlemeli veritabanında sqlite3_blob_read() ile okuma yapıldığında, Mac ve Android'de diskten ayrı dosya okumaya göre 2 kat, Windows'ta ise 10 kat daha hızlıdır

Yazma performansı ölçümü

• Tüm sistemlerde hem doğrudan G/Ç hem de SQLite için yazma performansı, okumaya göre 5 ila 15 kat daha yavaştır
• Yazma testlerinde antivirüs yazılımı SQLite yazmalarını neredeyse hiç etkilemezken, doğrudan diske yazma yaklaşık 10 kat yavaşlamaktadır
• Bunun nedeni muhtemelen SQLite'ın yalnızca tek bir veritabanı dosyasını değiştirmesi, doğrudan diske yazmanın ise antivirüs tarafından taranması gereken binlerce ayrı dosyayı değiştirmesidir

Genel sonuçlar

• SQLite, hem okumada hem yazmada ayrı disk dosyalarında saklanan Blob'larla rekabetçi olup çoğu zaman daha hızlıdır
• SQLite, antivirüs koruması açıkken Windows'ta doğrudan diske yazmadan çok daha hızlıdır
• Okuma, tüm sistemlerde ve hem SQLite hem de doğrudan disk G/Ç için yazmadan yaklaşık 10 kat daha hızlıdır
• G/Ç performansı işletim sistemi ve donanıma göre büyük ölçüde değişir. Sonuç çıkarmadan önce kendi ölçümlerinizi yapmanız gerekir
• Bazı diğer SQL veritabanı motorları, geliştiricilere Blob'ları ayrı dosyalarda saklayıp veritabanında yalnızca dosya adını tutmalarını önerir. Bu durumda, Blob'un tamamını veritabanında saklamak SQLite'ta çok daha hızlı okuma ve yazma performansı sağlar

GN⁺ görüşü

• SQLite'ın performansının ayrı dosyaları okuyup yazmaktan daha iyi olması oldukça ilginç. Bu, veritabanı kullanan uygulamaların performansını artırmaya yardımcı olabilir
• Ancak bu benchmark sonuçları her duruma genel olarak uygulanamaz. Verinin özellikleri, erişim düzenleri ve donanım yapılandırmasına göre değişebilir. Kritik uygulamalarda gerçek iş yükleriyle benchmark yapmak önemlidir
• Ayrıca SQLite'ın antivirüs taramasından kaçınabilmesi gibi bir avantajı vardır. Bu, çok sayıda küçük dosyayla çalışan uygulamalarda özellikle yararlı olabilir
• SQLite'ın dezavantajı, tüm verilerin tek bir dosyada tutulması nedeniyle veritabanı dosyası bozulursa tüm verilerin kaybedilebilmesidir. Bu yüzden veritabanı dosyasını düzenli olarak yedeklemek önemlidir

[iolothebard]

Veritabanına dosya özniteliklerine (dosya adı, boyut, erişim izinleri, …) erişimi de dahil ediyorsanız,
yoksa dosya G/Ç ile değil blok G/Ç ile karşılaştırmak gerekmez mi diye düşünüyorum…
Her halükarda SQLite gerçekten hızlı.

[GN⁺]

Hacker News görüşü

• Dosya sistemi öznitelikleri veya metadata olmadığı için ek öznitelik yazma ya da güncelleme gerekmez; fiziksel dosya ya da pipe/sembolik bağlantı kontrolü, izin denetimi, blok boyutu hizalama uyumsuzluğu gibi durumlar da olmadığından yalnızca tek bir open komutu gerekir

  • Özelliklerden vazgeçip genel amaçlı tasarımı yok saydığınızda anlaşılabilir bir durum
  • SQLite için bir FUSE eşlemesi kullanıp dizini mount ederek erişirseniz performans benzer olabilir ya da daha yavaş olabilir
  • Öznitelikleri devre dışı bırakıp optimize edilmiş blok boyutuyla özel bir dosya sistemi oluşturursanız benzer performans elde edebilirsiniz
  • rsync gibi shell komutları kullanarak dosyaları gezip düzenleyebilmenin getirdiği bir sadelik var
  • SQLite, paketlenmiş statik varlıklar veya appliance tipi uygulamalar için uygundur

• Windows 10'da 4 kat hız artışı, Windows dosya sistemi çağrılarının ne kadar yavaş olduğunu vurguluyor

• Dijital piyanodan çıkan tüm notaları gerçek zamanlı kaydetme fikri var

  • SQLite kullanarak her satırı piyanonun bir MIDI olayı olacak şekilde tek bir tabloda saklıyor
  • Performans iyi ve sonrasında analiz edilebiliyor

• Veritabanı laboratuvarında bunun OS araştırmalarıyla karşılaştırılması ilginç bulunmuş

  • İlişkisel veritabanları, küçük tekil kayıtlar ve tutarlılık için optimize edilir
  • Satır boyutu büyüdükçe performans keskin biçimde düşer

• WAL2 modunda sqlite DB'ye ekleme yapmayı düşünülüyor

  • Yazma performansı cezası neredeyse yok ve okuma/analiz tarafında büyük avantaj sağlıyor

• SQLite veritabanında open() ve close() sistem çağrıları yalnızca bir kez yapılıyor

  • Bu, tek tek dosyalarda blob kullanmaya kıyasla daha az ek yük oluşturuyor

• SQLite blob alanlarını kullanarak dosya saklamak önerilmiyor

  • Blob azami boyutu 2GB
  • Nesneleri byte olarak serileştirmek/seri açmak gerekiyor
  • Diğer sistemler/hizmetlerle etkileşim kurmak için dosya gerekiyor
  • SQLite'ın paralel istekleri işleyebilen ayarları var, ancak çekişen istekler nedeniyle veritabanı kilitleniyor

• Dosya sistemi üzerinde kurulu bir şeyin dosya sisteminden daha hızlı olması, dosya sistemini optimize edilmemiş bir şekilde kullandığınızda yavaş olduğu anlamına gelir

• SQLite veritabanında çok sayıda satırı silmek, dosya silmekten daha yavaş

• Tüm dosya sistemi/sürücü erişimleri OS tarafından yönetilir

  • Veritabanı dosyası diskte cluster'lar halinde saklanır
  • Veritabanı yönetim sistemi, belirli bir alanı ve problemleri çözmek için kullanışlı olacak şekilde oluşturulmuştur

[halfenif]

20 yıl önce dosyaları blob olarak Oracle DB'ye koyan mimariyi gayet iyi kullanıyorduk.. ama her seferinde insanlara bunun avantajlarını açıklamak zorunda kalıyordum. Elbette her seferinde başarılı olmuyordu.

[narusas]

20 yıl önce olsaydı, Oracle SAN DISK fiyatları pek de ucuz olmazdı..