m/cluster Durchsatz

Hallo,

hat jemand belastbare Durchsatzzahlen eines m/clusters zur Verfügung.
Bin gerade auf der Suche danach und bis jetzt noch nicht fündig
geworden. Konkret: Wie groß ist der Durchsatz eines m/clusters aus N
nodes verglichen mit einem "normalen" mysqld auf einem node - dieselbe
Hardware nartürlich vorausgesetzt. Es gibt hier Befürchtungen, dass die
Datensynchronisation einen _erheblichen_ Teil der Performance auffrisst;
im Extremfall, dass der Cluster langsamer ist als ein Einzelnode.

Herbert

Re: m/cluster Durchsatz

Herbert Pophal wrote:

> hat jemand belastbare Durchsatzzahlen eines m/clusters zur Verfügung.

Frag bei mysql.com. Entweder in den Foren oder gleich einen Sales-
Engineer.

> Konkret: Wie groß ist der Durchsatz eines m/clusters aus N
> nodes verglichen mit einem "normalen" mysqld auf einem node - dieselbe
> Hardware nartürlich vorausgesetzt.

MySQL Cluster ist nicht mit einem "normalen" mysqld zu vergleichen.
Die NDB-Engine (die auf den Data-Nodes läuft) ist extra auf hohen
Durchsatz optimiert. Durch die in-Memory Datenhaltung ist NDB
mindestens Faktor 10 schneller als jede disk-based Engine von MySQL.

> Es gibt hier Befürchtungen, dass die
> Datensynchronisation einen _erheblichen_ Teil der Performance auffrisst;
> im Extremfall, dass der Cluster langsamer ist als ein Einzelnode.

Das sicher nicht. Ich habe selber keine Zahlen, aber die Cluster-
Performance wächst bis in den deutlich zweistelligen Bereich nahezu
linear mit der Data-Nodes (weil Daten nicht nur repliziert, sondern
auch partitioniert werden). Das gilt natürlich nicht für patholo-
gische Queries (etwa JOINs über komplette Tabellen) - für die der
Kommunikationsbedarf zwischen den Nodes stark steigt.


XL

Re: m/cluster Durchsatz

Axel Schwenke wrote:
> Herbert Pophal wrote:
>
>
>>hat jemand belastbare Durchsatzzahlen eines m/clusters zur Verfügung.
>
>
> Frag bei mysql.com. Entweder in den Foren oder gleich einen Sales-
> Engineer.
>
>
>>Konkret: Wie groß ist der Durchsatz eines m/clusters aus N
>>nodes verglichen mit einem "normalen" mysqld auf einem node - dieselbe
>>Hardware nartürlich vorausgesetzt.
>
>
> MySQL Cluster ist nicht mit einem "normalen" mysqld zu vergleichen.
> Die NDB-Engine (die auf den Data-Nodes läuft) ist extra auf hohen
> Durchsatz optimiert. Durch die in-Memory Datenhaltung ist NDB
> mindestens Faktor 10 schneller als jede disk-based Engine von MySQL.

Bestimmt, aber du hast mich missverstanden. Es war nicht die Rede von
MySQL Cluster, sondern von m/cluster (www.continuent.com). MySQL Cluster
ist (angeblich) nicht kompatibel mit Typo3, und darum geht es auch.

>>Es gibt hier Befürchtungen, dass die
>>Datensynchronisation einen _erheblichen_ Teil der Performance auffrisst;
>>im Extremfall, dass der Cluster langsamer ist als ein Einzelnode.
>
>
> Das sicher nicht. Ich habe selber keine Zahlen, aber die Cluster-
> Performance wächst bis in den deutlich zweistelligen Bereich nahezu
> linear mit der Data-Nodes (weil Daten nicht nur repliziert, sondern
> auch partitioniert werden). Das gilt natürlich nicht für patholo-
> gische Queries (etwa JOINs über komplette Tabellen) - für die der
> Kommunikationsbedarf zwischen den Nodes stark steigt.
>
>
> XL

Herbert

Re: m/cluster Durchsatz

