SQLite 3 für Datenbankadministratoren #

Diese Seite richtet sich an Datenbankadministratoren, die eine Exponential-Website auf SQLite 3, dem Standard des Installers, betreiben sollen und Serverdatenbanken besser kennen als Dateidatenbanken. Sie beantwortet: was der Treiber der SQLite-Bibliothek hinzufügt, aus welchen Dateien eine Datenbank besteht, welche Verbindungseinstellungen angewendet werden und warum, wie Leser und Schreiber nebeneinander bestehen und wo SQLite nicht mehr passt. Quelle: 9.2 SQLite 3 und der Treiber lib/ezdb/classes/ezsqlite3db.php.

Inhalt #

1. Warum SQLite der Standard ist
2. Wo die Datenbank liegt
3. Was der Treiber bei jeder Verbindung tut
4. Die PRAGMA-Standards
5. WAL: Leser und Schreiber nebeneinander
6. Die SQL-Kompatibilitätsschicht
7. Wo SQLite passt
8. Checkliste

Warum SQLite der Standard ist #

Der Einrichtungsassistent wählt es vor (settings/setup.ini [DatabaseSettings] DefaultType=sqlite3), exp:install verwendet es, wenn kein --db angegeben ist, und die Kickstarter-Vorlage nennt es zuerst. Es braucht keinen Serverprozess, kein Netzwerk und keine Konten. Mit dem Treiber, den Exponential mitliefert, ist es eine vollwertige Produktionsdatenbank für eine Website, die von einer Maschine ausgeliefert wird: Die meisten Seitenaufrufe werden von Caches beantwortet, bevor sie sie erreichen, und gleichzeitige Veröffentlichungen reihen sich ein, statt zu scheitern.

Wo die Datenbank liegt #

Die Einstellung Database ist ein Dateiname:

• ein einfacher Name (exponential.db) liegt in var/storage/sqlite3/ (die Konstante eZSQLite3DB::STORAGE_DIRECTORY);
• ein Name, der mit / beginnt, ist ein absoluter Pfad;
• :memory: ist eine Wegwerf-Datenbank (nur für Tests).

exp:install nennt die Datei exponential.db, der Einrichtungsassistent schlägt sqlite.db vor. Ein fehlendes Verzeichnis wird mit Modus 0775 angelegt; eine fehlende Datei wird leer angelegt. Ein falscher Wert für Database scheitert daher nicht beim Verbinden: Er öffnet eine neue, leere Datenbank, und die Website meldet fehlende Tabellen.

php bin/php/console exp:ini get site.ini/DatabaseSettings/Database --allow-root-user
ls -l var/storage/sqlite3/

Eine Datenbank besteht aus vier Dateien: der Datenbank, -wal, -shm und dem .writer-lock des Treibers (SQLite-Dateien, Eigentümer und Rechte).

Was der Treiber bei jeder Verbindung tut #

1. Er löst die Datei auf wie oben. Eine Datei, die sich (nach ConnectRetries weiteren Versuchen) nicht öffnen lässt, löst eZDBNoConnectionException mit dem vollständigen Pfad aus.
2. Er registriert Funktionen, die SQLite fehlen: md5() und die Aggregate BIT_OR und BIT_AND, die die Inhalts-Engine verwendet, um Sprachmasken zusammenzufassen.
3. Er wendet die PRAGMAs an, das Busy-Timeout zuerst.
4. Er schaltet auf WAL um, nur wenn die Datei noch nicht im WAL-Modus ist (der Modus wird in der Datei gespeichert).

Die PRAGMA-Standards #

Ändern oder ergänzen Sie PRAGMAs mit SQLitePragmas[], ein name=value je Eintrag. Der Treiber akzeptiert im Namen nur Buchstaben und Unterstriche und im Wert Buchstaben, Ziffern, _ und - und überspringt alles andere. WAL gewinnt immer: Ein Eintrag journal_mode wird auf WAL zurückgestellt.

[DatabaseSettings]
SQLitePragmas[]
SQLitePragmas[]=cache_size=-16384
SQLitePragmas[]=journal_size_limit=67108864

cache_size gilt je Verbindung: Rechnen Sie mit bis zu 64 MB für jeden PHP-FPM-Worker und jeden Velocity-Worker, der die Datenbank geöffnet hat, oder senken Sie den Wert wie oben (16 MB).

WAL: Leser und Schreiber nebeneinander #

• Leser blockieren den Schreiber nie, und der Schreiber blockiert Leser nie. Seitenaufrufe laufen weiter, während ein Redakteur veröffentlicht.
• Es gibt jeweils einen Schreiber. Der Treiber lässt den nächsten Schreiber warten, bis er an der Reihe ist (SQLite: die Schreibwarteschlange und Sperren).
• Ein Checkpoint kopiert das WAL in die Datenbank zurück, automatisch bei etwa 1000 Seiten; bei ständigem Lesen kann die WAL-Datei eine Weile wachsen (SQLite-Wartung).
• Alle Prozesse müssen auf einer Maschine laufen. WAL verwendet gemeinsamen Speicher und funktioniert daher nicht über ein Netzwerkdateisystem.

Die SQL-Kompatibilitätsschicht #

Das SQL des Kernels wurde zuerst für MySQL geschrieben. Der Treiber überbrückt die Lücken: Er schreibt UPDATE ... JOIN in UPDATE ... FROM um (SQLite 3.33 oder neuer) und akzeptiert und ignoriert MySQL-Session-Anweisungen (SET NAMES, SET FOREIGN_KEY_CHECKS, SET CHARACTER SET, SET AUTOCOMMIT, SET SQL_MODE, SET UNIQUE_CHECKS). SQLite vergleicht bei = mit Beachtung der Groß-/Kleinschreibung und ignoriert sie bei ASCII-Buchstaben in LIKE.

Wo SQLite passt #

Es passt zu einer Maschine, beliebig vielen Lesern und einem Redaktionsteam. In den Lasttests des Projekts skalierten gleichzeitige Leser mit der Zahl der Prozesse, und 16 gleichzeitige Schreiber wurden ohne Fehler abgeschlossen, in der Warteschlange. Wählen Sie einen Datenbankserver, wenn mehr als eine Maschine schreiben muss, wenn viele Redakteure den ganzen Tag gleichzeitig große Änderungen veröffentlichen oder wenn Sie Replikation oder Benutzer und Rechte auf Datenbankebene brauchen (Eine Engine wählen).

Checkliste #

• To do: Die SQLite-Bibliothek von PHP ist 3.33 oder neuer (php --ri sqlite3).
• To do: PRAGMA journal_mode gibt wal aus.
• To do: Jeder Prozess, der die Website verwendet, kann das Verzeichnis und die Dateien schreiben.
• To do: Die Datenbank ist nicht über HTTP erreichbar.
• To do: Sicherungen verwenden .backup oder VACUUM INTO, nie eine einfache Kopie einer beschäftigten Datei (Sicherungen je Engine).
• To do: Der Speicher ist für cache_size je Worker bemessen.

Verwandte Seiten #

• SQLite: die Schreibwarteschlange und Sperren
• SQLite-Wartung: ANALYZE, VACUUM und die WAL-Datei
• SQLite für Hoster
• SQLite-Datenbankunterstützung, Der SQLite3-Datenbanktreiber
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.