Interner Fork von MySQL

http://www.heise.de/newsticker/Abspaltung-von-MySQL-fuer-Webanwendungen--/meldung/113186

"Viele Features, die in den letzten Jahren auf Druck von MySQL-Nutzern aus Unternehmen hinzukamen, fehlen in Drizzle: Stored Procedures, Trigger, Prepared Statements und Views. Auch der Query Cache fällt weg;"

Meiner Meinung nach ein falscher Schritt. Andere Unternehmen bauen zwar auch diverse Express-Versionen, die eine reduzierte Funktionalität haben, diese beschränkt sich aber zu 95% auf Kapazitäten (Speicherbegrenzung) und nur zu 5% auf Funktionalitätseinschränkungen (Geo-Datenbank, Clustering, etc).

Gerade Views, Prepared Statements und der Query Cache sehe ich im Webbereich als wichtig an.

Wenn Sun Probleme hat MySQL in der vollen Ausführung stabil zu halten, würde ich mir persönlich ein paar Gedanken über die Datenbank machen.

Halte das auch für keinen geschickten Schachzug.
Wer soll das denn bitte einsetzen?
Komplexere Webanwendungen werden ohne Query-Cache dann was für Masochisten, oder wie?

Über den Rest kann man vielleicht noch hinwegsehen, viele Webanwendungen verwenden diese Dinge eh noch nicht (kommen ja aus der MySQL 4.x Zeit...). Ist aber schmerzlich, wenn man mal etwas mehr vorhat.

Koennte mir vorstellen, dass es zu dem Schritt nicht durch die Nachfrage nach so einem Produkt kam. Vielleicht haben ein paar Entwickler genug von diesem Monstrum MySQL und wollen es entschlacken und eine schlanke, einfache und schnelle Datenbank anbieten.

Der Artikel erwaehnt ja, dass sie manche Features vielleicht wieder einbauen wollen (Query-Cache?). Ich weiss nicht was fuer eine Auswirkung ein Fehlender Query-Cache auf die Performance hat. Und ich habe auch nicht nachgeschaut aber ich kann mir vorstellen, dass einfache Webanwendungen wie Wordpress keine Stored Prozedures, Trigger usw. verwenden. Fuer so eine Anwendung waere das doch optimal.

Und im Desktop-Anwendungsbereich geht der Trend ja irgendwie zu schlanken, aufgeraeumten und schnellen Anwendungen (z.B. Firefox vs Mozilla Suite). Vielleicht denken sich die Entwickler im Serverbereich wird es auch dazu kommen - ein Beispiel faellt mir ein: apache vs lighttp.

Original von Toby

Halte das auch für keinen geschickten Schachzug.
Wer soll das denn bitte einsetzen?
Komplexere Webanwendungen werden ohne Query-Cache dann was für Masochisten, oder wie?

Bei größeren Anwendungen mit vielen ändernden Datenzugriffen (z.B. Browsergames) hilft der Query-Cache eher weniger. Die Queries müssen so schnell wieder aus dem Cache entfernt werden, dass dieser kaum noch genutzt wird.

Ich frag mich jedoch, ob ein Fork wirklich notwendig ist und ob man durch diese Optimierungen wirklich viele Server einsparen kann.

Klar, bei Browsergames usw ist der natürlich nicht so wichtig. Aber nehmen wir halt an, das es komplexe Abfragen auf einen relativ statischen (nicht viele Änderungen) Datenbestand gibt, da macht er dann doch wieder Sinn. Könnte z.B. Shops betreffen.