Beim Durchstöbern der verschiedenen NoSQL-Datenspeicher stellt sich mir die Frage, wieso man das alles überhaupt will. Genauer: Was genau ist das Problem, das man mit NoSQL lösen möchte?

Diejenigen Leute, die NoSQL-Lösungen einsetzen, haben in der Regel die Schwierigkeit, daß ihre Datenmenge größer wird, als man auf einer einzelnen Maschine mit der geforderten Servicequalität handhaben kann.

Im Webbereich sind die Anforderungen für interaktives Browsen oft so, daß man die gewünschten Antwortzeiten nur dann erreichen kann, wenn die dabei verwendeten Datenbanken ihre Daten und Indices zum allergrößten Teil im RAM halten können. Verfügbarkeit und Preis von Speicher sind aber Grenzen gesetzt - mit aktuellen Nehalem-Kisten zum Beispiel liegt der Sweet-Spot irgendwo bei 48G oder 96G Hauptspeicher, die Datenbankgröße für solche zeitkritischen Systeme also nach meinen Erfahrungen zwischen 100G und 200G.

Ich schrieb :

heretic666 schrieb am 4. November 2010 12:11

…das man nicht auch wahlweise mit PostgreSQL oder MS SQL erschlagen kann?

Mir fällt da im Moment kein Punkt ein…

Postgres ist ein Repräsentant der klassischen Datenbanken und fällt in dieselbe Kategorie wie Oracle, MS SQL oder DB/2. MySQL ist eine Datenbank, die sich in vielen Punkten an den Erfordernissen des Webs orientiert und ganz andere Schwerpunkte als Postgres oder Oracle setzt. Das ist auch eine der Erfahrungen, die der rote Sales (Oracle Sales) gerade mit blauen Kunden (MySQL Kunden) macht: Die meisten lassen sich nicht einfach auf rot konvertieren, weil das rote Produkt schlicht nicht die Leistungen bietet, die blauen Kunden wichtig sind.

Kurzer SQL WTF von heute:

mysql> SELECT 'a'='b'; 
0

mysql> SELECT 'a'='b'='c';
1

Warum ist das so?

Im MySQL Sourcecode ist in sql/sql_yacc.yy definiert:

%left   EQ EQUAL_SYM GE GT_SYM LE LT NE IS LIKE REGEXP IN_SYM

Damit ist der Operator EQ (das Vergleichheitszeichen) als links-assoziativ definiert. Vergleiche von Vergleichen sind also zugelassen,

1 = 2 = 3 ist also ein zulässiges Konstrukt und es wird als ( 1 = 2 ) = 3 evaluiert.

Für viele MySQL-Anwendungen sind Covering Indexes eine wichtige Sache. Domas hat einen Artikel darüber Wie Wikipedia von Covering Indexes profitiert , und auch sonst sind solche Indices für viele MySQLer ein täglicher Bestandteil der Optimierungsarbeit.

Nun las ich neulich in einem Artikel eine Seitenbemerkung, daß Postgres keine Covering Indices unterstützt und das scheint tatsächlich der Fall zu sein , auch wenn ich in der Doku selber keine Hinweise darauf gefunden habe.

Warum Postgres das nicht kann ist zunächst einmal klar: MVCC macht das sehr schwierig. In meinem Vortrag zur InnoDB Storage Engine (Teil 1 , Teil 2 ) habe ich schon einmal beschrieben, was passiert, wenn eine Zeile in InnoDB geschrieben wird.

Meine Firma verwendet SAP. Zum Glück habe ich damit nicht viel zu tun, außer um meine Beurteilungen abzusegnen und Urlaub zu beantragen. Das heißt, ich verwende SAP maximal 3 mal im Jahr. Bis vor kurzem hatte unser SAP keine LDAP-Anbindung. Ich hatte also ein SAP-Login, das von meinem Firmen-Login verschieden war und auch ein anderes Paßwort hatte. Da ich nur so ca. 3 Mal im Jahr ins SAP muß, ist das Paßwort unweigerlich abgelaufen, wenn ich mich in das SAP einloggen will.

