Skalierung (andere DB?)

Hallo,
wir haben hier ein System welches Nutzeraktivitäten analysiert (Webtraffic).
Z. Z. erfolgt die Berechnung auf 5 DB Servern mit jeweils 4 CPU Kernen, alle
mit RAID-10 15.000 SAS Festplatten, 4 GB Ram. Datenumfang je Server ca.
50-100 GB. Leider ist die Skalierung mit Mysql sehr mühsam, d.h. weitere
Kunden können nur durch hinzufügen neuer Server realisiert werden. Jeder
Kunde hat ca. 5-30 GB Daten, die permanent anwachsen. Wir brauchen im Grunde
ein Cluster um die Verfügbarkeit und Performance der Server besser
auszunutzen. Jetzt ist z.B. Kunde x auf Server a. Auf Server a sind noch
weitere Kunden. Wenn Server ausgelastet ist, kann keiner der anderen Server
"helfen", außer man zieht eben einen Kunden von Server a nach Server b. Sehr
unpraktisch. WIr haben schon an ein SAN gedacht, aber wie wird hier die
Performance sein? 5 MySQL Server, die wirklich richtig ackern, 24h, und
richtig I/O haben. DIe Maschinen haben je 4 GB. Das Problem ist nicht der
Speicher, denn wir würden die Daten nur dann richtig in den Speicher
bekommen, wenn die Kisten alle mind 32-64 GB hätten. Wir hatten jetzt einen
Mysql Enterprise Berater für ein paar Tage hier. Es gab ein paar gute Tipps,
aber nichts was wirklich eine andere Richtung gezeigt hätte. Partitionierung
von 5.1 wäre ein hoch interessantes Thema für uns, ist jedoch bei Mysql noch
in weit entfernt bis es wirklich stabil laufen wird. Unser Admin hat jetzt
MSSQL in den Raum geworfen. Hier sollen Clusterfunktionalitäten,
Verfügbarkeit, alles schon fertig sein. Ich bin sehr skeptisch, denn in der
Anwendung stecken bereits 2-3 Jahre Optimierung drin. Und ob die dann noch
sinnvoll sind. Ansonsten vielleicht PostreSQL? Der Datenumfang gesamt sind
300-500 GB, wobei wir jetzt sehr viel Daten aggregieren um den Datenumfang
nicht zu schnell wachsen zu lassen. Im Grunde wollen wir das aber nicht,
d.h. die Daten zu stark aggregieren, denn manche Analysen sind mit
aggregierten Daten nicht mehr möglich. Ohne Aggregation würde die Datenmenge
je Tag um ca. 30 GB anwachsen.

Christian

Re: Skalierung (andere DB?)

Christian Schmelzer wrote:

> wir haben hier ein System welches Nutzeraktivitäten analysiert (Webtraffic).

Und wo genau ist in diesem gesamten Monolog die eigentliche Frage?


> WIr haben schon an ein SAN gedacht, aber wie wird hier die Performance sein?

Wenn ihr die Daten ständig über das Netzwerk hereinschaufeln müsst, dürfte das
nicht schneller werden als wenn alles auf lokalen Platten liegt.


> Unser Admin hat jetzt MSSQL in den Raum geworfen.

Wenn sich euer Admin mit MSSQL sehr gut auskennt, macht es sicherlich Sinn,
darüber nachzudenken. Wenn er sich jedoch besser mit Mysql als mit dem neuen
Produkt auskennt, ist alles, was er sagt, bloss Hörensagen.
Letztendlich kommt ihr nicht um eine Evaluierung herum, eure Software muss
umgeschrieben werden und ihr braucht jemanden, der sich mit der neuen Daten-
banksoftware gut auskennt.


> Ansonsten vielleicht PostreSQL?

Hier gilt prinzipiell das gleiche wie bei MSSQL.


> Der Datenumfang gesamt sind 300-500 GB

Das füllt nicht mal eine Platte *wunder*
So etwas bewältigen andere Firmen ganz locker.


Anstatt neue Ideen über andere Datenbanken in den Raum zu werfen, würde ich
mir eher überlegen, wie ich meine Prozesse so anpassen kann, das ich beispielsweise
nicht ständig soviele Daten auslesen muss.

Es kommt mir der Gedanke, das ihr einen Service anbietet, dem ihr nicht so
ganz gewachsen seit.


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Skalierung (andere DB?)

Andreas Scherbaum wrote:
> Christian Schmelzer wrote:
>
>> wir haben hier ein System welches Nutzeraktivitäten analysiert
>> (Webtraffic).
>
> Und wo genau ist in diesem gesamten Monolog die eigentliche Frage?
>
>

Ok, war etwas lang ;-)


>> WIr haben schon an ein SAN gedacht, aber wie wird hier die
>> Performance sein?
>
> Wenn ihr die Daten ständig über das Netzwerk hereinschaufeln müsst,
> dürfte das nicht schneller werden als wenn alles auf lokalen Platten
> liegt.
>
>
>> Unser Admin hat jetzt MSSQL in den Raum geworfen.
>
> Wenn sich euer Admin mit MSSQL sehr gut auskennt, macht es sicherlich
> Sinn, darüber nachzudenken. Wenn er sich jedoch besser mit Mysql als
> mit dem neuen Produkt auskennt, ist alles, was er sagt, bloss
> Hörensagen.
> Letztendlich kommt ihr nicht um eine Evaluierung herum, eure Software
> muss umgeschrieben werden und ihr braucht jemanden, der sich mit der
> neuen Daten- banksoftware gut auskennt.
>
>
>> Ansonsten vielleicht PostreSQL?
>
> Hier gilt prinzipiell das gleiche wie bei MSSQL.
>
>
>> Der Datenumfang gesamt sind 300-500 GB
>
> Das füllt nicht mal eine Platte *wunder*
> So etwas bewältigen andere Firmen ganz locker.
>

