Eine Engine wählen
Diese Seite richtet sich an Datenbankadministratoren, die die Datenbank einer neuen Exponential-Website auswählen oder freigeben müssen. Sie beantwortet: welche Fragen die Wahl entscheiden, was jede Engine im Betrieb kostet und wo jede nicht mehr passt. Sie fasst 9.7 Vergleich und die Abschnitte zu Grenzen in Datenbankunterstützung zusammen.
Inhalt
- Fünf Fragen
- Der Vergleich
- Typische Antworten
- Wann SQLite nicht mehr passt
- Bevor Sie MongoDB oder Oracle wählen
- Später umentscheiden
Fünf Fragen
- Wie viele Maschinen schreiben in die Datenbank? Eine Maschine (mit beliebig vielen PHP-Prozessen) kann SQLite verwenden. Mehrere Webserver brauchen einen Datenbankserver: PostgreSQL, MariaDB, MySQL, MongoDB oder Oracle.
- Wie viel wird gleichzeitig geschrieben? SQLite reiht Schreiber nacheinander ein (die Schreibwarteschlange); die Server-Engines sperren Zeilen.
- Was betreibt und sichert Ihre Organisation bereits? Eine Engine, die Ihr Team bereits überwacht, patcht und wiederherstellt, ist mehr wert als ein kleiner technischer Vorteil.
- Brauchen Sie Replikation, Wiederherstellung zu einem Zeitpunkt oder Datenbankbenutzer und Rechte? SQLite hat nichts davon selbst.
- Welche Erweiterungen wird die Website verwenden? Erweiterungen mit eigenem SQL wurden meist für MySQL geschrieben; sie können auf PostgreSQL oder Oracle Arbeit brauchen und auf MongoDB einen eigenen Weg (SQL von Erweiterungen für jede Engine prüfen).
Der Vergleich
| SQLite 3 | MySQL / MariaDB | PostgreSQL | MongoDB | Oracle | |
|---|---|---|---|---|---|
| Zu betreibender Server | keiner | ja | ja | ja | ja |
| Gleichzeitige Schreiber | einer nach dem anderen, in der Warteschlange | Zeilensperren (InnoDB) | Zeilensperren (MVCC) | auf Dokumentebene | Zeilensperren |
| Mehrere Anwendungsserver | nein (ein Host) | ja | ja | ja | ja |
| Lesereplikate | nein | eingebaut (UseSlaveServer) | extern | Replica Sets | extern (Data Guard) |
| SQL-Abfrage-Cache | ja | ja | ja | nein | ja |
| Benutzer und Rechte | Dateisystem | ja | ja | ja | ja |
| Bekannte Lücken | ein Host; Schreibzugriffe in der Warteschlange | 4-Byte-Zeichen über die Verbindung utf8 | Grenzen des Adapters | '' ist NULL; Groß-/Kleinschreibung zählt |
Quelle: 9.7 Vergleich.
Typische Antworten
| Situation | Übliche Wahl | Warum |
|---|---|---|
| Eine Website auf einem Server, ein Redaktionsteam, beliebig viele Leser | SQLite 3 | Kein Server zu betreiben; WAL lässt Leser während Schreibzugriffen weiterarbeiten; die meisten Seitenaufrufe beantworten Caches |
| Eine Website auf mehreren Webservern, oder viele Redakteure, die den ganzen Tag große Änderungen veröffentlichen | PostgreSQL | Der empfohlene Server des Projekts: striktes SQL, Sperren auf Zeilenebene, eigene Replikation und Wiederherstellung zu einem Zeitpunkt, in der CI getestet |
| Eine Organisation, die auf MySQL oder MariaDB standardisiert ist, oder viele reine MySQL-Erweiterungen | MariaDB oder MySQL | Die Engine, für die die meisten Erweiterungen geschrieben wurden; eingebaute Lesereplikate |
| Eine Organisation, die auf MongoDB standardisiert ist | MongoDB | Über den Adapter unterstützt; lesen Sie zuerst seine Grenzen |
| Eine Organisation, die auf Oracle standardisiert ist | Oracle 19c oder neuer mit ezoracle | Verbindungspooling (DRCP), Failover und Tracing für ein Oracle-Haus |
| Eine öffentliche Demo, die alle paar Stunden neu gebaut wird | SQLite 3 | Zwischen den Builds ist nichts zu löschen (9.10) |
Wann SQLite nicht mehr passt
Aus Grenzen, und wann Sie eine andere Engine wählen:
- Mehr als eine Maschine muss in dieselbe Datenbank schreiben. WAL braucht gemeinsamen Speicher auf einem Host; ein Netzwerkdateisystem ist kein Ersatz.
- Viele Redakteure veröffentlichen gleichzeitig große Änderungen, den ganzen Tag, sodass die Warteschlange regelmäßig
länger ist als
SQLiteTransactionWait. - Sie brauchen Replikation, einen Hot Standby oder eine Wiederherstellung zu einem Zeitpunkt aus der Datenbank selbst.
- Sie brauchen Datenbankbenutzer und Rechte.
Die Größe der Datenbank ist selten der Grund. SQLite bewältigt Datenbanken, die weit größer sind als die Inhalte einer Exponential-Website.
Bevor Sie MongoDB oder Oracle wählen
- MongoDB: Der Adapter führt nie echtes SQL aus; handgeschriebenes SQL, das er nicht übersetzen kann, liefert ein leeres
Ergebnis und protokolliert
MONGO TODO. Die tiefe Neuerzeugung von URL-Aliasen ist unvollständig,eztagsist nicht verwendbar, der Shop-Checkout undezflowsind nicht durchgängig getestet, es gibt keine SQL-Update-Dateien und der SQL-Abfrage-Cache gilt nicht (MongoDB: Grenzen und Betrieb). - Oracle: braucht Exponential 6.0.15 oder neuer, Oracle 19c oder neuer in
AL32UTF8,oci8gegen einen Oracle-Client gebaut und Aufmerksamkeit für''als NULL und Vergleiche mit Beachtung der Groß-/Kleinschreibung. Oracle ist nicht in der CI des Projekts (Oracle mit ezoracle einrichten).
Später umentscheiden
Eine Website kann über das Format .dba zwischen den SQL-Engines umziehen, mit den Übertragungsbefehlen der Erweiterung
nach Oracle und mit den Skripten in bin/mongodb/ nach MongoDB. Planen Sie ein Wartungsfenster ein
(Eine Website auf eine andere Engine umziehen).
Verwandte Seiten
- Unterstützte Engines und Versionen
- Leistung und Skalierung
- Datenbanken in der offiziellen Reihenfolge
- Datenbankunterstützung
- Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.
Werden Sie Exponential-Partner
Partner teilen ihre Informationen, stellen Mittel bereit, geben Beiträge zurück und entwickeln die Produkte mit uns, und so wächst Exponential. Eine Partner-Website und ein Dashboard sind für Mitte 2027 geplant: Werden Sie noch heute Partner, damit wir schneller wachsen und neue Funktionen früher liefern.