SQLite adalah format penyimpanan yang direkomendasikan oleh Library of Congress AS

 (sqlite.org)
1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • SQLite termasuk dalam format penyimpanan yang direkomendasikan oleh US Library of Congress untuk dataset
  • Dasar terkait dapat dilihat pada deskripsi format SQLite dari Library of Congress dan daftar format yang direkomendasikan untuk data: https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml#local, https://www.loc.gov/preservation/resources/rfs/data.html
  • Per 29 Mei 2018, format penyimpanan yang direkomendasikan untuk dataset selain SQLite hanyalah XML, JSON, dan CSV
  • Format penyimpanan yang direkomendasikan oleh Library of Congress adalah format yang dinilai oleh para ahli preservasi dapat memaksimalkan kemungkinan bertahan dan akses berkelanjutan dari konten digital
  • Kriteria penilaiannya mencakup keterbukaan, tingkat adopsi, transparansi, dokumentasi mandiri, ketergantungan eksternal, dampak paten, dan mekanisme perlindungan teknis seperti enkripsi

SQLite dan format penyimpanan yang direkomendasikan LoC

Kriteria penilaian format penyimpanan yang direkomendasikan

  • Format penyimpanan yang direkomendasikan adalah format yang dinilai oleh para ahli preservasi Library of Congress dapat memaksimalkan kemungkinan bertahan dan akses berkelanjutan dari konten digital
  • Saat memilih format penyimpanan yang direkomendasikan, Library of Congress mempertimbangkan kriteria berikut

  • Keterbukaan

    • Menilai sejauh mana tersedia spesifikasi dan alat yang lengkap untuk memverifikasi integritas teknis, serta sejauh mana pihak yang membuat dan memelihara konten digital dapat mengaksesnya
    • Dokumentasi yang lengkap lebih penting daripada persetujuan dari lembaga standardisasi yang diakui

  • Tingkat adopsi

    • Menilai sejauh mana produsen, distributor, dan pengguna utama sumber daya informasi sudah menggunakan format tersebut
    • Ini mencakup penggunaan sebagai format master, format penyampaian untuk pengguna akhir, dan sarana pertukaran antar sistem

  • Transparansi

    • Menilai sejauh mana representasi digital dapat dianalisis secara langsung dengan alat dasar, seperti apakah dapat dibaca manusia dalam editor teks biasa

  • Dokumentasi mandiri

    • Objek digital yang terdokumentasi mandiri mencakup metadata deskriptif dasar, metadata teknis, dan metadata administratif lainnya

  • Ketergantungan eksternal

    • Menilai sejauh mana rendering atau penggunaan bergantung pada perangkat keras, sistem operasi, atau perangkat lunak tertentu, serta kerumitan menangani ketergantungan tersebut di lingkungan teknologi masa depan

  • Dampak paten

    • Menilai sejauh mana paten dapat menghambat kemampuan lembaga preservasi untuk mempertahankan konten dalam format tersebut

  • Mekanisme perlindungan teknis

    • Menilai apakah ada penerapan mekanisme seperti enkripsi yang dapat menghalangi preservasi konten dalam repositori tepercaya

Bacaan terkait

