Database Reference
In-Depth Information
schwindigkeit oder beides konzipiert. Sie sind für Probleme besonders gut
geeignet, bei denen die Daten keine besonders engen Beziehungen zuein-
ander haben. Bei einer Web-Anwendung erfüllen beispielsweise die Session-
Daten der Nutzer dieses Kriterium. Die Session-Aktivität der Nutzer unter-
scheidet sich von den Aktivitäten der anderen Nutzer und sie stehen in keiner
Beziehung zueinander.
Nicht so gut für:
Da häufig Möglichkeiten zur Indexierung und dem Scanning fehlen, helfen
Ihnen KV-Speicher nicht weiter, wenn Sie die Daten über einfache CRUD-
Operationen (Create, Read, Update, Delete) hinaus abfragen müssen.
Spaltenorientiert
Spaltenorientierte Datenbanken haben mit KV- und RDBMS-Speichern vie-
les gemein. Wie bei Schlüssel/Wert-Datenbanken werden Werte über passen-
de Schlüssel abgefragt. Wie beim relationalen Modell sind die Werte Gruppen
von null oder mehr Spalten, wenngleich jede Zeile so viele enthalten kann,
wie sie will. Im Gegensatz zu den beiden speichern spaltenorientierte Daten-
banken Daten aber in Spalten und nicht in Zeilen. Das Einfügen von Spalten
ist billig, die Versionierung trivial und es gibt keine echten Speicherkosten
bei unbefüllten Werten. Wir haben HBase als klassische Implementierung
dieser Gattung kennengelernt.
Gut für:
Spaltenorientierte Datenbanken wurden traditionell mit horizontaler Ska-
lierbarkeit als primärem Entwurfziel entwickelt. Als solche eignen sie sich
besonders gut für „Big Data“-Probleme und sind in Clustern von mehreren
zehn, hundert oder gar tausend Knoten zu Hause. Sie tendieren auch zu fest
eingebauten Features wie Komprimierung und Versionierung. Das Parade-
beispiel für ein gut geeignetes Problem für spaltenorientierte Datenbanken
ist die Indexierung von Webseiten. Die Seiten im Web sind textlastig (profitie-
ren also von der Komprimierung), hängen in gewisser Weise zusammen und
ändern sich mit der Zeit (profitieren also von der Versionierung).
Nicht so gut für:
Die verschiedenen spaltenorientierten Datenbanken haben unterschiedliche
Features und daher auch unterschiedliche Nachteile. Doch eine Sache ha-
ben sie alle gemeinsam: Sie sollten Ihr Schema darauf basierend entwerfen,
wie Sie die Daten abfragen wollen. Sie sollten also im Voraus eine Vorstel-
lung davon haben, wie Sie die Daten nutzen wollen, und nicht nur, wie die
Daten aussehen. Wenn das Nutzungsmuster für die Daten nicht im Vorfeld
