Verteilte Datenbank auf zentralem Storage?

S

SamanthaCox

Neuer Benutzer
Beiträge
2
Hallo!

Ich habe hier mal eine Frage. Macht es einen Sinn mit "verteilten" DBs zu agieren, wenn ohnehin dann alles auf einem Storage-System liegt.
Momentan ist es so: Es gibt eine große zentrale DB auf die viele Benutzer zugreifen und in die viel geschrieben wird. Die Schreibzugriffe eines Benutzers A sind aber für den Benutzer B eher irrelevant (B führt eher keine Leseoperationen auf die Datensätze von A durch). Beide Benutzer schreiben aber in die selbe Tabelle.
Ich möchte nun in mehrere DBs aufteilen, sodass 1. die einzelnen DBs wesentlich kleiner sind und 2. einzelne DBs auch nur für ein Subset der Benutzer da sind, sodass nicht alle in die selbe DB schreiben. Letzendlich wird aber zur Speicherung trotzdem das vorhandene Storage verwendet werden.

Meine Frage jetzt:
Macht eine Aufteilung unter diesen Vorrausetzungen Sinn?

Gehen wir davon aus, dass die Aufteilung gemacht ist und überlegen, was das für Performance-Vorteile bringen könnte.
(1) Kann bspw. eine Aufteilung in mehrere LUNs am Storage-System (je eins für jede der kleinen DBs) Vorteile bringen, weil das Storage nicht mehr alles in die selbe LUN schreiben muss?
(2) Ist es vielleicht von Vorteil, weil die DBs kleiner sind und Index-Updates dadurch schneller sind?
(3) Ist es möglicherweise auch ein Vorteil, weil die Schreibzugriffe besser parallelisierbar sind (nicht alle auf dieselbe DB). (Bei einer zentralen DB müssen vielleicht öfters Clients warten, weil grad wer anders schreibt)

Oder ist es vielleicht so, dass es eh nix bringt weil:
ad (1) Das Storage System kann das intelligent handeln und auf die Disks verteilen, weswegen eine Aufteilung keinen Vorteil bringt
ad (2) Die Index-Updates sind von logarithmischer Komplexität und der Vorteil ist deshalb vernachlässigbar
ad (3) Da sich die Datensätze der einzelnen Benutzer nicht gegenseitig Sperren (jeder schreibt nur sein eigenes Zeugs, und das der anderen interessiert sie nicht) sind die Schreibzugriffe auch auf einer zentralen DB ausreichend parallelisierbar

Kann jemand etwas dazu sagen.


lg,
Sam
 
Werbung:
Das hängt zunächst schonmal stark vom DBMS ab, ich denke aber wir reden hier mal nicht von Access oder so.

[contra] Bei einer MS SQL Datenbank und vermutlich auch Oracle macht es aus Performance Gründen keinen Sinn (Index, Geschwindigkeit Tabelle).

[pro] Die Rechte einzelner Benutzer auf Tabellen und Datensätze sind problemlos konfigurierbar, natürlich könnte man hier der Übersicht wegen (also allein für das Verständniss des Admins) Tabellen oder DBs getrennt anlegen.

[pro] In manchen Fällen, z.B. MS SQL Express, kann es aus Lizenztechnischen Gründen sinnvoll sein. Wenn z.B. eine Datenbank nur ein maximum an RAM oder CPU Kernen unterstützt.

[contra] Storage hängt zunächst mal vom Storage ab. Ich weiss nicht wie das bei euch aufgebaut ist aber wir haben 6 LUNs die sowieso nur auf 2 Storages in einer MSA hängen. Die Pfade (nicht die LUNs) machen Round Robin, haben also eine Art Lastenausgleich (da wir nur 1 GBit iSCSI nutzen, kein FC). In deinem Szenario würden LUNs brach liegen, wenn ein User seine LUN nicht benutzt. Eigentlich hätte jeder sein eigenes Storrage welches von den anderen nicht mit benutzt werden kann, das kann nicht im Sinne des Erfinders sein.
Dagen spricht auf jedenfall der Mehraufwand mit der Einrichtungsarbeit mehrere LUNs zum selben Zweck. Auch dürfen LUNs unter keinen Umständen weg brechen.
 
Hi!

Danke für die Antwort.

Deinen zweiten Punkt (das erste pro) verstehe ich allerdings nicht ganz. Was meinst du damit?

