Master Slave mit detaillierter Datenverteilung

Hallo Newsgroup!

Ich stecke gerade in der Planungsphase eines neuen Projekts und stehe
vor einem Problem, bei dem ich nicht so richtig weiter komme. Daher
hoffe ich, unter euch stecken ein paar kluge Köpfe, die mir zu einer
richtigen Entscheidung helfen können. Also, folgendes Szenario:

Ich habe eine Master Datenbank, über die Veranstaltungen eingepflegt
werden sollen. Jede Veranstaltung ist Kategorien, Bundesländern und
ähnlichem zugeordnet. Anhand dieser Zusatzinformationen, soll es
möglich sein, bestimmte Daten, an verschiedene Slave Datenbanken zu
übertragen. Das, so weit möglich, ohne zeitliche Verzögerung.

Es wäre also mit keinem simplen Duplikat der kompletten Master-DB
getan, da in den Slave-DBs wirklich nur für sie bestimmte Datensätze
vorhanden sein sollen. Die Master Slave Funktion von MySQL reicht mir,
meines Wissens nach, also noch nicht, da bei ihr immer alle Daten aus
dem Log an die Slaves weiter gegeben werden. Ein gezieltes weitergeben,
bestimmter Daten aus dem Log, wäre mein Ziel. Das ganze sollte dann
auch noch für eine Vielzahl von Slaves funktionieren.

Nun schwirren in meinem Kopf verschieden Lösungsansätze, aber keiner
scheint mir wirklich ausgegoren. Bei jedem Datenbankzugriff abzufragen,
welche Daten, welche Slaves etwas angehen und sie dann direkt zu
verteilen, wird wohl recht schnell in einer Sackgasse enden. Ich kann
nicht davon ausgehen, dass die Datenbanken immer alle erreichbar sind.
Also müsste ich mitloggen, welche DB die Daten erhalten hat und welche
noch nicht. Dann sollte es aber auch möglich sein, einen neuen Slave,
mit einem mal, alle für ihn bestimmten Daten zuzuspielen. Zudem
könnte die Anzahl der Slaves auch eventuell zu große werden und eine
direkte Verteilung der Daten dadurch zu zeitaufwendig...

Sollte es vielleicht so sein das, ähnlich wie auf MySQL Ebene, der
Slave beim Master anfragt, welche Daten neu hinzugekommen sind und der
Master dann die entsprechenden Querys zurück gibt. Eventuell über ein
SOAP Interface?

Ist es aber vielleicht auch möglich, die Sache direkt auf MySQL Ebene
zu lösen? Kann ich eventuell über mysqli soweit auf die MySQL
Funktionen zugreifen?

Nun, ihr seht, das Problem ist recht komplex, bzw. ich bin ihm noch
nicht so richtig gewachsen... Eventuell gibt es ja eine ganz einfache
Lösung und ich bin einfach noch nicht darauf gestoßen. Jeder Tipp,
Denkanstoß oder auch Hinweis, auf bestehende Lösungen, würde mir auf
jeden Fall sehr weiterhelfen.

Kurz noch zum Server und den geplanten Techniken, die zum Einsatz
kommen sollten. Laufen soll alles auf einem dedizierter Linux Server.
Auf ihm läuft PHP4 oder auch 5 und als Datenbanksystem kommt MySQL zum
Einsatz.

So, bevor das hier jetzt noch ausartet, höre ich besser auf und hoffe.
Wenn ihr noch Fragen habt, nur her damit! Erst schon mal vielen Dank
für eure Mühe.

Schöne Grüße,
Andy

Re: Master Slave mit detaillierter Datenverteilung

Hi Andy

Andy Wesely wrote:
> Ich habe eine Master Datenbank, über die Veranstaltungen eingepflegt
> werden sollen. Jede Veranstaltung ist Kategorien, Bundesländern und
> ähnlichem zugeordnet. Anhand dieser Zusatzinformationen, soll es
> möglich sein, bestimmte Daten, an verschiedene Slave Datenbanken zu
> übertragen. Das, so weit möglich, ohne zeitliche Verzögerung.

