© saicle/Shutterstock.com
Reimplementierung eines Onlineshops mit einer NoSQL-Datenbank in der Cloud

NoSQL mit großen Datenmengen


Im vorangegangenen Artikel haben wir einen grundsätzlichen Überblick über das neu zu implementierende Shopsystem von Goodgame Studios gegeben. Dieses Shopsystem läuft zukünftig weltweit verteilt in der Cloud, bindet eine große Anzahl von Bezahldiensten an, soll nach heutigen Maßstäben zügig reagieren und muss zu Spitzenzeiten große Lasten aushalten. In diesem Artikel gehen wir auf die verwendete Datenbanktechnologie ein.

Die Entscheidung, eine NoSQL-Datenbank zu verwenden und mit großem Datenaufkommen zu kombinieren, wollen wir begründen und softwaretechnisch genauer darlegen. Der Artikel ist dafür wie folgt aufgebaut: Zuerst beschreiben wir das Setting und die grundlegenden Anforderungen an unsere Datenspeicherung. Daran anschließend gehen wir näher auf die Konzepte rund um NoSQL-Datenbanken ein. Technische Beispiele sollen genauer darlegen, wie der Umgang mit dieser Art von Datenbank funktioniert.

Das Setting

Mehr als 220 Mio. User greifen aus 230 Ländern laut Google Analytics auf unsere Systeme zu. Eine schnelle, weltweite Verfügbarkeit ist daher unsere primäre Anforderung. Netzwerklatenzen wären recht groß, wenn wir unseren Onlineshop von einem zentralen Punkt aus betreiben würden, weshalb ein verteiltes System zu bevorzugen ist.

28 Mio. Spieler kaufen in diesem Onlineshop Produkte. Damit fallen vielfältige Daten an, die gespeichert werden müssen. Hierbei handelt es sich um kundenspezifische Daten, wie zum Beispiel Statistiken oder persönliche Daten. Ein weiterer Typ sind die shopspezifischen Daten, wie zum Beispiel die zur Verfügung stehenden Artikel oder die verfügbaren Zahlungsdienstleister. Zu guter Letzt gibt es dann noch transaktionsspezifische Daten, wie zum Beispiel die Bestellungen selbst oder Token, die als Identifikator an den Zahlungsanbieter weitergeleitet werden können.

Die Herausforderung

Unsere Herausforderung für die Auswahl der Datenbank bestand darin, dass wir

  • Daten für den gesamten Kaufvorgang ablegen müssen (semistrukturierte Daten)

  • Mit großen Volumina in kleinen Zeiträumen umgehen können müssen (kostengünstige Skalierung)

  • Eine weltweit synchrone Sicht auf diese Daten brauchen (Replikationsmechanismus)

Die Daten, die wir zu speichern haben, sind unterschiedlich strukturiert. Wir haben sowohl relationale als auch nicht relationale Daten. „One size fits it all“ ist deshalb nicht die optimale Herangehensweise. Deswegen haben wir die passenden Datenbanken für die jeweilige Datenart gewählt. Für die relationalen Daten haben wir uns für MySQL entschieden; bei verteilten NoSQL-Datenbanken mussten wir zuerst die passende Datenbank finden.

Datenbankauswahl

In der Konzeptionsphase (2012) des neuen Onlineshops mussten wir uns für eine NoSQL-Datenbank entscheiden. Als populäre Kandidaten kamen hier Cassandra, Couchbase, MongoDB und Redis in die engere Wahl. Da die Performance für uns sehr wichtig war – und auch immer noch ist –, haben wir hausintern umfangreiche Performancetests durchgeführt. Hieraus ging Couch­base als Sieger hervor, da diese Datenbank mit Abstand am besten skalierte. Unsere Beobachtung deckt sich auch mit anderen Ergebnissen [1], [2].

Des Weiteren haben wir die Datenbanken auf Features wie Master-to-Master-Replikation, einfache automatisierbare Skalierbarkeit und einfache Administration untersucht und damals nur bei Couchbase diesen Funktionsumfang gefunden.

NoSQL vs. SQL

Man kann mit NoSQL-Datenbanken ebenfalls Relationen speichern, und SQL-Datenbanken könnte man genauso als Key-Value Store nutzen. Wir gehen aber davon aus, dass eine NoSQL-Datenbank schneller agiert als eine SQL-Datenbank, da diese ausschließlich im Speicher arbeitet. Denn NoSQL-Datenbanken skalieren deutlich einfacher und arbeiten direkt aus dem Speicher heraus, ohne Daten von der Festplatte laden zu müssen. Der wahre Unterschied liegt jedoch in den Relationen und AKID-Kriterien (Atomarität, Konsistenz, Isolation und Dauerhaftigkeit) [3].

Zuerst schauen wir auf die Relationen: Während man z. B. mit MySQL InnoDB gültige Relationen erzwingen und diese sogar kaskadieren kann, müssen bei NoSQL-Datenbanken Relationen manuell gepflegt werden. Bei NoSQL-Datenbanken beispielsweise kann der Schlüssel eines Dokuments als Referenz in einem anderen Dokument gespeichert werden, Integrität kann jedoch nicht garantiert werden.

SQL-Datenbanken, zu denen auch MySQL gehört, erfüllen die AKID-Kriterien; NoSQL-Datenbanken können diese nur unter Umständen sicherstellen. Atomare Operationen können nur bei Datenoperationen erreicht werden, die eine Änderung beschreiben – wie zum Beispiel das Erhöhen einer Zahl um einen bestimmten Wert. Da viele NoSQL-Datenbanken ausschließlich im Speicher agieren, ist nicht einmal die Dauerhaftigkeit gegeben, da bei einem Neustart die im Speicher befindlichen Daten verloren gehen können. Hierfür müssten NoSQL-Datenbanken Daten atomar in den persistenten Speicher (Platte) schreiben.

NoSQL-Daten verfolgen im Allgemeinen das BASE-Prinzip (Basically Available, Soft State, Eventual Consistent) [4]. Basically Available bedeutet, dass zu jeder Zeit eine Version des Dokuments verfügbar ist, gegebenenfalls jedoch eine veraltete. Soft State besagt, dass Daten nur für eine gewisse Zeit verfügbar sind; können aber irgendwann einmal nicht mehr verfügbar sein, was zum Beispiel in der Speicherbasierung begründet sein kann. Das Eventual Consistent besagt, dass ein konsistenter Zustand in einer möglichst kurzen Zeitspanne erreicht wird, diese jedoch nicht festgelegt werden kann.

Buckets

Was bei relationalen Datenbanken eine Datenbank ist, ist bei dokumentenorientierten Datenbanken ein so genannter Bucket. Ein Bucket ist gewissermaßen ein Container für Dokumente, die meist logisch zusammenhängen, wie zum Beispiel Kundendaten. Da es bei Couchbase abgesehen von einem Lese...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang