[Datenbanken] Liegt die Zukunft von MySQL bei MariaDB?

Hallo zusammen,

ich möchte Euch fragen, wie Ihr die Zukunft von MySQL seht, vor allem, was Euren persönlichen Umgang damit in Vergangenheit und in Zukunft angeht.

Zuerst zu meinem Hintergrund (wem das zuviel Text sein sollte, der kann gleich unterhalb der Aufzählung weiterlesen):

• Ich habe in der Zeit von 1999 bis 2003 Jahren privat und beruflich recht viel mit MySQL zu tun gehabt und war damals sehr überzeugt von der Datenbank (im Sinne von "da kann man doch eigentlich alles damit machen, was haben die anderen immer nur die Subselects, usw. verlangen"). Ein MS-SQL-Server war in meiner damaligen Firma auch für das eine oder andere Projekt im Einsatz, hat bei mir aber vor allem problematische Erinnerungen hinterlassen, die ihn zumindest zum damaligen Zeitpunkt als aus meiner nicht einsetzbar aussehen ließen (mal völlig außen vorgelassen, dass ich damals wie heute von Server-Umgebungen auf einer Windows-Plattform nicht viel halte).
  
• Dann kam erst einmal eine Zeit bis 2006, in der ich beruflich weniger mit Datenbank-Modellierung zu tun hatte, mich dafür aber per JDBC-Treiber an vorhandene Datenbanken, die vorrangig Oracle-basiert waren, angedockt habe. In dieser Zeit habe ich gelernt, dass MySQL unglaublich Endbenutzer-freundlich ist was den Kommandozeilen-Client "mysql" und die Administration mit "phpMyAdmin" angeht, dafür aber auch tatsächlich einige Funktionen gefehlt haben, die für den heterogenen vernetzten Business-Einsatz von Belang sein können (in meinem damaligen Tätigkeitsbereich wäre z.B. ohne Trigger nichts gegangen). An Oracle hat mich damals am meisten gestört, dass die Werkzeuge "Toad" und "SQL Navigator", die mir zur Verfügung standen, so schlecht benutzbar waren, dass man dauernd am Fluchen ist, und man nicht ohne weiteres Spalten bei einer Tabelle hinzufügen konnte, schon gar nicht an einer frei wählbaren Position.
  
• Von 2006 bis vor kurzem habe ich MySQL beruflich und auch privat ziemlich links liegen lassen, weil wir in unserer Firma mit der PostgreSQL-Datenbank mit der PostGIS-Erweiterung GIS-Software entwickelt haben. An PostgreSQL finde ich vieles faszinierend, es ist eigentlich die ideale Datenbank, das die meisten Bequemlichkeits-Vorteile von der "kleinen" MySQL und die Feature-Vorteile der "großen" Datenbanken wie Oracle in einem freien Produkt vereint. (Nebenbei: bei neuen Spalten kann man zwar auch bei PostgreSQL die Position nicht frei bestimmen, aber man kann sie wenigstens ansonsten problemlos ergänzen).
  
• Aktuell: seit April bin ich in einer neuen Tochterfirma im Konzern, die u.a. Webprojekte für den internen Bedarf und externe Kunden realisiert. Meine ausschließliche GIS-Software-Entwicklungstätigkeit mit PostgreSQL hat sich auf moderate Weiterentwicklung für interne Zwecke reduziert, dafür sind andere Projekte in mein Tätigkeitsfeld gekommen, die mich wieder mehr mit MySQL und Oracle zusammenbringen.
  Bei Oracle merke ich, dass es immer noch unglaublich schwierig ist so etwas einfaches wie einfach mal einen SQL-Dump des Datenbankschemas zu bekommen (was mit mysqldump und pg_dump nicht mehr als ein Fingerschnipp ist), trotzdem werde ich meine Oracle-Kenntnisse in nächster Zeit erweitern müssen.
  Ich persönlich würde ja nahezu alle MySQL-Projekte eher mit PostgreSQL realisieren, aber PostgreSQL ist a) in meinem neuen Team bisher nicht präsent und steht b) nicht auf allen relevanten Webspace-Plattformen zur Verfügung, so dass ich verstehen kann, dass hier eher MySQL-basiert entwickelt wird.

