Wofür wir MariaDB einsetzen
MariaDB läuft unter jedem System, das wir betreuen. Shopware 6 legt darin Artikel, Preise, Kunden und Bestellungen ab, TYPO3 seine Seitenbäume und Inhalte, WordPress seine Beiträge. Dazu kommen eigene Anwendungen auf PHP 8 und Symfony, bei denen wir das Schema selbst entwerfen — Fachlichkeit zuerst, danach die Tabellen. Wer ein Datenmodell nachträglich geraderücken muss, zahlt das über Jahre in Migrationen.
Ein zweiter großer Teil der Arbeit sind gewachsene Bestände aus Altsystemen. Tabellen ohne Fremdschlüssel, Zeichensatzmischungen aus latin1 und utf8, Spalten, deren Bedeutung niemand mehr kennt. Wir übernehmen solche Daten in ein sauberes Modell, stellen durchgängig auf utf8mb4 um und dokumentieren, was wir dabei entscheiden. Das ist unspektakuläre Arbeit. Sie entscheidet aber darüber, ob eine Migration später ein Termin oder ein Projekt ist.
Wie wir damit arbeiten: messen, dann handeln
Bevor jemand über größere Hardware spricht, schalten wir das Slow Query Log ein und sehen nach, welche Abfragen tatsächlich Zeit kosten. Danach kommt EXPLAIN: Liest die Datenbank die halbe Tabelle, weil ein Index fehlt oder weil die Bedingung so formuliert ist, dass er nicht greift? Meistens ist es das. Ein zusammengesetzter Index an der richtigen Stelle ersetzt mehr Serverleistung, als ein Angebot vermuten lässt.
Schemaänderungen laufen bei Symfony-Anwendungen über Doctrine-Migrationen, versioniert und auf einer Kopie geprobt, bevor sie produktiv laufen. Backups gehören zum Managed Hosting auf unseren Servern in Deutschland — und zwar mit Wiederherstellungstest. Ein Backup, das nie zurückgespielt wurde, ist eine Vermutung. Wir überwachen außerdem Verbindungen, Puffergrößen und Plattenplatz, weil eine volle Platte eine Datenbank schneller anhält als jede Lastspitze.
Wann Sie kein Datenbankprojekt brauchen
Nicht jede langsame Seite ist ein Datenbankfall. Wenn ein Shop bei zwei Bestellungen am Tag träge wirkt, liegt es häufiger an unkomprimierten Bildern, an einem überladenen Frontend oder an einer Schnittstelle, die synchron auf ein ERP wartet. Wir messen das erst, bevor wir ein Angebot für Datenbankarbeit schreiben. Manchmal ist die ehrliche Antwort: Hier ist nichts zu optimieren, das Problem sitzt woanders.
Genauso selten brauchen mittelgroße Projekte einen Datenbank-Cluster, eine zweite Datenbanktechnologie daneben oder eine Aufteilung über mehrere Server. Eine gut entworfene MariaDB-Instanz trägt normale Shop- und Portallasten ohne Verrenkungen. Wer stattdessen Replikation, Sharding und einen zusätzlichen Speicher einführt, kauft sich Betriebsaufwand ein, den jemand dauerhaft tragen muss. Das kann richtig sein. Es sollte nur eine Entscheidung sein und kein Reflex.