Herbert Pophal wrote:
> Bestimmt, aber du hast mich missverstanden. Es war nicht die Rede von=20
> MySQL Cluster, sondern von m/cluster (www.continuent.com). MySQL Cluster=
=20
> ist (angeblich) nicht kompatibel mit Typo3, und darum geht es auch.
>>>Es gibt hier Befürchtungen, dass die
>>>Datensynchronisation einen _erheblichen_ Teil der Performance auffrisst=
;
>>>im Extremfall, dass der Cluster langsamer ist als ein Einzelnode.

Wenn ich mir deren Produktbeschreibung anschaue, haette ich die
gleiche Befuerchtung. Deren vorgeschaltete Cluster-Loesung scheint ja
Schreibrequests immer auf alle Nodes zu verteilen (d.h. kein
Performancegewinn durch mehr Nodes, sondern eher Reduktion, da ja
gewartet werden muss, bis der angsamsten Node committed hat) und
Leserequests immer nur von dem "aktiven" Node, der die Requests
initial empfaengt, zu beantworten, d.h. auch hier gibt es durch die
Clusterung keinen Performance-Gewinn.=20

Scheint also eine reine HA-Sache zu sein. Die Frage ist dann, wie sie
mit typischen Fehlerfaellen zurechtkommen (z.B. Disk-Probleme auf
einem Node, er nimmt zwar TCP-Requests munter entgegen, antwortet
aber lahm (nach Platten-Resets) oder gar nicht) und wie dann die
Performance aussieht.

Aber es gibt doch Demo-Versionen zum Download, installiere das Ding
doch einfach mal und berichte hier von den Ergebnisse vom Cluster im
Vergleich zur Single-Node-Kiste. Wuerde sicherlich viele hier
interessieren.

Re: m/cluster Durchsatz

Herbert Pophal wrote:
>
> du hast mich missverstanden. Es war nicht die Rede von
> MySQL Cluster, sondern von m/cluster (www.continuent.com).

Aha. Dann drück dich deutlicher aus. Ich kenne das noch als
EMIC-Cluster. Aber so oft, wie die ihren Namen wechseln, kommt
man ja gar nicht mehr hinterher.

> MySQL Cluster
> ist (angeblich) nicht kompatibel mit Typo3, und darum geht es auch.



Typo3? Und dahinter einen Cluster wegen der *Performance* ???
Bruhahaha. YMMD.

Typo3 ist so ziemlich das lahmste (vor allem: per Design lahme)
CMS, das mir je untergekommen ist. Für den Karnickelzüchterverein
Hintertupfingen mit 10 Pageviews am Tag mag Typo3 geeignet sein.
Aber sobald Performance *irgendeine* Rolle spielt, sollte man es
umgehend aus dem Kreis der möglichen Lösungen streichen.

Die gute Nachricht ist: mit Typo3 ist die Datenbank nicht dein
Flaschenhals. Ein vernünftig konfiguriertes MySQL reicht allemal.




Dann noch was prinzipielles bezüglich Cluster und Performance. Im
Datenbankbereich sind die weitaus meisten Cluster eher HAC als HPC.
Der Fokus liegt immer mehr auf Verfügbarkeit als auf Leistung.

Der EMIC-Cluster ist gar nicht mal schlecht. Natürlich erreicht er beim
Schreibdurchsatz bestenfalls die Leistung eines einzelnen Nodes, aber
das Lesen skaliert schon ordentlich.

Nachteile gibts aber auch reichlich:
- teuer
- proprietär, es wird ein gepatchtes MySQL verwendet, daher dem
aktuellen Stand immer hinterher
- nur für Linux/x86 (und neuerdings wohl auch x86_64)



XL

Re: m/cluster Durchsatz

Axel Schwenke wrote:
> Herbert Pophal wrote:
>
>>du hast mich missverstanden. Es war nicht die Rede von
>>MySQL Cluster, sondern von m/cluster (www.continuent.com).
>
>
> Aha. Dann drück dich deutlicher aus. Ich kenne das noch als

Versteh' ich nicht. Ich habe im OP von m/cluster geschrieben, _nicht_
von MySQL Cluster. Also see Subject.

> EMIC-Cluster. Aber so oft, wie die ihren Namen wechseln, kommt
> man ja gar nicht mehr hinterher.

Das mag sein. Mein erster Lesekontakt war auch über emicnetworks, und
jetzt halt über continuent. Hmm, was soll man davon halten? Was uns (und
andere) stört, ist das Fehlen vernünftiger Doku, ohne den ganzen Kram
runterzuladen und sich vorher registrierewn zu müssen.

