VMS Vorschlag: MyISAM gegen InnoDB

[eRaaaa]

was spricht im allgemeinen eig. gegen eine innodb engine?
gerade bei so vielen transaktionen, find ich es sinnvoll...wollte schon bei sehr vielen addons (z.b. bonuslosehandel) transaktionssicherheit einbauen, was ja bekanntlich myisam leider nicht unterstützt...auch fremdschlüssel wäre doch was tolles. da beim vms sehr viele transaktionen vonstatten gehen, wäre das doch sinnvoll? über ne kleine diskussion würd ich mich freuen :)

[Sebmaster]

Hab dazu mal eben ein eigenes Thema gemacht:wink:

Ich bin dagegen, da InnoDB durch die Transaktionssicherheit etc. um einiges langsamer ist:der:

Vor allem, weil es relativ viele Abfragen gibt (die in den Addons eh nicht durch Transaktionen gesichert werden, weil die Addons meist ziemlich... ja, wissen wir ja) und MyISAM da schneller ist.:wink:

Kurz: Transaktionen wird (fast) kein Addon-Bauer verwenden, und nur fürs Standard-Script meiner Meinung nach nicht nötig:hand:

[jpwfour]

Sicherlich wäre InnoDB für manche Tabellen praktisch und sinnvoll.

Besonders da je nach Einsatz das mit der Performanz auch nicht unbedingt zutrifft (1 (http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/)), andererseits ist es nicht unbedingt notwendig (da ja viele VMS1' mit vielen Usern auch so ohne größere Probleme laufen).

Punkt 2 und 3 muss ich Sebmaster zustimmen, wenn sich jemand mit beschäftigt kann er für sich selber das umstellen, aber der Großteil der Nutzer braucht das nicht bzw. beschäftigt sich eh zu wenig mit dem Thema :yes:

Und warum kann man im VBB keine Footnotes machen? (Oder warum weiß ich nichts davon? :biggrin1:)

[breaker]

Gescheite Querys und/oder Subquerys ohne Cross-Tables würden da schon mehr reissen als eine komplette Umstellung auf Inno, passend dazu dann natürlich auch PHP5-Klassen, um nicht jeden fetzen Code 100 mal im Script zu haben ;)

[tampulin]

�

[breaker]

Da ist Klärungsbedarf. Wie begründest du diese Aussagen?

Ich hatte vor ca 8/9 Monaten mal eine Mysql-Query (einfache Bedingungen) welche über 3-4 Tabellen ging und rund 15000 Datensätze liefern sollte, die Query hat bei mir (Netzwerk-server: 2 x 2 GHz, 3 GB Ram) rund 40 Sekunden gedauert.

Nachdem ich die Query komplett neu geschrieben habe (left join) hat die gleiche Query mit den gleichen Datensätzen und der gleichen Anzahl der Datensätze nurnoch rund 0,05 Sekunden gedauert.....Das meinte ich mit gescheite Querys bauen ;)

Der Unterschied war so gewaltig, das ich heute 10 mal prüfe, wie schnell die Query ist....Query ist eben nicht Query ;)

Das PHP OOP-Klassen 20% Performance brauchen halte ich für "aus der Luft gegriffen", genauso das ein gescheiter SQL-Layer bis zu 60% braucht....wo nimmst du solche Weisheiten her? Klammforum?

[Sebmaster]

...

Ich denke dein vorheriger Post kam so rüber, als würdest du lieber ein paar mehr Anfragen an die DB stellen:biggrin1:


genauso das ein gescheiter SQL-Layer bis zu 60% braucht....wo nimmst du solche Weisheiten her?

