document

Java Mag
Mit Kubernetes in der Entwicklung starten 48
3.2016
magazin
Java • Architekturen • Web • Agile
www.javamagazin.de
AngularJS
TensorFlow
Die Fallstricke 70
Der Weg des maschinellen Lernens 11
infos
Programm
5!
ab Seite 3
!
h
c
t
a
M
a
s
’
It
Finde die NoSQL-­
Datenbank, die zu
dir passt
r
ü
f
k
c
u
r
d
Sonder
© iStockphoto.com/bowie15
e
d
.
c
i
r
t
n
e
c
e
www.cod
Technische Schulden
managen 30
Mobile Apps mit eigenem Backend 54
AngularJS-Performance
verbessern 78
Sonderdruck
Agile
Auswahl einer NoSQL-Lösung
k
n
a
b
n
e
t
a
D
e
h
c
l
We
?
r
i
m
u
z
t
ss
a
p
HBase, MongoDB, Couchbase, Redis … Die Zahl der
verschiedenen NoSQL-Systeme ist groß und der Markt
unübersichtlich. Gleichzeitig wird der Einsatz dieser
Lösungen für viele Unternehmen zunehmend relevanter. Daher stellt sich bei Entwicklungsprojekten immer
öfter die Frage: Welche NoSQL-Datenbank ist die richtige für meine Anwendung? Und welche Implikationen
bringt die neue Technologie mit sich?
von Stefan Siprell und Philip Stroh
2
javamagazin 2 | 2016
© Software & Support Media GmbH
www.JAXenter.de
Sonderdruck
Agile
Unternehmensanwendungen müssen heute in immer
kürzerer Zeit immer größere Datenmengen verarbeiten.
Gerade im Bereich hochverfügbarere Webanwendungen, die performant mit großen Datenmengen umgehen
müssen, sind relationale Datenbanksysteme oft nicht
mehr in der Lage, moderne Anforderungen zu befriedigen. In vielen Unternehmen halten daher seit einiger
Zeit NoSQL-Datenbanken Einzug.
Die Auswahl eines geeigneten NoSQL-Systems fällt
durch die Vielfalt der Lösungen allerdings schwer. Anders als bei relationalen Datenbanksystemen, deren
Funktionalitäten sich oft überdecken, ist die NoSQLWelt wesentlich heterogener und ein Vergleich dadurch
umso schwieriger. Aktuell werden über 200 unterschiedliche Lösungen unter dem Oberbegriff NoSQL
geführt [1].
Die TimoCom, eine Laderaum- und Frachtenbörse, hat
sich im Zuge eines Projektvorhabens die Frage gestellt,
welche NoSQL-Lösung die richtige Wahl für die zukünftige Weiterentwicklung ihrer B2B-Plattform ist. Dabei lag
der Fokus zum einen auf der Einführung einer Messenger-Applikation für die Kunden-zu-Kunden-Kommunikation, die sich in das bestehende Webangebot integriert.
Zum anderen lag der Fokus auf dem Konsolidieren der
bereits existierenden NoSQL-Systeme und dem Abgrenzen dieser Systeme hinsichtlich ihres Einsatzgebiets.
Mit Unterstützung der codecentric wurde hierzu ein
Auswahlprozess gestartet, ursprünglich mit dem zugegebenermaßen naiven Ziel, möglichst nur ein System zu
ermitteln, das den gewünschten Anforderungskatalog
abdeckt. Hierbei wurde allerdings schnell klar, dass eine
Universallösung durch die unterschiedlichen Stärken
und Schwächen der Technologien nicht zu finden ist.
Stattdessen galt es, für die Anforderungen des jeweiligen
Projekts die passende Datenbank auszuwählen.
Doch welche markanten Kriterien gibt es, nach denen die NoSQL-Welt geordnet werden kann und die
den bestehenden Anforderungen gerecht werden? Die
Unterscheidung zwischen dokumenten- und spaltenorientierten Systemen sowie Key-Value Stores ist bekannt.
Aber welche Vor- und Nachteile bringen die unterschiedlichen Kategorien mit sich und für welche Anwendungsfälle eignen sie sich?
Vorgehen bei der Systemauswahl: Was ist wichtig?
Die Systemauswahl in unserem Beispiel erfolgte in mehreren Schritten. Zuerst haben wir einen allgemeinen
Überblick über die verschiedenen Systeme erstellt, der
diese nach bestimmten Kategorien gruppiert. Pro Kategorie unterscheiden sich die Systeme in der Regel in
Bezug auf Betriebs- und Entwicklungsaspekte, wie z. B.
der Clustering-Konfiguration. Relativ ähnlich verhalten
sie sich aber im Hinblick auf grundlegende Eigenschaften, z. B. für welche Art von Daten sich diese Systeme
eignen und wie sich die Datenmodellierung gestaltet
(u. a. [2]). Diese gemeinsamen Charakteristiken wurden
in einem Entscheidungsbaum für den weiteren Auswahlprozess berücksichtigt.
www.JAXenter.de
Bereits im Vorfeld der Untersuchung haben wir die
Anforderungen an die Systeme und Einsatzszenarien aus
bestehenden und geplanten Projekten abgeleitet. Nachdem die zu betrachtenden Systemkategorien und deren
grundlegende Eigenschaften bestimmt waren, haben wir
im nächsten Schritt pro Kategorie die Unterschiede zwischen den Systemen untersucht, um hieraus letztendlich
die geeignete Lösung im Abgleich mit den Anforderungen zu bestimmen. Hierbei wurden u. a. die folgenden
Aspekte geprüft:
•CAP-Theorem: Welche Aspekte der Konsistenz, Verfügbarkeit und Partitionstoleranz werden durch die
Lösung unterstützt [3]?
•Schreib- und Leseverhalten: Ist die Datenbank eher
für Schreib- oder Lesezugriffe optimiert? Ist auch ein
Mixed Workload möglich?
•Performance und Skalierbarkeit: Werden die notwendigen Performanceanforderungen erfüllt? Skaliert die
Lösung idealerweise linear?
•Entwicklung: Wie gestaltet sich die Nutzung in der
Entwicklung? Welche Treiber gibt es und wie gut
integrieren sich diese mit den bereits verwendeten
Java-Frameworks?
•Infrastruktur: Welche Hardwareanforderungen stellt
das System und wie verträgt es sich mit der bestehenden Infrastruktur? Ist die Lösung On-Premise zu
betreiben?
•Betrieb und Administration: Wie komplex sind der
Aufbau und der Betrieb eines entsprechenden Clusters? Welche Administrations- und Monitoringtools
gibt es? Wie funktionieren Backup- und FailoverMechanismen?
•Weitere Aspekte: Wie verbreitet ist die Lösung? Ist
sie für den kommerziellen Einsatz geeignet? Gibt es
kommerziellen Support?
Im Entscheidungs- und Bewertungsprozess wurden
Kollegen aus Betrieb, Administration und Entwicklung
einbezogen und deren Erfahrungen und Anforderungen
an zukünftige Tools berücksichtigt. Teilweise wurden
kleinere Prototypen entwickelt, um das System bspw.
aus Entwicklersicht zu bewerten. Dies führte letztendlich auch zu einem breiten Konsens über das zukünftige
Toolset.
Online vs. offline
Grundsätzlich gibt es zwei Zugriffsprofile für Daten:
Man möchte diese entweder transaktional (= online)
ansprechen oder analytisch (= offline) auswerten. Für
den allgemeinen Überblick über die verschiedenen Datenbanken wurde daher auf oberster Ebene zwischen
Artikelserie:
Teil 1: Auswahl einer NoSQL-Lösung
Teil 2: Einführung einer NoSQL-Lösung
© Software & Support Media GmbH
javamagazin 3 | 2016
3
Sonderdruck
Agile
Datenbanken für den Onlineeinsatz und Produkten für
den Offlineeinsatz unterschieden.
Online impliziert dabei immer eine wartende Anfrage eines Kunden oder anderen Systems. Der Abschluss
der Operation wird benötigt, um einen Geschäftsvorfall
anzubahnen, auszuführen oder zu beenden. Typische
Applikationen sind E-Commerce-Systeme, Social-Media-Netzwerke oder Suchmaschinen. Hier sind niedrige Latenzzeiten über aktuelle Daten entscheidend. Im
Onlinebereich sollten somit vorrangig Systeme gewählt
werden, die einzelne Anfragen schnell und verlässlich
ausführen können.
Offlinesysteme hingegen werden nicht direkt für Kundenanfragen benötigt. Die Daten in Offlinesystemen
werden häufig per Batch Job verarbeitet, und es werden
zu bestimmten Zeiten Ergebnisse erwartet. Typische
Muster sind Klassifizierungs-, Reporting- und Analyseanwendungen. Im Gegensatz zu den Onlinesystemen sind Verfügbarkeit und Geschwindigkeit einzelner
Transaktionen hier zweitrangig.
Daten in Offlinesystemen speichern und analysieren
Wenn es darum geht, große Datenmengen im Offlinebereich zu speichern und zu analysieren, ist eine Hadoop-Lösung das Standardwerkzeug. Hadoop ist keine
NoSQL-Datenbank im engeren Sinne. Es ist vielmehr
ein Framework zur verteilten Datenspeicherung und
-verarbeitung. Big-Data-Architekturen sehen Hadoopund NoSQL-Datenbanken vielfach als Ergänzung zueinander. Die NoSQL-Systeme speichern die Daten aus den
Online-Use-Cases und befüllen nachgelagert auch Hadoop. Dort lassen sich die Daten daraufhin systemübergreifend analysieren. Um möglichst effektive Analysen
im Offlinespeicher durchführen zu können, müssen die
Rohdaten gespeichert werden, direkt wie sie anfallen.
Aggregation oder Sampling der Daten würden die Daten
hinsichtlich ihrer Qualität und Aussagekraft einschränken oder verfälschen.
Hadoops HDFS (Hadoop Distributed File System)
ist ein hochverfügbares Dateisystem, das es erlaubt, unstrukturierte Rohdaten in großen Mengen, verteilt auf
mehreren Clusterknoten, zu speichern. HDFS repliziert
die Daten auf dem Softwarelayer, sodass auf Commodity-Hardware günstig gearbeitet werden kann – mittlerweile ist der TCO (Total Cost of Ownership) eines
Terabytes pro Jahr unter die 500-Euro-Marke gerutscht.
Es existiert des Weiteren ein reichhaltiges Ökosystem,
um aus den Rohdaten aussagekräftige Analysen zu extrahieren. Mit dem Ressourcenmanager YARN können zudem weitere Werkzeuge jenseits vom klassischen
Map­Reduce genutzt werden, um die riesigen Datenmengen zu verarbeiten. Immer populärer wird hier bspw. die
Kombination mit Apache Spark [4].
Daten in Onlinesystemen speichern und analysieren
Bei den NoSQL-Systemen im Onlinebereich gibt es verschiedene Paradigmen, die zu speichernden Daten zu
strukturieren:
•Dokumentenbasiert: Datensätze werden als in sich
geschlossene Dokumente gespeichert. Die Dokumente (meist im JSON-Format) können beliebig hierarchisch erweitert werden.
•Spaltenbasiert: Analog zu RDBMS werden Datensätze in Zeilen und Attribute in Spalten gespeichert,
allerdings erlauben die spaltenorientierten Systeme
Milliarden an Spalten pro Zeile.
•Schlüsselwertebasiert: Einträge werden als einfache
Werte (skalare Strings, Listen, Sets und Maps) gespeichert und einem Schlüssel zugeordnet. Werte lassen
sich nur über ihre Schlüssel finden.
•Graphenbasiert: In Graphen stehen nicht die Daten
selbst im Vordergrund, stattdessen werden vorrangig
deren Beziehungen untereinander verwaltet.
Graphdatenbanken haben wir aufgrund eines fehlenden Anwendungsfalls in der Untersuchung nicht weiter
evaluiert. Key-Value-basierte Speicherungen sind eher
Spezialfälle – hierzu später mehr. Grundsätzlich ist es
möglich, jede Art von Information nach beliebigen Vorgaben zu strukturieren. Die Eignung einer Methode für
einen Informationstyp ist daher keine eindeutige „Geht/
geht nicht“-Entscheidung, sondern vielmehr eine De­
sign­entscheidung dazu, wie gut sich Modellierung anwenden lässt.
In dokumentenorientierten Lösungen wird ein Dokument (hierarchische Ansammlung von Datenknoten) in
der Regel in ein binäres Format serialisiert, indiziert und
persistiert. Das Dokument muss analog zu einer Zeile
vollständig gelesen werden, um dieses auszuwerten –
Aspekt
Dokumentenorientiert
Spaltenorientiert
Größendynamik der Entität
Starr – Wachsende Entitäten ziehen teure
Reorganisationen nach sich
Dynamisch – Wachsende Entitäten sind
einfach weitere Spalten
Wiederholende Strukturen
Referenz – Strukturen und Inhalte werden
als Dokumente referenziert
Denormalisierung – Wiederholende Werte
werden als Teil des Schlüssels gehalten
Abfragedynamik
Hoch – Durch Referenzen können
neue Anfragetypen auf der gleichen
Speicherstruktur ausgeführt werden
Gering – Speicherstrukturen sind sehr
stark für die jeweiligen Abfragen optimiert
Grouped-Reads
Schlecht – Dokumente können beliebig
verteilt werden, hoher Koordinationsaufwand
im Cluster
Gut – Durch das Halten von verwandten
Daten auf einem lokalen Knoten wird der
Koordinationsaufwand im Cluster reduziert
Tabelle 1: Dokumenten- oder spaltenorientierte Datenbank? Wie die verschiedenen Systeme mit verschiedenen Aspekten umgehen
4
javamagazin 3 | 2016
© Software & Support Media GmbH
www.JAXenter.de
Sonderdruck
Agile
auch wenn von vielen Dokumenten(-zeilen) immer nur
eine Eigenschaft (Spalte) benötigt wird. Zudem gibt es
wenige Möglichkeiten, Strukturen und Inhalte zu modellieren, die sich über eine Vielzahl von Dokumenten erstrecken – dies kann nur über Dokumentreferenzen analog
zu einem Join in SQL erreicht werden. Zuletzt muss man
relativ stark in das System eingreifen, um die Verteilung
der Dokumente auf dem Cluster zu beeinflussen.
In spaltenorientierten Systemen, auch BigTable-Systeme genannt, werden die Daten hingegen in einer multidimensionalen Map gespeichert und auf eine mehr oder
weniger flache Tabellenstruktur projiziert. Wiederholt
man z. B. millionenfach einen Teil des Schlüssels, wird
der Wert nur einmal in der Map und die weiteren Teile des Schlüssels bzw. die Werte werden als Sub-Maps
gespeichert. Da man die Daten mit geringem Overhead
stark denormalisieren kann, optimiert man die Strukturen für die jeweiligen Abfragen – so entfällt in der Regel
die Notwendigkeit, Daten während einer Abfrage zu dereferenzieren. BigTable-Systeme erlauben es außerdem,
über den Aufbau der Schlüssel zu modellieren, wie die
Daten im Cluster verteilt werden. So können bspw. bei
Cassandra-Daten lokal (d. h. auf einer Node im Cluster) zusammengehalten werden, indem sie den obersten
Schlüssel (Partition Key) teilen.
Im direkten Vergleich der Systeme ist noch anzumerken, dass Dokumente eine hohe Varianz an Speicherlängen haben können. Dokumentenbasierte Systeme lassen
in den persistierten Datenblöcken daher häufig leeren
Platz zwischen den einzelnen Dokumenten. Sofern ein
einzelnes Dokument nur beschränkt wächst, reicht der
Platz meist aus. Ist dies aber nicht mehr der Fall, müssen mit hohem Aufwand die Blöcke physisch auf dem
Massenspeicher reorganisiert werden. Cassandra, als
Vertreter der spaltenorientierten Systeme, speichert hingegen die Änderungen im Append-only-Modus auf dem
Massenspeicher und wird regelmäßig neue optimierte
Versionen der Datenblöcke persistieren und die alten
entsorgen.
Durch die starken Unterschiede liegen die „Sweet Spots“
der Systeme in verschiedenen Bereichen (Tabelle 1).
Es wurde schnell klar, dass kein Modell das andere
ersetzen kann – stattdessen mussten die Systeme sich
ergänzen, um allen Anforderungen gerecht zu werden.
Zusammengefasst ergibt sich somit aus Sicht der
Datenmodellierung folgendes Bild: In spaltenorientierten Systemen lassen sich insbesondere listenbasierte
Datenmodelle mit kleinen und einfach strukturierten
Entitäten gut abbilden. Einsatzszenarien sind bspw.
Server-Events, Telematikdaten, Transaktionsprotokolle, Sensordaten und Ähnliches. Dokumentenbasierte
Systeme dagegen sind geeignet, wenn Dokumente mit
relativ konstanter Dokumentengröße vorliegen. Das
Datenmodell kann dabei durchaus komplexer sein. Dies
trifft u. a. für Stammdatensysteme zu.
Bei der weiteren Systemauswahl wurden die dokumentenbasierten Datenbanken MongoDB und
Couchbase genauer untersucht. An dieser Stelle kann al-
www.JAXenter.de
lerdings nur sehr verkürzt auf die Unterschiede zwischen
den beiden Lösungen eingegangen werden. Couchbase
hatte auf den ersten Blick die innovativeren Konzepte,
bspw. ein hochperformantes, auf Memcached basierendes Backend, eine einfache Clusterkonfiguration und
eine bessere Skalierung. MongoDB hingegen überzeugt
beim Handling aus Entwicklersicht durch eine ausgereifte Query-Sprache, Out-of-the-box-Indizes, eine hohe
Verbreitung in der Community, einen eingebauten verteilten Objectstore und auch eine bessere Unterstützung
von Dokumentenupdates im API.
Der Abgleich mit den potenziellen Einsatzszenarios ergab bei Betrachtung der erwarteten Last und der
benötigten Clustergrößen, dass Couchbase seine wahren Stärken in diesen Punkten nicht ausspielen kann.
Schließlich gab die einfachere Handhabung in der Entwicklung den Ausschlag, MongoDB als dokumentenbasierte Datenbank zu wählen. Bei den spaltenorientierten
Datenbanken wurde die Auswahl aufgrund der Verbreitung schnell auf zwei Tools beschränkt [5] – Apache
Cassandra und Apache HBase.
Hier liefert HBase zwar die besseren Performanceergebnisse bei Leseoperationen mit Range Scans,
allerdings sind die Schnelligkeit der individuellen Zugriffe über Spaltenindex oder Primärschlüssel sowie die
Schreibperformance bei Cassandra ungeschlagen. Da
bei Cassandra das Konsistenzlevel zudem dynamisch
pro Statement eingestellt werden kann (dabei bedeutet
höhere Konsistenz schlechtere Performance), können
Konsistenz und Performance flexibel gegeneinander abgewogen werden [6]. Dies war einer der ausschlaggebenden Punkte für die Wahl von Cassandra.
Systeme für spezielle Einsatzszenarien
Die bisher untersuchten Datenbanken haben ihre Daten stets auf persistentem Speicher gesichert. Unter Umständen kann es sinnvoll sein, die Daten vorrangig im
volatilen Hauptspeicher zu halten, um damit möglichst
schnell Anfragen zu bedienen. Auf dieses Vorgehen
setzen Key-Value Stores und Suchindizes. Suchindizes
wurden in Abgrenzung zu den NoSQL-Datenbanken in
der Analyse ebenfalls mit einbezogen, werden im Folgenden aber nicht im Detail beleuchtet [7].
Bei den Key-Value Stores obliegt es der Anwendung,
die Daten in Schlüssel-Wert-Paare zu gliedern und deren
Konsistenz zu gewährleisten. Da die Daten im Hauptspeicher liegen, sind mit dem schnellen Zugriff Anwendungsfälle denkbar, wie verteilte Locks, Queues, Caches
oder Counter. In den bestehenden Applikationen wurde Ehcache bereits erfolgreich als In-Memory-Cache
eingesetzt, eine andere verbreitete Alternative wäre
Hazelcast. Beide Lösungen können als JAR in die Anwendungen eingebunden werden und benötigen keine
weitere externe Installation. Falls eine Persistierung auf
Festplatte z. B. für ein Desaster Recovery benötigt wird,
ist Redis ein schlankes und horizontal gut skalierendes
Tool. Als Suchindex wurde Elasticsearch für die Volltextsuchen und das Suchen über geografische Daten
© Software & Support Media GmbH
javamagazin 3 | 2016
5
Sonderdruck
Agile
Abb. 1: Entscheidungsbaum zur Auswahl der Systemkategorie
vorgesehen, sofern die eingesetzte Datenbank hier keine
entsprechenden Möglichkeiten bietet.
Ergebnis
Aus den genannten Beobachtungen wurde ein Entscheidungsbaum abgeleitet, der es erlaubt, eine geeignete Datenbankkategorie anhand bestimmter Charakteristika
einer Applikation zu ermitteln (Abb. 1).
Für jede Kategorie wurde des Weiteren ein System
ausgewählt, das in der Kategorie besonders geeignet erscheint (Abb. 2). Hier sind tatsächlich in den meisten
Fällen die Big Player im NoSQL-Bereich als Standards
definiert worden.
Zugegebenermaßen vereinfacht der Entscheidungsbaum die Vielseitigkeit der einzelnen Systeme. Er dient bei
6
javamagazin 3 | 2016
der Auswahl einer Lösung als ein erster Indikator, welche Datenbankkategorie den jeweiligen Anwendungsfall
besonders gut abdeckt. Danach müssen weitere Eigenschaften des Systems geprüft und mit den Anforderungen
der zu entwickelnden Anwendung abgeglichen werden.
Im Laufe der Untersuchung wurden diese Eigenschaften
ebenfalls dokumentiert (Clustering, Read-/Write-Performance, Konsistenzverhalten etc.). Beim Abgleich mit den
Anforderungen kann sich beispielsweise auch ergeben,
dass man die Modellierungssicht auf das System, die im
Entscheidungsbaum hinterlegt ist, zugunsten anderer
Kriterien aufgibt. Durch die Breite der untersuchten und
zugelassenen Lösungen wurde hier aber genug Spielraum
geschaffen, um sich bei der Systemauswahl innerhalb des
ausgewählten Toolsets zu bewegen.
© Software & Support Media GmbH
www.JAXenter.de
Sonderdruck
Agile
Abb. 2: Ausgewählte Systeme in der jeweiligen Kategorie
Für die am Anfang des Artikels genannte MessengerAnwendung wurde im Rahmen der Analyse Apache
Cassandra als Datenspeicher ausgewählt. Viele der Entitäten in der Messaging-Domäne haben folgende Eigenschaften gemein:
•Sehr klein: Chatnachrichten haben wenige Attribute,
die flach modelliert sind.
•Dynamische Listen: Die Anzahl von Kontakten,
Chats, Nachrichten o. Ä. wird kontinuierlich linear
wachsen.
•Starke Zuordnung: Chatnachrichten sind bspw. immer genau einem Chat zugeordnet.
Das relativ einfache und auf Listen basierende Datenmodell der Anwendung lässt sich somit sehr gut in einer spaltenorientierten Datenbank abbilden. Zudem
überzeugten die beindruckende Schreib- und sehr gute
Leseperformance, die vielseitige Clustering-Konfiguration sowie die lineare Skalierbarkeit der Cassandra. Bei
schnell steigender Akzeptanz der Anwendung und entsprechend wachsenden Request-Zahlen lässt sich daher
durch das Hinzunehmen weiterer Knoten die Performance und Verfügbarkeit sehr leicht sicherstellen. Auch
die Handhabung in einer Java-Anwendung ist durch
entsprechende Bibliotheken gut abgedeckt.
Datenvolumens, der Performance oder der Datenvarianz ist daher ein RDBMS weiter das Mittel der Wahl,
insbesondere, wenn das entsprechende Know-how unter
den Mitarbeitern vorhanden ist.
Innerhalb des Unternehmens hat die Analyse außerdem dazu beigetragen, die NoSQL-Systeme und deren
Stärken und Schwächen besser zu verstehen. Somit ist
eine gute Grundlage für zukünftige Projekte im NoSQLBereich geschaffen. Das Ergebnis stellt gleichzeitig eine
Momentaufnahme dar, die man durch die schnelle Weiterentwicklung im Bereich der NoSQL-Datenbanken
regelmäßig überprüfen und aktualisieren muss.
Nach Abschluss des Auswahlprozesses wurde begonnen, die Messaging-Anwendung auf Basis von Apache
Cassandra umzusetzen. Die Erfahrungen aus diesem Projekt werden im zweiten Teil dieser Artikelserie, der in der
nächsten Ausgabe erscheint, detaillierter dargestellt.
Stefan Siprell ist bei der codecentric als Architekt tätig. Seine
Schwerpunkte liegen in der Konzeption datengetriebener Anwendungen.
Philip Stroh arbeitet als Softwarearchitekt bei der TimoCom Softund Hardware GmbH. Er hat langjährige Erfahrung in der Entwicklung und Konzeption von Java-basierten Webanwendungen.
Fazit
Mit dem Entscheidungsbaum wurde ein Hilfsmittel geschaffen, das Architekten und Entwicklern eine erste
Einordnung erlaubt, welche Datenbank sich für das umzusetzende Projekt anbietet. Durch die Definition von
Standardsystemen können sich Betrieb und Entwicklung
nun gemeinsam auf die Technologien vorbereiten und
die Kenntnisse in diesem Bereich gezielt ausbauen.
Die extreme Heterogenität und Spezialisierung in
der NoSQL-Welt hat auch gezeigt, welche Vorteile
die vergleichsweise homogenen relationalen Datenbanksysteme mit ACID-Eigenschaften bieten. Für Anwendungsfälle ohne spezielle Anforderungen bzgl. des
www.JAXenter.de
Links & Literatur
[1] List of NoSQL Databases: http://bit.ly/1rWAUxS
[2] NoSQL Data Modeling Techniques: http://bit.ly/1zmWIpP
[3] Visual Guide to NoSQL Systems: http://bit.ly/1vVCAzc
[4] Spark and Hadoop: Working Together: http://bit.ly/1OfXAmN
[5] DB-Engines Ranking: http://bit.ly/1ORFaM0
[6] Kalantzis, Christos: „Revisiting 1 Million Writes per second“: http://nflx.
it/1BOd4xz
[7] Elasticsearch as a NoSQL Database: http://bit.ly/1R7BtFh
© Software & Support Media GmbH
javamagazin 3 | 2016
7