1 komentar

 
GN⁺ 1 jam lalu
Komentar Hacker News

  • Saya selalu terinspirasi oleh SQLite. Secara umum saya menyukainya, tetapi jika tidak perlu menulis data, ini juga bisa menjadi pilihan yang agak berlebihan
    Karena itu saya tidak benar-benar melampaui SQLite, tetapi saya membuat format yang jauh lebih ringan, lebih cepat, dan bisa bekerja dengan file terkompresi zstd
    Indeksnya sangat kecil dan, seperti SQLite, dapat menyimpan data biner maupun teks
    Bagian wasm yang menangani dekompresi, pembacaan, dan pencarian berukuran 38KB tanpa kompresi, dan mungkin sekitar 16KB dengan gzip. Dibandingkan dengan 1.2MB wasm dan glue code SQLite, ukurannya hanya 3%, tetapi pencarian dan pemuatannya jauh lebih cepat
    Program saya bukan berbasis kolom dan tidak cocok untuk pengelolaan spreadsheet, tetapi sangat cocok untuk kamus serta arsip file gambar dan audio
    Saya juga mem-port decoder jbig2 menjadi modul wasm 17KB, sehingga bisa membaca hasil pindaian hitam-putih 8KB per halaman dan tetap cukup terbaca
    https://github.com/tnelsond/peakslab
    SQLite dirancang dengan sangat baik, sedangkan PeakSlab sangat sederhana

    • Anda menyebut “1.2MB wasm dan glue code SQLite”, tetapi bentuk standar non-minified di trunk saat ini sebenarnya 1.7MB. Sebagian besar ukurannya datang dari dokumentasi, jadi WASM dan JS hampir terbagi rata. Namun jika diminify, 1.2MB memang benar
      Sebagai catatan, saya adalah salah satu maintainer-nya
      Berdasarkan trunk saat ini, angkanya adalah sqlite3.wasm 896745, sqlite3.mjs 816270 (non-minified dengan dokumentasi), sqlite3.mjs 431388 (non-minified tanpa dokumentasi), sqlite3.mjs 310975 (minified)
    • Saya belum pernah mendengar PeakSlab sebelumnya, tetapi ini benar-benar keren dan segar. Performa kamusnya juga tampak hebat, dan layak dibookmark untuk dipakai nanti
    • Ini terlihat lebih dekat ke arah bersaing dengan Berkeley DB lama: https://en.wikipedia.org/wiki/Berkeley_DB
      Sekarang saya lihat lisensinya bahkan sudah bukan BSD lagi, dan bagaimanapun hampir punah karena SQLite, tetapi dulu dipakai untuk kebutuhan dasar penyimpanan key-value berbasis disk
    • SQLite sendiri juga cukup sederhana, dan saya suka prinsip desain dari dialek SQL-nya
      Semacam, “right join itu cuma left join dengan arah terbalik, jadi tidak perlu ada”
      Tentu saja selalu mungkin membuat sesuatu yang lebih sederhana atau lebih terspesialisasi. Banyak aplikasi yang memakai database akan berjalan sangat baik hanya dengan SQLite, dan beberapa aplikasi mungkin sudah cukup hanya dengan file teks alih-alih DB seperti SQLite
    • Solusi yang lebih standar sepertinya adalah cdb. Hanya saja, ia tidak mendukung data terkompresi
      https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)

  • Saya selalu menyukai SQLite, tetapi saya pernah mendengar ada perusahaan yang melarang penggunaannya
    Alasannya, terlalu mudah membuat database untuk aplikasi, sehingga komponen yang sangat inti dari aplikasi itu tampak seperti sekadar file biasa. File itu bisa memakai ekstensi apa pun, dan bisa disalin ke server lain. Bahkan jika di dalamnya ada informasi identitas pribadi, tetap saja begitu
    Jika dibayangkan situasi ini berkembang sebanyak jumlah aplikasi di sebuah perusahaan, hasilnya bisa menjadi kekacauan besar
    Tim DevOps dan DBA lebih suka database berupa mesin besar dan berat yang jelas terlihat sebagai server database. Tindakan menghubungkannya pun terlihat jelas, dan seterusnya
    Meski begitu, saya tetap suka SQLite

    • Kalau begitu saya penasaran apakah perusahaan yang sama juga melarang Excel. Spreadsheet Excel sering menjadi database bayangan di tempat-tempat yang tidak terduga
    • Dalam percakapan tentang “apa pun bisa menjadi database mission-critical”, tulisan ini wajib dibaca
      https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
    • Jika itu “file yang bisa punya ekstensi apa pun”, maka cukup baca magic number-nya. Lagi pula, ekstensi file memang tidak boleh dipercaya
      Soal “bisa disalin ke server lain”, spreadsheet juga begitu
      Saya tidak menyangkal bahwa akses data yang terpusat itu diinginkan, tetapi logika itu tampaknya belum cukup matang
    • SQLite juga punya pemakaian menarik seperti ini: https://sqlite.org/sqlar.html
    • Itulah sebabnya file konfigurasi seperti itu diletakkan di AppData atau direktori dotfile, atau lokasi padanannya di ~/Library pada MacOS

  • Dulu saya menganggap “SQLite itu produk mainan dan tidak bisa dipercaya untuk data sungguhan”, tetapi sekarang saya berubah ke kubu “pakai SQLite untuk hampir semuanya”
    Jika Anda bisa menyesuaikan diri dengan pola single writer, multiple readers, SQLite itu sangat bagus. Dengan pengaturan yang tepat, Anda tidak akan kehilangan data, dan pengaturan itu bisa ditemukan hanya dengan mencari sekitar satu menit
    Saat ini sebagian besar aplikasi saya hanyalah kombinasi biner Go + SQLite + file layanan systemd
    Saya belum pernah kehilangan data, performanya luar biasa, dan untuk sebagian besar aplikasi itu sudah lebih dari cukup

    • Single writer sebenarnya bukan masalah sebesar yang sering dibicarakan orang. Drive NVMe zaman sekarang luar biasa, jadi dengan pengaturan WAL yang dioptimalkan, 5.000 penulisan per detik itu mudah dicapai. Kebanyakan aplikasi bahkan tidak bisa bermimpi sampai level itu
      Saya bahkan pernah mencapai 180 ribu penulisan per detik di VPS biasa dengan pola batch writer
    • Saya penasaran apakah Anda memakai beberapa node backend. Jika iya, saya juga penasaran bagaimana node-node yang berbeda itu mengakses file SQLite yang sama

  • Karena tertulis “pada saat tulisan ini dibuat (2018-05-29)…”, ini berarti kabar yang usianya hampir 8 tahun. Tapi saya tidak mengeluh karena sampai sekarang belum tahu, malah lebih ke arah berterima kasih karena sudah dibagikan
    Otak matematika saya sempat ngadat dan saya kira ini 6 tahun lalu

    • Sekarang sudah 2026, jadi ini 8 tahun yang lalu
    • Saat membacanya saya merasa deja vu

  • Format penyimpanan yang direkomendasikan pada 2026: https://www.loc.gov/preservation/resources/rfs/data.html

    • Jika ingin menyimpan data sambil merencanakan hingga 300~500 tahun ke depan, dan membuatnya tahan terhadap segala macam inovasi serta penuaan teknologi yang mendasar, benar-benar dibutuhkan cara berpikir jangka panjang
      Media berbasis kertas apa yang paling lama bertahan?
    • Kriteria rekomendasinya tampak cukup longgar. XLS masuk sebagai format “preferred”

  • Untuk pelestarian data sektor publik, SQLite mungkin salah satu pilihan terbaik
    Spesifikasinya terbuka, diadopsi luas, dan kemungkinan besar masih bisa dibaca di masa depan
    Ketergantungannya pada sistem operasi atau layanan tertentu kecil, dan risiko patennya juga rendah
    Dari sudut pandang keberlanjutan jangka panjang, sangat penting untuk tidak bergantung pada perusahaan atau layanan tertentu

    • Para arsiparis juga menyukai format yang dekat dengan bentuk aslinya. SQLite memungkinkan relasi relasional dipertahankan apa adanya, sesuatu yang sulit diwakili oleh CSV

  • Saya suka SQLite dan senang ini dibagikan, tetapi rasanya judulnya perlu ditambahkan “(2018)” di akhir
    Tertulis, “pada saat tulisan ini dibuat (2018-05-29), format penyimpanan lain yang direkomendasikan untuk dataset hanyalah XML, JSON, dan CSV”

    • Sebagai catatan, setelah itu banyak format ditambahkan ke daftar
      Untuk format preferred, selama data tetap lengkap dan detail serta presisinya terjaga, format berbasis karakter yang independen platform lebih diutamakan daripada format native atau biner. Ini mencakup standar pasar de facto yang matang dan diadopsi luas
      Misalnya format berbasis skema yang terkenal dengan alat validasi terbuka, format berorientasi baris seperti TSV, CSV, fixed-width, serta format terbuka independen platform seperti .db, .db3, .sqlite, .sqlite3
      Juga termasuk format proprietari yang menjadi standar de facto di profesi tertentu atau didukung oleh banyak alat. Misalnya Excel .xls/.xlsx, Shapefile, dan semacamnya
      Untuk encoding karakter, yang diprioritaskan adalah UTF-8, UTF-16 dengan BOM, US-ASCII, atau ISO 8859-1, lalu encoding lain yang memiliki nama
      Untuk format acceptable, dalam kategori data termasuk format terbuka nonproprietari yang terdokumentasi publik dan disetujui sebagai standar oleh komunitas profesional atau lembaga pemerintah (seperti CDF, HDF, dll.), serta format data berbasis teks yang memiliki skema yang tersedia
      Untuk pengemasan atau transfer, ZIP, RAR, tar, dan 7z diperbolehkan selama tidak memiliki enkripsi, kata sandi, atau mekanisme perlindungan lain
      https://www.loc.gov/preservation/resources/rfs/data.html

  • Baru kemarin saya juga berpikir sudah lama tidak melihat tulisan tentang SQLite di bagian atas HN
    Saya sangat menyukai kesederhanaan dan kecepatan SQLite, dan sudah memakainya baik untuk proyek pribadi maupun pekerjaan
    Namun dalam pekerjaan sehari-hari, saya akhirnya tetap kembali ke Excel. Bukan karena saya lebih suka Excel, melainkan karena penggunaannya sangat luas sehingga itu menjadi cara dengan friksi paling rendah untuk berbagi dan menjelajahi dataset bersama pemangku kepentingan yang kurang teknis atau para eksekutif

    • Saya tidak berpikir ini akan tiba-tiba meruntuhkan pandangan dunia Anda, tetapi karena ini berguna bagi saya, mungkin juga bisa membantu Anda, jadi mungkin layak melihat Metabase
      Bisa di-host sendiri, dan sangat sederhana jika yang Anda inginkan hanya menampilkan data kepada pemangku kepentingan dalam bentuk yang mudah dicerna. Tentu saja kalau Anda terlalu mendalaminya, Anda bisa menyesali semua keputusan hidup, tetapi saya menahan diri agar tidak sampai begitu
      https://www.metabase.com/
    • Yang selalu mengganggu saya dari SQLite adalah bahwa cara kerjanya bergantung pada parsing teks. Saya tidak mengerti kenapa kueri harus ditulis sebagai teks, dan kenapa tidak bisa diekspresikan sebagai logika program
      Karena ini saya belum pernah memakai database relasional sama sekali. Saya tidak suka. Saya tahu performanya bisa lebih baik daripada data terstruktur murni, tetapi saya tidak suka SQL dan bahkan ide tentang SQL itu sendiri, dan saya tidak ingin menulisnya, mempelajarinya, atau memakai sistem yang bergantung padanya
      Rasanya seperti pendekatan yang salah, setingkat PHP. Adakah cara untuk mengurangi ini? Saya tidak ingin terus menyerah pada SQLite gara-gara SQL, tetapi saya benar-benar tidak bisa menerimanya. Saya tidak suka membangun string atau adanya parsing string di mana pun dalam stack, rasanya memang salah

  • SQLite sangat serbaguna sampai mengejutkan. Hanya beberapa minggu lalu saja, ada ekstensi yang dirilis untuk mengimplementasikan queue antarproses, stream, publish/subscribe dan semacamnya di atas SQLite
    Show HN: Honker – Semantik Postgres NOTIFY/LISTEN untuk SQLite | 327 poin | 94 komentar | https://news.ycombinator.com/item?id=47874647
    Notifikasi real-time adalah salah satu potongan besar yang selama ini kurang saat membangun seluruh aplikasi di atas backend SQLite, dan sekarang sudah ada solusi yang cukup bagus

  • Menyenangkan melihat SQLite mendapat pengakuan tingkat institusional sebesar ini. Berkat format satu file-nya, penyimpanan arsip menjadi jauh lebih sederhana dibanding dump database tradisional