Nun meiner eigentlichen Frage aus dem Thread-Titel: wenn ich heute auf die MySQL-Homepage schaue, bin ich als Nutzer der Community-Version völlig verwirrt, wie ich ohne Zuhilfenahme von Google die normale Dokumentation auffinden soll. Schon unter der Führung von Sun hat es die Firma MySQL geschafft, die Bedeutung der weit verbreiteten Community-Version herunterzuspielen und die Dokumentation in einen Entwicklerbereich zu verstecken. Aber seit einigen Monaten ist selbst dieser Entwicklerbereich mit der Dokumentation nicht mehr auffindbar, wenn man sich zielsuchend auf der MySQL-Homepage bewegt. Vielleicht stelle ich mich auch nur irgendwie dumm an, aber ich gewinne den Eindruck, wie wenn Oracle die Nutzer der Community-Version langsam aber sicher loswerden möchte.

Da denke ich auf einmal daran, dass der Gründer von MySQL Monty Widenius vor ein paar Monaten Sun verlassen hat und ein Fork-Projekt namens "MariaDB" angekündigt hat. So wie es scheint hat er auch einige der ursprünglichen MySQL-Entwickler im Team. Die MariaDB-Homepage hat zwar anscheinend noch keinen vollwertigen Ersatz für die MySQL-Dokumentation, aber es macht doch einen Eindruck, wie wenn die Nutzer der Community-Version eher hier ihr Glück finden könnten.

Was meinen diejenigen von Euch, die MySQL benutzen, werdet Ihr ausschließlich bei der "Oracle"-Version von MySQL bleiben oder streckt Ihr auch schon die Fühler aus, ob Ihr mit MariaDB oder evtl. sogar einer ganz anderen Datenbank wie PostgreSQL arbeiten möchtet?

Tjo, was diese "MariaDB" angeht, kann ich nicht viel sagen. Außer dass man vielleicht noch etwas abwarten sollte, bis man das produktiv einsetzt (um zu sehen wie sich das so entwickelt).

Was Dir bei MySQL vielleicht helfen könnte ist folgender Link: http://dev.mysql.com/. Darüber ist für mich jedenfalls alles Wesentliche erreichbar.

Danke für den Link, aber um den ging es mir gar nicht so sehr, da man die Dokumentation mit einer Suchmaschine ja problemlos finden kann. Mich beschäftigt viel mehr die Tatsache, dass man auf der normalen MySQL-Webseite gar nicht mehr zu der Dokumentation hingeführt wird, sondern nur die kommerziellen Produkte angeboten werden, und die Intention dahinter (klar, die wollen Geld verdienen, aber hat das MySQL AB früher nicht auch schon getan?).

anscheinend nicht genug, sonst wären sie kaum gekauft worden...
Oracle ist auch nicht gerade bekannt dafür eine besonders Opensource lastige Firma zu sein und igendwas für umsonst zu verteilen... allerdings haben sie ja eignetlich schon "große" datenbanken...
Aber klar, MySQL war denen wohl schon lange ein dorn im auge...stellt euch mal vor jeder forenbesitzer hätte eine oracle-lizenz kaufen müssen

Zu dem Thema "Zukunft von MySQL" gibt es spannende Entwicklungen:

• MariaDB hat eine neue Version veröffentlicht und auch die Homepage zumindest einer optischen Generalüberholung unterzogen. Mit dem neuen Dokumentationsbereich kann ich mich noch nicht ganz anfreunden.
• Es hat sich in den letzten Wochen noch eine zweite Organsiation namens SkySQL gebildet, die ebenfalls aus ehemaligen MySQL AB-Mitarbeitern besteht. Hier ein Statement von Patrik Backman dazu.

Ein großer Problemfall ist wahrscheinlich tatsächlich noch der Bereich Dokumentation, da MariaDB derzeit noch keine eigene Dokumentation aufweist. Diese muss wahrscheinlich neu geschrieben werden, da die Copyrights für die Texte nun bei Oracle liegen. Ich frage mich nur, wie lange Oracle das zulässt, dass die MySQL-Dokumentation auch für nicht-MySQL-Nutzer frei im Internet abrufbar ist.

