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.

SAP BW 7.5

Viel gibt es noch nicht zu lesen über das nächste BW Minor Release 7.5. Auf dem SCN gibt es seit kurzem einen ersten Entwurf für die BW 7.5-Seite mit ersten Informationen zum Ramp-Up. Kurz darauf wurde von Lothar Henkes dann auch erste Folien zu SP1 bereitgestellt.

Die Konzentration ist natürlich voll auf SAP HANA. Obwohl B/4 HANA nicht erwähnt wird, wird der Weg dorthin bzw. die Option, nur neue BW-Objekte zu nutzen beschrieben. Das Schaubild nennt es „SAP BW, Edition for SAP HANA“.

Ob das BW 7.5 auch auf Any DB läuft, wird hier noch nicht klar. Ähnlich wie bei BW 7.4 wird hier die Information nicht aktiv von der SAP gepusht. Der Weg zeigt auf jeden Fall voll in Richtung HANA. 2.500+ Kunden werden hier für 2015 angegeben. Wieviele Kunden hat SAP für BW ohne HANA? 15.000?

Roland Kramer von SAP hat zum 01. Oktober 2015 eine erste Präsentation bereitgestellt. Daraus lässt sich folgendes über das neue Release lesen:

  • Eclipsebasierte Modellierung von Datenflüssen
  • SAPUI5-basierte Monitoring- und Administrationswerkzeuge
  • Dynamic Tiering für Advanced DSO’s
  • Weitere Big Data/Hadoop-Integration
  • Weiterer pushdown von datenintensiven Funktionen in die HANA
  • Lokale Planungsszenarien mit BW Workspaces und BPC Embedded Model

Bzgl. der weiteren Entwicklung gibt es folgende Aussagen:

  • Advanced DSO und CompositeProvider als zentrale Modellierungsobjekte
  • KEINE 3.x-Datenflüsse, InfoCubes oder DSO’s
  • Vereinfachte Governance
  • Alle Datenladeprozesse basieren auf optimiertem Requesthandling
  • Alle Modellierungswerkzeuge basieren auf Eclipse
  • Alle Administrationswerkzeuge basieren auf SAPUI5
  • BW on HANA-optimierter Business Content
  • Erweiterte Unterstützung für den Übergang zu HANA-optimierten BW-Objekten

Wichtige Erweiterungen für das Advanced DSO sind nichtkummulative Kennzahlen (Bestandskennzahlen), templatebasierte Modellierung, Unterstützung von Planungsszenarien, Unterstützung von Updates über API (bisher bei DSO’s für direktes Schreiben) und Konvertierungswerkzeuge für klassische DSO’s und InfoCubes.

Ansonsten wird mittels Dynamic Tiering und Nearline Storage (NLS) die Big Data-fähigkeit verbessert, die eclipsebasierte Modellierung von Queries zieht gleich mit den bisherigen Möglichkeiten und die Plannungsmöglichkeiten (BPC, BPC-PAK, IP-PAK) werden vereint.

Einige Detailbeschreibungen finden sich auch hier.

SAP HANA (aus Analytics-Sicht)

Dieser Betrag ist aktuell ein Work in Prozess und soll als Landingpage für SAP HANA und im Speziellen der eingebauten analytischen Möglichkeiten der Datenbank bieten.

SAP HANA wird ja als alles Mögliche gehandelt. SAP HANA wird SAP BW ersetzen, SAP HANA als Big Data Plattform, SAP HANA als Allheilmittel für alle Business-Probleme, …

Schaut man sich eine Übersicht der SAP HANA-Plattform SPS10 an, so tauchen allerlei Begriffe auf, welche in Richtung Analytics/BI deuten:

  • Spatial (Geo-Analyse)
  • Graph (Komplexe Netzwerkzusammenhänge)
  • Predict (Vorhersagen, Data Mining)
  • Text Analytics (Analyse unstrukturierter Daten)
  • Planning (Planungsprozesse)
  • Data Enrichment (???)
  • Series Data (???)
  • Streaming (Complex Event Prozessing)
  • ELT & Replication (???)
  • Hadoop Integration
  • Columnar (OLAP)

