Download pptx - RDBMS oder NoSQL – warum nicht beides?

RDBMS oder NoSQL– warum nicht beides?

München, den 22. Juni 2016Julian Endres & Daniel Schulz

Public – Company Confidential – Customer Confidential – Sensitive

2TDWI-2016-RDBMS-vs-NoSQL-Master.pptx

Die Referenten

Julian EndresApplications Consultant bei Capgemini

Julian Endres ist Applications Consultant bei Capgemini im Bereich Big Data & Analytics. Er ist dabei im gesamten BI-Stack mit derzeitigem Fokus auf Technologien wie Qlik, Tableau, Hadoop und NoSQL-Datenbanken tätig.Im Bereich der nicht-relationalen Datenbanken widmet er sich besonders der Marktreife und Einsetzbarkeit von einzelnen Lösungen im Unternehmenskontext sowie Architekturen im Big-Data-Kontext.

Daniel SchulzSenior Solution Architect bei Capgemini

Daniel Schulz ist Senior Solution Architect bei Capgemini. Er arbeitet seit fünf Jahren im Big-Data-Bereich mit besonderem Fokus auf der Automotive-Branche. Er interessiert sich seit seiner Schulzeit für Statistik, seit dem Studium auch für Machine Learning und deren Einsatz in der Datenanalyse. Sein besonderes Interesse gilt Markovmodellen und der Performanceoptimierung von Software und Datenbanken.

© Capgemini 2016. All Rights Reserved


Agenda


1. Einführung in NoSQL-Datenbanken

2. Diverse Anwendungsfälle

3. Big-Data-Referenzarchitektur

4. NoSQL-Evaluierungsframework

5. Innovation Dilemma & Résumé

Einführung


NoSQL-Datenbanken – Historie

• RDBMS wurden zwischen den 1960er und 1980er Jahren als Wertschöpfung gegenüber Dateisystemen eingeführt

• Daten werden in Spalten und Reihen abgespeichert

• Tabellen werden über Primär- und Fremdschlüssel miteinander verknüpft

• RDBMs Vorteile:• Stellen v.a. Struktur sicher• Nutzer/Rollen-Konzept und Gewährleistung von Datensicherheit• Sicherstellung der Konsistenz und Transaktionssicherheit• Optimierung der Anfrage durch SQL• und weitere

• dieser Hintergrund ist wichtig • bei Betrachtung der Entwicklung von NoSQL sowie• bei Prognosen über die Zukunft des Datenbankenmarktes

© Capgemini 2016. All Rights ReservedNoSQL-Datenbanken


NoSQL = „Not only SQL“

Eine einheitliche Definition existiert nicht. NoSQL – Datenbanken erfüllen vielmehr charakteristische Eigenschaften in unterschiedlichem Maße.

Definition

NoSQL-Datenbanken – Begriff



NoSQL-Datenbanken – Charakteristiken

• Betrieb in verteilten Clusterumgebungen für native horizontale Skalierung (Partitionierung und Replikation der Daten über mehrere Knoten)

• „Eventual consistency“ / gelockerte Konsistenz: Zugunsten von Verfügbarkeit und Performance ist die Konsistenz der Daten über die verteilten Partitionen nicht zu jedem Zeitpunkt sichergestellt.

Eine verteilte Datenbank kann nur zwei der drei Anforderungen von Konsistenz, Verfügbarkeit und Partitionstoleranz gleichzeitig garantieren. (CAP-Theorem von Brewer)*

• Gelockerte Schemarestriktionen und unterschiedliche Möglichkeiten der Datenstrukturierung

• Datenbankspezifische Abfragesprachen und APIs

• Häufig open-source Produkte mit Wurzeln in Web-Firmen

• Polyglotte Architekturen (z.B. zusammen mit Hadoop, RDBMS oder DW) oft in Big-Data-Lösungen umgesetzt

Consistency

Availability PartitionTolerance

* Vereinfachte Darstellung. Mehr Informationen: http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed


