Warum wir die Datenbank gewechselt haben - wieder einmal
![Warum wir die Datenbank gewechselt haben - wieder einmal article-picture](/images/c/2024/08/27/64135665665_article.jpg)
Liebe Nutzerinnen und Nutzer,
ich hatte ja versprochen, noch etwas zum Datenbankwechsel zu schreiben. Hier eine kleine Historie dazu:
05/1999 bis 01/2021 MySQL 4 bis 8 (auch MariaDB war für einige Monate online)
01/2021 - Beginn der Umstellung auf ArangoDB
05/2022 - ArangoDB-Migration abgeschlossen
04/2024 - Beginn der PostgreSQL-Migration
08/2024 - PostgreSQL Migration beendet
Bereits 2012 wollten wir auf PostgreSQL umsteigen, aber leider war sie damals in ersten Tests nicht schneller als MySQL und so habe ich den Plan verworfen. Stattdessen habe ich MariaDB ausprobiert und sie war ein paar Monate online. Leider brauchte ich dann für die Entfernungsberechnung der Jobbörse ein GEO-System. Das konnte die damalige MariaDB leider nicht. Also bin ich wieder auf MySQL umgestiegen.
Das Problem von MySQL war eine magische Grenze von 400 bis 500 Verbindungen gleichzeitig, die ich auch mit größerer Hardware nicht überwinden konnte. Selbst ein neuer und teurer 32-Core XEON Server mit 64 GB RAM konnte da nicht helfen.
Das war auch der Grund, warum ich weiter gesucht habe und schließlich bei ArangoDB gelandet bin. Diese Datenbank schaffte locker 5000 Verbindungen gleichzeitig. Aber auch hier gab es einen Haken, den ich erst zu spät entdeckte, als die Migration gerade abgeschlossen war. Das hatte ich wohl übersehen.
Die DBEngine von ArangoDB basiert auf RocksDB und diese ist für SSDs optimiert. Solange ich meine eigene Hardware im Rechenzentrum hatte, war das kein Problem. Aber ich wollte und habe dann auf eine Cloud-Umgebung umgestellt. In einer Cloud-Umgebung ist das SSD-Problem aber sehr schnell spürbar. Ich habe das Problem dann mit RAM gelöst. Aktuell sind das fast 200 GB RAM und eine sehr hohe Auslastung von 22 CPU-Kernen.
Ein weiterer Grund für den unfreiwilligen Umstieg auf PostgreSQL war die Tatsache, dass die Firma ArangoDB schon vor Monaten beschlossen hatte, den PHP-Support einzustellen. Sie haben sich leider nicht davon überzeugen lassen, dass PHP immer noch eine der wichtigsten Programmiersprachen im Internet ist. Sie bevorzugen stattdessen GO, das im Ranking der Programmiersprachen deutlich weiter hinten liegt. Aber Go ist wohl gerade in.
Wie auch immer, da PHP offiziell nicht mehr unterstützt wird und der Ressourcenhunger von ArangoDB mittlerweile gigantisch geworden ist, macht die Verwendung von ArangoDB nicht mehr viel Sinn.
Hinzu kommt, dass der vorhandene PHP-Treiber schon seit einiger Zeit intern Fehler meldet, da er noch nicht an PHP 8 angepasst wurde. Diese Fehler haben mittlerweile zu Problemen und auch zu Fehlverhalten geführt.
Diesmal habe ich "nur" 4 Monate für die Migration gebraucht. Das war deutlich schneller als die 1,5 Jahre für ArangoDB.
Ich hatte mir auch andere Systeme angeschaut, aber nichts Vergleichbares und vor allem Günstiges gefunden. Jedes System hatte Vor- und Nachteile.
Die PostgreSQL-Engine ist jetzt doppelt so schnell, hat eine gute Volltextsuche, ein schnelles GIS-System, gute Extensions und einen vernünftigen SQL-Dialekt.
Ich sehe jetzt schon, dass es sich gelohnt hat:
Im Moment bin ich auf jeden Fall zufrieden. Die gemeldeten Fehler halten sich in Grenzen. Die ersten Anzeichen deuten darauf hin, dass sich dies sehr positiv auf unsere Website auswirkt.
❤️
Gruß
Frank
ich hatte ja versprochen, noch etwas zum Datenbankwechsel zu schreiben. Hier eine kleine Historie dazu:
05/1999 bis 01/2021 MySQL 4 bis 8 (auch MariaDB war für einige Monate online)
01/2021 - Beginn der Umstellung auf ArangoDB
05/2022 - ArangoDB-Migration abgeschlossen
04/2024 - Beginn der PostgreSQL-Migration
08/2024 - PostgreSQL Migration beendet
Bereits 2012 wollten wir auf PostgreSQL umsteigen, aber leider war sie damals in ersten Tests nicht schneller als MySQL und so habe ich den Plan verworfen. Stattdessen habe ich MariaDB ausprobiert und sie war ein paar Monate online. Leider brauchte ich dann für die Entfernungsberechnung der Jobbörse ein GEO-System. Das konnte die damalige MariaDB leider nicht. Also bin ich wieder auf MySQL umgestiegen.
Das Problem von MySQL war eine magische Grenze von 400 bis 500 Verbindungen gleichzeitig, die ich auch mit größerer Hardware nicht überwinden konnte. Selbst ein neuer und teurer 32-Core XEON Server mit 64 GB RAM konnte da nicht helfen.
Das war auch der Grund, warum ich weiter gesucht habe und schließlich bei ArangoDB gelandet bin. Diese Datenbank schaffte locker 5000 Verbindungen gleichzeitig. Aber auch hier gab es einen Haken, den ich erst zu spät entdeckte, als die Migration gerade abgeschlossen war. Das hatte ich wohl übersehen.
Die DBEngine von ArangoDB basiert auf RocksDB und diese ist für SSDs optimiert. Solange ich meine eigene Hardware im Rechenzentrum hatte, war das kein Problem. Aber ich wollte und habe dann auf eine Cloud-Umgebung umgestellt. In einer Cloud-Umgebung ist das SSD-Problem aber sehr schnell spürbar. Ich habe das Problem dann mit RAM gelöst. Aktuell sind das fast 200 GB RAM und eine sehr hohe Auslastung von 22 CPU-Kernen.
Ein weiterer Grund für den unfreiwilligen Umstieg auf PostgreSQL war die Tatsache, dass die Firma ArangoDB schon vor Monaten beschlossen hatte, den PHP-Support einzustellen. Sie haben sich leider nicht davon überzeugen lassen, dass PHP immer noch eine der wichtigsten Programmiersprachen im Internet ist. Sie bevorzugen stattdessen GO, das im Ranking der Programmiersprachen deutlich weiter hinten liegt. Aber Go ist wohl gerade in.
Wie auch immer, da PHP offiziell nicht mehr unterstützt wird und der Ressourcenhunger von ArangoDB mittlerweile gigantisch geworden ist, macht die Verwendung von ArangoDB nicht mehr viel Sinn.
Hinzu kommt, dass der vorhandene PHP-Treiber schon seit einiger Zeit intern Fehler meldet, da er noch nicht an PHP 8 angepasst wurde. Diese Fehler haben mittlerweile zu Problemen und auch zu Fehlverhalten geführt.
Diesmal habe ich "nur" 4 Monate für die Migration gebraucht. Das war deutlich schneller als die 1,5 Jahre für ArangoDB.
Ich hatte mir auch andere Systeme angeschaut, aber nichts Vergleichbares und vor allem Günstiges gefunden. Jedes System hatte Vor- und Nachteile.
Die PostgreSQL-Engine ist jetzt doppelt so schnell, hat eine gute Volltextsuche, ein schnelles GIS-System, gute Extensions und einen vernünftigen SQL-Dialekt.
Ich sehe jetzt schon, dass es sich gelohnt hat:
- Die Seite ist gefühlt und messbar überall schneller (Steigerung von 30 bis 40%)
- Seiten mit 100 oder 200 Kommentaren sind kein Problem mehr
- Die RAM-Auslastung mit allen Query-Caches etc. liegt bei knapp 16 GB (ArangoDB: 120 bis 180 GB) - und ich habe die RAM-Einstellungen noch nicht einmal großartig optimiert.
- Die CPU-Auslastung liegt bei lächerlichen 10 bis 15% (ArangoDB: 70 bis 80%) - das Top sagt mir einen Load Average über den Tag von 0.78 bis 0.95 !!!
- SQL ist für mich persönlich einfacher und schneller zu verstehen als AQL (die letzten 4 Jahre waren mit AQL kein Vergnügen - mit SQL ist es sooo viel schöner und verständlicher).
- Joins sind wirklich, wirklich schnell mit PostgreSQL
- Die Struktur von ArangoDB sind stateless Json Arrays, einfach zu lesen, aber sehr schwer zu schreiben.
- Die Idee der vordefinierten Felder in SQL funktioniert für uns besser.
Im Moment bin ich auf jeden Fall zufrieden. Die gemeldeten Fehler halten sich in Grenzen. Die ersten Anzeichen deuten darauf hin, dass sich dies sehr positiv auf unsere Website auswirkt.
❤️
Gruß
Frank
Please also mark the comments that contributed to the solution of the article
Content-ID: 667691
Url: https://administrator.de/contentid/667691
Printed on: September 1, 2024 at 00:09 o'clock
15 Comments
Latest comment
Natürlich tolle Arbeit, und vor allem viel tiefer gehend als ich angenommen hätte. Betreibst du auf der Datenbank nur administrator.de und was genau machst du mit GIS?
Ich hoffe für dich, das PostgreSQL sich bewährt. Tut immer gut, wenn man mal durchschnaufen kann und eine Baustelle weniger hat und gut für PGSQL, wenn es sich neue Plattformen erfolgreich erschließt.
Ich hoffe für dich, das PostgreSQL sich bewährt. Tut immer gut, wenn man mal durchschnaufen kann und eine Baustelle weniger hat und gut für PGSQL, wenn es sich neue Plattformen erfolgreich erschließt.
Moin @Frank
für mich sind Datenbanken und Datenbankprogrammierung wie böhmische Dörfer. Da bin ich raus. Um so mehr bin ich dankbar für diese Seite und dass sie um so fluffiger geht.
Danke
Kreuzberger
für mich sind Datenbanken und Datenbankprogrammierung wie böhmische Dörfer. Da bin ich raus. Um so mehr bin ich dankbar für diese Seite und dass sie um so fluffiger geht.
Danke
Kreuzberger
Ich bin da bei @kreuzberger
Datenbanken sind etwas, das man haben muss und das andere machen.
Aber man spürt schon wie fluffiger die Seite läuft.
Wenigstens mal wieder eine Arbeit, von der die User auch was spüren. Im positiven Sinn.
Oft genug macht und tut man und keiner merkts, weils ja auch eigentlich so gedacht war.
Datenbanken sind etwas, das man haben muss und das andere machen.
Aber man spürt schon wie fluffiger die Seite läuft.
Wenigstens mal wieder eine Arbeit, von der die User auch was spüren. Im positiven Sinn.
Oft genug macht und tut man und keiner merkts, weils ja auch eigentlich so gedacht war.
Und ich dachte, Bananen, das ischt, was man haben muß..
lks
PS: Wer's nicht kennt: https://youtu.be/nuN8FubxgiM
Sehr interessant, vor allem dein Enthusiasmus für Datenbankwechsel. ![face-big-smile face-big-smile](/images/icons/fa/light/face-laugh.svg)
Ich habe selbst damit nur am Rande Berührungspunkte, durch die entsprechenden Anwendungen,
aber die Softwarefirmen halten immer brav an ihren einstigen Datenbanken fest.
Da hat bislang nie jemand irgendwie gewechselt.
Somit recht breit gefächert:
Ich habe selbst damit nur am Rande Berührungspunkte, durch die entsprechenden Anwendungen,
aber die Softwarefirmen halten immer brav an ihren einstigen Datenbanken fest.
Da hat bislang nie jemand irgendwie gewechselt.
Somit recht breit gefächert:
- Actian
- MSSQL & -Express
- PostgreSQL
- MariaDB
- MySQL
- FirebirdSQL
- ....
@Frank, @dertowa:
Ich kann aus eigener Erfahrung bestätigen, dass es äußerst hilfreich ist, wenn die SQL-Syntax und das Datenbankkonzept zwischen den verwendeten DBM-Systemen weitgehend identisch ist. Dadurch lassen sich unterschiedliche Datenbanksysteme bei einem parallelen Einsatz wesentlich leichter administrieren. Auch bei der Migration ist das von großem Vorteil, wenngleich die Tücken im Detail stecken. Und wer einmal SQL verstanden hat, dem eröffnen sich viele interessante Möglichkeiten.
Nicht ohne Grund werden in dieser Hinsicht MS SQL-Server, MySQL / MariaDB und PostgreSQL dicht beieinanderliegen.
Die vordefinierten Felder bei PostgreSQL sind bestimmt das Äquivalent der Computed Columns bei MS SQL-Server, oder?
@Lochkartenstanzer:
"Äffle & Pferdle" - immer absolut geil!!! Leider gibt es das offiziell schon länger nicht mehr im südwestdeutschen Landesprogramm. Man kann darauf nur noch auf Youtube & Co. zugreifen, aber immerhin!
Viele Grüße
HansDampf06
Ich kann aus eigener Erfahrung bestätigen, dass es äußerst hilfreich ist, wenn die SQL-Syntax und das Datenbankkonzept zwischen den verwendeten DBM-Systemen weitgehend identisch ist. Dadurch lassen sich unterschiedliche Datenbanksysteme bei einem parallelen Einsatz wesentlich leichter administrieren. Auch bei der Migration ist das von großem Vorteil, wenngleich die Tücken im Detail stecken. Und wer einmal SQL verstanden hat, dem eröffnen sich viele interessante Möglichkeiten.
Nicht ohne Grund werden in dieser Hinsicht MS SQL-Server, MySQL / MariaDB und PostgreSQL dicht beieinanderliegen.
Die vordefinierten Felder bei PostgreSQL sind bestimmt das Äquivalent der Computed Columns bei MS SQL-Server, oder?
@Lochkartenstanzer:
"Äffle & Pferdle" - immer absolut geil!!! Leider gibt es das offiziell schon länger nicht mehr im südwestdeutschen Landesprogramm. Man kann darauf nur noch auf Youtube & Co. zugreifen, aber immerhin!
Viele Grüße
HansDampf06
@Frank:
Das ist ja ein Graus mit NoSQL-Datenbanken der Art von ArangoDB. Denn ich bin der Meinung, dass selbst dann, wenn alles akribisch dokumentiert wird, keiner - auch nicht der geistige Vater einer Tabellenstruktur - nach Jahr und Tag noch alles jederzeit im Kopf hat und bei jedem Schritt und Tritt an die vielen Feinheiten denkt.
Wahrscheinlich macht das Json-Konzept bei ArangoDB nur dann einen Sinn, wenn man um die Tabellenstruktur eine Art Bibliothek mit Zugriffsmodulen legt. Ein Zugriff erfolgt dann ausschließlich über diese Zugriffsmodule und in den Modulen wird rundum sichergestellt, dass alle Definitionselemente sachgerecht berücksichtigt und gesprochen werden. Wahrscheinlich kommt man dann am Ende am selben Punkt an, der den SQL-Datenbanken ähnelt. Denn schließlich ist jedes einzelne Datenbankelement wie Felder einer Tabelle ein Objekt, dass bestimmte Eingeschaften hat und konkrete Methoden der Interaktion zulässt. Gemäß Deiner Beschreibung wird man das bei NoSQL-Datenbanken erst selbst erstellen müssen (z.B. via diese Zugriffsmodule / Bibliothek), während bei SQL-Datenbanken, das eben integraler Bestandteil der Datenbankengine und der DBMS-Struktur ist.
Ich kann mir gut vorstellen, dass ein Ansatz wie bei ArangoDB dann einen Sinn macht, wenn man (1.) ohnehin die weitere Verarbeitung auf Json-Basis oder ähnlich durchführen möchte / muss. Denn dann könnte die Integration der Datenbank in den Anwendungsfall wesentlich effizienter, geradliniger etc. sein - die angedachte Bibliothek könnte somit umfassend auf den Anwendungsfall ausgelegt sein / werden. Denkbar ist aber auch (2.), auf diese Art und Weise eine ganz individuelle Datenbankanwendung erstellen zu können, für die die Standard-DBM-Systeme nicht so gut passen würden. Aber im Falle von Standardanwendungsfällen wie wohl hier erscheint die Nutzung eines Standard-DBM-Systems zielführender, weil ohnehin relativ leicht integrierbar und der Fokus auf das eigentliche Datenmodell und die zugehörigen Abfragen, Funktionen, Prozeduren etc. gelegt werden kann. Dafür muss man nicht unbedingt das "Fahrrrad neu erfinden", wenn ein Standard-DBM-System das bereits gebrauchsfertig liefert.
Ein unschätzbarer Vorteil der Standard-DBM-System könnte auch darin liegen, dass es riesige Communities gibt, die einem relativ schnell Lösungsmöglichkeiten liefern können, mindestens aber Gedankenanstöße für den zu wählenden Lösungsweg.
Viele Grüße
HansDampf06
Das ist ja ein Graus mit NoSQL-Datenbanken der Art von ArangoDB. Denn ich bin der Meinung, dass selbst dann, wenn alles akribisch dokumentiert wird, keiner - auch nicht der geistige Vater einer Tabellenstruktur - nach Jahr und Tag noch alles jederzeit im Kopf hat und bei jedem Schritt und Tritt an die vielen Feinheiten denkt.
Wahrscheinlich macht das Json-Konzept bei ArangoDB nur dann einen Sinn, wenn man um die Tabellenstruktur eine Art Bibliothek mit Zugriffsmodulen legt. Ein Zugriff erfolgt dann ausschließlich über diese Zugriffsmodule und in den Modulen wird rundum sichergestellt, dass alle Definitionselemente sachgerecht berücksichtigt und gesprochen werden. Wahrscheinlich kommt man dann am Ende am selben Punkt an, der den SQL-Datenbanken ähnelt. Denn schließlich ist jedes einzelne Datenbankelement wie Felder einer Tabelle ein Objekt, dass bestimmte Eingeschaften hat und konkrete Methoden der Interaktion zulässt. Gemäß Deiner Beschreibung wird man das bei NoSQL-Datenbanken erst selbst erstellen müssen (z.B. via diese Zugriffsmodule / Bibliothek), während bei SQL-Datenbanken, das eben integraler Bestandteil der Datenbankengine und der DBMS-Struktur ist.
Ich kann mir gut vorstellen, dass ein Ansatz wie bei ArangoDB dann einen Sinn macht, wenn man (1.) ohnehin die weitere Verarbeitung auf Json-Basis oder ähnlich durchführen möchte / muss. Denn dann könnte die Integration der Datenbank in den Anwendungsfall wesentlich effizienter, geradliniger etc. sein - die angedachte Bibliothek könnte somit umfassend auf den Anwendungsfall ausgelegt sein / werden. Denkbar ist aber auch (2.), auf diese Art und Weise eine ganz individuelle Datenbankanwendung erstellen zu können, für die die Standard-DBM-Systeme nicht so gut passen würden. Aber im Falle von Standardanwendungsfällen wie wohl hier erscheint die Nutzung eines Standard-DBM-Systems zielführender, weil ohnehin relativ leicht integrierbar und der Fokus auf das eigentliche Datenmodell und die zugehörigen Abfragen, Funktionen, Prozeduren etc. gelegt werden kann. Dafür muss man nicht unbedingt das "Fahrrrad neu erfinden", wenn ein Standard-DBM-System das bereits gebrauchsfertig liefert.
Ein unschätzbarer Vorteil der Standard-DBM-System könnte auch darin liegen, dass es riesige Communities gibt, die einem relativ schnell Lösungsmöglichkeiten liefern können, mindestens aber Gedankenanstöße für den zu wählenden Lösungsweg.
Viele Grüße
HansDampf06