MongoDB: Grenzen und Betrieb #

Diese Seite richtet sich an Datenbankadministratoren, die entscheiden, ob MongoDB zu einer Website passt, oder die bereits eine betreiben. Sie beantwortet: was der Adapter nicht unterstützt, wie Sie eine Funktion erkennen, die still nichts zurückgibt, wie Upgrades und Schemaprüfungen ohne SQL funktionieren, wie Sie sichern und wie eine MySQL-Website nach MongoDB umzieht. Quellen: MongoDB als Datenbank, 9.5 MongoDB und Abschnitt 26 der Portierungsreferenz.

Inhalt #

1. Wie der Adapter arbeitet
2. Bekannte Grenzen
3. Unübersetztes SQL finden
4. Upgrades ohne SQL-Dateien
5. Sicherungen
6. Eine MySQL-Website nach MongoDB umziehen
7. Leistung
8. Checkliste

Wie der Adapter arbeitet #

expMongoDB führt nie echtes SQL aus. Er zerlegt die SQL-förmigen Aufrufe des Kernels und macht daraus Operationen find, aggregate, Insert, Upsert und Delete auf Collections, die wie die Tabellen des Kernels heißen (ezcontentobject, ezcontentobject_tree und so weiter). Sein Schema-Handler ist expMongoSchema (settings/dbschema.ini, Typ mongo). eZDB::instance()->databaseName() gibt mongo zurück.

Bekannte Grenzen #

• Handgeschriebenes SQL, das der Adapter nicht übersetzen kann, liefert ein leeres Ergebnis und protokolliert eine Warnung. Erweiterungen mit eigenem SQL können einen MongoDB-Weg brauchen. Ein leeres Ergebnis ist keine Antwort: Code, der mit eigenem SQL über Zugriffe entscheidet, muss es als „nein“ lesen, nie als „nichts schränkt das ein“. Prüfen Sie das Protokoll auf nicht übersetztes SQL, bevor eine Site in Produktion geht.
• Die tiefe Neuerzeugung von URL-Aliasen nach dem Verschieben von Teilbäumen ist unvollständig.
• Listenseiten für Rollen und Richtlinien können leer sein, obwohl Berechtigungen durchgesetzt werden.
• Einige Cronjobs sind nicht portiert.
• eztags ist nicht verwendbar.
• Der Shop-Checkout und die Planung von ezflow sind nicht durchgängig getestet.
• Der SQL-Abfrage-Cache gilt nicht.
• Es gibt keine SQL-Update-Dateien.
• Fehler: errorNumber() meldet die Codes von MongoDB (11000 für einen doppelten Schlüssel); der Treiber antwortet mit false und wirft nichts (Fehlercodes und Meldungen der Datenbank).

Testen Sie jede Erweiterung und jeden Workflow, den Ihre Website verwendet, auf einer Staging-Kopie, bevor Sie live gehen.

Unübersetztes SQL finden #

Durchsuchen Sie die Logs nach der Markierung, die der Adapter schreibt:

grep -rn "MONGO TODO" var/log/ | tail -20

Jeder Treffer nennt eine Anweisung, die statt Daten ein leeres Ergebnis geliefert hat. Eine Seite, die "nichts gefunden" zeigt, wo andere Engines Inhalte zeigen, hat meist hier einen Treffer. Melden Sie Kernel-Anweisungen im Software-Tracker; korrigieren Sie das SQL Ihrer eigenen Erweiterungen (SQL von Erweiterungen für jede Engine prüfen).

Upgrades ohne SQL-Dateien #

MongoDB hat kein Verzeichnis update/database/. Was es ersetzt:

• Setup > Upgrade-Prüfung, "Überprüfe Datenbankkonsistenz", vergleicht Collections statt Tabellen: fehlende Collections nach Funktion gruppiert, Collections, die nicht im Schema stehen, und die mongosh-Befehle, die die fehlenden anlegen (Die Upgrade-Prüfung).
• php update/common/scripts/6.0/createaudittables.php legt die Audit-Index-Collections von 6.0.15 über den Schema-Handler an (zuerst --dry-run).
• Die Papierkorb-Dokumente erhalten beim Schreiben trashed_by und trashed_via; ältere werden mit ihren Standards gelesen, movetrashrecords.php läuft also wie auf den anderen Engines.
• Führen Sie bin/mongodb/create_indexes.js nach einem Upgrade erneut aus.

Siehe 11.3 Die Update-Dateien.

Sicherungen #

mongodump --uri="mongodb://exponential@localhost:27017/exponential" --out=/backup/$(date +%F)
mongorestore --uri="mongodb://exponential@localhost:27017/exponential" --drop /backup/2026-10-05

Die Werkzeuge fragen nach dem Passwort, wenn die URI keines enthält. Replica Sets, Oplog-basierte Sicherungen zu einem Zeitpunkt und Snapshots sind eigene Funktionen von MongoDB und funktionieren wie mit jedem Client. Sichern Sie var/storage und settings/override zusammen mit der Datenbank (Sicherungen je Engine).

Eine MySQL-Website nach MongoDB umziehen #

Die Skripte in bin/mongodb/ ziehen eine bestehende MySQL-Website um:

Das Verfahren ist Abschnitt 18 der Portierungsreferenz. Planen Sie ein Wartungsfenster ein, legen Sie danach die Indizes an und führen Sie die Cronjobs aus (Eine Website auf eine andere Engine umziehen).

Leistung #

Die Leistung folgt der Zahl der Anweisungen je Seite, weil jeder Kernel-Aufruf zu einer oder mehreren MongoDB-Operationen wird. Die Indizes aus create_indexes.js sind der erste Hebel; die Caches vor der Datenbank der zweite (Leistung und Skalierung).

Checkliste #

• To do: Jede Erweiterung und jeder Workflow auf Staging getestet; kein MONGO TODO in den Logs nach einem vollständigen Durchklicken.
• To do: eztags, Shop-Checkout und ezflow nicht gebraucht oder getestet.
• To do: Indizes nach der Installation und nach jedem Upgrade angelegt.
• To do: Upgrade-Prüfung nach jedem Upgrade ausgeführt; fehlende Collections angelegt.
• To do: Sicherungen mit mongodump eingeplant und eine Wiederherstellung getestet.

Verwandte Seiten #

• MongoDB einrichten
• Eine Engine wählen
• MongoDB für Hoster
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.