CAP-Theorem

NoSQL-Datenbanken


Fokus von Datenlösungen im Big Data Kontext


Velocity

VarietyVolumeHadoop (HDFS)

NoSQL

Data Warehouses(OLAP)

In-memory & event processing tools

Filesysteme

NoSQL-Datenbanken

TDWI-2016-RDBMS-vs-NoSQL-Master.pptx

NoSQL-Datenbanken – Typische fachliche Anwendungsfälle


9

• Web & Mobile Applikationen (Caching, Leaderboards, Latency kritische Anwendungen, Online Games, Sessions, Personalisierung)

• Soziale Netzwerke

• Log- und Sensordaten aus dem Internet-of-Things-Bereich (z.B. real-time Tracking von Maschinendaten)

• Customer 360° View

• Analytics (Datenanalyse, Betrugserkennung, MapReduce)

• … und mehr

NoSQL-Datenbanken


NoSQL-Datenbanken – Typische technische Anwendungsfälle


10

• Hohes Datenvolumen und lineare Skalierbarkeit

• Einsatz von Commodity Hardware

• Flexible Datenschemata (z.B. Änderungen am Datenmodell in agilen Umfeldern)

• Spezielle Abfragen (z.B. Geoqueries)

• Globale Verteilung der Daten (Replikation)

1 0 0 1 01 0

0 1

0 11 1 0

1 0 1 1

0 0 1 1 1 0 1

0 1 0 0 1 1 0 1

1 0 1 0 1 1 0 0

1 0 1 1

NoSQL-Datenbanken


NoSQL-Datenbanken – Datenschemata

Dokumentorientiert

SpaltenorientiertKey-Value

Graph


Relational NoSQL

NoSQL-Datenbanken


Map Reduce: Parallelisierte und verteilte Verarbeitung, bei der Datenin gruppierte Key-Value Paare aufgeteilt und zusammengeführt (map) undsortiert (reduce) werden. Dies erfordert häufig speziell auf den Anwendungsfall abgestimmte Skripte.

Proprietäre Abfragesprachen: Sind dem jeweiligen Datenschema angepasst und um spezifische Funktionen erweitert. Zur Integration in Systeme werden proprietäre APIs und Frameworks benötigt. Beispiele:

RESTful HTTP Argumente: URL kodierte HTTP Anfragen mittels GET und POST. Austauschformat häufig JSON.GET http://127.0.0.1:5984/database/document

SQL: Spezifische Übersetzungsframeworks existieren oder Abfragesprachen sind daran angelehnt z.B. CQL von Cassandra.

NoSQL-Datenbanken – Abfragen


12

Bildquelle: https://de.wikipedia.org/wiki/Datei:MapReduce2.svg

Besetzung der Filme beginnend mit ‚T‘ / Graph-DB Neo4j: db.restaurants.find({ location:

{ $geoWithin: { $centerSphere: [ [ -73.93414657, 40.82302903 ],

5 / 3963.2 ] } } })

MATCH (actor:Person)-[:ACTED_IN]->(movie:Movie) WHERE movie.title STARTS WITH "T“RETURN movie.title AS title, collect(actor.name) AS cast ORDER BY title ASC LIMIT 10;

Restaurants im Umkreis / MongoDB:

NoSQL-Datenbanken


Googles Trend für “NoSQL” – Interesse stieg ~2010 sprunghaft an

Realisierungen könnten zeitlich versetzt nachziehen



Googles Trend für Terme NoSQL & RDBMS

Gezeitenwechsel zwischen RDBMS und NoSQL bei Interesse erkennbar



NoSQL - Datenbanken – Pro & Contra

Pro + Con -

zu viele DB Produkte, Einsetzbarkeit in

Unternehmen häufig unklar

oft knappe Verfügbarkeit von erfahrenen Kollegen &

mangelhafte Dokumentation

fehlende Standards, Abfragesprachen &

Best Practices

gelockerte Konsistenz