Ich habe letztes Jahr hier und hier ja schon mal was über “intelligente” Stromzähler geschrieben, zu deren Einbau wir ja nun alle verpflichtet sind, wenn wir renovieren oder neu bauen.

Das Thema rollt nun auch langsam in das Licht der Öffentlichkeit, etwa schreibt der Spiegel in Teure Ersparnis :

Das Sparpotential des intelligenten Stromnetzes werde “enorm überschätzt”, resümiert Energieberater Klafka. Zuweilen verursache ein intelligenter Zähler sogar erst mal zusätzlichen Stromverbrauch, weil die Tarifdaten rund um die Uhr übertragen werden müssen. Eine dazu nötige permanente DSL-Verbindung verschlingt pro Jahr rund 131 Kilowattstunden. Zum Vergleich: Ein moderner Kühlschrank benötigt weniger als 100.

In Kennzeichen Digital beim ZDF schreibt Mario Sixtus einen ganz wunderbaren Text über die ganze Google Streetview Hysterie. Kernpunkt:

Ein interessanter Effekt des Netzes ist es, theoretische Rechte in praktische zu verwandeln. Das allgemeine Grundrecht auf freie Meinungsäußerung machte sich beispielsweise in der Pre-Netz-Ära sehr hübsch im Grundgesetz und in Sonntagsreden. Abgesehen von Flugblättern, Leserbriefen und Stammtischansprachen hatte der gemeine Bürger allerdings kaum eine Möglichkeit, von diesem Recht Gebrauch zu machen.

The Dreaming Void , Peter F. Hamilton, EUR 6.50, 608 Seiten.

Die ferne Zukunft. Teile der Menschheit leben postphysikalisch als Uploads, andere haben sich mehr oder weniger genetisch aufgerüstet oder ihre Körper mit Nanotechnik angereichert. Sterben muß niemand mehr, und Not leiden oder gar hart arbeiten auch nicht, außer er wählt dies als Lebensstil.

Im Zentrum der Galaxis liegt ein gigantisches Schwarzes Loch, The Void. Der Astrophysiker Inigo beginnt, Szenen aus dem Leben von Edeard zu träumen, einem Menschen, der offenbar im Mikrouniversum im Inneren der Void lebt - ein bemerkenswertes Universum, denn offenbar kann man dort mit dem Geist Einfluß auf die Materie nehmen.

In einem Kommentar zu Master-Master schrieb ich:

Für den von Dir genannten Sonderfall der Filialsysteme habe ich noch einen deutschen Artikel in der Warteschlange, ich muß nur Zeit finden ihn zu schreiben.

Normalerweise sieht MySQL Replikation so aus:

MySQL Replikation - Architekturübersicht

Master Binlog

Auf dem Master ist mit der Konfigurationsanweisung log_bin das Binlog aktiviert.

Das Binlog loggt bei Statement Based Replication (SBR) alle Anweisungen, die Daten verändern (also quasi alles außer SELECT). Binlog-Dateien haben dasselbe Namensprefix und werden dann durchnumeriert. Die Datenbank beginnt ein neues Binlog, wenn die laufende Binlog-Datei größer als max_binlog_size (Default 1G) wird, wenn das Kommando FLUSH LOGS ausgeführt wird oder wenn der Server neu gestartet wird.

Lalufu fragte in den Kommentaren von Master-Master :

Ich habe eine MM-Replikation mit zwei Servern.

Beide haben auto_increment_increment=10,

Server A hat auto_increment_offset=0 und Server B hat auto_increment_offset=1.

Ich lege mir eine Tabelle mit einem auto_increment-Feld (id) an und mache auf Server A einen INSERT, dann kriegt die row id=0, und wird auf B repliziert, richtig?

Dann noch einen INSERT auf A, die row kriegt id=10, und wird auf B repliziert.Wenn ich jetzt auf B einen INSERT mache, welchen Wert kriegt das id in der row?