News Wikimedia setzt ab jetzt auf MariaDB

Auch MemSQL muss, um komplett ACID-compliant zu sein, genausoviel auf die Festplatte schreiben, wie ein normales InnoDB mit Bufferpoool > Dataset. Denn die Änderung muss vor beenden der Transaktion im Log persistent auf der Festplatte liegen. Da hilft auch kein magisches "wir sind eine In-Memory Datenbank".
Das sind Grundsätze der Implementierung von ACID, die nicht gebrochen werden können. MemSQL kann nur ACID lascher implementieren, dass nur alle Sekunde die Änderungen auf die Festplatte geflusht werden, und bis dahin nur im Ram sind (Serverausfall: max. 1 Sekunde Daten weg). Aber oh wunder, das ganze kennt auch schon InnoDB innodb-flush-log-at-trx-commit=2.

MemSQL ist genauso ein Wolkengebilde, wie die meisten NoSQL-Datenbank, nur deutlich besser getarnt. Reads werden nicht wirklich schneller, da auch ein InnoDB alles im Ram halten kann und die Schreibperformance kann man auch nur verbessern, wenn man ACID lascher implementiert, womit wir bei einem sekündlichen Flush sind oder uns noch weiter in Richtung der NoSQL-Datenbanken mit deutlich weniger Garantien bewegen.
Mal eine wirklich schöne kritische Meinung über die Benchmarks der MemSQL-Entwickler (!!), warum es in deren Tests schneller als MySQL ist. Und wie man genausogut das Gegenteil beweisen kann.
tl;dr: Man vergleicht eine standardmäßig optimierte MemSQL-Konfiguration gegen eine Standardkonfiguration von MySQL, die eben nur 128Mb Ram nutzt, kein Wunder, wenn MySQL dann lahm ist.
 
Gibts irgendwas, das für die Mehrheit der Benutzer besser geworden ist, seit Oracle es sich gekrallt hat? Solaris wird mehr auf gut zahlende Kundschaft zugeschnitten, die geforkten Varianten krebsen eher rum. ZFS wird nicht mehr herausgegeben, damit hat man bei >v28 (Filesystem-Encryption!) nen ultrahässliches Lock-In auf entweder Solaris-Basis oder die freien Abkömmlinge, die jetzt dazu inkompatible Featuresets bauen müssen. MySQL wird ebenfalls auf die $$$-Kunden geschneidert und Features dort zuerst rausgegeben, darum der Wechsel auf MariaDB. Dann war noch der Krampf mit OpenOffice, das inzwischen so Open ist, dass zig auch berufliche Entwickler jetzt zu LibreOffice gegangen sind, weils anders nicht mehr sinnvoll machbar ist. Was kommt noch? Java läuft nur noch, wenn parallel dazu Adware von Oracle im Vordergrund plärren darf?

Is ja verständlich, dass die Firma Geld verdienen will, aber manchmal wünsch ich denen echt was an den Hals...
 
ice-breaker schrieb:
Hier kacken aber auch NoSQL-Datenbanken ab, denn diese sind meist darauf ausgelegt nur wirklich so effizient zu sein, wenn der ganze Inhalt in den Ram passt, kein Wunder, ausm Ram lesen ist höllisch schnell.
Und spätestens bei vielen Änderungen an Indexstrukturen leidet eben die Performance, da helfen dann auch später keine spezialisierten Indexe mehr, irgendwo ist nunmal Schluss.



Kann mich dem Post von Daaron nur anschließen, NoSQL ist ein massiv überbewerter Hype. Es gibt reale Anwendungszwecke dafür, ohne Frage, diese sind aber weit geringer, wie NoSQL aktuell eingesetzt wird. Neija, irgendeine Sau wird immer durchs Dorf getrieben...
Erstmal ist NoSQL ja auch nicht gleich NoSQL...
So arbeitet MongoDB ja auch anders als z.B. JackRabbit oder Db4o...
Wir stellen derzeit ein Projekt z.B. von JackRabbit auf MongoDB um und die Leistung ist deutlich besser(DB mit ca 1Mio. Dokumenten)
Beides sind NoSQL Datenbanken und beide werden nicht als InMemDB genutzt...
 
Das ändert aber nichts an der Grundaussage: NoSQL einsetzen, nur damit man NoSQL eingesetzt hat (it is webscale!!!), ist Hirnriss deluxe.
Wenn eure Anwendung von NoSQL-Ansätzen profitiert, dann ist das eben bei euch so. Wikimedia ist hingegen wohl kein Fall für NoSQL, die Daten sind wohl sehr schön relational strukturierbar.
 
Zurück
Oben