Vielfalt an Produkten

oft Lizenz-freie Software

vielfältige und flexible Datenschemata

native Skalierbarkeit, hohe Performance &

Fehlerresistenz


Knowledge-Management für Automotive-Wissenschaft


Vision des Kunden war Übersicht in großem Dokumentenfundus

Ziel war schnelles Finden von R&D-Papern nach Schlagwörtern & Inhaltsbeziehungen in Automotivedomäne


• Parsen, Indizierung und Persistieren von Forschungsberichten aus Automobilbau• Finden von Dokumenten nach Suchtermen• Graph von untereinander abhängigen Dokumenten• Aufdecken von inhaltlichen Beziehungen – sog. „Content-derived Metadata“, wie

• Autoren,• Forschungsfeldern,• Abteilungen,• explizite Referenzen und inhaltliche, implizite Verweise,• zeitliche Abhängigkeiten,• etc.

Anwendungsfälle Knowledge-Management für Automotive-Wissenschaft


Data Hub kommt ohne RDBMS zur Steicherung aus

Ziel war schnelles Finden von Wissenschaftspapern nach Schlagwörtern und Inhaltsbeziehungen für R&D


menschliche Anwender

Dokumente

Data Hub



Lessons Learned


Hadoop ist• günstiger, skalierbarer, ausfall-sicherer Massenspeicher• mächtiges Framework zur Speicherung von riesigen Mengen an Rohdaten als OLAP-System• entscheidendes Bottleneck war damals Nahe-Echtzeitanfrage der Daten kein OLTP-System• relativ komplex – auch damals, als es deutlich weniger Komponenten dafür gab• weniger Anwender-freundlich als BI-Tools


Rechencluster für Vorhersagen, Applikationen & Automotive-Simulationen


Automotive-Kunde wollte riesige Datenmenge diverser Struktur verarbeiten können

Lösung ist Data Lake: RDBMS + NoSQL-System

• gesucht ist • skalierbares, ausfallsicheres, hoch-performantes System,• günstigem Massenspeicher für Rohdaten,• auch mit Tabellen-artiger Struktur,• mit geringen, laufenden Kosten,• welches weitestgehend zukunftssicher für kommende 30 Jahre ist

• Anforderungen für eine zentrale Umgebung v.a. für• Sales-Prognosen,• Aftersales-Analysen,• Simulationen für operative Planungen,• Datenimport von diversen, bestehenden, internen und externen Datenquellen sowie• generische Möglichkeit Applikationen auf eigenem Datenbestand auszuführen

© Capgemini 2016. All Rights ReservedAnwendungsfälle Rechencluster für Vorhersagen,

Applikationen & Automotive-Simulationen


Job-Offloading: RDBMS schickt große Datenmengen zur Aggregation in Hive ans Hadoop; Datenfluss mit Sqoop realisiert

Datenmengen zu groß für Auswertung in RDBMS – daher Auswertung in skalierbarem Hadoop-System

Anwendungsfälle Rechencluster für Vorhersagen, Applikationen & Automotive-Simulationen

Aggregate

Detaildaten



Ausführung eigenen Java-Codes auf Spark auf Detaildaten in Hadoops HDFS

System kann MPP-ähnlich beliebige Algorithmen in Spark, YARN und MapReduce ausführen


Aggregate

Detaildaten

Teilevorhersagen



Hadoop-Plattform zur Speicherung von Daten sowie zur Ausführung von Applikationen & Algorithmen darauf

Oozie steuert gesamten Datenfluss (ETL) und Ausführung der Applikationen & Algorithmen


Aggregate

Detaildaten

Teilevorhersagen



Anwender können mittels BI-Tool Tableau auf Daten in RDBMS und Hadoop zugreifen — Data Lake fühlt sich an, wie ein Datenpool

arbeiten i.d.R. auf RDBMS, da Antworten in Naheechtzeit; Drill-Through referenzierte Daten im Hadoop deutlich langsamer (im Minutenbereich) dafür Arbeit auf riesigen Datenmengen (Terabyte-Bereich) möglich