> Es wäre also mit keinem simplen Duplikat der kompletten Master-DB
> getan, da in den Slave-DBs wirklich nur für sie bestimmte Datensätze
> vorhanden sein sollen. Die Master Slave Funktion von MySQL reicht mir,
> meines Wissens nach, also noch nicht, da bei ihr immer alle Daten aus
> dem Log an die Slaves weiter gegeben werden. Ein gezieltes weitergeben,
> bestimmter Daten aus dem Log, wäre mein Ziel. Das ganze sollte dann
> auch noch für eine Vielzahl von Slaves funktionieren.

Du könntest für jeden Slave-Bereich eine eigene DB verwenden. Diese
kannst du dann einzeln Duplizieren. In einer Ober-DB verwaltest du dann
noch die gemeinsamen Daten.

Oder aber du duplizierst immer alles, aber regelst bei den Slaves die
Zugriffsrechte auf die Daten.

Ich bin aber sicher, dass du dank diesem Wunsch, Daten seperat verwalten
zu wollen, stark von der Normalisierung abweichen musst.

Alles andere (selbstgebasteltes Master-Slaving) halte ich für Gebastel.

HTH, Johannes

Re: Master Slave mit detaillierter Datenverteilung

"Andy Wesely" wrote:

> bestimmte Daten, an verschiedene Slave Datenbanken zu
> übertragen. Das, so weit möglich, ohne zeitliche Verzögerung.
>
> Es wäre also mit keinem simplen Duplikat der kompletten Master-DB
> getan, da in den Slave-DBs wirklich nur für sie bestimmte Datensätze
> vorhanden sein sollen.

Klingt von den allgemeinen Anforderungen nach einem Anwendungsfall für
die MySQL-Replikation. Bis auf das "jede Datenbank nur ihre Daten".

MySQL-Replikation kann man einschränken auf Datenbank- und Tabellen-
Ebene. Aber eventuell hilft dir ja folgendes:

1. Replikation für die fraglichen Tabellen mit allen Datensätzen.
2. Zugriff auf die Daten über Views. Jede Slave-Datenbank bekommt
dazu ihre eigene View in dann nur "ihre" Datensätze erscheinen.

Da man in MySQL-Views (Achtung: erst ab Version 5) auch schreiben kann,
kann deine Applikation Lese- und Schreibzugriffe jeweils auf die View
machen und braucht die richtige Tabelle dahinter gar nicht zu kennen.


HTH, XL

Re: Master Slave mit detaillierter Datenverteilung

Post removed (X-No-Archive: yes)

Re: Master Slave mit detaillierter Datenverteilung

Hi Rainer

Rainer Gauweiler wrote:
> On Thu, 02 Feb 2006 10:50:11 +0100, Johannes Vogel wrote:
>> Du könntest für jeden Slave-Bereich eine eigene DB verwenden. Diese
>> kannst du dann einzeln Duplizieren. In einer Ober-DB verwaltest du dann
>> noch die gemeinsamen Daten.
> Dann muss er aber im Endeffekt in der Applikation entscheiden, wohin er
> welche Daten schreibt. Wenn dann Clients dazu oder weg kommen artet das
> aus.

ACK.

>> Oder aber du duplizierst immer alles, aber regelst bei den Slaves die
>> Zugriffsrechte auf die Daten.
> Naja, das will er wohl nicht. Würde auch schlecht skalieren und gibt eventuell
> Probleme mit dem Datenschutz und/oder Kundenbedürfnissen.

ACK. Ist aber für die Realisation der Replikation eine einfache Umsetzung.

>> Ich bin aber sicher, dass du dank diesem Wunsch, Daten seperat verwalten
>> zu wollen, stark von der Normalisierung abweichen musst.
> Wozu? Es will doch nur nach Attributen filtern. Also reicht ihm eine weitere
> Tabelle, die die Attribute den Clients zuordnet.

Wir haben's hier mit MySQL zu tun. MySQL bietet zur Replikation das
Master/Slave Modell an, welches auf Ebene 'database' funktioniert. Auf
keinen Fall können Daten gefiltert werden. Entweder alles oder nichts.

