Spaltenorientierte Datenbanken

Spaltenorientierte Datenbanken sind selbst im Bereich NoSQL etwas besonderes. Während relationale Datenbanken aber auch NoSQL-Datenbanken wie Key-Value oder dokumentenorientierte Datenbanken zeilenbasiert organisiert sind, legen spaltenorientierte Datenbanken, wie der Name schon sagt, Daten als Spalten ab. In der SAP-Welt ist Sybase IQ dafür ein Beispiel. Jedoch kann auch in der HANA DB eine Tabelle als spaltenorientiert abgelegt werden.

Da pro Spalte ein Wert nur einmal vorkommt, zeichnet sich eine spaltenorientierte Datenbank durch hervorragende Aggregation- und Komprimierungsseigenschaften aus. Sie ist damit für OLAP-Operationen optimiert.

Vorteile:

  • Hohe Verfügbarkeit, gute horizontale Skalierung
  • Unterstützt Semi-strukturierte Daten
  • Durch die Komprimierung kommt es zu einem effizienten Zugriff auf die Datenbank

Nachteile:

  • Nicht optimal für transaktionale Anwendungen
  • Komplexeres Datenmodell verglichen mit Key-Values oder dokumentenorientierte Datenbanken
  • Nicht für Graph-Daten geeignet

Einsatzzweck:

  • Besser wenn Schreibvorgänge überwiegen, da die DB schneller schreiben als lesen. Somit auch für Realtime-Analytics gut geeignet.
  • Web Messaging Anwendungen
  • Alle Anwendungen, welche ad-hoc Abfragen auf aggregierte Daten machen
  • Gut für Empfehlungen (Kunden, welche A gekauft haben, …)

Beispiele für Anbieter spaltenorientierter Datenbanken:

  • Hadoop/Hbase
  • Cassandra
  • Accumulo
  • Cloudera
  • MAPR

Quelle: http://data-magnum.com/lesson-7-column-oriented-databases-aka-big-table-or-wide-column/

Key-Value Stores (Tuples)

Key-Value Stores (KVS) werden als sehr einfache Art der NoSQL-Datenbanken beschrieben. Sie bestehen aus einem Schlüssel (Key) und einem Behälter (Bucket), welcher beliebige Werte (Values) umfasst.

KVS sind schemalos, zeilenbasiert und für die Batchverarbeitung und analytische Zwecke ausgelegt.

Vorteile von KVS:

  • Immer verfügbar, kaum störungsanfällig
  • Effizient bei der Bereitstellung von bestimmten zusammengehörigen Werten (Values)
  • Sehr einfaches Datenmodell
  • Skaliert hervorragend auf vielen Servern
  • Kein Overhead (Indizies, Stored Procedures, temporäre Tabellen, Views, …)
  • Leistungsfähiges Offlinereporting für große Datenmengen

Nachteile von KVS:

  • Nicht für komplexe Anwendungen geeignet
  • Nicht für Transaktionen geeignet. Ineffizient beim Update eines Teils der Werte eines Buckets.
  • Nur für Batch-Betrieb (Query-Laufzeit ist Minuten bis Stunden)
  • Nicht effizient für die Abfrage auf einzelne Datensätze
  • Nur eventuell konsistent
  • Nicht für Graph-Daten geeignet
  • Bereitstellung eindeutiger Schlüssel bei steigender Datenmenge wird schwieriger
  • Muss generell alle Werte in einem Bucket bei einer Abfrage lesen

Einsatzzweck:

  • Textdaten und Dokumente
  • Call Center Logs
  • Umfragetexte
  • E-Mails
  • Social Media Feeds
  • Web Logs, Click Data
  • Aktienpreise
  • Realtime-Daten z. B. POS-Daten
  • Anwendungen mit hoher Schreibperformance (Velocity) bzw. kontinuierlich entstehenden Daten

Beispiele für KVS-Datenbankanbieter:

  • Hadoop
  • DynamoDB
  • Riak
  • Redis
  • FoundationDB
  • Voldemort

Quelle: http://data-magnum.com/lesson-5-key-value-stores-aka-tuple-stores/

NoSQL

Im Folgenden starte ich eine Darstellung der verschiedenen Möglichkeiten von NoSQL. Als Start bediene ich mich der Blogeinträge von Bill Vorhies von Data MAGNUM.

NoSQL (=Not only SQL) umfasst Datenbanken, welche im zum Teil nach anderen Prinzipien wie Relationale Datenbanken (RDMS) arbeiten und für verschiedene Zwecke optimiert sind. Aktuell gibt es große Diskussionen, ob NoSQL-Datenbanken die heute verbreiteten relationalen Datenbanken ersetzen können oder Sie einfach ersetzen.

Es werden verschiedene Typen von NoSQL-Datenbanken unterschieden. Dies sind:

Oft findet man als Unterscheidung zwischen der relationalen und der nicht-relationalen Welt die Kriterien ACID (relational) bzw. BASE (nicht-relational). Eine kompakte Erklärung dazu findet sich bspw. hier, wobei auch darauf hingewiesen wird, dass es bei NoSQL eine strikte Trennung nicht gibt.