Große Datenbank

    Hi,



    ich bin Quereinsteiger mit IT-Ausbildung und normalerweise auf embedded Systems und SPSen unterwegs – daher bitte ich um Nachsicht.

    Aktuell entwickele ich eine firmeninterne Anwendung auf LAMP Basis. Ubuntu 22.04, Apache 2, MariaDB und PHP auf einem NetCup V-Server. Ich erwarte bei dieser Anwendung keine große Anzahl von DB-Transaktionen, allerdings eine größere Menge Daten, welche in derselben DB gespeichert werden sollen. Der leistungsfähigste VServer, den ich hier gefunden habe, bietet 2TB SSD – grob überschlagen könnte das nach 2 Jahren Betrieb eng werden.

    Ist es mit MariaDB möglich, dieselbe DB auf mehreren Servern zu verteilen um so eine Skalierbarkeit zu erreichen? Wonach muss ich suchen? Welche alternativen Möglichkeiten gibt es? Davon ab, wie machen es die Profis?

    Vielen Dank und viele Grüße

    Küne

    Hallo,


    ev noch einmal ein Schritt zurück: kannst du uns einen Einblick geben was mit der Anwendung erreicht werden soll und was für eine Art an Daten anfallen bevor der Stack festgelegt wird?


    Da du aus der embedded bzw. PLC Welt kommst denke ich sofort an Time-Series-Daten.
    Vielleicht liege ich mit der Annahme aber auch daneben 😀

    MariaDB kann das, glaube ich, nur mit MaxScale. Vielleicht wärest du besser beraten ein anderes Datenbankbackend zu benutzen, das Sharding von Haus aus unterstützt. Was genau sind denn deine Anforderungen an Datendurchsatz, Parallelität, Schreib-/Leseverhältnis?

    Zitat von kuene

    Davon ab, wie machen es die Profis?

    Abhängig von den Daten werden NoSQL Datenbanken (z.B. MongoDB, Cassandra), Data-Warehouses und Objectstorage (S3, minio, ceph) verwendet.



    Zitat von kuene

    Ist es mit MariaDB möglich, dieselbe DB auf mehreren Servern zu verteilen um so eine Skalierbarkeit zu erreichen? Wonach muss ich suchen? Welche alternativen Möglichkeiten gibt es?

    Meistens wird eine Skalierung mit Sharding und Clustering erreicht - nur nicht immer mit MariaDB, sondern auch mit anderen DBMS.


    Prüfe zunächst, ob die Daten, die du speichert, wirklich für MariaDB geeignet sind, oder ob es elegantere Möglichkeiten gibt.

    Hi und vielen Dank für die Antworten,



    Zitat von Patrick0815

    Hallo,


    ev noch einmal ein Schritt zurück: kannst du uns einen Einblick geben was mit der Anwendung erreicht werden soll und was für eine Art an Daten anfallen bevor der Stack festgelegt wird?

    Die Nutzer der Anwendung erfassen Datensätze. Diese Datensätze haben Eigenschaften (Text oder Zahlen), die ebenfalls durch Benutzer gepflegt werden. Dazu gehören auch Bilder (JPEG/PNG) und PDF Dateien asl Belege, welche base64 kodiert in der DB gespeichert werden sollen. Das Ziel ist letztendlich aus den eingegebenen Daten Statistiken zu bilden, Reports zu erstellen und Trends abzuleiten.


    Zitat von Loxley

    MariaDB kann das, glaube ich, nur mit MaxScale. Vielleicht wärest du besser beraten ein anderes Datenbankbackend zu benutzen, das Sharding von Haus aus unterstützt. Was genau sind denn deine Anforderungen an Datendurchsatz, Parallelität, Schreib-/Leseverhältnis?

    Ich habe MariaDB gewählt, weil die Community groß zu sein scheint und es bisher das einzige DB-System ist, mit dem ich mich befasst habe. Insofern bin ich offen für andere Vorschläge. Der Durchsatz und die Parallelität werden gering sein. Es wird max. 20 User geben, die voraussichtlich <5 Datensätze täglich anlegen. Das Schreib-Leseverhältnis kann ich nicht schätzen.



    Für weitere Vorschläge wäre ich Dankbar!


    LG

    Küne

    Zitat von kuene

    Dazu gehören auch Bilder (JPEG/PNG) und PDF Dateien asl Belege, welche base64 kodiert in der DB gespeichert werden sollen.

    Wie wäre es stattdessen einfach nur Links in den Feldern zu speichern. Somit könntest du die Daten auch relativ einfach auf mehrere Server verteilen.

    Zitat von nitram

    Wie wäre es stattdessen einfach nur Links in den Feldern zu speichern. Somit könntest du die Daten auch relativ einfach auf mehrere Server verteilen.

    Wäre ebenfalls mein Vorschlag. Am "günstigsten" / einfachsten könntest du z.B. ein Auto-Skalierbaren S3 Bucket nutzen und in der DB dann nur die Links (bzw. Filenames, könntest ja z.B. einfach die Hashes der Dateien berechnen) dahin speichern. Jenachdem welchen Anbieter / welches Produkt du nutzen möchtest, sind dann auch Replikationen / Backups inkl.


    Die Frage ist: wie häufig / intensiv musst du denn auf Dokumente / Bilder zugreifen? Also brauchst du für deine Statistik hauptsächlich die Meta-Daten oder auch die Inhalte? Ggf kannst du ja dann auch nur den Text (bei Scans z.B. mittels OCR) in die DB schreiben. Binär-Daten in einer Datenbank zu speichern macht eigentlich nur in wenigen Ausnahmen Sinn..

    Zitat von kuene

    Dazu gehören auch Bilder (JPEG/PNG) und PDF Dateien asl Belege, welche base64 kodiert in der DB gespeichert werden sollen.

    Base64 macht Dateien um Faktor 1,3 größer. Du hast auch die Möglichkeit Binärdateien direkt als BLOB (Binary Large Object) zu speichern, das erhöht die Dateigröße nicht.


    Außerdem kannst du die Dateien im Dateisystem speichern und z.B. per NFS weiteren Storage anbinden - in der DB speicherst du dann nur noch den Pfad und ggf. eine Prüfsumme der Datei.

    netcup.de - Storagespace für vServer / Root-Server
    Webhosting, Server, Domains, Managementdienste, einfach alles fuer einen erfolgreichen Internetauftritt
    www.netcup.de


    Alternativ Dateien in einem Objectstore speichern.

    Bilder gehören nicht in eine relationale DB. Nimm S3 oder mongoDB community. Ich betreue eine ähnliche Konstellation. Die SQL DB ist 40GB groß, aber die paar Millionen Bilder nehmen viele TB ein auf mongoDB. Mongo kann sharding und Replikation. Ab einer gewissen Datenmenge ist die mongo community edition auf einem dedizierten Server preislich günstiger. Nimm aber nicht die netcup Storage Server. Der Prozessor ist so alt, daß Du keine neuere mongo-Version laufen lassen kannst. Ich habe dafür was beim roten H genommen. Hat auch für den gleichen Preis wesentlich mehr TB und RAM sowie einen moderneren Prozessor.

    Bei mongodb beachten dass hier eine kommerzielle Verwendung ohne Kauf Lizenz nicht gestattet ist. Nutzung der mongodb Community edition im kommerziellen Bereich sorgt dafür daß du deinen kompletten Code von allen Komponenten die da miteinander kommunizieren offen legen musst.


    (Ist quatsch, siehe weiter unten)

    Zitat von perryflynn

    Nutzung der mongodb Community edition im kommerziellen Bereich sorgt dafür daß du deinen kompletten Code von allen Komponenten die da miteinander kommunizieren offen legen musst.

    Das stimmt nicht? Nur bei einem DB as a service modell muss entsprechendes offengelegt werden.

    Wenn dein Dienst einfach nur die DB verwendet, ist keine Offenlegung notwendig, denke ich.

    perryflynn https://www.mongodb.com/licens…r-side-public-license/faq


    Diff ist hauptsächlich

    Code
    a. “If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version.”

    wobei "Programm" als MongoDB selbst definiert ist. Die Treiber sind weiterhin unter AGPL lizensiert - damit wird nur ein DBaaS angegriffen, nicht die Verwendung der DB selbst.

    Ich denke, wenn Du Blobs außerhalb der DB ablegst (S3-kompatibel z.B.) wirst Du mit einer ganz normalen Maria-DB-Instanz auskommen. Für den Anwendungszweck wäre auch eine Dokumentenbasierte DB (einfacher erweiterbar) geeignet, aber wenn Du MariaDB kennst, dann ist das der richtige Weg.


    Die Informationen zur Mongo-DB-Lizensierung hier im Thread solltest Du überprüfen bevor Du sie glaubst, ich habe gegenlautende:

    * https://www.mongodb.com/legal/licensing/community-edition

    * https://www.mongodb.com/licens…r-side-public-license/faq

    * https://www.mongodb.com/licensing/server-side-public-license

    Nachdem ich schon mal mit einem Request Tracker in der Größen Ordnung +2TB gespielt habe, kann ich nur versuchen dich davon abzuhalten, denn das Ende vom Lied war das man Regelmäßig per Skript, das vom RT Mitgeliefert wurde, die Anhänge auf nen NFS Share weggeschoben hat.


    Die Antwort lautet auf jeden Fall nicht Relationale Datenbank. Die sind in sich per Design ein SPoF den du nur mit deiner Applikation sinnvoll lösen kannst. Ja man kann ein Galera Cluster betreiben und ich kann dir sagen das dieses RT von dem ich da oben spreche, vorher auf einem Galera lief und am Ende auf ein Master-Slave Blech setup migriert wurde, weil es absolut scheisse skaliert. Galera schickt erst dann ein ack für deinen write wenn alle ihn geschieben habe. Backups mit Galera in der Größen Ordnung kannst du praktisch komplett vergessen. MySQL/MariaDB hingegen gehen noch mit mysqldump.


    Ich würde dir für solche Datenmengen ehrlich gesagt alles andere als PHP mit MySQL als Stack empfehlen, weil das einfach schon per se zum scheitern verurteilt ist. Als Beispiel finde ich das Nextcloud es schon fantastisch zeigt wie man es einfach nicht machen sollte, aber die haben noch mehr Probleme als nur ihr Stack.


    MongoDB kann man auch kostengünstig gegen /dev/null ersetzen.


    Wenn dir ein verteiltes System wichtig ist das skalieren kann, kann man über Cassandradb durchaus nachdenken. Es ist zumindest eine Lösung die gewisse Probleme im Datenbankbereich in der Frage Verteilung/Skalierung gut löst.


    Wie man merkt habe ich eine Abneigung gegen PHP und MySQL und das leider irgendwie mit Erfahrungswerten.


    Ich bin ein großer Fan von C# geworden nachdem die viel richtig machen. PostgreSQL wäre im Relationalen Bereich mittlerweile mein Standard nachdem die viele nette Erweiterungen bieten wie z.B. TimeScaleDB und richtig top durch optimiert werden können. Fang am Besten mal mit einer SQLite an und schau wie weit du kommst.


    Wenn ich mir einen Traum Stack bauen könnte der so einiges kann, würde ich auf C#/Elixir/Rust mit Kafka und CassandraDB setzen um wirklich alles abzudecken was mir nur passieren kann in Frage Skalierung/Verteilung/Integrität.

    Ich will aber auch sagen das wir hier nicht von einem Stack reden der Mal eben gebaut wird. Dafür sollte man wirklich ernsthafte Programmierung Erfahrung haben damit das Design von Grund auf zumindest solide ist. Perfekt wird sowas sowie so nie, aber man kann sich schon gut den Weg zum soliden Zustand verbauen.

    Zitat von Skulduggery

    Nachdem ich schon mal mit einem Request Tracker in der Größen Ordnung +2TB gespielt habe, kann ich nur versuchen dich davon abzuhalten, denn das Ende vom Lied war das man Regelmäßig per Skript, das vom RT Mitgeliefert wurde, die Anhänge auf nen NFS Share weggeschoben hat.


    Die Antwort lautet auf jeden Fall nicht Relationale Datenbank. Die sind in sich per Design ein SPoF den du nur mit deiner Applikation sinnvoll lösen kannst. Ja man kann ein Galera Cluster betreiben und ich kann dir sagen das dieses RT von dem ich da oben spreche, vorher auf einem Galera lief und am Ende auf ein Master-Slave Blech setup migriert wurde, weil es absolut scheisse skaliert. Galera schickt erst dann ein ack für deinen write wenn alle ihn geschieben habe. Backups mit Galera in der Größen Ordnung kannst du praktisch komplett vergessen. MySQL/MariaDB hingegen gehen noch mit mysqldump.


    Ich würde dir für solche Datenmengen ehrlich gesagt alles andere als PHP mit MySQL als Stack empfehlen, weil das einfach schon per se zum scheitern verurteilt ist. Als Beispiel finde ich das Nextcloud es schon fantastisch zeigt wie man es einfach nicht machen sollte, aber die haben noch mehr Probleme als nur ihr Stack.

    Sehr sehr viel Meinung.


    Zitat von Skulduggery

    MongoDB kann man auch kostengünstig gegen /dev/null ersetzen.

    MongoDB ist perfekt fürs Clustering und Sharding mit mehreren Szenarios. (Hash, Hot / Cold, Geografisch).

    Die Treiber haben bereits einen Read / Write Split integriert.


    Klar, dass was bei MongoDB durch die Treiber abgedeckt wird, machen bei Cassandra die Server - aber MongoDB ist meine goto Datenbank und hat mir noch nie einen Datenverlust beschert. Evtl. hast du das Manuel nicht gelesen oder suchst zwecks CAP-Theorem nach dem falschen Tool, aber der Vergleich mit /dev/null? Wie kommt der zu stande?


    Nebst komplett andere CAP Architektur und NoSQL Architektur ist MongoDB im Ranking deutlich vor Cassandra: https://db-engines.com/de/ranking


    Zitat von Skulduggery

    Fang am Besten mal mit einer SQLite an und schau wie weit du kommst.

    Nein, keine gute Idee.



    Zitat von Skulduggery

    Wenn ich mir einen Traum Stack bauen könnte der so einiges kann, würde ich auf C# mit Kafka und CassandraDB setzen um wirklich alles abzudecken was mir nur passieren kann in Frage Skalierung/Verteilung/Integrität.

    Warum braucht man da jetzt einen Message Broker? Es geht hier um eine Datenbank und nicht um einen Crashkurs in Micro-Service Architektur.

    Mag sein das für dich MongoDB eine GoTo Sache ist, für mich ist es einfach nichts und gemessen an den Applikationen die ich mit MonogDB schon getestet oder teilweise betrieben habe, will ich es einfach nicht haben. Das ist nix ganzes und nix halbes.


    Zitat von H6G

    Nein, keine gute Idee.

    Warum soll den eine SQLite keine gute Idee sein? Meiner Meinung nach muss man nicht alles direkt auf eine Full Feature RDMS schmeissen ohne zu wissen ob es überhaupt ein Problem mit kleineren feineren Implemenationen gegeben hätte. Gerade diese Full Feature RDMS und NoSQL Technologien fügen plötzlich ein Komplexitäts Layer hinzu das es vielleicht garnicht gebraucht hätte. Einfach bauen und schauen wann sich wirklich Probleme ergeben und dann diese entsprechend lösen. Von Theorien über Probleme behindert man sich mehr beim Coden als einfach zu machen und dann die realen Probleme zu lösen.


    Aber wir hatten ja schon das Thema mit:

    Zitat von H6G

    Sehr sehr viel Meinung.


    Zitat von H6G

    Warum braucht man da jetzt einen Message Broker? Es geht hier um eine Datenbank und nicht um einen Crashkurs in Micro-Service Architektur.

    Naja du scheinst ja auch voreingenommen zu sein von dem her lass ich das auch mal so stehen. Ich hab meine Meinung zu PHP/MySQL Stacks und du hast deine Meinung zu Architekturen die einem das Leben unter Umständen einfacher machen.

    Du könntest auch einfach dein Datenbank-Layer / Klasse abstrahieren oder eine ORM Library benutzen und dann diverse Backends ausprobieren.

    Meinung:

    Ich bin z.B. ein Fan von https://gorm.io/ und Go als Backend. Da muss man sich aber natürlich auch erstmal in die Sprache einlernen.

    Ist aber auch recht "ähnlich wie C und Konsorten". Die Dateien würde ich aber auch mit MongoDB nicht in die DB schreiben.

    Zitat von Skulduggery

    Meiner Meinung nach muss man nicht alles direkt auf eine Full Feature RDMS schmeissen ohne zu wissen ob es überhaupt ein Problem mit kleineren feineren Implemenationen gegeben hätte.

    Eigentlich sollte es mit SQL 92 / 99 keinen Unterschied machen, die einzelnen DBMS Implementationen unterscheiden sich jedoch im Syntax.

    SQLite ist hauptsächlich für Apps mit eingebetteter interner Datenbank - für Backend Systeme skaliert SQLite nicht gut und die Migration braucht Code-Anpassungen, je nach ORM.


    Zitat von Skulduggery

    NoSQL Technologien fügen plötzlich ein Komplexitäts Layer hinzu das es vielleicht garnicht gebraucht hätte.

    Daten nicht mehr normalisieren zu müssen nimmt für mich einiges an Komplexität raus.



    Zitat von Skulduggery

    du hast deine Meinung zu Architekturen die einem das Leben unter Umständen einfacher machen.

    Ich benutze selber µService Architekturen - OP würde trotzdem gerne Dateien in eine DB speichern, ob es da sinnvoll ist auf µServices hinzuweisen, zumal angegeben war, dass nur ein Server existiert.


    Erstmal das Problem mit der Datenspeicherung lösen, und dann kann man sich über Architekturen und Sprachen Gedanken machen.