High Performance Scalable Data Stores von Rick Cattell

Im seinem Papier geht Rick allerdings nicht nur auf die verschiedenen NoSQL Vertreter ein, sondern hat ebenfalls eine Liste an relationalen Datenbanken die sich das Thema Skalierbarkeit auf die Fahne geschrieben haben.

Neben einer Vorstellung der verschiedenen Lösungen gibt es ausserdem Beispiele zu Anwendungsgebieten der einzelnen Vertretergruppen.

Behandelt werden:

Key-Value Stores

• Redis
• Scalaris
• Tokyo Tyrant / Cabinet
• Voldemort
• Riak

Document Stores

• SimpleDB
• CouchDB
• MongoDB

Extensible Record Stores

• HBase
• HyperTable
• Cassandra

Scalable Relational Databases

• MySQL Cluster
• ScaleDB
• Drizzle
• VoltDB

via highscalability.com

Dabei wird sowohl einleitend auf die Unterschiede der sogenannten NoSQL Datenbanken im Vergleich mit den relationalen Vertretern der Datenbankwelt eingegangen, als auch die Einrichtung und die ersten Schritte mit CouchDB erklärt.

Besonders gut gefällt mir dabei das Fazit des Autors Rudolf Jansen. Denn er vertritt dort die Ansicht, dass NoSQL Datenbanken gar nicht antreten um relationale Datenbanken zu verdrängen. Viel mehr sollte man die beiden Optionen als Ergänzungen nebeneinander verstehen und je nach Einsatzzweck auf die Stärken des einen oder anderen Systems zurückgreifen.

Vor dem Hintergrund, dass die meisten NoSQL Systeme noch relativ jung sind, bleibt natürlich die Unsicherheit, ob denn die gewählte Datenbank auch in einigen Monaten oder Jahren noch existieren wird. Zwar sind die meisten Open Source, aber die wenigsten Webentwickler werden ein Interesse daran haben, nebenher mehrere 10.000 Zeilen Datenbankquelltext pflegen zu müssen.

CouchDB scheint allerdings hier durchaus brauchbar aufgestellt zu sein. Das System existiert immerhin schon seit 2005 und die dahinter stehende Firma Relax Inc. ist mitlerweile mit einer durchaus beruhigenden Summe Risikokapital (2 Millionen US-Dollar) ausgestattet.

CouchDB – angesagter Vertreter der “NoSQL”-Datenbanken

Mit dem Relational Database Service bietet Amazon jetzt ganz neu MySQL als Datenbank an. Dabei kann man die größe der Datenbankinstanz auswählen. Diese wird dann automatisch hochgefahren. Darüber hinaus kümmert sich Amazon auch um die wichtigsten Wartungsarbeiten und um Backups.

Instanzen mit mehr Arbeitsspeicher

Zusätzlich zu den High-CPU Instanzen führt Amazon jetzt auch High-Memory Instanzen ein. Die Instanzen hören auf die lustigen Namen Double Extra Large und Quadrupe Extra Large. Am Rande bemerkt, klingt das für mich irgendwie nach Fastfood…

Gesenkte Preise

Ab dem 1. November senkt Amazon darüber hinaus die Preise für die EC2 Instanzen um 15%. Für die EU-Instanzen bedeutet dies folgende neue Preise pro Stunde.

Standard

• Small: $ 0,095
• Large: $ 0,38
• Extra Large: $ 0,76

High-Memory

• Double Extra Large: $ 1,34
• Quadruple Extra Large: $ 2,68

High-CPU

• Medium: $ 0,19
• Extra Large: $ 0,76

Dies kann unter Umständen zum Verlust der letzten Transaktionen führen. Mit der von Redis ebenfalls unterstützen Replikation lässt sich dieses Problem aber verringern.

Redis ist Open Source unter der BSD-Lizenz verfügbar und es gibt bereits Bibliotheken für eine Vielzahl an Programmiersprachen. Unter anderem sind Ruby, Python, PHP, Java, und Perl aber auch Erlang und Lua vertreten. Je nach Bibliothek kann es sein, dass Sharding nicht unterstützt wird oder unterschiedliche Hash-Algorithmen verwendet werden. Hier soll wohl für die Zukunft nach Möglichkeit eine einheitliche Lösung geschaffen werden.

Insbesondere die Geschwindigkeit von Redis ist vielversprechend. Laut Webseite schafft Redis 110.000 SET und 81.000 GET Operationen pro Sekunde. Als Hardware wird dabei auf einen “entry-level Linux Server” verwiesen. Weitere Einschätzungen insbesondere im Vergleich mit MySQL findet man im MySQL-Performance-Blog.

Nach einem Tag war meine Inovationcode bereits im Postfach und ich konnte beginnen, außer einer E-Mail-Adresse waren nicht mehr Daten von Nöten. Suse stellt 15GB Speicherplatz zur Verfügung, was für die ersten Tests mehr als ausreichend ist. Insgesamt ist die Oberfläche sehr intuitiv bedienbar, in der ganzen Testphase hatte ich nie das verlangen nach einer Anleitung.

Appliance erstellen

