14
Warum wir die Datenbank gewechselt haben - wieder einmal
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667691
Url: https://administrator.de/contentid/667691
Ausgedruckt am: 21.11.2024 um 12:11 Uhr
14 Kommentare
Neuester Kommentar
Danke, Frank, für deine/eure unermüdliche Arbeit an dieser Seite. Ohne diese Seite wären wir wohl alle irgendwo im Web verstreut und hätten keine gemeinsame "Spielwiese".
Die Arbeit die hier leistet, können wir gar nicht wieder gut machen.
Danke!
Die Arbeit die hier leistet, können wir gar nicht wieder gut machen.
Danke!
9
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.
2
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
1
Den Performance-Gewinn spürt man sehr, vielen Dank!
1
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.
2
Und ich dachte, Bananen, das ischt, was man haben muß..
lks
PS: Wer's nicht kennt: https://youtu.be/nuN8FubxgiM
1
Sehr interessant, vor allem dein Enthusiasmus für Datenbankwechsel. 
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
- ....
1
Zitat von @ukulele-7:
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?
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?
Ja ich betreibe damit einzig die Webseite. Die Suche in der Jobbörse läuft per Distanzberechnung. PLZ auswählen und eine Umkreissuche starten. Dafür brauchen wir das GIS-System
Gruß
Frank
1
@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
1Zitat von @HansDampf06:
Die vordefinierten Felder bei PostgreSQL sind bestimmt das Äquivalent der Computed Columns bei MS SQL-Server, oder?
Die vordefinierten Felder bei PostgreSQL sind bestimmt das Äquivalent der Computed Columns bei MS SQL-Server, oder?
Nein, viel einfacher, ich meinte die Tabellendefinition
Bei ArangoDB schreibt man einfach Arrays (json) in die Tabelle (Collection) ganz ohne irgendeine Tabellendefinition, ganz ohne ein Schema. Am Anfang ist das praktisch, mit der Zeit machst du hier und da aber kleine Änderung etc. Wenn du das nicht gut dokumentierst, kann es schnell passieren, dass du Felder in deinem Array vergisst. Das ist der große Nachteil von NoSQL Datenbanken. Man muss immer genau nachschauen, ob das Feld existiert oder nicht. Es werden nur die Felder im Array angezeigt, die auch einen Inhalt haben. Felder mit "null" sind zwar möglich, werden aber standardmäßig beim Update gelöscht (das Verhalten kann auch abgeschaltet werden).
Dieses zustandslose Design von NoSQL-Datenbanken kann ein Fluch oder Segen sein. Bei der Migration musste ich sehr oft die Tabellendefinition aktualisieren, weil ich wieder irgendein Feld vergessen hatte. Was ich also aus den letzten 4 Jahren mit ArangoDB gelernt habe ist: Als Webentwickler -> Finger weg von NoSQL Datenbanken.
Das ist ein gut gemeinter Rat und nur meine persönliche Meinung.
Gruß
Frank
@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
1Zitat von @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.
@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.
Richtig
Ich denke, das haben die Entwickler irgendwann auch gemerkt, also haben sie eine Art JSON-Schema Validierung nachträglich hinzugefügt, wo man mit einer bestimmten Syntax die Felder validieren konnte. Die DB war aber nicht in der Lage aus der vorhandenen Collection (Tabelle) automatisch ein Schema zu erstellen. Was dann bedeutet, dass man im Nachhinein alles von Hand erstellen musste. Sehr suboptimal. Außerdem hat ArangoDB keine Trigger. Das ist ein echter Nachteil. Eigene Funktionen konnten nur in JavaScript erstellt werden, nicht in AQL. So musste man immer hin und her wechseln.Ich kann mir gut vorstellen, dass ein Ansatz wie bei ArangoDB dann einen Sinn macht ..
Ich denke, dass man zum Beispiel mit ArangoDB schnelle Analysen von vielen Datenquellen erstellen kann, weil man sich nicht um die Struktur der Felder kümmern muss. Einlesen, auswerten und weiter. Ansonsten fällt mir im Moment kein großer sinnvoller Einsatz von NoSQL Datenbanken ein. Aber da gibt es sicher andere Anwender mit anderen Meinungen.
Gruß
Frank
Hier eine schöne Grafik, die zeigt, dass ArangoDB in der Cloud mit der RocksDB Engine nicht wirklich gut funktioniert (Disk IO). Das gilt übrigens für alle Datenbanken, die RocksDB als Engine verwenden - und das sind nicht wenige.
In einer reinen SSD-Umgebung ohne NAS-Systeme funktioniert RocksDB ganz gut. Sobald aber Netzwerkspeicher oder ähnliches ins Spiel kommen, verliert man enorm an Performance und Ressourcen.
Generell verbraucht ArangoDB zu viel Arbeitsspeicher, vor allem wenn man die Performance von PostgreSQL nach der Umstellung betrachtet. PostgreSQL ist deutlich schneller mit weniger Speicher als ArangoDB. Derzeit sind es 16 bis 20 GB bei der PostgreSQL. In der Grafik wird auch Redis als Cache-DB mit eingerechnet.
Die Umstellung war am 27.08.2024
Gruß
Frank
In einer reinen SSD-Umgebung ohne NAS-Systeme funktioniert RocksDB ganz gut. Sobald aber Netzwerkspeicher oder ähnliches ins Spiel kommen, verliert man enorm an Performance und Ressourcen.
Generell verbraucht ArangoDB zu viel Arbeitsspeicher, vor allem wenn man die Performance von PostgreSQL nach der Umstellung betrachtet. PostgreSQL ist deutlich schneller mit weniger Speicher als ArangoDB. Derzeit sind es 16 bis 20 GB bei der PostgreSQL. In der Grafik wird auch Redis als Cache-DB mit eingerechnet.
Die Umstellung war am 27.08.2024
Gruß
Frank
2
Immer schön, wenn eine Umstellung nicht nur geklappt hat, sondern sich auch rentiert.