Ansich bin ich ja (wie schon im Eingangs-Posting erwähnt) eher pro-PostgreSQL eingestellt, aber eine gesunde Weiterentwicklung einer freien MySQL-Version kann ich nur begrüßen.

Edit: Noch eine Frage an Euch: Sieht jemand von Euch bei der eigentlich MySQL-Entwicklung bei Oracle nicht schwarz?

Ge0rgy schrieb:

stellt euch mal vor jeder forenbesitzer hätte eine oracle-lizenz kaufen müssen

Zum Vergrößern anklicken....

Das hätten 99% der Forenbesitzer nicht getan, stattdessen hätte es keine Foren gegeben, oder Postgres-basierte, oder textdatei-basierte... mySQL ist toll, aber Oracle ist für 97% der Einsatzzwecke von MySQL kein adäquater Ersatz. Entweder war Oracle strunzdoof, als ihnen MySQL ein Dorn im Auge war, oder sie haben mySQL zur Stärkung der Marke Oracle gekauft, oder s geht ihnen tatsächlich um die 3% der MySQL-Nutzer, die auch Oracle-DBs kaufen würden...

Antarctica schrieb:

Das hätten 99% der Forenbesitzer nicht getan, stattdessen hätte es keine Foren gegeben, oder Postgres-basierte, oder textdatei-basierte... mySQL ist toll, aber Oracle ist für 97% der Einsatzzwecke von MySQL kein adäquater Ersatz. Entweder war Oracle strunzdoof, als ihnen MySQL ein Dorn im Auge war, oder sie haben mySQL zur Stärkung der Marke Oracle gekauft, oder s geht ihnen tatsächlich um die 3% der MySQL-Nutzer, die auch Oracle-DBs kaufen würden...

Zum Vergrößern anklicken....

Oracle strunzdoof oder scharf auf ein paar wenige, die nicht wissen was sie brauchen? Wohl eher nich

Oracle hat MySQL gekauft weil die Datenbank eben nur minimal im Markt der OracleDB wildert, sondern andere Märkte besetzt. Man hat sich neue Märkte damit erschloßen, nicht einen direkten Konkurrenten beseitigt.
Im Grunde hast Du es schon gesagt. Auch wenn MySQL gern als die große Alternative gefeiert wird, in Unternehmen werden MSSQL und Oracle nicht eingesetzt, weil sie so viel toller sind als MySQL. Eingesetzt werden die, weil sie integriert in komplexen Infrastrukturen entscheidender Anwendungen daherkommen. Die Frage nach MySQL stellt sich meist gar nicht, wenn es um dedizierte DB-Server in Konzernen geht, ganz einfach weil ein oder mehrere professionelle Anwendungen sowieso MSSQL oder Oracle erfordern und es dazu keine MySQL-basierten Alternativen gibt.
Mit dem MySQL-Aufkauf will man nun halt auch an den IT-Buden verdienen die dank anderer Anforderungen (Hosting oder ähnlicher Kram) mit MySQL gut leben können, aber nicht auf Support verzichten können.

Größtes Problem der freien Datenbanken ist halt immer, dass MS/Oracle alle Aufgaben von ihnen übernehmen kann. Aber MySQL/Postgre nunmal noch lange nicht alle Aufgaben der proprietären übernehmen darf/kann.

yourgreatestfear schrieb:

Größtes Problem der freien Datenbanken ist halt immer, dass MS/Oracle alle Aufgaben von ihnen übernehmen kann. Aber MySQL/Postgre nunmal noch lange nicht alle Aufgaben der proprietären übernehmen darf/kann.

Zum Vergrößern anklicken....

Was ich sagen wollte, war aber, dass 97% der MySQL-Anwender nicht auf Oracle migrieren würden, wenn es zwingend erforderlich würde, um die ANwendung weiterzubetreiben. Stattdessen würde die Anwendung gewechselt oder das Angebot eingestellt.

