Hi,
Im Artikel heisst es:
> Gleichzeitig erhöht sich der Datendurchsatz, denn die Knoten
> halten ihre Daten im Hauptspeicher.
OK, prima Sache; nur: wenn schon im RAM, dann kann es sinnvoller
sein, gleich die fertigen Datenstrukturen persistent im RAM zu
halten, ohne den Umweg via SQL (z.B. mit Apache-Modulen in mod_perl
und globalen Variablen).
> Eine typische Konfiguration mit vier Knoten à zwei CPUs
> soll eine Antwortzeit von 5 bis 10 Millisekunden und einen
> Datendurchsatz von 100.000 replizierten Transaktionen pro
> Sekunde ermöglichen.
hupsassa.
Kurz zuvor stand aber doch: "halten ihre Daten im Hauptspeicher".
Transaktionen heisst aber normalerweise, dass die Daten permanent und
absturzsicher (!) auf Platte geschrieben sind. Und Repliziert sollte
ja heissen: eine Änderung, die auf allen Rechnern durchgeführt wird.
Die Kiste bzw. das Plattenarray, die da dann 100.000 Transaktionen
pro Sekunde kann, das will ich sehen: denn das sind 100.000
Schreibzugriffe pro Sekunde. Auch wenn sie von Postgres das
"commit_delay"-Feature abgeschaut haben, kommen da ein paar zu
schreibende Daten zusammen. Und der Overhead für Cluster/Replikation
und commit_delay usw. nicht zu vergessen.
Und 100.000 Transaktionen pro Sekunde mit einer durchschnittlichen
Dauer von 5 bis 10 ms, das heisst: im Schnitt sind 500 bis 1000
Transaktionen gleichzeitig *offen*. Schon wieder ein Hupsassa! Auch
das gibt einen netten Verwaltungsaufwand und nette Probleme.
Oder ist es mal wieder so, dass MySQL seine eigenen Begriffe
einführt? Transaktion wäre dann mit "Query" gleichzusetzen und die
100.000 "Transaktionen" wären dann 100.000 Queries bei den
problematischen MyISAM-Tabellen auf zwei mal vier Prozessoren
(welchen?)?
Mit MyISAM-Tabellen mit ihren Locks bei Schreibzugriffen und der
nicht vorhandenen Transaktionssicherheit?
Das ist dann lange nicht mehr so toll, und es stellt sich gleich die
nächste Frage: was für Queries? Welche Daten? Wieviel Daten? Bei
einem einfachen Select kriege ich auf meinem
Single-Prozessor-Athlon-2000XP+ mit Postgres auch 10000
Queries/Sekunde hin.
Und was ist mit den vielen vielen MySQL-Gotchas?
http://sql-info.de/mysql/gotchas.html
Kommt dann immer noch der 2. März raus, wenn man vom 31. Februar (!)
zwei Tage abzieht? ;-)
Also, irgendwie kann ich mich des Eindrucks nicht erwehren, dass es
sich hier hauptsächlich (nicht ausschließlich!) um Marketing-Blabla
handelt.
Ciao
Alvar, http://www.a-blast.de/ läuft leider noch mit MySQL,
MyISAM und ohne Transaktionen. Mit InnoDB: das Kritische
ca. 10 mal langsamer. :-(
Erste Tests mit PostgreSQL: deutlich schneller als MyISAM.
Tja -- wie war das mit "MySQL macht Kompromisse weil es
schnell ist?". Das gilt zumindest nicht immer ;-)
Im Artikel heisst es:
> Gleichzeitig erhöht sich der Datendurchsatz, denn die Knoten
> halten ihre Daten im Hauptspeicher.
OK, prima Sache; nur: wenn schon im RAM, dann kann es sinnvoller
sein, gleich die fertigen Datenstrukturen persistent im RAM zu
halten, ohne den Umweg via SQL (z.B. mit Apache-Modulen in mod_perl
und globalen Variablen).
> Eine typische Konfiguration mit vier Knoten à zwei CPUs
> soll eine Antwortzeit von 5 bis 10 Millisekunden und einen
> Datendurchsatz von 100.000 replizierten Transaktionen pro
> Sekunde ermöglichen.
hupsassa.
Kurz zuvor stand aber doch: "halten ihre Daten im Hauptspeicher".
Transaktionen heisst aber normalerweise, dass die Daten permanent und
absturzsicher (!) auf Platte geschrieben sind. Und Repliziert sollte
ja heissen: eine Änderung, die auf allen Rechnern durchgeführt wird.
Die Kiste bzw. das Plattenarray, die da dann 100.000 Transaktionen
pro Sekunde kann, das will ich sehen: denn das sind 100.000
Schreibzugriffe pro Sekunde. Auch wenn sie von Postgres das
"commit_delay"-Feature abgeschaut haben, kommen da ein paar zu
schreibende Daten zusammen. Und der Overhead für Cluster/Replikation
und commit_delay usw. nicht zu vergessen.
Und 100.000 Transaktionen pro Sekunde mit einer durchschnittlichen
Dauer von 5 bis 10 ms, das heisst: im Schnitt sind 500 bis 1000
Transaktionen gleichzeitig *offen*. Schon wieder ein Hupsassa! Auch
das gibt einen netten Verwaltungsaufwand und nette Probleme.
Oder ist es mal wieder so, dass MySQL seine eigenen Begriffe
einführt? Transaktion wäre dann mit "Query" gleichzusetzen und die
100.000 "Transaktionen" wären dann 100.000 Queries bei den
problematischen MyISAM-Tabellen auf zwei mal vier Prozessoren
(welchen?)?
Mit MyISAM-Tabellen mit ihren Locks bei Schreibzugriffen und der
nicht vorhandenen Transaktionssicherheit?
Das ist dann lange nicht mehr so toll, und es stellt sich gleich die
nächste Frage: was für Queries? Welche Daten? Wieviel Daten? Bei
einem einfachen Select kriege ich auf meinem
Single-Prozessor-Athlon-2000XP+ mit Postgres auch 10000
Queries/Sekunde hin.
Und was ist mit den vielen vielen MySQL-Gotchas?
http://sql-info.de/mysql/gotchas.html
Kommt dann immer noch der 2. März raus, wenn man vom 31. Februar (!)
zwei Tage abzieht? ;-)
Also, irgendwie kann ich mich des Eindrucks nicht erwehren, dass es
sich hier hauptsächlich (nicht ausschließlich!) um Marketing-Blabla
handelt.
Ciao
Alvar, http://www.a-blast.de/ läuft leider noch mit MySQL,
MyISAM und ohne Transaktionen. Mit InnoDB: das Kritische
ca. 10 mal langsamer. :-(
Erste Tests mit PostgreSQL: deutlich schneller als MyISAM.
Tja -- wie war das mit "MySQL macht Kompromisse weil es
schnell ist?". Das gilt zumindest nicht immer ;-)