Bzgl. des Szenarios habe ich mich vermutlich missverständlich ausgedrückt. Es ist nicht so, dass jeder Benutzer dann seine eigene DB hat, sondern jede DB ist für ein Subset der Benutzer da (Partitionierung nach Benutzern). Das Bsp ist übrigens stark vereinfacht. Es würde schon pro DB noch genügend los sein. Ich befürchte aber mit zentraler DB mittelfristig an Performancegrenzen zu stoßen (trotz fetter HW). Jetzt stellt sich für mich die Frage - ist das eine unbegründete Angst und lässt sich auch die zentrale DB weit genug skalieren (noch fettere HW, zweites Storage dazu) oder ist da irgendwann Schluss mit skalieren. Prinzipiell heißt es ja immer so, das Scale-UP nicht unbegrenzt geht, aber nachdem die Storage-Systeme heutzutage ja praktisch beliebig skalierbar sind und Server mit x CPUs á x Cores verfügbar sind mit wasweißich an Speicher, bin ich mir eben nicht sicher. Darum möchte ich mal ein Gefühl dafür erlangen, welche Kriterien denn eher für eine zentrale DB und welche für eine verteilte DB sprechen.

Die Fragen, die ich mir stelle sind die folgenden:

Wird die DB mit zunehmender Größe zu langsam (auch wenn es eher keine Locking-Probleme gibt) - wird vielleicht der Index irgendwann so groß, dass er nicht mehr in den Speicher passt - muss der ganze Index überhaupt in den Speicher oder gibt es Szenarien, in denen das gar nicht notwendig ist - kann trotz eines riesigen Index dieser noch schnell genug aktualisiert werden oder ist wird irgendwann das Ausleeren des Index-Caches zu teuer?

Sind skalierbare Storage-System beliebig skalierbar (auch für eine einzelne LUN) oder hört sich die Skalierbarkeit irgendwann auf und ist nur noch über mehrere LUNs zu regeln? Ist die Verbindung zum Storage-System vielleicht auch irgendwann überlastet, dass ich dann ohnehin ein zweites unabhängiges Storage (mit eigener Anbindung) brauche?

Die CPU des DB Servers spielt auch eine Rolle - oder gibt man dann einfach HW mit 8 CPUs mit je 16 Cores rein und wenn dann die wieder nicht reicht nimmt man 16 CPUs usw. - oder ist früher schon Schluss, weil es gar keine HW mit 8 CPUs gibt weil hier v.a. Speicherbottlenecks auftreten würden. Bzw. kann der DB-Server überhaupt soviel parallelisieren? Oder ist es gar nicht möglich soviele Cores auszulasten, denn selbst wenn es keine Locking-Probleme gibt, dann (möglicherweise) müssen alleine beim Index aktualisieren die einzelnen Threads aufeinander warten, weswegen ohnehin ein zentraler DB-Server nicht beliebig skalierbar wäre (aufgrund mangelnder Parallelisierbarkeit)?

Fragen über Fragen, ich weiß. Für all diese Probleme wäre eine verteilte DB halt geschickt, weil ich hier überall wüßte, dass man das Problem lösen kann:

Storage nicht skalierbar - na und? zweites unabhängiges Storage mit eigenständiger DB drauf oder die Nodes selbst mit Platten ausstatten
DB-Größe bremst die DB-Performance aus - na und? Aufteilen auf mehrere Nodes
CPU nicht skalierbar - na und? Neuer Node

Ich möchte aber eben nicht blauäugig sagen, "na da mach ma mal eine verteilte DB" (das ist ja doch ungleich mehr Entwicklungsaufwand) wenn sich dann rausstellt, dass für alle Probleme, die die verteilte DB lösen soll, es bei einer zentralen DB ohnehin auch eine adäquate Lösung gäbe.
 
Werbung:
Ich habe mit so riesigen Datenbanken noch nie zu tun gehabt und ich denke, jedes DBMS hat dort seine eigenen Stärken / Schwächen. Natürlich arbeitet ein Unternehmen wie Google oder Facebook (modifiziertes MySQL) mit einer dezentralen Datenbanken auf "billiger" Hardware. Die Anwendung ist dafür gebaut.

Wenn du aber in einen Bereich der Finanzen gehst und z.B. SAP HANA nutzt wirst du eher auf dicke Hardware setzen. Ich denke die erste Hürde gegen eine Zentrale DB wird bei diesem Systemen das Dateisystem sein, aber in solchen Regionen habe ich mich noch nicht bewegt.
 
Zurück
Oben