News Wikimedia setzt ab jetzt auf MariaDB

Also auf Arch läuft MariaDB super.
Schön das auch ein OpenSource Treiber wie Wikimedia darauf setzt und daraus noch Vorteile ziehen kann. :)
 
na denne..das es es besser wird mit wikimedia
 
Sagt mal, beherrscht MariaDB auch einen Tabellen-Typ jetzt mit Fremdschlüssel und Volltext-Index? Ich hab mir MariaDB lange nicht angesehen, da die meisten Kunden immer noch MySQL einsetzten. ;)
 
Mysql 5.6 hat für InnoDB Volltextindexe, ob MariaDB das schon gemerged hat, musste mal schauen. Ansonsten wird es mit 10.0 passieren.
 
Wikipedia oder Wikimedia in der Ueberschrift?
 
Hujj wichtige News!

Hätte den aber eine noSQL Lösung vorgeschlagen. Wenn umstellen, dann gleich richtig.
 
Ich erst so " hää, warum gerade bei Hochzeiten solche Anfragen? Surfen die Gäste da alle bei Wiki rum?"
:)
 
Zeboo schrieb:
Hujj wichtige News!

Hätte den aber eine noSQL Lösung vorgeschlagen. Wenn umstellen, dann gleich richtig.

NoSQL-Lösungen sind nicht die Antwort auf alle Fragen. Nicht ohne Grund setzen z.B. Pinterest, Instagram und Disqus nach wie vor auf Postgres und Sharding nachdem sie zuvor auch NoSQL Lösungen benutzt haben. Wieso würdest Du denen* vorschlagen auf eine NoSQL Lösung umzusteigen?

EDIT: * also Wikipedia.
 
Zuletzt bearbeitet von einem Moderator:
Neben der Tatsache, dass die Wikimedia Foundation versucht, möglichst nur freie Software einzusetzen, die im Gegensatz zu Oracles MySQL nur eine freie Lizenz hat, überzeugten auch Entwicklungen bei MariaDB, wie etwa Verbesserungen beim Abfragen-Optimizer sowie die Werkzeuge von Perconas XtraDB und trugen dazu bei, die nicht eben einfache Aufgabe der Umstellung einer solch großen Datenbank anzugehen.
What?
 
Zeboo schrieb:
Hätte den aber eine noSQL Lösung vorgeschlagen. Wenn umstellen, dann gleich richtig.

Unsinn. noSQL ist eine pure Hype-Nummer. Für klar strukturierte Daten geht nix über eine relationale Datenbank. Der ganze Kram hat zwar seine Anwendungsgebiete, aber es ist alles andere als das angepriesene Allheilmittel. Bei noSQL wird es z.B. meist mit ACID verdammt eng. Da Datenkonsistenz aber oft wichtiger als Geschwindigkeit ist -> RDBMS herrschen.

Du musst vor allem bedenken, wie Schreib- und Lesezugriffe verteilt sind. Solange deutlich mehr Lese- als Schreibzugriffe vorkommen kann ein RDBMS mit gut eingestelltem Cache problemlos mit noSQL-Lösungen mithalten. Problematisch wird es erst, wenn aufgrund der Schreibzugriffe das Caching in den Sack geht und außerdem bei jedem Schreibvorgang der Index neu aufgebaut bzw. erweitert werden muss.
 
Daaron schrieb:
Problematisch wird es erst, wenn aufgrund der Schreibzugriffe das Caching in den Sack geht und außerdem bei jedem Schreibvorgang der Index neu aufgebaut bzw. erweitert werden muss.

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...
 
fethomm schrieb:
Insgesamt verarbeiten die Server für die britische Wikipedia zu Hochzeiten rund 50.000 Anfragen pro Sekunde.
Was ist mit britisch gemeint? Die englische Wikipedia oder nur die Server, die auf der Insel stehen?

Gruss,
Peter
 
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.
Genau dafür gibts aber jetzt MemSQL. MySQL-kompatibles RDBMS, aber komplett im RAM gelagert (mit Spiegelung auf Festplatte).
Außerdem könnte man bei gewissen Datenstrukturen, z.B. bei den Magento Indizes, auch auf RAM setzen. Einfach die Index-Tabellen (catalog_fulltext & Co) per Symlink auf ne RAM-Disk legen. Wenn der Server mal neustartet muss man die Indizes halt neu aufbauen, sind ja keine wichtigen Daten...
 
Und wenn der Ram für die Daten nicht reicht, ist man angeschmiert. InnoDB hält sowieso alles im Ram, wenn man den Bufferpool groß genug macht, von daher kein Unterschied.
Und die Indizes will ich sicherlich bei nem Neustart nicht erst neuaufbauen, dann ist der Server nach nem Neustart jaminutenlang nicht nutzbar.
 
dafür dauern Änderungen an kombinierten Artikeln nicht mehr so lange...
Verknüpf mal 100 Simple Products mit 2000 Configurables, und dann ändere bei einem der simple's den Lagerbestand....
 
Zurück
Oben