MySQL Petition

Harald Weidner hweidner-lists at gmx.net
Mo Jan 4 20:32:23 CET 2010


Hallo,

>> Wenn man minimale Regeln beim Tabellendesign beachtet,
>> kann man mit MySQL, MyISAM Tabellen und Replikation vollkommen
>> Locking-freie Read-Mostly Anwendungen bauen 
>
>Jenun, dass MySQL jetzt auch Rowlocking statt nur Tablelocking kann
>halte ich jetzt nicht so für den Brüller... 

Genau lesen. Ich habe von MyISAM geschrieben, und das unterstützt gerade
*kein* Rowlocking. Es kann aber bei Einhaltung gewisser Regeln in einer
Weise benutzt werden, in der man bei typischen Web-Anwendungen auf Locking
ganz verzichten kann, und gerade das macht es so performant.

>> und damit bei Web-Ausspielanwendungen eine Skalierung mit nahezu
>> 100% Effizienz erreichen.
>
>Was ist mit "100% Effizienz" gemeint?

Das, was man üblicherweise in der Technik damit meint: Wenn eine Anwendung
statt auf einem auf n Servern betrieben und ihre Performance dadurch um den
Faktor n erhöht wird.

Oder um es mit den Worten von Wikipedia zu sagen: "Effizienz ist das
Verhältnis zwischen der Größe der erbrachten Leistung und der Größe des
Aufwandes"

>> Ich wüsste kein anderes DBMS, mit dem das auch geht.
>
>PostgreSQL, zB. Das hat auch den Vorteil, dass es im Gegensatz zu
>MySQL auf Mehrkernmaschinen diese Kerne auch nutzt und nicht mit der
>kaputten Architektur von MySQL zu kämpfen hat (Trennung
>Server/Storageengine) 

PostgreSQL kann das von mir beschriebene Szenario definitiv nicht, zum einen
weil es die dazu nötigen Replikationsmechanismen (noch?) nicht kennt und zum
anderen die Lockingfreiheit in Read-Mostly Anwendungen prinzipbedingt nicht
unterstützt.

PostgreSQL ist ein klassisches transaktionsorientiertes DBMS, dass seine
Stärken dann ausspielt, wenn man eine Read:Write Ratio von annähnernd 1:1
hat. Also z.B. bei ERP Anwendungen, Bestellsystemen, Kontenbuchungen, eben
Transaktionsverarbeitung. Damit steht es in direktem Wettbewerb zu Oracle
und auch InnoDB. Read-Mostly Anwendung funktionieren völlig anders.

Die Skalierung von MySQL < 5.4 über mehrere CPU-Kerne ist zwar bedauerlich,
spielt aber in dem beschriebenen Szenario keine Rolle. In dem typischen
Setup zur horizontalen Skalierung wird der komplette Ausspielserver mitsamt
Webserver, Application Server und DBMS auf mehrere Maschinen repliziert. Das
DBMS kann und darf man dabei gerne lokal an die Menge von CPU Cores binden,
mit der es optimal läuft. Mit MySQL >= 5.4 ist das Problem ohnehin
Geschichte.

>Man soll Mysql aufrotten wo man es finden kann... *fiiiep* 
>flamewar fackeln wir dann auf linux-users-discussion ab, oder? ;-)

Ich diskutiere nur über technische Fragestellungen, an Flamewars beteilige
ich mich grundsätzlich nicht.

Gruß, Harald



Mehr Informationen über die Mailingliste Linux-Users