Die Menge ist ja nur ein Teil des "Problems", sondern die Daten zu
verarbeiten. Nur Ablegen wäre nicht das Problem.

>
> Anstatt neue Ideen über andere Datenbanken in den Raum zu werfen,
> würde ich
> mir eher überlegen, wie ich meine Prozesse so anpassen kann, das ich
> beispielsweise nicht ständig soviele Daten auslesen muss.
>
> Es kommt mir der Gedanke, das ihr einen Service anbietet, dem ihr
> nicht so
> ganz gewachsen seit.

Das ist Quatsch, selbst wenn es vielleicht so klang. Es geht darum sinnvoll
mit Mysql zu skalieren ohne lediglich Server hinzustellen. Und eine gute
Skalierung wäre Partitionierung, die Mysql jetzt nicht brauchbar bietet.

C.

Re: Skalierung (andere DB?)

Christian Schmelzer wrote:
> Andreas Scherbaum wrote:
>>
>> Anstatt neue Ideen über andere Datenbanken in den Raum zu werfen,
>> würde ich
>> mir eher überlegen, wie ich meine Prozesse so anpassen kann, das ich
>> beispielsweise nicht ständig soviele Daten auslesen muss.
>>
>> Es kommt mir der Gedanke, das ihr einen Service anbietet, dem ihr
>> nicht so
>> ganz gewachsen seit.
>
> Das ist Quatsch, selbst wenn es vielleicht so klang. Es geht darum sinnvoll
> mit Mysql zu skalieren ohne lediglich Server hinzustellen. Und eine gute
> Skalierung wäre Partitionierung, die Mysql jetzt nicht brauchbar bietet.

Gut, andersherum: was wertet ihr denn mit den paar Daten aus, was so umfangreich
ist und so viel Performance kostet, das ihr mit den gegebenen Ressourcen
nicht hinkommt?


Bye

--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)

Re: Skalierung (andere DB?)

Andreas
--
q: why do so many people take an instant dislike to mysql?
a: it saves time (oicu in #postgresql)
Explaining the concept of referential integrity to a mysql user is like
explaining condoms to a catholic (Shadda in #postgresql)

Re: Skalierung (andere DB?)

Am Thu, 22 Mar 2007 16:24:46 +0100 schrieb Christian Schmelzer:

Am Thu, 22 Mar 2007 16:24:46 +0100 schrieb Christian Schmelzer:

> wir haben hier ein System welches Nutzeraktivitäten analysiert (Webtraffic).
> Z. Z. erfolgt die Berechnung auf 5 DB Servern mit jeweils 4 CPU Kernen, alle
> mit RAID-10 15.000 SAS Festplatten, 4 GB Ram. Datenumfang je Server ca.
> 50-100 GB. Leider ist die Skalierung mit Mysql sehr mühsam, d.h. weitere
> Kunden können nur durch hinzufügen neuer Server realisiert werden. Jeder
> Kunde hat ca. 5-30 GB Daten, die permanent anwachsen. Wir brauchen im Grunde
> ein Cluster um die Verfügbarkeit und Performance der Server besser
> auszunutzen. Jetzt ist z.B. Kunde x auf Server a. Auf Server a sind noch
> weitere Kunden. Wenn Server ausgelastet ist, kann keiner der anderen Server
> "helfen", außer man zieht eben einen Kunden von Server a nach Server b. Sehr
> unpraktisch. WIr haben schon an ein SAN gedacht, aber wie wird hier die
> Performance sein? 5 MySQL Server, die wirklich richtig ackern, 24h, und
> richtig I/O haben.

Was spricht gegen die übliche Stern-Topologie. Ein Master, auf dem
geschrieben wird und readonly-Slaves für die Analysen. Die Kunden bleiben
weiterhin durch verschiedene Datenbanken getrennt, aber auf allen Slaves
liegen alle Daten.

> DIe Maschinen haben je 4 GB. Das Problem ist nicht
> der Speicher, denn wir würden die Daten nur dann richtig in den Speicher
> bekommen, wenn die Kisten alle mind 32-64 GB hätten.

64 Bit machts möglich und bezahlbar ist es auch. Das würde vermutlich
viel helfen.

Allerdings dauerte es natürlich einige Stunden, bis ein solcher Cache warm
ist. D.h. wenn der Kunde ggfs. von einem Server auf den anderen wechselt,
bricht die Performance ein.

> Wir hatten jetzt
> einen Mysql Enterprise Berater für ein paar Tage hier. Es gab ein paar
> gute Tipps, aber nichts was wirklich eine andere Richtung gezeigt hätte.
> Partitionierung von 5.1 wäre ein hoch interessantes Thema für uns, ist
> jedoch bei Mysql noch in weit entfernt bis es wirklich stabil laufen
> wird.

Kannst Du das näher erläutern? Ich ziehe gerade in erwägung, das
einzusetzen.

> Unser Admin hat jetzt MSSQL in den Raum geworfen. Hier sollen
> Clusterfunktionalitäten, Verfügbarkeit, alles schon fertig sein.

Das Problem mit MSSQL ist, das es auf Windows läuft.

> Ich bin
> sehr skeptisch, denn in der Anwendung stecken bereits 2-3 Jahre
> Optimierung drin. Und ob die dann noch sinnvoll sind. Ansonsten
> vielleicht PostreSQL?

Ich werfe hier mal Oracle in den Raum. Allerdings wirst Du auf
jeder neuen Datenbank erhebliche Anpassungen machen müssen.

Sorry, falls ich Punkte gebracht habe, die im Thread weiter oben
diskutiert werden. Ich sitze in der S-Bahn und mir fehlen die Followups.

Gruß,
Joachim