Fakta menarik tentang SQLite

• SQLite adalah database yang paling banyak didistribusikan dan digunakan

  • Lebih dari 1 triliun database SQLite sedang digunakan, dan dikelola oleh tiga orang
  • Tidak menerima kontribusi eksternal

• SQLite digunakan lebih banyak daripada gabungan semua mesin database lainnya

  • Ada miliaran salinan SQLite, dan ada di mana-mana

• SQLite adalah salah satu modul perangkat lunak yang paling banyak didistribusikan

• Hwaci adalah perusahaan yang mengembangkan SQLite, dan juga tertarik pada musik

• SQLite bermula dari kapal perang Amerika Serikat

  • D. Richard Hipp (DRH) sedang mengembangkan perangkat lunak untuk kapal perusak Angkatan Laut bernama USS Oscar Austin
  • Ada masalah di mana perangkat lunak yang ada berhenti bekerja setiap kali server mati
  • DRH membayangkan database yang bisa berjalan tanpa server

• SQLite bukan open source dalam arti hukum

  • Open source memerlukan definisi tertentu dan lisensi yang disetujui OSI
  • Sebagai gantinya, SQLite berada di ranah publik, dengan pembatasan yang lebih sedikit daripada lisensi open source

• Tidak menerima kontribusi eksternal

  • Hanya orang yang diundang yang dapat berkontribusi, dan kontribusi harus didedikasikan ke ranah publik

• Kode pengujian SQLite

  • Ada lebih dari 600 baris kode uji untuk setiap satu baris kode SQLite
  • Pengujian mencakup 100% seluruh percabangan pustaka

• Sebagian pengujian SQLite bersifat proprietary

  • Test suite bernama TH3 bersifat proprietary, dan untuk mengaksesnya harus bergabung dengan konsorsium SQLite

• Model bisnis SQLite

  • Menghasilkan pendapatan melalui dukungan berbayar, layanan pemeliharaan, keanggotaan konsorsium, dan ekstensi komersial

• SQLite memiliki kode etik alih-alih code of conduct

• SQLite sangat cepat, dan dalam beberapa use case bahkan 35% lebih cepat daripada file system

• SQLite menggunakan model single writer

  • Tidak mengizinkan beberapa penulis secara bersamaan

• Perbedaan dengan database lain

  • Secara default menggunakan mode rollback journal, dan foreign key dalam keadaan nonaktif
  • Menggunakan weak typing, sementara strong typing bersifat opsional

• Tidak adanya tipe di SQLite bisa terasa merepotkan

  • Data dapat dimasukkan tanpa batasan tipe

• SQLite sangat mementingkan kompatibilitas

  • Semua versi SQLite 3 dapat membaca dan menulis file database dari versi awal

• Penulis SQLite, DRH, menilai sistem version control yang ada tidak cocok, sehingga mengembangkan Fossil

• DRH menulis kode B-Tree di pesawat berdasarkan algoritme dari buku TAOCP

• Pelafalan SQLite yang disarankan adalah "Ess-Cue-El-Lite", tetapi tidak ada panduan resmi

[dalinaum]

SQLite bukan DB yang ternyata secepat dugaan banyak orang. MongoDB Realm, yang kini sudah dihentikan dukungannya, jauh lebih cepat. Tampaknya bagi banyak orang, kecepatan bukanlah faktor yang begitu penting dalam memilih.

[dalinaum]

Ada yang bertanya kenapa Realm cepat dan meminta dasar penjelasannya, tetapi sepertinya MongoDB menghapus tulisannya saat menghentikan dukungan.

Jadi, dari sudut pandang seseorang yang pernah bekerja di sana, saya ingin menjelaskan alasan teknis yang saya ingat. Saya rasa alasan terbesarnya adalah Realm menggunakan memori lebih sedikit dibanding SQLite dan memiliki tingkat cache hit yang lebih tinggi.

Realm pada dasarnya memilih kapasitas yang disimpan di memori berdasarkan ukuran yang digunakan. Jadi meskipun pengguna memilih tipe data berukuran besar, dalam banyak kasus serialisasinya dilakukan ke ukuran kecil beberapa bit. Konversi baru dilakukan ketika pengguna benar-benar memakai data yang lebih besar.

Realm menyimpan tipe data yang sama secara berkelompok dan berdekatan. Pengguna sering kali tidak mengakses semua data dalam tabel, melainkan hanya mengakses sebagian data secara berurutan. Karena encoding berukuran kecil yang disebutkan tadi, jumlah data yang bisa ditemukan sekaligus di cache menjadi jauh lebih banyak.