Damit ist ein Szenario à la "stellt euch mal vor jeder forenbesitzer hätte eine oracle-lizenz kaufen müssen" ziemlich abwegig...

Denn andersherum: das größte Problem von MS/Oracle ist halt immer, dass die meisten, die freie Datenbanken nutzen, sich den Einsatz von MS/Oracle nicht leisten können und/oder wollen...

Antarctica schrieb:

Was ich sagen wollte, war aber, dass 97% der MySQL-Anwender nicht auf Oracle migrieren würden, wenn es zwingend erforderlich würde, um die ANwendung weiterzubetreiben. Stattdessen würde die Anwendung gewechselt oder das Angebot eingestellt.

...

Zum Vergrößern anklicken....

Da würde simpel gerechnet werden. Und es ist fast immer billiger eine Serverlizenz zu erwerben als Belegschaft und Clientmaschinen auf eine alternative Anwendung umzustellen bzw. teure Migrationen dahin zu bezahlen.
Wenn ich aber lese 'Angebot eingestellt', dann vermute ich mal in vielen Köpfen wird MySQL nur auf Webhostern für paar bunte Seiten verstanden. Die dicke Asche machen MS und Oracle aber mit den tausend anderen DB-Anwendungen. Eine Datenbank zu wechseln ist in keinster Weise trivial für die meisten Anwendungen. Wenn ein Unternehmen einmal sich entschieden hat bleibt es meist für Jahre daran kleben. Leider darf ich nicht frei über die Infrastrukturen meiner Kunden plaudern, aber da faulen so einige uraltDBs vor sich hin, nur weil eine bestimmte Anwendung vor 15 Jahren dafür geschrieben wurde. Wenn in solchen Fällen die Serverkosten durch Lizenzen etc. steigen wird das in Kauf genommen angesichts der ungewissen Kosten und Risiken eines Wechsels.
Solange wir Entwickler nicht dafür bezahlt werden plattformunabhängig (genauer gesagt DBunabhängig) zu entwickeln, so lang wird es auch in Zukunft eher so sein, dass man ein paar teure Serverlizenzen einer Migration vorzieht.

yourgreatestfear schrieb:

Solange wir Entwickler nicht dafür bezahlt werden plattformunabhängig (genauer gesagt DBunabhängig) zu entwickeln, so lang wird es auch in Zukunft eher so sein, dass man ein paar teure Serverlizenzen einer Migration vorzieht.

Zum Vergrößern anklicken....

DB-unabhängig zu entwickeln bedeutet aber in den meisten Fällen (und gerade wo es notwendig ist) Kompromisse in Sachen Funktionalität und Geschwindigkeit eingehen zu müssen.
Und das ist mehr als ein fauler Kompromiss wenns darauf ankommt, ein kleinster gemeinsamer Nenner eben.

Hibernate und Konsorten zeigen ja vor wie es mehr schlecht als recht geht.
Niemand würde sowas für performancekritische Sachen einsetzen.

lg
__tom

Performance, Funktionalität und DB-unabhängig schließt sich nicht gegenseitig aus, nur will es keiner bezahlen.

Aber gerade Performance ist auf den Anforderungslisten meist einer der allerletzten Punkte. Da hat Microsoft mit ihren Monstern wie Sharepoint die Kundschaft ordentlich leiden lassen, so dass die meisten Produkte performant wirken ganz ohne Optimierung.

Es gibt aber leider Dinge die nicht unabhängig sind, wie spezielle sql-syntaxe oder tablespaces, Indexformen, Materialized Views, Stored Procedures usw.
Nicht nur der SQL Dialekt alleine macht eine DB aus.

lg
__tom

Und? Was hindert mich daran dies in der entsprechenden Schnittstelle meiner Anwendung zu implementieren?
Sobald stored procedures und komplexere views ein Thema darstellen ist man meist sowieso von Datenbanken wie MySQL weit entfernt. Solche Späße hab ich bisher nur in Oracle- und MSSQL-DBs bei Kunden gefunden.