*gähn* Also wenn wir uns über sowas streiten, dann könnte wir ja gleich ab PHP 5.3 auf den nativen MySQL-Treiber (http://dev.mysql.com/downloads/connector/php-mysqlnd/) umstellen...

Abgesehen davon wurde das Objektmodell in PHP 5 um einiges verbessert (http://www.ister.org/code/article/de/phpbench51.html) (gegenüber von PHP 4). Nichtsdestotrotz verlangt es immer noch mehr Power ab, als einfaches reinschreiben des Codes...

[breaker]

Ich denke dein vorheriger Post kam so rüber, als würdest du lieber ein paar mehr Anfragen an die DB stellen:biggrin1:

Wenn ich eine unbekannte DB mit verschiedenen Kollationen habe, bleibt mir schon fast nichts mehr anderes übrig, den ein Subselect oder LEFT / RIGHT / OUTER / INNER sowie GROUP schlägt da fehl und funktioniert nur, wenn alle Tabellen die gleiche Kollation haben.
Da das aber die wenigsten wissen, werden sie aufgeben und einzelne Querys machen......

[Sebmaster]

...

Hmm, das Problem mit den Kollationen hatte ich schon beim Adscan-Addon, aber ich hab keine Ahnung, warum mir der andere Kollationen in meine Tables reinstopft, als in die vom Standard-VMS:frusty:

[breaker]

Hmm, das Problem mit den Kollationen hatte ich schon beim Adscan-Addon, aber ich hab keine Ahnung, warum mir der andere Kollationen in meine Tables reinstopft, als in die vom Standard-VMS:frusty:

vll hilft dir ja das weiter ;)

mysql_query('SET NAMES latin1, CHARACTER SET latin1;');

[Sebmaster]

vll hilft dir ja das weiter ;)

mysql_query('SET NAMES latin1, CHARACTER SET latin1;');

Aber ich kann doch nicht in fremden DBs Einstellungen verändern:eek:

[tampulin]

�

[breaker]

Aber du kannst definieren in welchem Format du die Ausgabe haben möchtest.
Genauso gibt es auch die Möglichkeit die Formate in MySQL beim Select ect. umzuwandeln.

dev.mysql.com (http://dev.mysql.com/doc/refman/5.1/en/charset-collate-tricky.html)

@breaker
Nein, mit dem Klamm-Forum habe ich nichts zu tun, eigentlich auch nicht mit diesem hier.
Die Werte beziehe ich aus eigenen Informationen, mehr möchte ich dazu nicht sagen.

Ich bin auch nicht gegen OOP oder Abstraction-Layer. Nur dagegen, dass die in das VMS einfließen und dem Grundscript eine gewisse Komplexität und Richtung geben, die die meißten Benutzer hier und im Klammforum z.B. nicht verstehen würden.

Wie Sebmaster bereits sagte, ein Ableger oder eine andere Entwicklungsversion wäre besser dafür geeignet. Aber hier geht es eigentlich auch nur um Innodb ja / nein, daher ist mir dein Beitrag direkt aufgefallen und las sich wie von einem durchschnittlichen Klamm-User dahingeklatscht ohne jegliches Wissen.

Und was dein DB-Server an Hardware hat ist ja ganz toll *g* aber unter welchen Einstellungen hast du den MySql-Server laufen lassen? Table-Cache auf 64 wie in der Standard-Konfiguration? Btt

Das mit dem Server ist ja der Punkt...der hat eigentlich nichts anderes zu tun, wie die Klamotten Routen und ein paar Dienste bereit zu stellen, deshalb ist da auch eine Performance, wie sie sonst nur von guten Root-Servern bereit gestellt werde,- trotzdem hat die Query am anfang rund 40 Sekunden benötigt und war erst nach einem Umstellen richtig schnell ;)

[breaker]

Nur zur Info....das Script, an dem ich gerade Arbeite, wird in ca 6-7 Monate fertig sein ....und beinhaltet dann nur PHP5-Klassen ;)



public static function getInstance()
{
if (self::$instance == null)
{
self::$instance = new admin($aname = false);
}
return self::$instance;
}

protected function __construct($aname = false)
{
if ($aname !== false)
{
$this->aname = pAddslashes($aname);
}
$this->sql1 = false;
$this->data_db = array();
}

private function __clone()
{
die('Please use the instance');
}