>> Alles andere (selbstgebasteltes Master-Slaving) halte ich für Gebastel.
> Ich sehe nicht, was gegen einen Replikationsdienst mit entsprechendem
> Client spricht, sofern er eine saubere Architektur hat.

Der Replikationsdienst ist vorgegeben. Ausser der OP möchte was eigenes
programmieren. Das jedoch kann ich mir nicht vorstellen.

> Als Argument dafür könnte man nehmen, dass man so die Replikation unabhängig
> vom dbms hält und dieses dann eventuell wechseln kann, falls ein Client das
> aus welchen Gründen auch immer erfordert.

Das DBMS war vorgegeben. Und innerhalb dieser Vorgabe versuchte ich die
verschiedenen Optionen aufzuzeigen. Natürlich gibt es weitere,
aufwändigere. Am Besten wäre es wohl, er würde ein DBMS benutzen,
welches mit Schemen arbeitet (die meisten anderen).

HTH, Johannes

Re: Master Slave mit detaillierter Datenverteilung

Hallo,

nach längerer Abwesenheit melde ich mich auch mal wieder. Vielen Dank
schon mal für die bisherige Hilfe. Mal sehen ob ich in die bisher
angesprochenen Punkte noch etwas Klarheit bringen kann.

>> Du könntest für jeden Slave-Bereich eine eigene DB verwenden. Diese
>> kannst du dann einzeln Duplizieren. In einer Ober-DB verwaltest du dann
>> noch die gemeinsamen Daten.
>
>Dann muss er aber im Endeffekt in der Applikation entscheiden, wohin er
>welche Daten schreibt. Wenn dann Clients dazu oder weg kommen artet das
>aus.

So etwas wie einfache Duplikate halte ich auch für wenig sinnvoll. Die
Sache sollte so flexibel wie möglich gehalten werden. Gleichzeitig
sollte von der Normalisierung aber nicht ernsthaft abgewischen werden.
Wünschenswert wäre ein einmal angelegter Client, dem man
Filterattribute zuweisen kann, nach denen die Daten dann in seine
eigene DB verteilt werden.

>> Oder aber du duplizierst immer alles, aber regelst bei den Slaves die
>> Zugriffsrechte auf die Daten.
>
> Naja, das will er wohl nicht. Würde auch schlecht skalieren und gibt ev=
entuell
> Probleme mit dem Datenschutz und/oder Kundenbedürfnissen.

Stimmt, eigentlich möchte ich nicht das die Clients auf die Master DB
zugreifen. Datenbanken, in denen wirklich nur die für den Client
relevanten Daten liegen, auf die er lesend zugreifen kann, wären
wesentlich besser. Die beiden aufgefürten Argumente stimmen so voll
und ganz: Die Lösung sollte gut skalierbar bleiben, da ich nicht
weiß, auf wie viele Clients das ganze eines Tages hinaus läuft. Zudem
sollte der Kunde wirklich nur die für ihn bestimmten Daten zu Gesicht
bekommen und eine Filterung auf Client Seite wäre da doch etwas zu
leicht zu umgehen. Ich will einen Master/Slave Betrieb damit nicht
ausschließen, eine feiner Verteilung der Daten wäre mir aber
wesentlich lieber.

>> Alles andere (selbstgebasteltes Master-Slaving) halte ich für Gebastel.
>
> Ich sehe nicht, was gegen einen Replikationsdienst mit entsprechendem
> Client spricht, sofern er eine saubere Architektur hat.

Hört sich gut an, nur wie würde eine solche Architektur am besten
aussehen? Es müssten klar einige Dinge beachtet werden, damit das
ganze nicht im Chaos mündet. Ein paar Punkte habe ich in meinem ersten
Posting ja schon erwähnt. Aber das waren sicherlich noch nicht alle.
Wie müsste die Architektur für eine solche Lösung in groben Zügen
aussehen oder gibt es doch das Killerargument gegen eine solche
selbstgebaute Datenverteilung? Tatsächlich kann ich mir dabei keine
Datenverteilung auf MySQL Ebene vorstellen. Was eher an meinen
fehlenden Kenntnissen, als an der generellen Machbarkeit liegt.