Als Beispiel sei hier Peoplesoft genannt. Das kann man auf Oracle, MSSQL und im Notfall auch MySQL und Postgre betreiben. Dazu wird ein Rewritelayer eingesetzt, der PeopleSQL auf die verschiedenen DB Eigenheiten übersetzt. Und Peoplesoft ist eine ziemlich Performancekritische Anwendung.

Peoplesoft ist die schlimmeste Krätze was es punkto Datenbank und Datenbankdesign gibt was ich je erlebt habe.
Von perfomant kann bei diesem sog. "Datenmodell" in keinster weise eine Rede sein.
Wenn das Plattformunabhängigkeit bedeutet dann gute Nacht.

lg
__tom

Wir nutzen hier Firebird SQL und teilweise auch NHibernate und werden wohl über kurz oder lang ganz uaf Nhibernate umstellen. Zu jeder Kritik im bezug auf Performance findet man wieder zich Artikel die diese kritik wiederlegen und umgekehrt. Von daher halte ich solche generellen Aussagen wie "Hibernate und Konsorten zeigen ja vor wie es mehr schlecht als recht geht. Niemand würde sowas für performancekritische Sachen einsetzen." nicht unbedingt für so sinnvoll. Das geht meistens in Richtung Fanboy Diskussionen wenn man sich mal länger damit beschäftigt. Wirklich Objektive Aussagen sind da leider sehr sehr rar gesäht. Einen ganz tollen Artikel (den ich leider gerade nicht parat habe) gibts da z.B. von jemandem der eben auch sagt Hibernate sei schlecht und langsam. Sucht man dann mal nach dem Typen im netz, findet man raus das es der Chef von einer Firma ist die mit einem eigenen OR-Mapper Geld verdienen will

Gibt ja auch so ein paar nette Benchmark Seiten die mit sehr Realitätsfernen Tests immer mal wieder zeigen das (N)Hibernate langsamer ist, dann aber in Interviews zugeben das ihre Tests nicht so aussagekräftig sind.

Ich will damit nicht sagen das (N)Hibernate ein Allheilmittel ist und sicher ist es auch in bestimmten Anwendungszenarien nicht die klügste Wahl, aber generell zu sagen es wäre nur mehr schlecht als recht umgesetzt halt ich halt für unpassend. Das trifft wenn dann wohl eher auf die mangelhafte Dokumentation zu die sich dann in einer enormen Lernkurze bzw. langen Einarbeitungszeit niederschlägt.

Grundsätzlich, und da wirst Du mir zustimmen, gibt es keine Abstraktionsschicht die nicht ein Overhead bzw. Speckgürtel ist.
Ebenso gibt es kein "one fits all"-Wunder.
Kein Vorteil eben ohne Nachteil.

lg
__tom

Klar will ich das nicht abstreiten, dafür gibts eben Vorteile an anderen Stellen.
Ich meinte ja nur das man eben nicht so pauschal etwas verteufeln sollte.

tomturbo schrieb:

Peoplesoft ist die schlimmeste Krätze was es punkto Datenbank und Datenbankdesign gibt was ich je erlebt habe.
Von perfomant kann bei diesem sog. "Datenmodell" in keinster weise eine Rede sein.
Wenn das Plattformunabhängigkeit bedeutet dann gute Nacht.

lg
__tom

Zum Vergrößern anklicken....

Da kann ich dir nicht widersprechen. Aber ja, genau das bedeutet vollkommene Plattformunabhängigkeit. Was nichts daran ändert, das die Anwendung performancekritisch ist, da oftmals zentraler Bestandteil der Geschäftsoperationen. Du hast die freie Wahl, auf was du die Anwendung aufsetzt, bezahlst dafür aber den Preis, dass du richtig dicke Eisen drunter setzen musst, um ordentliche Antwortzeiten hin zu bekommen. Und ja, es gibt immer noch Firmen, die sich so etwas freiwillig antun...

Wobei sich das genauso anhört wie bei einer Sharepointumgebung, welche auch mörderische Maschinen verlangt obwohl es eine reine MS-Geschichte ist und extrem plattformabhängig ist.

