SQLite, ABD Kongre Kütüphanesi'nin önerdiği saklama formatlarından biri

 (sqlite.org)
1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • SQLite, veri kümeleri için US Library of Congress tarafından önerilen saklama formatları arasında yer alıyor
  • İlgili dayanak, Library of Congress'in SQLite format açıklaması ile veri için önerilen formatlar listesinde görülebilir: https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml#local, https://www.loc.gov/preservation/resources/rfs/data.html
  • 29 Mayıs 2018 itibarıyla veri kümeleri için önerilen saklama formatları, SQLite dışında yalnızca XML, JSON, CSV
  • Library of Congress'in önerdiği saklama formatları, koruma uzmanlarının dijital içeriğin yaşama olasılığını ve sürekli erişilebilirliğini en üst düzeye çıkardığını düşündüğü formatlar
  • Değerlendirme ölçütleri arasında açıklık, benimsenme düzeyi, şeffaflık, kendi kendini belgeleme, dış bağımlılıklar, patent etkisi ve şifreleme gibi teknik koruma mekanizmaları yer alıyor

SQLite ve LoC önerilen saklama formatları

Önerilen saklama formatlarının değerlendirme ölçütleri

  • Önerilen saklama formatları, Library of Congress'in koruma uzmanlarının dijital içeriğin yaşama olasılığını ve sürekli erişilebilirliğini en üst düzeye çıkardığını düşündüğü formatlardır
  • Library of Congress, önerilen saklama formatlarını seçerken aşağıdaki ölçütleri dikkate alır

  • Açıklık

    • Teknik bütünlüğü doğrulamak için eksiksiz belirtim ve araçların bulunması ile bunlara dijital içeriği oluşturan ve sürdüren kişilerin erişebilme düzeyi değerlendirilir
    • Tanınmış bir standart kuruluşunun onayından ziyade eksiksiz dokümantasyon daha önemlidir

  • Benimsenme düzeyi

    • Bilgi kaynaklarının başlıca üreticileri, dağıtıcıları ve kullanıcılarının ilgili formatı hâlihazırda ne ölçüde kullandığı değerlendirilir
    • Bunun içinde ana format, son kullanıcıya sunum formatı ve sistemler arası değişim aracı olarak kullanım da yer alır

  • Şeffaflık

    • Yalnızca metin düzenleyici gibi temel araçlarla dijital gösterimin doğrudan analiz edilip edilemediği, örneğin insan tarafından okunabilir olup olmadığı değerlendirilir

  • Kendi kendini belgeleme

    • Kendi kendini belgeleyen dijital nesneler; temel açıklayıcı meta veriler, teknik meta veriler ve diğer idari meta verileri içerir

  • Dış bağımlılıklar

    • Belirli donanım, işletim sistemi veya yazılıma render etme ya da kullanım açısından ne ölçüde bağımlı olduğu ve bu bağımlılıkların gelecekteki teknoloji ortamlarında ele alınmasının ne kadar karmaşık olduğu değerlendirilir

  • Patent etkisi

    • Patentlerin, koruma kurumlarının bu formattaki içeriği sürdürme yeteneğini ne ölçüde engellediği değerlendirilir

  • Teknik koruma mekanizmaları

    • Güvenilir depolardaki içeriğin korunmasını engelleyen şifreleme gibi mekanizmaların uygulanıp uygulanmadığı değerlendirilir

İlgili okumalar