Aggregate

Detaildaten

Teilevorhersagen



Externe Quellsysteme können Daten in Streams und Batches einfügen

alle Datenformate sind beliebig strukturierbar, da Hadoops HDFS ein Rohdatenspeicher ist



Aggregate

Detaildaten

Teilevorhersagen



Weitere Evolution dieses Data Lake’s nutzt diverse RDBMS-Quellsysteme & NoSQL-Systeme

RDBMS und NoSQL sollen jeweilige Stärken ausspielen


einige menschliche & viele technische Anwender

beigestelltes, erweiterndes RDBMS

zum Data Lake

RDBMS-Quellsysteme

Data Lake



Lessons Learned

kritisch beim Einsatz von Hadoop und Cassandra


Hadoop• ist immer noch relativ komplex• ist weniger Anwender-freundlich als BI-Tools

• sehr gute Integration von Tableau in Hadoop und Cassandra• gute Integration in DWH-Systeme

• ist deutliche Schwierigkeiten es Datenschutz-konform zu betreiben• ist deutlich langsamer als Cassandra in Beantwortung von Anfragen durch Latenz im Master/Slave-Design



Lessons Learned

weitere Aspekte von Hadoop und Cassandra


Hadoop• ist günstiger, skalierbarer, ausfall-sicherer, durchgehend verfügbarer Massenspeicher• ist mächtiges Framework zur Speicherung von riesigen Mengen an Rohdaten als OLAP-System• Caches, Datenbanken und Komponenten ermöglichen auch Nahe-Echtzeitanfragen als OLTP-System• Komponenten, wie Hive, Impala & Spark SQL, ermöglichen

• nahezu den Ersatz eines DWH durch Hadoop• Job-Offloading vom DWH nach Hadoop

• ist relativ Linux-affin in Nutzung

Cassandra• benötigt vorher bekanntes Schema und mglw. Spiegeltabellen je Anfragemuster

führt mglw. zu doppelter Replikation der Daten:• Replikationsfaktor im Design und• Spiegeltabellen / Materialisierte Sichten auf Anwendungsebene

• ist relativ Linux-affin in Nutzung


Qualitätssicherung auf Geodaten


Vision des Kunden

• Auswertung von Massenpositionsdaten aus GPS-Signalen• Geräte aus ganzem Monitoringgebiet liefern Daten an ein zentrales System über Mobilfunknetze• Nachverfolgung aller Bewegungen aller Geräte kurzfristig möglich• Auswertung tabellenartiger und graphenartiger Daten• Anwendung von Advanced-Analytics- resp. Machine-Learning-Methoden auf gesamtem Datenbestand und

seiner Historie• Kunde war Neueinsteiger in Big-Data-Analysen

© Capgemini 2016. All Rights ReservedAnwendungsfälle Qualitätssicherung auf Geodaten

Eingehende Daten sind…

• 1 TB bis 10 TB je Tag• OLAP-Analysen in ¼-Stunden-Batches• strukturiert oder unstrukturiert im Binärformat• ungleich verteilt• Datenlieferungen durch vier Systeme, teilweise voneinander abhängige und unabhängige Systeme


Der Speicher- & Rechencluster ist in jedem Knoten datenlokal aufgebaut

Ring-Architektur mit deckungsgleichem, datenlokalem Spark-Verbund


Ausführungsschicht

Datenhaltung

Anwendungsfälle Qualitätssicherung auf Geodaten


Datenfluss von den Quellen zur Qualitätssicherung

Datenhaltung in bestenfalls zwei verbundenen Spark-on-Cassandra-Ringen zur Analyse


Vorverarbeitung OLTP-Ring für hohen Data Ingest

Sensordaten von Transportmitteln

OLAP-Ring für Data Science

GPS-Daten



Austausch mit RDBMS

Sqoop überträgt Daten bidirektional zw. Relationalen Datenbanken und Cassandra