Das DBMS MySQL ist übrigens tatsächlich eine feste Vorgabe.

Greets,
Andy

Re: Master Slave mit detaillierter Datenverteilung

"Andy Wesely" wrote:

Irgendwie kommt mir diese Diskussion verdammt bekannt vor.

> So etwas wie einfache Duplikate halte ich auch für wenig sinnvoll. Die
> Sache sollte so flexibel wie möglich gehalten werden. Gleichzeitig
> sollte von der Normalisierung aber nicht ernsthaft abgewischen werden.
> Wünschenswert wäre ein einmal angelegter Client, dem man
> Filterattribute zuweisen kann, nach denen die Daten dann in seine
> eigene DB verteilt werden.
>
>>> Oder aber du duplizierst immer alles, aber regelst bei den Slaves die
>>> Zugriffsrechte auf die Daten.
>>
>> Naja, das will er wohl nicht. Würde auch schlecht skalieren und gibt ev
> entuell Probleme mit dem Datenschutz und/oder Kundenbedürfnissen.
>
> Stimmt, eigentlich möchte ich nicht das die Clients auf die Master DB
> zugreifen.

Das hat damit nichts zu tun. Natürlich wären bei der herkömmlichen
Replikation die Slaves komplette Kopien des Masters (wobei du die
Replikation zumindest bis auf Tabellenebene einschränken kannst).
Der *Zugriff* der Clients würde aber auf die Slaves erfolgen.

> Datenbanken, in denen wirklich nur die für den Client
> relevanten Daten liegen, auf die er lesend zugreifen kann, wären
> wesentlich besser.

Datenabhängige Zugriffsbeschränkungen lassen sich am besten mit Views
modellieren. Diese Views wären natürlich auf jedem Slave anders und
würden aus den replizierten, kompletten Tabellen den für den jeweiligen
Client relevanten Teil herausschneiden. Auch mehrere Clients auf einem
Slave wären kein Problem.

> Die beiden aufgefürten Argumente stimmen so voll
> und ganz: Die Lösung sollte gut skalierbar bleiben, da ich nicht
> weiß, auf wie viele Clients das ganze eines Tages hinaus läuft.

Skalierbarkeit ist bei der MySQL-Replikation normalerweise kein Thema.
Allerdings würde dein Master mehr Daten (unter der Annahme, daß die
Slaves disjunkte Datenmengen bekommen sollen - sovielmal mehr Daten wie
es Slaves sind) in die Welt verteilen. Ob das ein Problem ist, hängt
davon ab, wieviel auf dem Master geschrieben wird.

> Zudem
> sollte der Kunde wirklich nur die für ihn bestimmten Daten zu Gesicht
> bekommen und eine Filterung auf Client Seite wäre da doch etwas zu
> leicht zu umgehen.

Wenn du das mit Views löst, ist das so sicher, wie die Datenbank ist.

Einen wesentlichen Vorteil, *alle* Daten auf *alle* Slaves zu vertei-
len, sehe ich darin daß es so einfach möglich ist, Slaves umzuwidmen.
Wenn z.B. ein Slave ausfällt und ein anderer seine Funktion mit über-
nehmen soll, ändert man einfach ein paar Views und fertig. Stell dir
mal vor, wie das im anderen Fall aussähe. Auch das Aufsetzen eines
neuen Slaves ist so trivial. Einfach eine Kopie eines bestehenden
Slaves machen und die Views anpassen.

>> Ich sehe nicht, was gegen einen Replikationsdienst mit entsprechendem
>> Client spricht, sofern er eine saubere Architektur hat.
>
> Hört sich gut an, nur wie würde eine solche Architektur am besten
> aussehen? Es müssten klar einige Dinge beachtet werden, damit das
> ganze nicht im Chaos mündet. Ein paar Punkte habe ich in meinem ersten
> Posting ja schon erwähnt. Aber das waren sicherlich noch nicht alle.
> Wie müsste die Architektur für eine solche Lösung in groben Zügen
> aussehen oder gibt es doch das Killerargument gegen eine solche
> selbstgebaute Datenverteilung?

