Interessante Fakten über SQLite

• SQLite ist die am weitesten verbreitete und meistgenutzte Datenbank

  • Mehr als 1 Billion SQLite-Datenbanken sind im Einsatz und werden von drei Personen gepflegt
  • Externe Beiträge werden nicht zugelassen

• SQLite wird häufiger genutzt als alle anderen Datenbank-Engines zusammen

  • Es gibt Milliarden von SQLite-Kopien, und sie sind überall

• SQLite ist eines der am weitesten verbreiteten Softwaremodule

• Hwaci ist das Unternehmen, das SQLite entwickelt hat, und interessiert sich auch für Musik

• SQLite entstand auf einem US-Kriegsschiff

  • D. Richard Hipp (DRH) entwickelte Software für den Marinezerstörer USS Oscar Austin
  • Es gab das Problem, dass die bestehende Software jedes Mal nicht mehr funktionierte, wenn der Server ausfiel
  • DRH entwarf eine Datenbank, die auch ohne Server funktioniert

• SQLite ist im rechtlichen Sinn nicht Open Source

  • Open Source erfordert eine bestimmte Definition und eine von der OSI genehmigte Lizenz
  • Stattdessen ist SQLite Public Domain und damit weniger eingeschränkt als durch eine Open-Source-Lizenz

• Externe Beiträge werden nicht zugelassen

  • Nur eingeladene Personen können beitragen, und Beiträge müssen der Public Domain gewidmet werden

• Der Testcode von SQLite

  • Auf jede Codezeile von SQLite kommen mehr als 600 Zeilen Testcode
  • Die Tests decken 100 % aller Verzweigungen der Bibliothek ab

• Einige SQLite-Tests sind proprietär

  • Eine Testsuite namens TH3 ist proprietär, und für den Zugriff muss man dem SQLite-Konsortium beitreten

• Das Geschäftsmodell von SQLite

  • Einnahmen werden durch bezahlten Support, Wartungsservices, Konsortiumsmitgliedschaften und kommerzielle Erweiterungen erzielt

• SQLite hat statt eines Verhaltenskodex einen Ethikkodex

• SQLite ist sehr schnell und in einigen Anwendungsfällen 35 % schneller als ein Dateisystem

• SQLite hat ein Single-Writer-Modell

  • Mehrere gleichzeitige Schreibvorgänge werden nicht zugelassen

• Unterschiede zu anderen Datenbanken

  • Standardmäßig wird der Rollback-Journal-Modus verwendet, und Fremdschlüssel sind deaktiviert
  • Es verwendet schwache Typisierung, starke Typisierung ist optional

• Dass SQLite keine Typen erzwingt, ist unpraktisch

  • Daten können ohne Typbeschränkungen eingefügt werden

• SQLite misst Kompatibilität sehr große Bedeutung bei

  • Alle Versionen von SQLite 3 können Datenbankdateien der frühen Versionen lesen und schreiben

• Der Autor von SQLite, DRH, entwickelte Fossil, weil er bestehende Versionsverwaltungssysteme für ungeeignet hielt

• DRH programmierte im Flugzeug einen B-Tree auf Basis der Algorithmen aus dem TAOCP-Buch

• Für SQLite wird die Aussprache "Ess-Cue-El-Lite" empfohlen, es gibt jedoch keinen offiziellen Leitfaden

[dalinaum]

SQLite ist keine so schnelle DB, wie man vielleicht denkt. Das inzwischen eingestellte MongoDB Realm ist deutlich schneller. Offenbar war Geschwindigkeit für die Leute nicht so ein wichtiger Entscheidungsfaktor.

[dalinaum]

Es gab jemanden, der gefragt hat, warum Realm schnell ist, und um Belege bat; offenbar hat MongoDB den Beitrag gelöscht, als der Support eingestellt wurde.

Deshalb möchte ich aus der Erinnerung, aus der Perspektive von jemandem, der dort einmal gearbeitet hat, die technischen Gründe erläutern. Ich denke, der größte Vorteil war, dass Realm im Vergleich zu SQLite weniger Speicher verbrauchte und eine höhere Cache-Trefferquote hatte.

Realm wählt grundsätzlich die im Speicher abgelegte Größe anhand der tatsächlich verwendeten Größe aus. Deshalb wird selbst dann, wenn der Nutzer einen Datentyp mit großer Größe auswählt, häufig in eine kleine Größe von nur wenigen Bits serialisiert. Erst wenn der Nutzer tatsächlich größere Daten verwendet, wird eine Konvertierung vorgenommen.

Realm speichert gleiche Datentypen gebündelt und nebeneinander. Nutzer greifen häufig nicht auf alle Daten einer Tabelle zu, sondern fortlaufend nur auf einen Teil der Daten. Durch die zuvor erwähnte platzsparende Kodierung passt dann natürlich viel mehr auf einmal in den Cache.