Datenintegration

Ausführungsschicht

Datenhaltung

RDBMS



Zugriffsschicht für Datenanalysten

Nutzung von SQL, R, Python, SQL, Scala und Java möglich


Analyselayer

Ausführungsschicht

Datenhaltung

Datenanalyst

Zeppelin



Abschied von Oracle

Oracle-ähnliche Technologie gesucht

• Oracle bei Kunden weitestgehend gesetzte, erprobte Technologie• Cassandra sehr viel ähnlicher als Hadoop zu Oracle-Lösungen

• SQL-Developer DevCenter• Enterprise Manager OpsCenter• u.a. Backup-Verfahren, Nutzer/Rechte/Rollen-Konzept, PreparedStatements sehr ähnlich zu Oracle• Umstellungen im Detail

© Capgemini 2016. All Rights ReservedAnwendungsfälle Qualitätssicherung auf Geodaten


Aufbau Spark-on-Cassandra-Cluster

Cassandra bevorzugte Wahl gegenüber Oracle und Hadoop


• Cassandra bevorzugte Datenbank durch Einfachheit• Distribution DSE (DataStax Enterprise) enthält viele Machine-Learning-Lösungen aus Hadoop-Distributionen• schlanker, schneller und mächtiger Technologiestack• Aufbau Cluster mit 1 aktivem & 1 passivem Ring – synchronisieren sich fortlaufend gegenseitig



Aufbau Netzwerktopologie der Speicher- & Rechenknoten über Rechenzentren und Umgebungen


Sampledaten bei Bedarf

Produktion mit Standby-Cluster

24/7 automatische Synchronisation der

Daten zweier Rechenzentren

Data Science & Entwicklung 24/7 automatische

Synchronisation der Daten zweier

Rechenzentren

Quell-systeme



Lessons Learned – so far

kritisch bei Einsatz von NoSQL


vor allem Cassandra und HBase• können oft ähnlich hohes Datenschutzlevel erreichen, wie RDBMS• erfordern damit auch Kenntnis der Zugriffsmuster auf Daten – vor Realisierungsbeginn• erfordern oftmals Commodity-Hardware – Netzwerkspeicher, wie SAN oder NAS, kann ein Antipattern sein

DSE als Big-Data-Distribution ist• weniger komplex als Hadoop, da nur relevanteste Komponenten für Data Science enthalten sind• deutlich einfacher Datenschutz-konform bettreibbar

• strukturierte und umfassende Herangehensweise zur Beurteilung von NoSQL-Datenbanken benötigt Lösung folgt gleich


Neo4j im UK-Public-Sektor


Neo4j im UK-Public-Sektor


43

Zielsetzung: Erkennung und Visualisierung von Zusammenhängen in Daten aus externen, internen und kommerziellen Quellen

Anwendergruppen: Experten Datenanalysten (ca. 6 Nutzer), Ermittler (ca. 1000 Nutzer in einem Jahr). Kurze Trainingszeit.

Technologien: Isoliertes, globales Behördennetzwerk, Greenplum PostgreSQL, Neo4j, Elasticsearch, node.js, nginx, Webapplikation

DB Größe: Millionen von neuen Datensätzen pro Tag

Hardware: Commoditiy, 4 Hexa Core Prozessoren, 128 GB RAM. Keine Cloud Umgebung.

Anwendungsfälle Neo4j im UK-Public-Sektor


POLE: Party, Object, Location, Event


POLE enthält alle Objekte und ihre Verbindungen.

Party: Logische Repräsentation eines Individuums

Object: Logische Repräsentation eines physischen Objekts

Location: Logische Repräsentation einer Ortes

Event: Logische Repräsentation eines Ereignisses

Party

Object Location

Event

MATCH (P1:person {name:’John’})-[R1:goes_to]->(L1:’conference’) RETURN L1;



POLE: Party, Object, Location, Event in RDBMS


Atomare Rohdaten werden erhalten