>>MySQL Cluster
>>ist (angeblich) nicht kompatibel mit Typo3, und darum geht es auch.
>
>
>
> Typo3? Und dahinter einen Cluster wegen der *Performance* ???
> Bruhahaha. YMMD.

Das sagt niemand. Es geht um die HA. Aber das soll nicht
notwendigerweise als _Bremse_ wirken. Wenn man das mit MySQL replication
und IP failover hinbekommt, soll es auch gut sein.

> Typo3 ist so ziemlich das lahmste (vor allem: per Design lahme)
> CMS, das mir je untergekommen ist. Für den Karnickelzüchterverein
> Hintertupfingen mit 10 Pageviews am Tag mag Typo3 geeignet sein.

Das kann ich ja mal den Leuten erzählen, die das ausgesucht haben, und
denen, die das einsetzen :-)
Ansonsten: um welche CMSs geht es und wie hast du das ermittelt?

> Dann noch was prinzipielles bezüglich Cluster und Performance. Im
> Datenbankbereich sind die weitaus meisten Cluster eher HAC als HPC.
> Der Fokus liegt immer mehr auf Verfügbarkeit als auf Leistung.

Genau darum geht es, siehe oben.

> Der EMIC-Cluster ist gar nicht mal schlecht. Natürlich erreicht er beim
> Schreibdurchsatz bestenfalls die Leistung eines einzelnen Nodes, aber
> das Lesen skaliert schon ordentlich.

OK, immerhin eine Aussage. Siehe auch Svens Posting.

>
> Nachteile gibts aber auch reichlich:
> - teuer
> - proprietär, es wird ein gepatchtes MySQL verwendet, daher dem
> aktuellen Stand immer hinterher

Da ich die Testsoftware noch nicht gezogen habe: welche MySQl-Version
steckt da drin?

> - nur für Linux/x86 (und neuerdings wohl auch x86_64)

wäre hier kein Problem.


Herbert

Re: m/cluster Durchsatz

Herbert Pophal wrote:
> Axel Schwenke wrote:

[EMIC aka m/cluster]

> Hmm, was soll man davon halten? Was uns (und
> andere) stört, ist das Fehlen vernünftiger Doku, ohne den ganzen Kram
> runterzuladen und sich vorher registrierewn zu müssen.

IIRC war die Doku auf dem EMIC-Webserver ausführlicher. Und ich habe
mit den Jungs auch schon auf Messen gesprochen. Kommunikativ sind die
durchaus. Habt ihr denn mal per Email nachgefragt?

>>>MySQL Cluster
>>>ist (angeblich) nicht kompatibel mit Typo3, und darum geht es auch.
>>
>>
>>
>> Typo3? Und dahinter einen Cluster wegen der *Performance* ???
>> Bruhahaha. YMMD.
>
> Das sagt niemand.

Dann haben wir uns wohl nochmals mißverstanden.

> Es geht um die HA. Aber das soll nicht
> notwendigerweise als _Bremse_ wirken. Wenn man das mit MySQL replication
> und IP failover hinbekommt, soll es auch gut sein.

Naja, der Vorteil von m/cluster ist halt, daß man
a) alles schlüsselfertig bekommt und
b) synchron repliziert wird

Eine Eigenbau-Lösung auf Basis der MySQL-Replikation stellt definitiv
höhere Anforderungen an den Betreiber, wenn man das gleiche Level wie
mit m/cluster erreichen will. Synchrone Replikation geht so gar nicht.

Deswegen *kann* das trotzdem die bessere Lösung sein. Habe ich selber
schon so aufgesetzt und das läuft mittlerweile seit gut 2 Jahren ohne
Probleme.

>> Typo3 ist so ziemlich das lahmste (vor allem: per Design lahme)
>> CMS, das mir je untergekommen ist. Für den Karnickelzüchterverein
>> Hintertupfingen mit 10 Pageviews am Tag mag Typo3 geeignet sein.
>
> Das kann ich ja mal den Leuten erzählen, die das ausgesucht haben, und
> denen, die das einsetzen :-)
> Ansonsten: um welche CMSs geht es und wie hast du das ermittelt?

