close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Die optimale Datenbank - Wie könnte sie aussehen? - JUG Saxony

EinbettenHerunterladen
Die optimale Datenbank Wie könnte sie aussehen?
Kai Spichale
adesso AG
4/4/2014
1
Datenbank Features
Graphen
ACID-Transaktionen
CRUD-Operationen
In-Memory-Technologie
JOINs + referentielle Integrität
Security
Tuning
Backups Komplexe Aggregationen
2
Hochverfügbarkeit
Recovery
SQL
Dokumente
Streaming
Einfache Administration
Volltextsuchen
Constraints
Horizontale Skalierbarkeit
JSON
Cloud
Flexibles Schma
Partitionierung
Indizes
Komprimierung
Datenbankarchitektur der 70er u. 80er Jahre
IBM System R
►
Erstes relationales Datenbankmanagementsystem
►
Forschungsprojekt in 70er Jahren
►
Abfragesprache SEQUEL und Anfrageoptimierer
►
B-Bäume als Indexverfahren
►
Beteiligung von Edgar F. Codd
►
Datenbanken folgten für Jahrzehnte der 80er-JahreArchitektur
3
“In my opinion, these legacy systems are at the end
of their useful life.”
Michael Stonebraker, 2009
Gründe
►
Datawarehouse-Systeme sind 50x schneller durch
Spaltenorientierung
►
Hauptspeicherdatenbanken sind 50-100x schneller
►
Ungeeignet für Text-basierte Anwendungen und
Suchmaschinen
4
Das Ende der RDBMS-Ära
Schlussfolgerung
►
Natürliche Datenmodelle nutzen, nicht mit Tabellen
simulieren
►
Bessere Performance mit nicht-relationale Modellen und
nativen Implementierung
►
Kein „One size fits all“
Ansatz
Performance
Konsistenz
Datenstruktur
Verfügbarkeit
5
Volumen
Datenzugriff
Änderungen
Anwendungsfälle
Messreihen
Cassandra
Produktkatalog
MongoDB
Finanzdaten
6
Empfehlungen
Neo4J
Analysen
Cassandra
Audit Log
MySQL
Cassandra
Einkaufswagen
Volltextsuche
Riak
elasticsearch
Soziales Netzwerk
FlockDB
User Sessions
Redis
Positionsdaten
MongoDB
Bestellungen
Oracle
Datenbankarchitekturen
Traditionelle
Architektur
Oracle,
MySQL
7
Shared Disk
Architektur
Oracle RAC
Shared Nothing
Architektur
Vertica,
Apache Cassandra
Datenbankarchitekturen
HauptspeicherDatenbanken
►
Daten und Zwischenergebnisse sind
Referenzen im Speicher
►
Hohe Kosten für Hauptspeicher
►
Oracle TimesTen, HSQLDB, Redis
TPC-H Benchmark (1000GB Ergebnisse)
EXASOL
4,253,937 QphH
Oracle Database 11g
326,454 QphH
Microsoft SQL Server 2008
173,961 QphH
8
Datenbankarchitekturen
Verteilte HauptspeicherDatenbanken
9
►
Lasterverteilung und Skalierung
►
„Durability“ durch Redundanz
►
SAP HANA, Exasol
Datenbankarchitekturen
Verteilter Cache
10
►
Workload von Datenbanken
reduzieren
►
Oracle Coherence, Ehcache,
Memcached
Datenbankarchitekturen
Application
(Driver)
Redundante Datenhaltung
►
Backup
Files
Besser als ein Backup ist ein
Failover Server
Datenbankarchitekturen
Application
(Driver)
Master
Slave
12
Slave
Master-Slave Replikation
►
Synchron vs. asynchron
►
Ausfallsicherheit und
Lasterverteilung
►
MongoDB, MySQL,
HBase, Neo4j
Datenbankarchitekturen
Application
(Driver)
Master
Master-Master Replikation
►
Synchron vs. asynchron
►
Ausfallsicherheit und
Lasterverteilung
Master
Beispiele
►
Apache CouchDB (Multiversion Concurrency Control)
►
Oracle (Asynchron mit Konfliktbehandlung, Synchron mit
Two-Phase-Commit)
13
Datenbankarchitekturen
DHT ohne Master
14
►
Variable Replikatanzahl
►
Geeignet für große verteilte
Systeme
►
Starke Konsistenz durch
Quorum-Reads und QuorumWrites
►
Amazon Dynamo, Apache
Cassandra, Riak
Vielzahl von Replikationskonfigurationen
One-to-One
unidrektional
One-to-Many
One-to-One
bidrektional
MultiMaster
Many-to-One
Nachrichtenbasiert
15
CAP Theorem
Eric Brewer formuliert Vermutung in 2000
► Gilbert, Lynch veröffentlichen formalen Beweis in 2002
►
Consistency
Availability
►
Partition
Tolerance
Ein verteiltes System kann niemals alle 3 Garantien
vollständig erfüllen
CA-Systeme
C
A
P
Eigenschaften
►
Starke Konsistenz durch ACID-Transaktionen
►
Ausfallsicherheit durch Multi-Master- / Master-SlaveReplikation
Vertreter
►
Klassische Persistenz-Lösungen in Enterprise-Umgebungen
►
RDBMS (IBM DB2, MySQL, Oracle)
►
Keine reinen CA-Systeme in der Praxis
17
Den Vertrag vereinfachen
►
18
Wahrscheinlichkeit für einen Serverausfall oder
eine Netzwerkpartitionierung in einem großen
verteilten System ist sehr wahrscheinlich
*P-Systeme
C
A
CP-Systeme
P
AP-Systeme
►
Garantieren starke
Konsistenz
►
Tolerieren vorrübergehende
Dateninkonsistenzen
►
Bei Partitionen wird
Konsistenz geschützt auf
Kosten der verfügbaren
Server
►
Bessere Lese- und
Schreibperformance durch
höhere Verfügbarkeit bei
Netzwerkpartitionen
►
Google Bigtable,
►
Apache Cassandra
►
Apache HBase
►
CouchDB
19
Schwache Datenkonsistenz
►
Schlussendlich werden alle N Replikate aktualisiert
Schreiboperationen
►
W = Anzahl der Replikate, die die Schreiboperation
bestätigen müssen
Leseoperationen
►
20
R = Anzahl der Replikate, die die Leseoperation bestätigen
müssen
Konfigurierbare Datenkonsistenz in Cassandra
►
Replizierte Shards werden
im Cluster verteilt
►
Konfigurierbare
Replikatanzahl
21
Konfiguration für starke Konsistenz
W=N
v1
v2
N .. #Replikate
W .. #Schreibbestätigungen
v1
v2
Client
22
Write v2
v2
v1
Konfiguration für starke Konsistenz
W=N
R=1
v2
N .. #Replikate
W .. #Schreibbestätigungen
R .. #Lesebestätigungen
Client
23
v2
Read
v2
Konfiguration für schwache Konsistenz
W=1
Nicht verfügbar
v2
N .. #Replikate
W .. #Schreibbestätigungen
v2
v3
Client
24
Write v3
v3
v2
Konfiguration für schwache Konsistenz
W=1
R=1
v2
v3
N .. #replicas
W .. #acknowledgement from replicas
R .. #read results from replicas
Client
Read
v3
v2
v2
►
25
v2
v3
Starke Datenkonsistenz: W + R > N
Schwache Konsistenz aus Client Sicht
►
Nicht alle erfolgreichen Updates sind anschließend für alle
Clients sichtbar
►
Schlussendliche Konsistenz: Garantie, dass nach einer
gewissen Zeit ohne weitere Datenänderungen alle Replikate
aktualisiert werden
►
Varianten
> Monotone Lesekonsistenz
> Read-Your-Writes-Konsistenz (Session-Konsistenz)
26
Datenmodelle
27
Key Value Stores
Vertreter: Redis
► Speichert Schlüssel-Wert-Paare
► Werte sind: „foo“, „42“, JSON-Blob, Hashes, Lists
► Sets
> Union
> Intersection
> Add / remove
> Cardinality
In-Memory Datenbank mit konfigurierbarer Persistenz
► Hash Slots mit Master-Slave-Replikation
►
28
Wide Column Stores
Vertreter: Apache Cassandra
►
Speichert Tabellen mit (fast) beliebig vielen Spalten
►
Keine Join-Operationen
►
Dynamisches Schema
►
DHT mit konfigurierbarer Konsistenzstufen
►
Kommerzielle Version mit In-Memory-Option, SolrIntegration, Hadoop-Integration
29
Spaltenorientierte Datenbanken
►
Cassandra wird häufig als spaltenorientierte Datenbank bezeichnet:
Beispiel:
ID
FIRST_NAME
LAST_NAME
1
James
Bond
2
Bruce
Lee
Zeilenorientiert: 1,James,Bond;2,Bruce,Lee;
Spaltenorientiert: 1,2;James,Bruce;Bond,Lee;
►
Aktuelle Implementierung: Cassandra speichert Daten zeilenorientiert in
SSTables auf der Festplatte
►
Zukünftige Implementierung: RCFile (Record Columnar File)
30
Dokumentenorientierte Datenbanken
Vertreter: MongoDB
►
Speichert BSON-Dokumente mit variabler Struktur
►
Aggregationsframework, MapReduce
►
Keine Join-Operationen
►
Dynamisches Schema
►
Sharding und Master-Slave-Replikation mit
unterschiedlichen Write Concerns
31
Graphendatenbanken
Vertreter: Neo4J
► Speichert Knoten und Kanten mit Properties
► Datenmodell optimiert für Traversierung
►
32
Transaktionale Master-Slave-Replikation für HA
Fazit
33
Anwendungsfallspezifische Trade-Offs
Messreihen
Cassandra
Produktkatalog
MongoDB
Finanzdaten
34
Empfehlungen
Neo4J
Analysen
Cassandra
Audit Log
MySQL
Cassandra
Einkaufswagen
Volltextsuche
Riak
elasticsearch
Soziales Netzwerk
FlockDB
User Sessions
Redis
Positionsdaten
MongoDB
Bestellungen
Oracle
Anwendungsfallspezifische Trade-Offs
Vernetzte Daten
Graph
Datenwachstum
Key Value,
Wide Column
Semistrukturierte
Daten
Dokumente,
Volltextsuchen
35
Sharding
RDBMS
ACID
Strukturierte
Daten
Kai Spichale
@kspichale
http://spichale.blogspot.de/
https://www.xing.com/profile/Kai_Spichale
36
Document
Kategorie
Technik
Seitenansichten
3
Dateigröße
545 KB
Tags
1/--Seiten
melden