Daten werden transformiert und in POLE geladen

AtomareDaten

POLEDatenhaltung

DatenMatching(MDM)

Dat

en

Que

llen

Land

ing

Are

aA

naly

tisch

e D

aten

in

MP

P D

aten

bank

(G

reen

plum

)SemantischerLayer(virtuelle Views)

POLE

Party Object Location Event

EL ETL Views


CSV, TXT, XLS, Oracle, SQL


CentOS Development Server 2

Architektur


Staging

CentOS Development Server 1

Web Front End

CSVs POLE subset

POLE Verbindungen POLE Attribute

JSON

DI Studio



Herausforderungen


POLE reduziert Entwicklungszeit und Fehleranfälligkeit und ist einfach verständlich, da die Komplexität nicht mit der Datentiefe oder Datenbreite zunimmt.

Es gibt aber viele POLE Objekte als Duplikate. Diese müssen zusammengeführt werden.

Hierfür wird ein probabilistisches Abgleichungsverfahren eingesetzt. Das Verfahren vergleicht viele Charakteristiken der Objekte und errechnet einen Übereinstimmungswert. Die Regeln zur Berechnung können von einem Algorithmus basierend auf allen Datensätzen bestimmt werden.

Ähnlich einem Gerichtsverfahren beurteilen die Regeln ( = Richter) unabhängig voneinander und kommen zu einer gemeinsamen Entscheidung.

„Namen-Richter“ „Tel. Nr.-Richter“ „Teilnehmer-ID Richter“

Record 1Name: Tom K. Klausen

Tel. Nr. (089) 872-1277

Teilnehmer-ID 872312318

Record 2Name: Thomas Klaussen

Tel. Nr. (089) 872-1727

Teilnehmer-ID 872412318



Datenhaltung


• GreenPlum• Enthält als relationale Datenbank alle Daten.• Es ist sehr ineffizient Verbindungen zwischen Datenobjekten zu

finden da mehrere Joins nötig wären. Eine „real-time“ Performance wäre nicht gegeben.

• Neo4J: • Ist ideal zur Identifizierung von Verbindungen zwischen Objekten.• Auch die Skalierung wird als sehr gut empfunden.• Daten werden zwischen den Server repliziert. Eine Partitionierung

findet nicht statt.• Herausforderung: Automatisches, zeitbezogenes Löschen von

Daten.• Um verschiedene Sichten auf die Daten zu ermöglichen muss die

Graphdatenbank dupliziert werden.

• Für eine Freitextsuche ist Neo4j nicht ideal. Hierfür wird Elasticsearch verwendet.



Lessons-Learned


NoSQL-Datenbanken…• sind i.d.R. stark wo RDBMS schwach sind – Marktnische muss für das Produkt existieren• hybrider Technologiestack kann Vorteile beider Systeme gewinnbringend nutzen• ein Datenmodell und Datenschema sind immer noch unerlässlich• RDBMS haben häufig Vorteile im Bereich der Sicherheit (Authentifizierung & Autorisierung)


Big-Data-Referenz-Architektur




51

• Zweck ist es existierende, interne und externe Architekturentwürfe im Big Data Umfeld zu konsolidieren.

• Die standardisierte Architektur dient als Vorlage für globale Big Data Projekte von Capgemini.

• Sie listet die wichtigsten Bausteine für Big Data Architekturen auf.

• Sie vermittelt einen breiten und umfassenden Blick auf die Fragestellungen im Big Data Umfeld und adressiert alle Stakeholder wie Endanwender, IT-Architekten, Data Scientists und Entwickler in drei verschiedenen Sichten.



Big-Data-Referenz-Architektur — Analytics


52

Der Zweck von Analytics ist es… zusätzlichen Wert zu schaffen (value) indem basierend auf Erkenntnissen gehandelt wird (insights & act) welche aus der Analyse von Informationen gewonnen werden (analyzing

information) die auf Datenverarbeitungsprozessen aus verschiedenen Quellen aufbauen