Ich habe mir den Code angeschaut. Aber schon die Idee, eine Template-
Engine in PHP (das ja selbst eine Template-Engine ist) zu schreiben,
finde (nicht nur) ich schon ziemlich pervers. Rasmus Lerdorf (der
Vater von PHP) hat dafür letztens in seinem Vortrag "Efficient PHP"
auch sehr deutliche Worte gefunden.

>> Nachteile gibts aber auch reichlich:
>> - proprietär, es wird ein gepatchtes MySQL verwendet, daher dem
>> aktuellen Stand immer hinterher
>
> Da ich die Testsoftware noch nicht gezogen habe: welche MySQl-Version
> steckt da drin?

Über die aktuelle Release kann ich nichts sagen. Aber der Wechsel von
4.0 auf 4.1 erfolgte bei EMIC wohl ein halbes Jahr später (oder wars
von 3.23 auf 4.0? Ist lange her).


XL

Re: m/cluster Durchsatz

Axel Schwenke wrote:
> Herbert Pophal wrote:
>

> IIRC war die Doku auf dem EMIC-Webserver ausführlicher. Und ich habe
> mit den Jungs auch schon auf Messen gesprochen. Kommunikativ sind die
> durchaus.

Im Gegensatz zur Website.

> Habt ihr denn mal per Email nachgefragt?

Noch nicht.

> Eine Eigenbau-Lösung auf Basis der MySQL-Replikation stellt definitiv
> höhere Anforderungen an den Betreiber, wenn man das gleiche Level wie
> mit m/cluster erreichen will. Synchrone Replikation geht so gar nicht.
>
> Deswegen *kann* das trotzdem die bessere Lösung sein. Habe ich selber
> schon so aufgesetzt und das läuft mittlerweile seit gut 2 Jahren ohne
> Probleme.

Was mir noch nicht klar ist: wie macht man einen mysql-slave zum master?
Habe ich da in der Doku bei mysql.com was übersehen?

[lahmes Typo3]

> Ich habe mir den Code angeschaut. Aber schon die Idee, eine Template-
> Engine in PHP (das ja selbst eine Template-Engine ist) zu schreiben,
> finde (nicht nur) ich schon ziemlich pervers. Rasmus Lerdorf (der
> Vater von PHP) hat dafür letztens in seinem Vortrag "Efficient PHP"
> auch sehr deutliche Worte gefunden.

Anders geasgt: ein interpretierender Interpreter.

>>Da ich die Testsoftware noch nicht gezogen habe: welche MySQl-Version
>>steckt da drin?
>
>
> Über die aktuelle Release kann ich nichts sagen. Aber der Wechsel von
> 4.0 auf 4.1 erfolgte bei EMIC wohl ein halbes Jahr später (oder wars
> von 3.23 auf 4.0? Ist lange her).

Ein weiterer Punkt, über den sich die Website ausschweigt :-( Statt
dessen wird für jedes */cluster nahezu der gleiche Text benutzt.

Herbert

Re: m/cluster Durchsatz

Herbert Pophal wrote:
> Axel Schwenke wrote:
>
>> Eine Eigenbau-Lösung auf Basis der MySQL-Replikation stellt definitiv
>> höhere Anforderungen an den Betreiber, wenn man das gleiche Level wie
>> mit m/cluster erreichen will. Synchrone Replikation geht so gar nicht.
>>
>> Deswegen *kann* das trotzdem die bessere Lösung sein. Habe ich selber
>> schon so aufgesetzt und das läuft mittlerweile seit gut 2 Jahren ohne
>> Probleme.
>
> Was mir noch nicht klar ist: wie macht man einen mysql-slave zum master?

Sobald ein mysqld mit Option log-bin läuft, kann er als Master für
beliebig viele Slaves dienen. Ein mysqld kann also durchaus beides
sein, Master und Slave. Da allerdings immer nur ein Master erlaubt
ist, kann man nur entweder Ketten, Bäume oder Ringe bauen. In der
Spache der Graphentheorie einen gerichteten Graphen, dessen Knoten
einen inbound-Grad von maximal 1 haben.


XL

Re: m/cluster Durchsatz

Ich danke für die bisherigen Beiträge.

grietinx
Herbert