Dazu kommen Themen wie HANA Live oder S/4HANA Analytics, welche wiederum verschiedene Möglichkeiten bieten, Analytics on HANA zu nutzen.

Schon eine ganze Menge an Punkten für eine analytische Plattform. In Unterartikeln werde ich die nächste Zeit versuchen, die Themen selbst erstmal zu verstehen und aufzubereiten.

Forrester Wave: In-Memory Datenbanken Q3/2015

Das Marktforschungsunternehmen Forrester hat eine Untersuchung von 11 In-Memory Datenbanken durchgeführt und diese entsprechend bewertet.

Forrester sieht den Einsatz von In-Memory Datenbanken im Bereich (Realtime) Analytics und bei extremen und schwer vorhersehbaren Transaktionsvolumen in den Bereichen Mobile, Internet of Things und Web Workloads. Auch die Entwicklung gänzlich neuer, hochperformanter Anwendungen ist ein Schwerpunkt.

In-Memory Datenbanken oder In-Memory Optionen für Datenbanken gibt es schon seit vielen Jahren. Nach meiner Beobachtung hat SAP gepuscht durch ein starkes Marketing und durch die klare strategische Festlegung für alle ihre verfügbaren Geschäftsanwendungen, bei SAP BW und SAP ERP angefangen, hier für eine hohe Aufmerksamkeit gesorgt. Dies spiegelt sich nun auch im Aufkommen entsprechender Untersuchungen wieder. Ein klares Zeichen ist hier bei SAP, dass das Hauptprodukt, nämlich das ERP-System noch der Datenbank HANA benannt wurde und als neues ERP Release unter dem Namen S/4 HANA verfügbar ist.

Forrester bringt eine Definition für In-Memory Datenbanken:

A database technology that stores all or partial data in memory on either a single or distributed server to support transactional, operational, and/or analytical workloads.

Diese Definition ist evtl. auch der Grund, dass spezialisierte analytische Datenbanken wie Exasol oder QlikView hier keine Berücksichtigung finden.

Interessanterweise unterteilt Forrester schon gleich die untersuchten Datenbanken in Datenbanken von traditionellen Anbietern wie SAP, IBM und Oracle sowie spezialisierte Anbieter wie Aerospike, DataStax und Kognito. Mit dieser Einteilung wird das Ergebnis im Prinzip vorweg genommen. Die traditionellen Anbieter sind auch in der Forrester Wave die führenden während die Spezialisten weitgehend unter Strong Performer klassifiziert werden.

Im weiteren werde ich mich auch auf die traditionellen Anbieter, allen voran SAP im Vergleich beziehen.

Sollte man eine Top 5-Liste erstellen wollen, wären wie angedeutet, die eher traditionellen Datenbankhersteller vertreten:

  1. SAP
  2. Oracle
  3. IBM
  4. Teradata
  5. Microsoft

SAP kommt mit Spitzenwerten bei CURRENT OFFERING (4,25) und STRATEGY (4,60) daher und teilt sich bei 5,00 von 5,00 möglichen Punkten mit IBM bei MARKET PRESENCE den ersten Platz.

Im Detail betrachtet zeigt SAP bei CURRENT OFFERING im Bereich Scale-out architecture und und Data movement mit jeweils nur 3,00 Punkten Schwächen. Auf der anderen Seite kann SAP als einziger 5,00 Punkte in den Bereichen Data management features und Transaction capabilities ausweisen.

Laut Forrester wird SAP HANA wird vorm Markt gut angenommen, was auch an der starken Integration in die angebotene Software von SAP liegt. Die Fokussierung auf In-Memory zahlt sich wohl aus. SAP investiert stark in Marketing aber auch in die technologische Weiterentwicklung, was ich ebenso wahrnehme. Es werden mehr als 7.000 Kunden angegeben seit dem Start 2011. Zu guter letzt zeigt Forrester noch auf, dass eine SAP HANA Datenbank evtl. einen Overkill für Unternehmen darstellt, welche die Datenbank nur für transaktionale Zwecke einsetzen und keinen Nutzen aus Datenanalysen oder komplexen Berechnungen holen, da SAP HANA im Vergleich als teuer gilt.