Realm hydratisiert keine POJO-Objekte, sondern stellt die Daten erst dann über Getter und Setter bereit, wenn sie benötigt werden. Dafür wird im Fall von Java auf Bytecode-Ebene eingegriffen. Der Grund, warum Datentypen wie Protobuf damals im Facebook-App-Client von Meta verwendet wurden, war, dass dieser Hydratisierungsprozess ein großer Performance-Nachteil ist und der Zugriff nur auf die tatsächlich benötigten Daten Vorteile bringt.

Realm war in den meisten Szenarien im Vergleich zu SQLite deutlich schneller, aber ich glaube nicht, dass das am Markt ein entscheidender Faktor war.

Soweit ich mich erinnere, war der größte Konkurrent von Realm Parse, das von Facebook entwickelt wurde. Danach wurde Google Firebase zum Konkurrenten. Beide sind keine lokalen mobilen Datenbanken, sondern Dienste, mit denen sich Daten einfach auf einem entfernten System speichern lassen. Man könnte sich fragen, wie diese beiden überhaupt Konkurrenten von Realm sein konnten, aber den tatsächlichen Nutzern reichte es offenbar, die Daten einfach irgendwo zu speichern, und Geschwindigkeit war nicht besonders wichtig.

Später investierte Ericsson, und dadurch wurde der Umfang von Realm reduziert. Ericsson verstand nicht, warum Realm, das auf iOS bereits einen gewissen Marktanteil hatte, weitere Funktionen entwickeln sollte. Stattdessen wurde der Wert als Synchronisationslösung stärker anerkannt. Danach wurde Realm in MongoDB integriert.

[aer0700]

Ich glaube, etwa 80 % des Grundes, warum ich mich für SQLite entschieden habe, war, dass es so einfach zu handhaben ist.

[dalinaum]

Ich halte auch das für einen der wichtigen Gründe. Realm bot eine auf Thread-Local basierende Nutzungsweise, automatische Aktualisierungen und erklärte, dass bei einer neuen Abfrage in einem anderen Thread dieselben Daten mit sehr geringen Kosten übergeben werden könnten; außerdem wurde empfohlen, Daten nicht an andere Threads weiterzugeben, aber solche Zusammenhänge waren nicht leicht zu erklären.

[sanggi]

Es scheint wirklich, als würde SQLite an den unterschiedlichsten Orten eingesetzt!

[xguru]

Wissenswerte Fakten über SQLite

[GN⁺]

Hacker-News-Kommentare

• Es gibt die Ansicht, dass die OSI nicht der Maßstab für Open Source ist. Die Open-Source-Definition der OSI ist nützlich, steht aber auch in der Kritik und ist umstritten. Zu behaupten, SQLite sei rechtlich kein Open Source, ist falsch

  • Sich auf eine OSI-Zulassung zu stützen, ist nicht wünschenswert. Die Liste der von der OSI genehmigten Lizenzen spiegelt nur eine praktische und politische Geschichte wider
  • Es gibt eine Debatte darüber, ob SQLite Open Source ist. Die Freigabe in die Public Domain ist keine Lizenz und erfüllt daher die OSD nicht, ist aber offener

• Der Blog wirkt wie der Versuch, mit wiederverwerteten alten Punkten zu einem populären Thema Aufrufe und Engagement zu erzeugen

  • Frühere Beiträge des Blogs mangeln es an technischer Tiefe und sie enthalten viele Übertreibungen

• SQLite hat keinen Verhaltenskodex (CoC), sondern einen Ethikkodex (CoE). Ein CoC wird als Werkzeug genutzt, um das Verhalten externer Mitwirkender zu kontrollieren, während ein CoE eine Erklärung darüber ist, welches Verhalten die SQLite-Entwickler anderen gegenüber an den Tag legen wollen

• Es gibt Verwirrung über die Aussprache von SQLite. Es heißt, es werde als "Ess-Cue-El-Lite" ausgesprochen, aber manche sprechen es auch als "S-Q-L-ite" aus

• SQLite unterstützt optional strikte Tabellen. Mit CREATE TABLE name (stuff TEXT) STRICT können Typen erzwungen werden

• SQLite kann nicht nur als SQL-Datenbank, sondern auch als NoSQL-Datenbank verwendet werden. Die Nutzung von JSON-Spalten zum Speichern von Daten ist praktisch

• Es gibt Erfahrungen aus der Zusammenarbeit an einem Projekt mit Richard Hipp. Er erzielt über Support-Verträge stabile Einnahmen

• In einer SQLite-Release wurde die Performance durch viele Mikrooptimierungen um 50 % verbessert

• SQLite wird für schnelles Prototyping und Log-Dumps verwendet, aber wenn mehrere Writer benötigt werden, wird es schwierig. Das ist einer der Hauptgründe, SQLite zu verlassen

• SQLite hat ein Single-Writer-Modell. Redis hat ebenfalls ein Single-Thread-Modell

• Eine der interessanten Fakten über SQLite ist, dass das Standardpräfix von sqlite_ auf etilqs_ geändert werden musste, nachdem Nutzer begonnen hatten, die Entwickler mitten in der Nacht anzurufen