Als erstes wählt man zwischen den unterschiedlichen Templates eines aus und vergibt einen Namen für dieses (Bild1). Im Menüpunkt “Software” steht ein Art Paketmanager zur Verfügung und zeigt einem die Basis Pakete an (Bild2). Ich habe einfach mal  “apache2-php5-mod” hinzugefügt, Abhängigkeiten werden automatisch aufgelöst (Bild3). Unter “Configuration” kann ich unterschiedliche Konfiguration vornehnmen, so kann ich beispielsweise Nutzer hinzufügen (Bild4), Skripte definieren oder eine MySql Datenbank einrichten.

“Overlayer Files” biete mir die Möglichkeit Datein direkt in die Appliance (“Image”) einzubinden, so kann ich zum Beispiel direkt meine Anwendung mit im “Image” ausliefern (Bild5). Nachdem wir alle Einstellungen unseren Wünschen entsprechend angepasst haben, müssen wir das “Image” noch bauen lassen (Bild6), hier kann man zwischen unterschiedlichen Arten der Auslieferung wählen. Nun ist ein wenig Gedulg angesagt, dannach steht das “Image” gepackt zum download bereit.

Auch habe ich die Möglichkeit das “Image” direkt für 60 Minuten im Browser zu testen (Bild7), dies ist meiner Meinung nach aber noch nicht 100%ig ausgereift genug. Für die ersten Steps mit dem “Image” aber vollkommen ausreichend.

Fazit

Suse lieft ein echt spannende Lösung um schnell “Images” zu erstellen und in Betrieb nehmen zu können, wie praxistauglich diese Lösung ist kann ich allerdings noch nicht sagen, da ich noch nicht die Zeit dafür gefunden haben. Auf jeden Fall hat Suse hier ein gewaltigen Schritt für zukünftiges gelegt, wir werden sehen wer in Zukunft ähnliche Lösungen liefern wird. Für Microsoft Systeme wäre das doch genial oder?

Jedenfalls findet sich auf dem Blog von Nati Shalom ein lesenwerter Artikel zu dem Thema. Nati ist der Ansicht, dass SQL nie die Lösung für jedes Problem war, aber genausowenig jetzt plötzlich nie mehr die richtige Lösung ist.

No to SQL? Anti-database movement gains steam – My Take

Einfach mal reinhören. Hier gehts zum Podcast.

Ist ein relationales Datenbanksystem wie der Web-Platzhirsch MySQL die Antwort auf alle Fragen, oder sind Key-Value- oder Dokumentenbasierte System die bessere Lösung. Und wenn ja in welchen Fällen. Denn wie so oft gilt, eine allgemeingültige Antwort gibt es nicht. Es kommt darauf an!

Nur worauf es ankommt, anhand welcher Kriterien man unterscheiden soll und wie diese Kriterien im Einzellfall zu werten sind ist eine Frage für sich. Genau diese Frage versucht Haytham El-fadeel in seinem aktuellen Posting Database Optimize patterns zu beantworten. Sein Blog hat jetzt bereits seit einiger Zeit einen Stammplatz in meinem Feedreader und hat bisher immer durch Anspruchsvolle Postings überzeugt. Deshalb, Lesetipp für Webentwickler und solche die es werden wollen.

Für Oracle ist dies ein großer Schritt. So erkauft man sich dadurch die fehlende Technologie um vom reinen Softwareanbieter zum Anbieter kompletter Unternehmenslösungen inklusive Hard- und Software zu werden. SUN hat dabei sowohl in den Bereichen Hardware, Betriebssystem als auch Anwendungssoftware interessante Produkte. So z.B. auf Betriebssystemebene mit Solaris, aber auch in Sachen Linux KnowHow.

Was aber wird aus MySQL?

Mit der Übernahme von SUN schluckt Oracle nämlich ganz nebenbei auch MySQL, dass vor einiger Zeit von SUN übernommen wurde.

Oracle ist nicht gerade als großer Verfechter des Open Source Konzepts bekannt und ausgerechnet MySQL nagt mit seiner stetig wachsenden Beliebtheit an Oracles Kerngeschäft. Ich kann mir nur schwer vorstellen, dass man bei Oracle die MySQL-Weiterentwicklung einfach so einstellen wird. Dafür setzen wohl zu viele große Unternehmen MySQL produktiv ein, als dass sich Oracle dies erlauben könnte.

Ob MySQL aber weiterhin Open Source und kostenlos nutzbar bleiben wird? Bereits nach der Übernahme durch SUN kamen schonmal Gerüchte auf, MySQL würde nur noch eingeschränkt kostenlos nutzbar bleiben und bestimmte Features würden auch nicht quelloffen entwickelt werden. SUN als Open Source Vorzeigekonzern hat diesen Gerüchte aber ganz schnell eine Absage erteilt.

Auch mit der Open Cloud Initiative hat SUN den eigenen Prinzipien treu diese Offenheit auf die eigene Cloud Strategie übertragen. Mit Q-Layer hatte man hierzu auch vor kurzem eine wichtige Aquisition getätigt. Auch die SUN Cloud Strategie schluckt Oracle natürlich mit der Übernahme.

Wie es jetzt weiter geht wird die Zukunft zeigen. Man sollte die Entwicklung aber unbedingt im Auge behalten, wenn man bisher gute Gründe hatte auf MySQL statt Oracle zu setzen.

Insbesondere bleibt abzuwarten wie viele der MySQL-Entwickler das Team verlassen werden.