1 yorum

 
GN⁺ 1 시간 전
Hacker News yorumları

  • SQLite’tan hep ilham alıyorum. Genel olarak seviyorum ama yazma işlemi yoksa oldukça ağır bir tercih de olabiliyor
    Bu yüzden SQLite’ın ötesine geçmiyor ama çok daha hafif ve hızlı, ayrıca zstd sıkıştırılmış dosyalarda da çalışan bir format yaptım. İndeksi çok küçük ve SQLite gibi binary ya da metin saklayabiliyor
    Sıkıştırmayı açma, okuma ve arama işini yapan wasm kısmı, sıkıştırılmamış hâlde 38KB, gzip ile muhtemelen yaklaşık 16KB. SQLite’ın wasm’i ve glue code’u olan 1.2MB ile karşılaştırınca %3 boyutunda, ama arama ve yükleme çok daha hızlı
    Programım sütun tabanlı değil ve spreadsheet yönetimi için uygun değil, ama sözlükler ile görsel ve ses dosyası arşivleri için iyi uyuyor
    jbig2 decoder’ı da 17KB’lık bir wasm modülüne port ettim; böylece sayfa başına 8KB’lık siyah-beyaz taramaları okuyabiliyor ve hâlâ anlaşılır kalıyor
    https://github.com/tnelsond/peakslab
    SQLite çok iyi tasarlanmış, PeakSlab ise çok basit

    • “SQLite’ın wasm’i ve glue code’u 1.2MB” denmiş ama trunk’taki güncel standart küçültülmemiş biçim aslında 1.7MB. Belgeler de JS kodu kadar neredeyse yer kapladığı için WASM ve JS neredeyse yarı yarıya bölünüyor. Gerçi küçültülünce 1.2MB doğru
      Bu arada onun bakımcısı benim
      Şu an trunk’a göre rakamlar sqlite3.wasm 896745, sqlite3.mjs 816270 (belgeler dahil küçültülmemiş), sqlite3.mjs 431388 (belgeler hariç küçültülmemiş), sqlite3.mjs 310975 (küçültülmüş)
    • PeakSlab’ı bilmiyordum ama gerçekten havalı ve yeni görünüyor. Sözlük performansı da çok iyi gibi; sonra tekrar kullanmak için yer imlerine eklemeye değer
    • Bu, eski Berkeley DB ile rekabet eden tarafa daha yakın görünüyor: https://en.wikipedia.org/wiki/Berkeley_DB
      Şimdi baktım, artık BSD lisanslı da değil; her hâlükârda SQLite yüzünden neredeyse yok oldu ama temel disk tabanlı key-value store kullanımında işe yarıyordu
    • SQLite da kendi içinde basit sayılır ve SQL lehçesinin tasarım ilkelerini seviyorum
      Mesela “right join sadece yönü ters bir left join’dir, o yüzden buna gerek yok” gibi
      Tabii her zaman daha basit ya da daha özelleşmiş bir şey yapılabilir. Veritabanı kullanan pek çok uygulama yalnızca SQLite ile gayet iyi çalışır; bazı uygulamalar ise SQLite gibi bir DB yerine sadece metin dosyalarıyla bile idare edebilir
    • Daha standart çözüm muhtemelen cdb olurdu. Ama sıkıştırılmış veriyi desteklemiyor
      https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)

  • SQLite’ı her zaman sevdim ama bazı şirketlerin kullanımını yasakladığını duydum
    Sebebi, uygulama için veritabanı oluşturmayı fazla kolaylaştırması ve bunun sonucunda uygulamanın en kritik bileşenlerinden birinin sıradan bir dosya gibi görünmesi. Bu dosya herhangi bir uzantıya sahip olabilir ve başka bir sunucuya kopyalanabilir. İçinde kişisel tanımlayıcı bilgiler olsa bile
    Şirket içindeki uygulama sayısı kadar bunun çoğaldığını düşününce epey kaotik olabilir
    DevOps ve DBA ekipleri, veritabanlarının herkesin bakınca veritabanı sunucusu olduğunu anlayacağı büyük ve ağır sistemler olmasını tercih ediyor. Bağlanma eylemi de açıkça belli oluyor vs.
    Yine de SQLite’ı hâlâ seviyorum

    • O zaman aynı şirketlerin Excel’i de yasaklayıp yasaklamadığını merak ediyorum. Excel tabloları çoğu zaman hiç beklenmeyen yerlerde gölge veritabanlarına dönüşüyor
    • “Her şey mission-critical bir veritabanına dönüşebilir” sohbetlerinde şu yazı zorunlu okuma olmalı
      https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
    • “Herhangi bir uzantıya sahip olabilen dosya” için magic number okunabilir. Zaten dosya uzantısına güvenmemek gerekir
      “Başka bir sunucuya kopyalanabilir” kısmı spreadsheet’ler için de geçerli
      Veriye erişimin merkezi olmasının tercih edilir olduğunu inkâr etmiyorum ama bu mantık yeterince güçlü görünmüyor
    • SQLite’ın böyle ilginç bir kullanım alanı da var: https://sqlite.org/sqlar.html
    • Bu yüzden bu tür ayar dosyaları AppData’ya, dotfile dizinine ya da MacOS’te ~/Library içindeki karşılık gelen yere konur

  • Eskiden “SQLite oyuncak bir ürün, gerçek veride güvenilmez” diye düşünürdüm ama artık “neredeyse her şey için SQLite kullanalım” tarafına geçtim
    Tek yazar, çok okuyucu desenine uyabiliyorsanız SQLite gerçekten çok iyi. Doğru ayarları kullanırsanız veri kaybetmiyor; o ayarlar da 1 dakikalık aramayla bulunabiliyor
    Bugünlerde uygulamalarımın çoğu sadece Go binary + SQLite + systemd service file birleşimi
    Henüz hiç veri kaybetmedim, performansı da harika ve çoğu uygulama için fazlasıyla yeterli

    • Tek yazar aslında sanıldığı kadar büyük bir sorun değil. Günümüz NVMe sürücüleri inanılmaz; optimize edilmiş WAL ayarıyla saniyede 5 bin yazma rahatça görülüyor. Çoğu uygulamanın hayal bile edemeyeceği bir seviye
      Hatta sıradan bir VPS’te batch writer deseniyle saniyede 180 bin yazma bile yaptım
    • Birden fazla backend node kullanıp kullanmadığını merak ediyorum. Öyleyse farklı node’lardan SQLite dosyasına nasıl eriştiğini de merak ediyorum

  • “Bu yazının yazıldığı sırada (2018-05-29)…” yazıyor, yani neredeyse 8 yıllık bir haber. Yine de bunu şimdiye kadar bilmiyordum, o yüzden şikâyetten çok paylaştığın için teşekkür tarafındayım
    Matematik beynim kısa süreliğine bozuldu ve 6 yıl sandım

    • Şu an 2026, yani 8 yıl önce
    • Okurken deja vu hissettim

  • 2026 için tavsiye edilen depolama formatı: https://www.loc.gov/preservation/resources/rfs/data.html

    • Veriyi saklarken 300-500 yıl sonrasını planlamak ve her türlü yeniliğe, temel teknolojik eskimeye dayanmasını sağlamak gerçekten uzun vadeli düşünmeyi gerektiriyor
      En uzun ömürlü kâğıt tabanlı ortam hangisidir acaba?
    • Tavsiye ölçütleri epey gevşek görünüyor. XLS “tercih edilen” olarak listelenmiş

  • Kamu verisinin korunmasında SQLite en iyi seçeneklerden biri olabilir
    Spesifikasyonu açık, yaygın biçimde benimsenmiş ve gelecekte de okunabilir kalma ihtimali yüksek
    Belirli bir işletim sistemine ya da hizmete bağımlılığı az ve patent riski de düşük
    Uzun vadeli sürdürülebilirlik açısından belirli bir şirkete ya da hizmete bağımlı olmamak çok önemli

    • Arşivciler orijinale yakın formatları da sever. SQLite, CSV ile ifade edilmesi zor olan ilişkisel ilişkileri olduğu gibi korumayı sağlar

  • SQLite’ı seviyorum ve paylaşılmış olmasına sevindim ama başlığın sonunda “(2018)” olması gerekirdi gibi geliyor
    “Bu yazının yazıldığı sırada (2018-05-29), veri kümeleri için önerilen diğer depolama formatları yalnızca XML, JSON ve CSV’dir” deniyor

    • Bilgi olsun, sonrasında listeye epey format eklendi
      Tercih edilen formatlar arasında, veri tam ve ayrıntı ile hassasiyeti koruduğu sürece, native ya da binary formatlara kıyasla platformdan bağımsız karakter tabanlı formatlar öncelikli. İyi geliştirilmiş ve yaygın kabul görmüş fiilî pazar standartları da buna dahil
      Örneğin açık doğrulama araçları olan iyi bilinen şema tabanlı formatlar, TSV, CSV ve fixed-width gibi satır odaklı formatlar, ayrıca .db, .db3, .sqlite ve .sqlite3 gibi platformdan bağımsız açık formatlar var
      Ayrıca belirli meslek gruplarında fiilî standart olan ya da birçok araç tarafından desteklenen kapalı formatlar da dahil. Örneğin Excel .xls/.xlsx ve Shapefile
      Karakter kodlamasında UTF-8, BOM’lu UTF-16, US-ASCII veya ISO 8859-1 ve sonrasında diğer adlandırılmış kodlamalar tercih ediliyor
      Kabul edilen formatlar arasında ise veri için uzman topluluklar ya da devlet kurumlarınca standart olarak onaylanmış, kapalı olmayan, açıkça belgelenmiş formatlar (CDF, HDF vb.) ve kullanılabilir şemaya sahip metin tabanlı veri formatları bulunuyor
      Paketleme ya da aktarım için şifreleme, parola veya başka koruma mekanizmaları olmayan ZIP, RAR, tar ve 7z kabul ediliyor
      https://www.loc.gov/preservation/resources/rfs/data.html

  • Daha dün bile HN üst sıralarında bir SQLite yazısı görmeyeli biraz oldu diye düşünmüştüm
    SQLite’ın basitliğini ve hızını gerçekten seviyorum; hem kişisel projelerde hem iş projelerinde kullandım
    Yine de günlük işte sonunda Excel’e dönüyorum. Excel’i daha çok sevdiğim için değil; bu kadar yaygın olduğu için, daha az teknik paydaşlar ya da yöneticilerle veri kümelerini paylaşmak ve incelemek açısından en az sürtünme yaratan yol bu oluyor

    • Bunun dünya görüşünü aniden yıkacağını sanmıyorum ama bana faydalı olduğu kadar sana da yardımcı olabilir diye Metabase’e bakmanı önerebilirim
      Kendi sunucunda barındırabiliyorsun ve paydaşlara veriyi kolay sindirilebilir biçimde göstermek istiyorsan gerçekten çok basit. Tabii gereğinden fazla derine inersen hayattaki tüm kararlarından pişman olabilirsin ama ben kendimi tutmaya çalışıyorum
      https://www.metabase.com/
    • SQLite’ın çalışmak için metin ayrıştırmaya dayanması beni hep rahatsız etti. Sorguları neden metin olarak yazmak zorundayız da program mantığı olarak ifade etmiyoruz, anlamıyorum
      Bu yüzden ilişkisel veritabanlarını hiç kullanmadım. Çünkü hoşlanmıyorum. Saf yapılandırılmış veriye göre daha performanslı olabileceğini biliyorum ama SQL’den ve SQL fikrinin kendisinden hoşlanmıyorum; onu yazmak, öğrenmek ya da ona dayanan sistemleri kullanmak istemiyorum
      Bana PHP düzeyinde yanlış bir yaklaşım gibi geliyor. Bunu hafifletmenin bir yolu var mı? SQL yüzünden SQLite’tan tamamen vazgeçmek istemiyorum ama bir türlü içime sinmiyor. String oluşturulmasından ya da stack’in herhangi bir yerinde string parsing olmasından hoşlanmıyorum; bana sadece yanlış geliyor

  • SQLite şaşırtıcı derecede çok yönlü. Daha birkaç hafta önce bile SQLite üzerinde processler arası kuyruk, stream ve publish/subscribe uygulayan bir eklenti paylaşılmıştı
    Show HN: Honker – SQLite için Postgres NOTIFY/LISTEN Semantics | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
    Gerçek zamanlı bildirimler, SQLite backend’i ile tüm uygulamayı kurarken eksik olan büyük parçalardan biriydi; artık bunun için oldukça iyi bir çözüm var gibi görünüyor

  • SQLite’ın bu düzeyde kurumsal tanınma görmesi güzel. Tek dosyalık formatı sayesinde arşivleme, geleneksel veritabanı dump’larına göre inanılmaz derecede daha basit hâle geliyor