Database Reference
In-Depth Information
Wir haben im Verlauf des Buches immer wieder gesehen, dass unterschied-
liche Datenbanken verschiedene Stärken haben. Moderne System-Designs
bewegensichdaherimmermehrinRichtung polyglotter Persistenzmodelle,
in denen verschiedene Datenbanken eine bestimmte Rolle innerhalb des Sys-
tems übernehmen. Sie werden lernen, wie man ein solches Projekt aufbaut,
wobei wir CouchDB als kanonische Datenquelle verwenden, Neo4j zur Ver-
arbeitung der Datenbeziehungen und Redis zur Befüllung mit Daten und als
Cache. Betrachten Sie das als Ihre Abschlussprüfung.
Beachten Sie, dass dieses Projekt nicht mit den Vorlieben der Autoren für eine
bestimmte Kombination von Datenbanken, Sprachen oder Frameworks zu-
sammenhängt. Es soll nur beispielhaft aufzeigen, wie mehrere Datenbanken
zusammenarbeiten und ihre Fähigkeiten zur Erreichung eines übergeordne-
ten Zieles einbringen können.
Ein polyglotter, persistenter Service
Unser polyglotter Persistenz-Service fungiert als Frontend zu einem Band-
Informationssystem. Wir wollen eine Liste mit Bandnamen speichern, den
Mitgliedern, die in diesen Bands mitwirken und eine beliebige Zahl von Rol-
len, die jedes Mitglied in dieser Band übernimmt, vom Leadsänger bis zum
Keytar-Spieler. Jede der drei Datenbanken - Redis, CouchDB und Neo4j -
übernimmt einen anderen Aspekt unseres Band-Managementsystems.
Redis übernimmt in unserem System drei wichtige Rollen: Es unterstützt
CouchDB beim Befüllen mit Daten, indem es als Cache für die jüngsten
Neo4j-Änderungen fungiert sowie als schneller Lookup für die partielle Su-
che. Seine Geschwindigkeit und seine Fähigkeit, unterschiedliche Datenfor-
mate zu speichern, machen es zu einem guten Kandidaten für die Befüllung
und die fest eingebauten Verfallszeit-Regeln eignen sich bestens für die Ver-
arbeitung von Cache-Daten.
CouchDB ist unsere maßgebliche (autoritative) Datenquelle (System of Re-
cord, SOR). Die Dokumentenstruktur von CouchDB bietet eine einfache Mög-
lichkeit, Bandinformationen mit verschachtelten Künstler- und Rolleninfor-
mationen zu speichern, und wir nutzen die Changes-API von CouchDB, um
unsere dritte Datenquelle auf dem neuesten Stand zu halten.
Neo4j ist unser Beziehungsspeicher. Obwohl die direkte Abfrage der
CouchDB-Datenquelle völlig in Ordnung wäre, erlaubt uns die Graph-Daten-
bank eine Einfachheit und Geschwindigkeit bei der Traversierung von Kno-
ten-Beziehungen, die andere Datenbanken nur schwerlich erreichen können.
Wir speichern Beziehungen zwischen Bands, Bandmitgliedern und den Rol-
len, die die Mitglieder spielen.