(process & source data)

ValueActInsightAnalyzeInformationProcessSource data

Data flow

Requirements



Big-Data-Referenz-Architektur — Technische Sicht


54

Manage

Process

Analyze

Information

Sourcedata

Data ExplorationReporting Ad-hoc Querying

Search, Retrieval

Structured data tables

Unstructured Data Text, speech, …

Semistructured data JSON, XML, …

Data WarehouseData Asset Catalog

Index Tags Metadata

Data Lake

Analytical Sandbox

NoSQL databases

Key value store

Documentstore

Column store

Graph store

NLP

SQL databases

Row based

Column based

Streaming, Event

Processing

File system

Analytics Base

Tables

Data Mining, Machine Learning Next Best Action

High level ingestion and data preparation

Low level ingestion

ETL/ELT

Adv. Visualization

SQ

L

SQ

L

Java

Scala

Python

R

Batch Processing

Data virtualization


NoSQL-Evaluierungsframework


NoSQL-Evaluierungsframework — Herausforderungen bei der Beurteilung von NoSQL Datenbanken


Herausforderungen

Schnelle technologische

Veränderungen im NoSQL Bereich

Benchmarks häufig von Herstellern

beeinflusst

Dokumentationen vernachlässigen

Informationen

Informationen über weniger populäre

Datenbanken schwer zugänglichI/O Benchmarks als

Entscheidungs-grundlage zu wenig





57

Beispiel für I/O Benchmarks; Yahoo! Cloud Serving Benchmark.

NoSQL Datenbanken werden von den Herstellern häufig nur im Bereich der Skalierbarkeit und Performance von Lese- und Schreibvorgängen (I/O) verglichen.





Auf der Suche nach der richtigen NoSQL Datenbank kann man sich nicht nur an I/O Performance Benchmarks orientieren. Zur umfassenden Bewertung gehören u.a. auch

das Architekturumfeld, die erwarteten Daten oder die nötigen Abfragen.



NoSQL-Evaluierungsframework — Berechnung des NoSQL Enterprise Readiness Index (NERI)


1 – Anforderungen im Anwendungsfall bestimmen das Gewicht einzelner Evaluierungskriterien

2 – Definition der Evaluierungskriterien und ihrer vier Leistungsstufen

3 – Bewertung der Kriterienerfüllung der Datenbanken

4 – Summe der gewichteten Bewertungen ergibt den vergleichbaren NERI



NoSQL-Evaluierungsframework — Kriteriencluster


Clustername Cluster Kriterien (zusammengefasst)

Globale Kriterien Verfügbarkeit bei verschiedenen Cloud Anbietern; Angebot an Service Levels; Qualität der Dokumentation; Generelles Interesse am Arbeitsmarkt (Anzahl an LinkedIn Stellen mit dieser Technologie); Mögliche Kosten

Datenmodell- und Speicherungskriterien Flexibilität des Datenschemas während der Laufzeit; Verfügbarkeit von verschiedenen Datentypen, von Speichermöglichkeiten (Disk, in-memory) und Indizes sowie von Kompression; Wege des Datenimports und Begrenzungen in der Datenbank- und Datensatzgröße.

Laufzeitkriterien (Dev Ops) Authorisierung und Authentifizierung; Backupmöglichkeiten; Logging; Monitoring des Datenbankzustands (z.B. in einem GUI)

Abfragekriterien Mächtigkeit der Abfragesprache(n) und der APIs; Schnittstellen zu populären Programmiersprachen; Erfüllung von Konsistenzkriterien

Kriterien zur verteilten Datenhaltung Verfügbarkeit, Konfigurierbarkeit und Ausfalltoleranz der Replikations- und Partitionierungsmechanismen; Mögliche Hardwareanforderungen

Performanzkritierien Verhalten der Latenz von Lese- und Schreibvorgängen unter sich erhöhender Last

1 0 0 1 01 0

0 1

0 11 1 0