Ich habe bei einem früheren Arbeitgeber mal mit einer selbergeschrie-
benen any-to-any Replikation gearbeitet. Die war trotz viel Sorgfalt
bei weitem nicht so zuverlässig wie die MySQL-eigene Replikation.

Ein praktisches Problem ist z.B., daß man wirklich *alle* Änderungen
an der Datenbank repliziert haben will und die dazu irgendwo abgreifen
muß. Jeder Level oberhalb des DBMS bietet dann die Möglichkeit, Queries
an der Replikation vorbeizuschmuggeln. Im besten Fall beschränkt man
sich nur selber darin, ein bestimmtes Framework (eine bestimmte Program-
miersprache, etc.) verwenden zu müssen.

Wenn du ein paar Finessen der MySQL-Replikation sehen willst: schau dir
mal ein Binlog mit 'mysqlbinlog' an. Dann überlege dir, warum da so
Sachen wie 'SET TIMESTAMP' drinstehen.


XL

Re: Master Slave mit detaillierter Datenverteilung

Post removed (X-No-Archive: yes)

Re: Master Slave mit detaillierter Datenverteilung

Post removed (X-No-Archive: yes)

Re: Master Slave mit detaillierter Datenverteilung

Rainer Gauweiler wrote:
> On Wed, 1 Mar 2006 16:43:32 +0100, Axel Schwenke wrote:
>
>> Skalierbarkeit ist bei der MySQL-Replikation normalerweise kein Thema.
>
> Ähm, also bei der Frage nach Skalierbarkeit ist natürlich die übertragene
> Datenmenge relevant. Wenn ich komplett kopiere dann übertrage ich
> ja auch für jeden Kunden alle Daten der anderen Kunden.
....

> Gute Skalierbarkeit definiere ich anders :-)
>
>> Allerdings würde dein Master mehr Daten (unter der Annahme, daß die
>> Slaves disjunkte Datenmengen bekommen sollen - sovielmal mehr Daten wie
>> es Slaves sind) in die Welt verteilen. Ob das ein Problem ist, hängt
>> davon ab, wieviel auf dem Master geschrieben wird.
>
> Eben.

Naja, die Anzahl Slaves wird man aus verschiedenen Gründen eher klein
halten wollen. Wenn das mal *wirklich* viele werden (gewöhnlich gut
informierte Quellen haben mir berichtet, daß jjj.zbovyr.qr insgesamt
ca. 300 Slaves an ihrer Master-Instanz hängen haben) dann zieht man
eine weitere Ebene von Slaves ein. Am Master hängen dann z.B. 10
solche Zwischen-Slaves, an jedem davon 10 richtige Slaves.

>> Wenn du das mit Views löst, ist das so sicher, wie die Datenbank ist.
>
> Gehen wir mal von einem Kunden aus, der vollen Zugriff auf die Installation
> des dbms hat. Gibt es momentan eigentlich irgendein dbms das Angriffsversuchen
> relevant lange Stand hält?

Voller Zugriff ist voller Zugriff.

> Geschickt
> plazierte Trigger mit Tabellen mit eingeschränkten Zugriffsberechtigungen
> stellen eine Hürde da, die man aus der Anwendung raus nicht so trivial
> umgehen kann.

Hmm. Mit Triggern sollte das eigentlich auch gehen. Dazu legt man auf
dem Master für jeden Slave eine Schatten-Datenbank an. Änderungen an
den Master-Tabellen schafft man per Trigger da hinein.

Bleibt das Problem, daß man nur ein Binlog hat, in dem nachher alle
Änderungen landen. Damit werden die auch an alle Slaves kopiert
(dort heißt das dann relay-log) und "fremde" Daten erst beim Einspie-
len in die Datenbank weggeworfen.

Bleibt noch die Möglichkeit, aus dem Trigger direkt in die Slave-
Datenbanken zu schreiben (z.B. per "federated" Tabellen). Das wäre
dann sogar synchron, würde aber fehlschlagen, sobald auch nur ein
Slave nicht erreichbar ist. Auch nicht so toll.


XL