Aber Plattformunabhängigkeit bedeutet nicht zwangsweise, dass Datenbankdesign grottig sein muss. Mir ist kein DBMS bekannt, welches technisch verhindert, dass ich eine saubere und schnelle Struktur verwende. Weder bei den proprietären noch bei den freien.

Eure Ausführungen finde ich auch ziemlich interessant, ich würde aber gern versuchen die Thematik dieses Threads von allgemeinen Datenbank-Themen und OR-Mappern wieder auf die Fragestellung "die MySQL-Zukunft in den Händen von Oracle" zu lenken. Mit dem Thread wollte ich eine Diskussion starten, wie die "Nische", in der MySQL aus div. Gründen sehr verbreitet ist (so klein ist diese Nische ja gar nicht), in Zukunft ausgefüllt werden kann.

Zum Thema: meiner Meinung nach errichtet Oracle (und Sun hat das in kleinerem Maßstab vorher auch schon gemacht) eine Mauer um MySQL, indem sie z.B. die Zugänglichkeit zu MySQL-Resourcen (wie die ursprünglich angesprochene MySQL-Dokumentation) zunehmend verschleiern, so dass sie derzeit nur über Suchmaschinen und nicht mehr über Verlinkung zugänglich ist. Sehen die MySQL-Benutzer unter Euch darin ein langfristiges Problem mit der Konsequenz Euch auch nach Forks wie MariaDB umzusehen die die Community-Weiterentwicklung eher vorantreiben, oder ist es Euch egal, so dass Ihr weiterhin beim Original-MySQL von Oracle bleiben werdet?

Kurzfristig ist vermutlich noch kein Handlungsbedarf, wenn Oracle so weitermacht, denke ich aber, dass in 2-4 Jahren u.U. die breite Masse der Entwickler und infolge auch Webhosting-Anbieter auf MariaDB o.ä. umschwenken könnten, Ein Knackpunkt wird vielleicht auch sein, wie lange MariaDB und evtl. andere MySQL-Forks die 100%-Kompatibilität zum originalen MySQL bewahren können. Außerdem muss eine neue Dokumentation für die Forks entstehen, da ich mir vorstellen kann, dass die originale MySQL-Dokumentation nicht übernommen werden kann.

Wie seht Ihr das?

Ich gehöre in Bezug auf Oracle eher zu den Skeptikern und denke nicht, dass dort tatsächlich der Wille besteht MySQL aktiv weiter zu entwickeln. Ich befürchte, dass MySQL ein ähnliches Schicksal droht wie OpenSolaris oder OpenOffice.org, daher sehe ich für MariaDB gute Chancen.

Andererseits wäre ein Geschäftsmodell mit kostenloser Open Source Version für Privatanwender und Lizensierung für Firmen natürlich auch denkbar, dann auch mit aktiver Weiterentwicklung.

Schwierige Frage

In der ganzen Geschichte steigt auf jeden Fall der Druck im Kessel immer mehr an, wenn ich das mal so metaphorisch ausdrücken darf. Siehe MySQL-Kenner wollen Oracle Konkurrenz machen auf Heise.

Benutzt schon einer von Euch MariaDB?

Rones schrieb:

Benutzt schon einer von Euch MariaDB?

Zum Vergrößern anklicken....

Nein. Wozu auch?

Solange es das "Original" gibt und zuverlässig seinen Dienst versieht, besteht nicht der geringste Anlass von MySQL zu wechseln.

Die Alternativen haben derzeit noch keine Vorteile sondern sind eher als Spielwiesen zu sehen.
Wer auf Stabilität setzt kann nicht ernsthaft einen Wechsel in Erwägung ziehen.

lg
__tom

MariaDB ist schon ganz schick. Je nach Einsatzzweck können CouchDB und MongoDB aber auch überzeugen.

Ich persönlich setze mittlerweile bei den meisten Projekten nur noch PostgreSQL ein - meine MySQL-Jahre habe ich schon länger hinter mir. PGSQL ist meiner Meinung nach an vielen Stellen überlegen.

Der Vergleich hinkt zwar, aber MSSQL ist wiederum noch beeindruckender. Damit durfte ich bei einem Auftrag mal arbeiten.