NoSQL-Evaluierungsframework — Beispiel Leistungsstufen


Code Kriteriumname Kriterium Beschreibung

Leistungsstufen

0 – nicht erfüllt

1 – schlecht erfüllt

2 – gut erfüllt 3 – sehr gut erfüllt

CM8 Indizierung Bewertet, ob es

die Möglichkeit

gibt die Daten zu

indizieren.

Keine Indizes

verfügbar.

Nur ein primär

Index ist möglich.

Ein primär und

ein sekundär

Index sind

möglich.

Ein primär und

mehrere

sekundäre

Indizes sind

möglich.



NoSQL-Evaluierungsframework — Beispiel Ergebnisse


3

NE

RI 2

,243

NE

RI 2

,252

NE

RI 1

,893

NE

RI 1

,104

Possible max. weighed Rat-

ing

Apache Cas-sandra (2.1.8)

Riak KV (2.0) Redis (3.0.3) Memcached (1.4.24)

0.000

0.500

1.000

1.500

2.000

2.500

3.000

0.5980.413 0.441 0.455 0.356

0.634

0.513 0.518 0.4300.291

0.484

0.351 0.3510.238

0.133

0.655

0.4420.570

0.394

0.309

0.485

0.4000.371

0.329

0.014

0.144

0.124 0.000

0.048

0.000

Key-Value Databases

Performance Criteria - CP*Distributed Database Criteria - CD*CRUD Query Criteria - CQ*Run-Time Management Criteria - CR*Data Model and Storage Criteria - CM*Global Criteria - CG*



NoSQL-Evaluierungsframework — Zusammenfassung


NoSQL Evaluation Framework

✓ theoriebasiert

✓ umfassend

✓ wiederholbar

✓ anpassbar und erweiterbar

✓ermöglicht eine strukturierte Analyse✓ gibt eine klare und nachvollziehbare Entscheidung


Innovators Dilemma


NoSQL

RDBMS

„Disruptive Innovation“ führt zu Technologie- & Marktwechsel – NoSQL-DBs sind Disruptive Innovationen gegenüber RDBMS

interessant ist vor allem Beispielanwender b da er aus beiden Märkten / Lösungstechnologien wählen kann


tech

nisc

he L

eist

ung

Zeit

Entwicklung der

technischen Anforderungen Beispiele wo sich Anwendungsfälle heute befinden

⦿ a

⦿ b

⦿ c

Innovators Dilemma


Résumé

RDBMS oder NoSQL – wer wird gewinnen?


Gewinner sind die jeweiligen Anwender mit sinnvollen NoSQL-Anwendungsfällen –

schon heute


Wir beantworten gerne Ihre Fragen!

Ihre Fragen?


The information contained in this presentation is proprietary.Copyright © 2015 Capgemini. All rights reserved.

www.capgemini.com

About CapgeminiMit 180.000 Mitarbeitern in über 40 Ländern ist Capgemini einer der weltweit führenden Anbieter von Management- und IT-Beratung, Technologie-Services sowie Outsourcing-Dienstleistungen. Im Jahr 2014 betrug der Umsatz der Capgemini-Gruppe 10,573 Milliarden Euro.

Gemeinsam mit seinen Kunden entwickelt Capgemini Geschäfts-, Technologie- sowie Digitallösungen, die auf die individuellen Kundenanforderungen zugeschnitten sind. Damit sollen Innovationen ermöglicht sowie die Wettbewerbsfähigkeit gestärkt werden. Als multinationale Organisation und mit seinem weltweiten Liefermodell Rightshore® zeichnet sich Capgemini durch seine besondere Art der Zusammenarbeit aus – die Collaborative Business ExperienceTM.

Erfahren Sie mehr unter http://www.de.capgemini.com.

http://www.facebook.com/Capgemini

http://www.linkedin.com/company/capgemini

http://www.twitter.com/capgemini

http://www.youtube.com/user/capgeminimedia

http://www.slideshare.net/capgemini