Realm tidak melakukan hydrate ke objek POJO, melainkan menyajikan data saat diperlukan melalui getter dan setter. Untuk ini, dalam kasus Java, manipulasi dilakukan pada level bytecode. Salah satu alasan tipe data seperti Protobuf digunakan saat itu di klien aplikasi Facebook milik Meta adalah karena proses hydrate ini menjadi kelemahan besar dari sisi performa, dan hanya mengakses data yang diperlukan memberi keuntungan.

Realm jauh lebih cepat daripada SQLite di sebagian besar skenario, tetapi saya rasa hal ini bukan faktor besar di pasar.

Kalau tidak salah, pesaing terbesar Realm adalah Parse yang dibuat oleh Facebook. Setelah itu, pesaingnya menjadi Firebase dari Google. Keduanya bukan database mobile lokal, melainkan layanan untuk menyimpan data jarak jauh dengan mudah. Mungkin terdengar aneh bagaimana keduanya bisa menjadi pesaing Realm, tetapi tampaknya bagi pengguna, yang penting data bisa disimpan di mana saja dan kecepatan tidak terlalu penting.

Setelah itu, Ericsson berinvestasi dan cakupan Realm pun dipersempit. Ericsson melihat Realm sudah memiliki pangsa tertentu di iOS, tetapi tidak memahami perlunya pengembangan fitur lebih lanjut. Sebaliknya, mereka lebih mengakui nilainya sebagai solusi sinkronisasi. Setelah itu, Realm diakuisisi oleh MongoDB.

[aer0700]

Sepertinya 80% alasan saya memilih SQLite adalah karena kemudahannya untuk ditangani.

[dalinaum]

Saya juga menganggap ini sebagai salah satu alasan penting. Realm menyediakan cara penggunaan berbasis thread-local, menawarkan pembaruan otomatis, dan mengatakan bahwa jika kueri baru dilakukan di thread lain, data yang sama dapat diteruskan dengan biaya yang sangat rendah, serta menyarankan agar data tidak dipindahkan ke thread lain, tetapi tidak mudah untuk menjelaskan hal-hal seperti ini.

[sanggi]

Sepertinya SQLite digunakan di sangat banyak tempat!

[xguru]

Kisah-kisah menarik yang belum banyak diketahui tentang SQLite

[GN⁺]

Komentar Hacker News

• Ada pendapat bahwa OSI bukanlah tolok ukur open source. Definisi open source dari OSI memang berguna, tetapi juga menuai kritik dan kontroversi. Mengatakan bahwa SQLite secara hukum bukan open source adalah klaim yang keliru

  • Bergantung pada persetujuan OSI bukanlah hal yang ideal. Daftar lisensi yang disetujui OSI hanya mencerminkan sejarah yang praktis dan politis
  • Ada perdebatan tentang apakah SQLite itu open source. Dedikasi ke domain publik bukanlah lisensi sehingga tidak memenuhi OSD, tetapi justru lebih terbuka

• Blog tersebut tampak seperti upaya untuk mendorong jumlah tayangan dan keterlibatan dengan memakai poin-poin lama yang didaur ulang tentang topik populer

  • Tulisan-tulisan blog sebelumnya kurang memiliki kedalaman teknis dan banyak berisi hal yang dibesar-besarkan

• SQLite memiliki kode etik (CoE), bukan code of conduct (CoC). CoC digunakan sebagai alat untuk mengendalikan perilaku kontributor eksternal, sedangkan CoE adalah pernyataan tentang perilaku yang ingin ditunjukkan para pengembang SQLite kepada orang lain

• Ada kebingungan tentang cara pengucapan SQLite. Disebut diucapkan "Ess-Cue-El-Lite", tetapi ada juga yang mengucapkannya "S-Q-L-ite"

• SQLite secara opsional mendukung strict table. Dengan CREATE TABLE name (stuff TEXT) STRICT, tipe dapat dipaksakan

• SQLite bukan hanya basis data SQL, tetapi juga bisa digunakan sebagai basis data NoSQL. Cara menyimpan data dengan kolom JSON cukup berguna

• Ada pengalaman mengerjakan proyek bersama Richard Hipp. Ia memperoleh pemasukan yang stabil melalui kontrak dukungan

• Dalam salah satu rilis SQLite, banyak mikro-optimalisasi meningkatkan performa hingga 50%

• SQLite digunakan untuk prototyping cepat dan dump log, tetapi menjadi sulit ketika menginginkan multi-writer. Ini adalah salah satu alasan utama untuk beralih dari SQLite

• SQLite memiliki model single-writer. Redis juga memiliki model single-thread

• Salah satu fakta menarik tentang SQLite adalah ketika para pengguna mulai menelepon pengembang di tengah malam, mereka harus mengubah prefiks default dari sqlite_ menjadi etilqs_