Cloud Data Management

Größe: px
Ab Seite anzeigen:

Download "Cloud Data Management"

Transkript

1 Cloud Data Management Kapitel 4: Record Stores und RDBMS Dr. Michael Hartung Sommersemester 2012 Universität Leipzig Institut für Informatik 1

2 Inhaltsverzeichnis Record Stores BigTable/HBase, Cassandra ACID-Eigenschaften: Megastore Replikation Relationale Datenbanken in der Cloud H-Store/VoltDB 2

3 BigTable und HBase Verteilte Datenspeicherung mit erweiterbarem relationalen Modell Ziele Spaltenorientierter Key-Value-Store Multi-Dimensional, Versioniert Hochverfügbar, High-Performance Milliarden von Zeilen, Millionen von Spalten, Tausende von Versionen Real-time read/write random access Große Datenmengen (mehrere PB) Lineare Skalierbarkeit mit Anzahl Nodes HBase ist Hadoop s BigTable Implementation BigTable Tablet Master Server HBase Region HBase Master Tablet Server GFS SSTable File HBase Region Server HFS MapFile File 3

4 Einsatzfälle Beispiel Web-Tabelle Tabelle mit gecrawlten Webseiten mit ihren Attributen/Inhalten Key: Webseiten-URL Millionen/Milliarden Seiten Szenarien Random-Zugriff durch Crawler zum Einfügen neuer/geänderter Webseiten Batch-Auswertungen zum Aufbau eines Suchmaschinenindex Random-Zugriff in Realzeit für Suchmaschinennutzer, um Cache-Version von Webseiten zu erhalten 4

5 Datenmodell Verteilte, mehrdimensionale, sortierte Abbildung (row:string, column:string, time:int64) string Spalten- und Zeilenschlüssel Zeitstempel Daten bestehen aus beliebigen Zeichenketten / Bytestrings Zeilen (nur) Lese- und Schreiboperationen auf eine Zeile sind atomar Speicherung der Daten in lexikographischer Reihenfolge der Zeilenschlüssel 5 [CDG+08]

6 Datenmodell (2) Spalten können zur Laufzeit beliebig hinzugefügt werden Spaltenfamilien (column families) Können n verwandte Spalten (ähnliche Inhalte) umfassen Spaltenschlüssel = Spaltenfamilie:Kennzeichen Benachbarte Speicherung von Spalten einer Familie innerhalb Familie: flexible Erweiterbarkeit um neue Spalten Zeitstempel mehrere Versionen pro Zelle festgelegte Versionszahl: automatisches Löschen älterer Daten 6 [CDG+08]

7 Datenmodell (3) Konzeptionelle Sicht (alternativ) Row Key Time Stamp Column Contents Column Family Anchor com.cnn.www T9 Anchor:cnnsi.com CNN T8 Anchor:my.look.ca CNN.COM T6 <html>.. T5 <html>.. Physische Speicherung Row Key Time Stamp Contents com.cnn.www T6 <html>.. T5 <html>.. Row Key Time Stamp Anchor com.cnn.www T9 Anchor:cnnsi.com CNN T5 Anchor:my.look.ca CNN.COM 7

8 Architektur Datenpartitionierung Zeilen in Tabelle sortiert nach Key Horizontale Partitionierung von Tabellen in Tablets Verteilung von Tablets auf mehrere Tablet Server Master Server Zuordung: Tablet Tablet Server Hinzunahme/Entfernung von Tablet Servern Lastbalancierung für Tablet Server Tablet Server Verwaltung von ca Tablets Koordiniert Lese- und Schreibzugriffe Tablet-Split für zu große Tablets ( MB) Replikation durch GFS Client Kommunikation mit Tablet Server für Lesen und Schreiben 8 Tablet Server (GFS Chunk Server) Master Server (GFS Master Server)... Tablets (Chunks) Tablet Server (GFS Chunk Server)...

9 Tablet Location Zweistufige Katalogverwaltung mit Root- und METADATA-Tabellen Root Tabelle Verweis auf alle Tablets einer METADATA Tabelle wird niemals geteilt = genau ein Tablet METADATA Tabelle Verweis auf alle Tablets (von User Tabellen) Identifikator: Tabellenname + letzte Zeile (Key) Tabellen sind sortiert nach Key Adressraum Eintragsgröße: 1KB Tablet Größe: 128MB Adressierbare Tablets: Größe aller Tablets: 9

10 Tablet: Lese-und Schreibzugriffe SSTable File Sortierte Map, unveränderbar nach Erstellung Bloom Filter zur Prüfung ob Daten vorhanden für row+column Schreiben Schreiben in Transaction Log (for redo) Schreiben in MemTable (RAM) Asynchron: Compaction (Verdichtung) Minor: Kopieren von MemTable-Daten in SSTable (und entfernen aus Log) Merge: Zusammenführen von MemTable-Daten und SSTable zu neuer SSTable Major: Entfernen gelöschter Daten (=Merge in eine SSTable) Lesen Zugriff auf MemTable-Daten und SSTables um Daten zu finden 10

11 Performanz Anzahl der 1000Byte Leseund Schreib-Ops pro Sekunde Gute Skalierbarkeit für bis zu 250 Tablet Server Schreiben ist schneller als lesen Commit-Log ist nur ein append; Lesen erfordert Zugriff auf MemTable + SSTable Wahlfreies Lesen (random reads) am langsamsten Zugriff auf (alle) SSTables notwendig Scanning und sequentielles Lesen performanter Ausnutzung sortierter Keys 11

12 BigTable vs. Cassandra Cassandra = BigTable-Modell + Dynamo-Infrastruktur Consistent Hashing auf Basis des Row-Key BigTable (CP) Cassandra (AP) pro Knoten mehrere Knoten Datenmodell Lesen Schreiben Partitionierun g Anfrage- Routing Konsistenz (row, column, timestamp) string MemTable + SSTables Transaction Log + MemTable; asynchrone SSTable-Erstellung 12

13 BigTable vs. RDBMS BigTable-Eigenschaften Verteilte Punkt- und Scan-Anfragen für Reads/Writes Built-In-Replikation Skalierbarkeit Batch-Verarbeitung (Source/Sink für MapReduce) Denormalisierte Daten / breite, spärlich besetzte Tabellen kostengünstig keine Query-Engine / kein SQL Transaktionen und Sekundär-Indexe (extern) möglich, jedoch schlechte Performance RDBMS deklarative Anfragen mit SQL (Joins, Group By, Order By ) automatische Parallelisierbarkeit auf verschiedenen PDBS-Architekturen Sekundär-Indexe Referenzielle Integrität ACID-Transaktionen, 13

14 Megastore: Datenmodell Hybrider Ansatz zwischen RDBMS und Data Store Ziel: Skalierbarkeit + Replikation + ACID-Transaktionen Relationales Schema Tabellen und Properties (Attribute) Definition von Indexen Data Store mehrwertige Properties (repeated) Abbildung auf BigTable-Modell BigTable-Modell Row = Entity, Row key = (konkatenierter) Primary Key (row, column, timestamp) value 14

15 Megastore: Partitionierung Datenpartitionierung in RDBMS horizontal vs. vertikal (oder kombiniert) Ziel: Anfragen müssen nur von einem (oder wenigen) Knoten bearbeitet werden Auswahl nach Art der Anfragen (Projektion, Selektion) Problem: Anfragen über mehrere Relationen Megastore: Anwendungsspezifische Partitionierung von Entities zu Gruppen (Entity groups) Definition von Parent-Child-Beziehung zwischen Tabellen (foreign key, 1:N) Root-Table = Tabelle ohne Parent Entity group = eine Entity in Root-Table + alle seine (Kindes-)Kinder Beispiele Mail-Programm: (Nutzer+ s) Blogger: (NutzerProfil), (Blog+Posts) 15

16 Megastore: Beispiel CREATE TABLE User { User user_id name 1 Schmidt 2 Meier Photo user_id photo_id time tag :15 [Dinner,Paris] :18 [Dinner,Berlin] :34 [Berlin, Mauer]... BigTable Key user.name photo.time photo.tag photo required int64 user_id; required string name; } PRIMARY KEY(user_id), ENTITY GROUP ROOT; CREATE TABLE Photo { required int64 user_id; required int32 photo_id; required int64 time; required string full_url; optional string thumbnail_url; repeated string tag; } PRIMARY KEY(user_id, photo_id), IN TABLE User, ENTITY GROUP KEY(user_id) REFERENCES User; EG1 EG2

17 MegaStore: Entity Groups Transaktionen und konkurrierende Zugriffe ACID-Semantik innerhalb einer Entity Group (logischer Einbenutzerbetrieb, strong consistency) keine ACID-Garantie für Transaktionen über mehrere Entity Groups Replikation Entity Groups werden synchron repliziert (auch über verschiedene Data Center) unabhängige Synchronisation verschiedener Entity Groups Indexes lokal: nur innerhalb einer Entity Group global: über mehrere Entity Groups CREATE LOCAL INDEX PhotosByTime ON Photo(user_id, time); CREATE GLOBAL INDEX PhotosByTag ON Photo(tag) STORING (thumbnail_url); 17

18 Transaktionen 18 [Megastore]

19 Transaktionen innerhalb einer Entity Group ACID-Semantik: Änderungen zunächst in WAL (write-ahead log), erst danach Anwendung Multi-Version Concurrency Control (MVCC) Bigtable-Timestamp pro Transaktion zur Unterscheidung Read kann konsistente, ältere Versionen während Write lesen Write-Operation blockiert Lese-Operation nicht Transaktion Read: Bestimme Timestamp der letzten zugesicherten (commit) Transaktion + Logfile Position Anwendungslogik: Lese Daten von Bigtable und erzeuge Logfile-Eintrag Commit: Einigung zwischen Knoten, dass Logfile-Eintrag geschrieben wird Apply: Durchführen der Operationen auf den Daten, Aktualisierung der Indexes Clean-up: Löschen nicht mehr benötigter Daten 19

20 Transaktionen innerhalb einer Entity Group (2) Commit vor Apply Lese-Operationen müssen ggf. warten RDBMS: Commit (Daten sind durable ) erst, wenn alle Daten sichtbar Reads current: Warten, bis alle zugesicherten (comitted) writes durchgeführt, dann lesen snapshot: Timestamp der letzten vollständigen durchgeführten Transaktion (ggf. zugesicherte aber noch nicht durchgeführte Transaktion nicht erfasst) inconsistent: aktuelle Werte (dirty reads) Konkurrierende Writes gleichzeitiger Read-Schritt in Transaktion liefert die gleiche Logfile-Position Einigungsprotokoll (Paxos) bestimmt eine Transaktion, die an die Position schreiben darf ( Winner ) andere ( losing ) Transaktionen werden informiert und abgebrochen, meist anschließendes Retry keine Serialisierung, aber Konsistenzsicherung 20

21 Transaktionen zwischen Entity Groups Queue-Mechanismus Transaktions-Nachrichten zwischen Entity Groups Gesendet von einer Entity Group während Transaktion (an andere Entity Group) Asynchrone Ausführung, keine ACID-Transaktionssemantik 2-Phasen-Commit-Protokoll Atomare Updates in Transaktionen zwischen Entity Groups möglich möglichst vermeiden, u.a. wegen hoher Latenz 21

22 Replikation Unabhängige, synchrone Replikation pro Entity Group Anfügen von Logfile-Blöcken nach vorheriger Einigung (Paxos) 22 [Megastore]

23 Replikation: Techniken Backup Kopie des aktuellen Datenbestands Master/Slave (meist asynchrone) Weiterleitung der Änderungen von Master an Slaves Bsp: MongoDB, Dynamo (einstellbar mit r/w-quorum), GFS (synchron) Master-Master unterschiedliche Versionen auf unterschiedlichen Knoten, Konfliktauflösung nötig Bsp: CouchDB 2-Phasen-Commit (2PC) verteiltes Protokoll mit Koordinator-Knoten (Problem: Koordinatorausfall) synchron: Propose, vote, commit/abort Bsp: Verteilte DB 23

24 Replikation: Übersicht Konsistenz Backup Master-Slave Master- Master [Google I/O Transactions Across Datacenters] 2PC Paxos Transaktionen Latenz niedrig niedrig niedrig hoch hoch Durchsatz hoch hoch hoch niedrig mittel Datenverlust viel etwas (async) etwas nein nein Verfügbarkeit bei Ausfall 24

25 Paxos: Verteiltes Einigungsprotokoll Mehrere Knoten müssen sich auf einen Wert einigen Szenarien: welche Transaktion darf schreiben, Wahl eines Primary Knotens, Datenreplikation,... Bedingung Knoten funktionieren entweder ganz oder gar nicht; Recovery möglich Nachrichten werden korrekt (vollständig) gesendet oder gar nicht Knoten haben nicht-flüchtigen Speicher Vorteile fehlertolerant, d.h. geringer Einfluss von Knotenausfällen (im Gegensatz zu 2PC) garantierte Korrektheit und Terminierung (im Gegensatz zu 3PC) 25

26 Paxos Phase 1 N Prozesse jeder Prozess kann Werte vorschlagen (propose), akzeptieren (accept) und lernen (learn) jeder Prozess hat Wertebereich für eigene Nachrichten, die in aufsteigender Reihenfolge verwendet werden (i-ter Prozess: i, i+n, i+2n,...) vor Senden einer Nachricht wird Nummer auf nichtflüchtigem Speicher gesichert Client beauftragt einen Prozess als Proposer Phase 1a: Proposer schickt Nachricht an andere Prozesse und sich selbst PREPARE (n) Nachricht-Nummer n Phase 1b: Prozesse reagieren auf PREPARE-Nachricht Lesen der letzten Nachrichten-Nummer n auf die geantwortet wurde Wenn n > n (oder es kein n gibt) PROMISE (n, v ): Ich nehme nie eine PREPARE-Nachricht mit Nummer <n an. zusätzlich (wenn n vorhanden) Mitteilung von (n, v ) andernfalls ignorieren 26

27 Paxos Phase 2 Phase 2a: Wenn Proposer von Mehrheit der Prozesse (>N/2) ein PROMISE erhalten hat, sendet er ACCEPT ACCEPT(n, v ) - neue Nachrichtennummer n v = von Antwortnachricht (n,v ) mit höchstem n wenn keine, dann eigenen Vorschlagwert Phase 2b: Prozess reagieren auf ACCEPT-Nachricht Lesen der letzten Nachrichten-Nummer n auf die geantwortet wurde Wenn n > n (oder es kein n gibt) Speichern von (n,v) und ACCEPTED (n,v) andernfalls ignorieren Wenn Proposer auf Mehrheit der Prozesse eine Antwort ACCEPT erhalten hat, ist der Vorschlag angenommen Einigung Weiterleiten der Nachrichten an alle Prozesse (Learning) 27

28 Paxos: Probleme Ausfall eines Acceptors kein Problem, solange Quorum (Mehrheit) erreicht wird Ausfall eines Learners ggf. neu Senden Ausfall des Proposers Ausfall nach PROPOSE aber vor Einigung Lösung durch Bestimmung eines neuen Proposers Mehrere Proposer Ausfall eines Proposers, Bestimmung eines neuen Recovery des ausgefallenen vor Einigung Wechselseitige PREPARE-Nachrichten überstimmen sich Lösung z.b. durch zufällige Timeouts, so dass ein Proposer sich durchsetzt Allgemein: Fortschritt und Korrektheit kann garantiert werden 28

29 Inhaltsverzeichnis Record Stores BigTable/HBase, Cassandra ACID-Eigenschaften: Megastore Relationale Datenbanken in der Cloud H-Store/VoltDB 29

30 Szenario: RDBMS und das Web Web-Anwendung nutzt RDBMS irgendwann reicht ein (großer) Datenbankserver nicht mehr aus Skalierbarkeit durch verschiedene Techniken Verteiltes Caching Problem der Aktualisierung, begrenzte Funktionalität Replikation der Datenbank Lese-Workload kann verteilt werden, dafür Schreibzugriffe auch auf mehreren Knoten Data Sharding Partitionierung der Daten über verschiedene Knoten Anwendung verwaltet Sharding: Serverausfälle, Anfragen/Transaktionen die über mehrere Knoten gehen, Re-Sharding,... Ziel: Datenbank/Data Store kümmern sich um Verteilung der Daten, Performanz, Behandlung von Ausfällen,

31 Cloud Data Stores Kein SQL (NoSQL Data Stores) einfacheres Datenmodell, einfache Operationen (Suche mit Schlüssel) Einfacheres Modell für konkurrierende Zugriffe (meist) keine ACID-Semantik, nächste Folie Abgeschwächtes Konsistenzmodell Replikation meist asynchron Eventual consistency: Clients können zur selben Zeit verschiedene Daten lesen konfigurierbarer Tradeoff zwischen Konsistenz und Performanz (read-write-quorum) Erhöhte Anforderung an Client-Applikation, u.a. Auflösung von Konflikten Bsp: Mischen verschiedener Warenkörbe Umgang mit Fehlern auf Grund fehlender Transaktionen Bsp: gleichzeitiges Kaufen des letzten Produkts Handling von eventual Consistency Bsp: verzögerte Aktualisierung des Facebook-Status bei Freunden 31

32 Behandlung konkurrierender Zugriffe Einfache Sperren pro Objekt/Dokument Nur ein Client kann gleichzeitig auf ein Objekt/Dokument/Record zugreifen Bsp: Azure Storage, MongoDB, BigTable MVCC Multi version concurrency control Erstellung und Management mehrere Versionen des gleichen Objekts/Dokuments/Records pro Knoten Client leistet Konfliktauflösung Bsp: Dynamo, CouchDB, Cassandra keine Behandlung keine Garantien hinsichtlich resultierender Daten bei konkurrierenden Zugriffen Bsp: SimpleDB ACID logische Serialisierung von Transaktionen (u.a. durch Sperren) Bsp: RDBMS, MegaStore (teilweise), VoltDB [Sigmod Record] 32

33 RBDMS-Designprinzipien RBDMS wurden für Shared-Memory und (später) Shared-Disk- Architekturen entwickelt Cloud Data Center: Shared Nothing RDBMS wurden primär für Speicherung und Verarbeitung von Daten auf Festplatten entwickelt; Hauptspeicher nur für Caching zunehmende Größe des Hauptspeichers ermöglicht andere Nutzungsformen RDBMS realisieren Recovery durch Logfiles auf Festplatte Schnelle Netzwerkstruktur ermöglicht Recovery durch Kopieren von Knoten RDBMS realisieren eine strenge Transaktionssemantik (ACID) zur Sicherung des Datenkonsistenz durch Locking Internet-Anwendungen können mit vereinfachten Konsistenzmodellen umgehen RDBMS unterstützen Multi-Threading Gründe: T2 kann bereits ausgeführt werden, wenn T1 auf Daten (von Platte) wartet; lange Transaktionen sollen kurze nicht blockieren (geringe Latenz) Szenario nicht mehr stets relevant (multi core, Hauptspeicherzugriff, OLTP workload) 33

34 Zeitaufteilung für RDBMS 13% sinnvoll Finden relevanter Daten, Aktualisieren der Werte 20% Locking Setzen, Aufheben und Verwalten von Sperren, Deadlock-Erkennung Ziel: Logischer Einbenutzerbetrieb 23% Logging Schreiben/Lesen von Logfiles Ziel: Redo Recovery (Wiederherstellung bei Ausfall), Undo Recovery (Wiederherstellung des Ursprungszustands bei Transaktionsabbruch) 33% Buffer Management Abbildung der Tabellen bzw. Datensätze in Seiten (Pages), die dann blockweise auf Festplatte gespeichert werden 11% Latching im Mehrbenutzerbetrieb Kurzzeitsperren für interne Datenstrukturen bei Mehrbenutzerbetrieb 34 Harizopoulos, S. et. al., OLTP: Through the Looking Glass and What We Found There, SIGMOD, June 2008.

35 RDBMS-Nutzung für Web-Anwendungen Erfolg einfacher Data Stores (KV, Document) zeigt, dass Datenunabhängigkeit nicht im Fokus steht enge Verzahnung von Web-Anwendung und Data Store Viele Web-Anwendungen haben einfache(re) Nutzungsformen OLTP mit einfachen Schreib/-Lese-Operationen wenige Datensätze schreiben und lesen pro Transaktion Transaktionen sind im Vorfeld bekannt keine ad-hoc Anfragen Transaktionen sind meist vergleichsweise einfach keiner User Stalls Nicht: komplexe Joins, OLAP, etc. 35

36 HStore: Überblick Verteilte Datenbank mehrere Knoten (Shared-Nothing), pro Knoten ein oder mehrerer Sites ein Site pro CPU = single-threaded Datenbank kein Latching Hauptspeicher-Datenbank zeilen-orientierte Speicherung im Hauptspeicher (B-Tree) kein Buffer Pool Transaktionen keine ad-hoc SQL-Anfragen, nur Stored Procedures (SP) direkter Zugriff und Datentransfer (kein ODBC) Transaktionen (SP) werden a-priori registriert und klassifiziert (z.b. two phase ) Globale Reihenfolge von Transaktionen strenge Konsistenz ACID-Eigenschaften Recovery Recovery mittels Replikate kein Logging VoltDB HStore als Open-Source-Produkt (mit Firma für Support) 36

37 HStore: Site-Architektur 37 Jones, Abadi, and Madden, "Low overhead concurrency control for partitioned main memory databases, SIGMOD 2010

38 Datenpartitionierung und Transaktionen Viele Schemas sind Tree Schemas ein (oder mehrere) Root-Tabellen (z.b. Kunde) andere Tabellen haben (mehrfache) 1:N-Beziehung zu Root-Tabelle Horizontale Partitionierung der Root-Tabelle Horizontale Partitionierung der anderen Tabellen gemäß Root-Tabellen- Partitionierung Alle Informationen zu einem Root-Datensatz in gleicher Partition vgl. Entity Group in Megastore Ziel: Ausnutzen von Single Site -Transaktionen Alle Operationen einer Transaktion in selber Partition (häufiger Fall) Weitere Arten von Transaktionen Two-Phase: erst nur Reads, evtl. Abort, dann alle Writes Commute: beliebige Verschränkung zweier Transkationen führt stets zum gleichen Ergebnis 38

39 HStore: Infrastruktur 39

40 Ausführung von Transaktionen Transaktionen erhalten eindeutigen Timestamp (site_id, local_unique_timestamp) Alle Sites sind geordnet, Uhrzeiten zwischen Sites (nahezu) synchron globale Ordnung Replikation 2+ Kopien jeder Tabelle Reads an beliebige Site, Writes werden an alle Sites gesendet Single-Site Transaktionen Primary Site sendet an Secondary (Backup) Sites weiter etwas warten, um sicherzustellen, dass keine früheren Transaktionen kommen Unabhängige, parallele Ausführung Annahme: Lokales Ergebnis (commit oder abort) = globales Ergebnis An Client = Primary Transaktionsergebnis, nachdem alle Secondary ein acknowledge geschickt haben ( Transaktionsergebnis) Kein ReDo-Log, keine Concurrency Control Two-Phase Transaktionen: Zusätzlich kein UnDo-Log 40

41 Multi-Node-Transaktion Multi-Node-Transaktion durch zentralen Koordinator Globale Reihenfolge der Transaktionen Einsatz mehrere Koordinator möglich mit globaler Reihenfolge Ausführung Zerlegung in mehrere Fragmente, die jeweils an Site geschickt werden Undo-Puffer um bei evtl. Abbruch Ursprungszustand wieder herzustellen Abschluss nach Bearbeitung des letzten Fragments sendet Primary alle Fragmente an alle Secondary und wartet auf acknowledge Prüfung auf commit/abort nicht nötig, da gleiches Ergebnis wie Primary 41

42 Zusammenfassung Relational Data Stores und RDBMS Umsetzung von RDBMS-Aspekten in Shared-Nothing-Architekturen Erweiterung von einfachen Data Stores um Anfragemächtigkeit und Indexes Konsistenzsicherung abgeschwächte ACID-Semantik MVCC-Prinzip um konsistente Vorversionen während Writes lesen zu können Performanz-Aspekte Daten in Hauptspeicher möglichst wenige Plattenzugriffe nur komplette SSTables einmal schreiben (BigTable) Realisierung Logfile-basierter RDBMS-Techniken ohne Plattenzugriffe möglichst wenige Multi-Node-Operationen durch geschickte anwendungs/schemaspezifische Datenpartitionierung Fokus auf spezielle OLTP-Anwendungen 42

43 Referenzen [HBase] [BigTable] Fay Chang, Jeffrey Dean, Sanjay Ghemawat et al. Bigtable: A Distributed Storage System for Structured Data. OSDI 06 [Megastore] Baker et al: Megastore: Providing Scalable, Highly Available Storage for Interactive Services. CIDR 11 [OLTP] Harizopoulos et al: OLTP through the looking glass, and what we found there. SIGMOD, 2008 [HStore] Stonebraker et al: The end of an architectural era: (it s time for a complete rewrite), VLDB

BigTable. 11.12.2012 Else

BigTable. 11.12.2012 Else BigTable 11.12.2012 Else Einführung Distributed Storage System im Einsatz bei Google (2006) speichert strukturierte Daten petabyte-scale, > 1000 Nodes nicht relational, NoSQL setzt auf GFS auf 11.12.2012

Mehr

NoSQL-Datenbanken. Kapitel 1: Einführung. Lars Kolb Sommersemester 2014. Universität Leipzig http://dbs.uni-leipzig.de 1-1

NoSQL-Datenbanken. Kapitel 1: Einführung. Lars Kolb Sommersemester 2014. Universität Leipzig http://dbs.uni-leipzig.de 1-1 NoSQL-Datenbanken Kapitel 1: Einführung Lars Kolb Sommersemester 2014 Universität Leipzig http://dbs.uni-leipzig.de 1-1 Inhaltsverzeichnis NoSQL-Datenbanken Motivation und Definition Kategorisierung, Eigenschaften

Mehr

9. Cloud Data Management

9. Cloud Data Management 9. Cloud Data Management Einführung Verteilte Datenhaltung Dateisysteme (GFS) Hbase (Google Big Table) Amazon Dynamo MapReduce B 9-1 Cloud Computing Cloud computing is using the internet to access someone

Mehr

TAV Übung 3. Übung 3: Verteilte Datenhaltung

TAV Übung 3. Übung 3: Verteilte Datenhaltung Übung 3: Verteilte Datenhaltung 1. Serialisierung Konstruieren Sie Historien aus drei Transaktionen T1, T2 und T3, die folgende Merkmale aufweisen: 1. Die serielle Reihenfolge ist T1 vor T2 vor T3. 2.

Mehr

Algorithmen. Consistent Hashing Bloom Filter MapReduce. Distributed Hash Tables. Einführung 1

Algorithmen. Consistent Hashing Bloom Filter MapReduce. Distributed Hash Tables. Einführung 1 Algorithmen Consistent Hashing Bloom Filter MapReduce Distributed Hash Tables Einführung 1 Consistent Hashing Problem: Wie finde ich den Speicherort für ein Objekt in einem verteilten System mit n Knoten?

Mehr

Google Spanner. Proseminar Ein-/Ausgabe Stand der Wissenschaft. Hanno Harte. Betreuer: Julian Kunkel 24.6.13

Google Spanner. Proseminar Ein-/Ausgabe Stand der Wissenschaft. Hanno Harte. Betreuer: Julian Kunkel 24.6.13 Google Spanner Proseminar Ein-/Ausgabe Stand der Wissenschaft Hanno Harte Betreuer: Julian Kunkel 24.6.13 1 /31 Gliederung - Überblick - Funktionsweise - True Time - Konsistenzsemantik - Benchmarks - Zusammenfassung

Mehr

NoSQL-Databases. Präsentation für Advanced Seminar "Computer Engineering", Matthias Hauck, matthias.hauck@stud.uni-heidelberg.de

NoSQL-Databases. Präsentation für Advanced Seminar Computer Engineering, Matthias Hauck, matthias.hauck@stud.uni-heidelberg.de NoSQL-Databases Präsentation für Advanced Seminar "Computer Engineering", Matthias Hauck, matthias.hauck@stud.uni-heidelberg.de Klassische SQL-Datenbanken Anwendungsgebiet: Geschäftsanwendungen Behördenanwendungen

Mehr

Apache HBase. A BigTable Column Store on top of Hadoop

Apache HBase. A BigTable Column Store on top of Hadoop Apache HBase A BigTable Column Store on top of Hadoop Ich bin... Mitch Köhler Selbstständig seit 2010 Tätig als Softwareentwickler Softwarearchitekt Student an der OVGU seit Oktober 2011 Schwerpunkte Client/Server,

Mehr

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2

Seminar Cloud Data Management WS09/10. Tabelle1 Tabelle2 Seminar Cloud Data Management WS09/10 Tabelle1 Tabelle2 1 Einführung DBMS in der Cloud Vergleich verschiedener DBMS Beispiele Microsoft Azure Amazon RDS Amazon EC2 Relational Databases AMIs Was gibt es

Mehr

Wide Column Stores. Felix Bruckner Mannheim, 15.06.2012

Wide Column Stores. Felix Bruckner Mannheim, 15.06.2012 Wide Column Stores Felix Bruckner Mannheim, 15.06.2012 Agenda Einführung Motivation Grundlagen NoSQL Grundlagen Wide Column Stores Anwendungsfälle Datenmodell Technik Wide Column Stores & Cloud Computing

Mehr

Persönlichkeiten bei bluehands

Persönlichkeiten bei bluehands Persönlichkeiten bei Technologien bei Skalierbare Anwendungen mit Windows Azure GmbH & co.mmunication KG am@.de; posts..de/am 1 2 3 4 5 6 7 8 9 Immer mehr Mehr Performance Mehr Menge Mehr Verfügbarkeit

Mehr

Think Big. Skalierbare Anwendungen mit Azure. Aydin Mir Mohammadi Bluehands GmbH & co.mmunication KG

Think Big. Skalierbare Anwendungen mit Azure. Aydin Mir Mohammadi Bluehands GmbH & co.mmunication KG Skalierbare Anwendungen mit Azure Bluehands GmbH & co.mmunication KG 1 2 3 4 5 6 7 8 9 Immer mehr Mehr Performance Mehr Menge Mehr Verfügbarkeit Skalierung http://www.flickr.com/photos/39901968@n04/4864698533/

Mehr

Oracle Big Data Technologien Ein Überblick

Oracle Big Data Technologien Ein Überblick Oracle Big Data Technologien Ein Überblick Ralf Lange Global ISV & OEM Sales NoSQL: Eine kurze Geschichte Internet-Boom: Erste Ansätze selbstgebauter "Datenbanken" Google stellt "MapReduce"

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

NoSQL Deep Dive mit Cassandra. Kai Spichale

NoSQL Deep Dive mit Cassandra. Kai Spichale NoSQL Deep Dive mit Cassandra Kai Spichale 13.04.2011 1 NoSQL 13.04.2011 2 BerlinExpertDays NoSQL Wide Column Stores / Column Families Document Stores Graph Databases Key Value / Tupe Stores 13.04.2011

Mehr

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann

TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann TU München, Fakultät für Informatik Lehrstuhl III: Datenbanksysteme Prof. Dr. Thomas Neumann Blatt Nr. 11 Übung zur Vorlesung Einsatz und Realisierung von Datenbanksystemen im SoSe15 Moritz Kaufmann (moritz.kaufmann@tum.de)

Mehr

NoSQL-Datenbanken. Kapitel 2: Key-Value Stores. Lars Kolb Sommersemester 2014. Universität Leipzig http://dbs.uni-leipzig.de 2-1

NoSQL-Datenbanken. Kapitel 2: Key-Value Stores. Lars Kolb Sommersemester 2014. Universität Leipzig http://dbs.uni-leipzig.de 2-1 NoSQL-Datenbanken Kapitel 2: Key-Value Stores Lars Kolb Sommersemester 2014 Universität Leipzig http://dbs.uni-leipzig.de 2-1 Inhaltsverzeichnis Key-Value Stores File/Object Storage Services Beispiele:

Mehr

Einführung in Hauptspeicherdatenbanken

Einführung in Hauptspeicherdatenbanken Einführung in Hauptspeicherdatenbanken Harald Zankl Probevorlesung 13. 01., 13:15 14:00, HS C Inhaltsverzeichnis Organisation Überblick Konklusion Harald Zankl (LFU) Hauptspeicherdatenbanken 2/16 Organisation

Mehr

NoSQL. Was Architekten beachten sollten. Dr. Halil-Cem Gürsoy adesso AG. Architekturtag @ SEACON 2012 Hamburg

NoSQL. Was Architekten beachten sollten. Dr. Halil-Cem Gürsoy adesso AG. Architekturtag @ SEACON 2012 Hamburg NoSQL Was Architekten beachten sollten Dr. Halil-Cem Gürsoy adesso AG Architekturtag @ SEACON 2012 Hamburg 06.06.2012 Agenda Ein Blick in die Welt der RDBMS Klassifizierung von NoSQL-Datenbanken Gemeinsamkeiten

Mehr

Apache Hadoop. Distribute your data and your application. Bernd Fondermann freier Software Architekt bernd.fondermann@brainlounge.de berndf@apache.

Apache Hadoop. Distribute your data and your application. Bernd Fondermann freier Software Architekt bernd.fondermann@brainlounge.de berndf@apache. Apache Hadoop Distribute your data and your application Bernd Fondermann freier Software Architekt bernd.fondermann@brainlounge.de berndf@apache.org Apache The Apache Software Foundation Community und

Mehr

Verteilte Systeme. Map Reduce. Secure Identity Research Group

Verteilte Systeme. Map Reduce. Secure Identity Research Group Verteilte Systeme Map Reduce Map Reduce Problem: Ein Rechen-Job (meist Datenanalyse/Data-Mining) soll auf einer riesigen Datenmenge ausgeführt werden. Teile der Aufgabe sind parallelisierbar, aber das

Mehr

Verteilte Systeme - 5. Übung

Verteilte Systeme - 5. Übung Verteilte Systeme - 5. Übung Dr. Jens Brandt Sommersemester 2011 Transaktionen a) Erläutere was Transaktionen sind und wofür diese benötigt werden. Folge von Operationen mit bestimmten Eigenschaften: Atomicity

Mehr

PostgreSQL in großen Installationen

PostgreSQL in großen Installationen PostgreSQL in großen Installationen Cybertec Schönig & Schönig GmbH Hans-Jürgen Schönig Wieso PostgreSQL? - Die fortschrittlichste Open Source Database - Lizenzpolitik: wirkliche Freiheit - Stabilität,

Mehr

PostgreSQL im praktischen Einsatz. Stefan Schumacher

PostgreSQL im praktischen Einsatz. Stefan Schumacher PostgreSQL im praktischen Einsatz 2. Brandenburger Linux Infotag 2005 Stefan Schumacher , PGP Key http:/// $Header: /home/daten/cvs/postgresql/folien.tex,v 1.11 2005/04/25

Mehr

Vorlesungsinhalt. Recovery. G. Specht: Datenbanksysteme 11-1. Kapitel XI. Vorlesung Datenbanksysteme Univ.-Prof. Dr.

Vorlesungsinhalt. Recovery. G. Specht: Datenbanksysteme 11-1. Kapitel XI. Vorlesung Datenbanksysteme Univ.-Prof. Dr. Recovery Kapitel XI Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt 11. Recovery Fehler

Mehr

Eine Einführung in Apache CouchDB. Java-Forum Stuttgart 2011

Eine Einführung in Apache CouchDB. Java-Forum Stuttgart 2011 Eine Einführung in Apache CouchDB Java-Forum Stuttgart 2011 Johannes Schneider, cedarsoft GmbH js@cedarsoft.com http://blog.cedarsoft.com http://cedarsoft.com Vielen Dank CouchDB The VERY Basics Vorerfahrung?

Mehr

Datenbanktechnologien für Big Data

Datenbanktechnologien für Big Data Datenbanktechnologien für Big Data Oktober 2013 Prof. Dr. Uta Störl Hochschule Darmstadt Big Data Technologien Motivation Big Data Technologien NoSQL-Datenbanksysteme Spaltenorientierte Datenbanksysteme

Mehr

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576 ein verteiltes und repliziertes Dateisystem is funded by the European Commission XtreemOS IPunder project contract IST-FP6-033576 1 Das XtreemOS Projekt Europäisches Forschungsprojekt gefördert von der

Mehr

Kapitel 4 Teil 2 NoSQL-Datenbanksysteme

Kapitel 4 Teil 2 NoSQL-Datenbanksysteme Kapitel 4 Teil 2 NoSQL-Datenbanksysteme Inhalt: CAP (Consistency/Availability/Partition-Tolerance); BASE (Basically Available, Soft State, Eventually Consistent); Datenmodelle: Key-Value-Stores, Spaltenbasierte

Mehr

Charakteristika und Vergleich von SQL- und NoSQL- Datenbanken

Charakteristika und Vergleich von SQL- und NoSQL- Datenbanken Universität Leipzig Fakultät für Mathematik und Informatik Abteilung Datenbanken Dozent: Prof. Dr. Erhard Rahm Betreuer: Stefan Endrullis Problemseminar NoSQL-Datenbanken Semester: WS 11/12 Charakteristika

Mehr

NoSQL Datenbanken. Seminar:Software as a Service, Cloud-Computing und aktuelle Entwicklungen Dozent: Dipl. Inf. Andreas Göbel

NoSQL Datenbanken. Seminar:Software as a Service, Cloud-Computing und aktuelle Entwicklungen Dozent: Dipl. Inf. Andreas Göbel NoSQL Datenbanken Seminar:Software as a Service, Cloud-Computing und aktuelle Entwicklungen Dozent: Dipl. Inf. Andreas Göbel 17. Juni 2010 Gliederung Der Begriff NoSQL Wichtige Konzepte NoSQL-Arten Cassandra

Mehr

BigTable vs. HBase. Iman Gharib. Schriftliche Ausarbeitung angefertigt im Rahmen des Seminars NOSQL

BigTable vs. HBase. Iman Gharib. Schriftliche Ausarbeitung angefertigt im Rahmen des Seminars NOSQL BigTable vs. HBase Iman Gharib Schriftliche Ausarbeitung angefertigt im Rahmen des Seminars NOSQL Universität Leipzig Fakultät für Mathematik und Informatik Wintersemester 2012 Betreuerin: Diplom-Bioinformatikerin

Mehr

MySQL Replikationstechnologien

MySQL Replikationstechnologien MySQL Replikationstechnologien Lenz Grimmer MySQL Community Relations Specialist $ whoami 1998 2002 2008 2010 Agenda Replikation: Definition und Klassifizierung Anwendungsgebiete

Mehr

Cassandra Query Language (CQL)

Cassandra Query Language (CQL) Cassandra Query Language (CQL) Seminar: NoSQL Wintersemester 2013/2014 Cassandra Zwischenpräsentation 1 Gliederung Basic facts Datentypen DDL/DML ähnlich zu SQL Besonderheiten Basic facts CQL kurz für

Mehr

Analyse und Auswertung großer heterogener Datenmengen

Analyse und Auswertung großer heterogener Datenmengen Analyse und Auswertung großer heterogener Datenmengen Herausforderungen für die IT-Infrastruktur Richard Göbel Inhalt Big Data Was ist das eigentlich? Was nützt mir das? Wie lassen sich solche großen Datenmengen

Mehr

Semantic Web: Resource Description Framework (RDF)

Semantic Web: Resource Description Framework (RDF) Big Data Semantic Web: RDF Information Retrieval Map Reduce: Massiv parallele Verarbeitung Datenströme Peer to Peer Informationssysteme No SQL Systeme Multi-Tenancy/Cloud-Datenbanken Semantic Web: Resource

Mehr

Web Technologien NoSQL Datenbanken

Web Technologien NoSQL Datenbanken Web Technologien NoSQL Datenbanken Univ.-Prof. Dr.-Ing. Wolfgang Maass Chair in Information and Service Systems Department of Law and Economics WS 2011/2012 Wednesdays, 8:00 10:00 a.m. Room HS 021, B4

Mehr

Einsatz von Replikation. Florian Munz

Einsatz von Replikation. Florian Munz Einsatz von Replikation Florian Munz Agenda Wofür braucht man Replikation? Anwendungsszenarien Wie funktioniert Replikation? Konsistenzbegriff und Strategien Wie implementiert man Replikation? Lösungen

Mehr

MySQL Cluster. Kai Voigt MySQL AB kai@mysql.com. Kiel, 17. Februar 2006

MySQL Cluster. Kai Voigt MySQL AB kai@mysql.com. Kiel, 17. Februar 2006 MySQL Cluster Kai Voigt MySQL AB kai@mysql.com Kiel, 17. Februar 2006 1 Agenda Warum? Wie? Wie genau? Was sonst? 2 Warum? 3 Kosten runter Hochverfügbarkeit (99,999%) Redundante Daten und Systeme Wiederherstellung

Mehr

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS)

Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht. Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Verteilte DB-Systeme Kapitel XIII Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt 13.

Mehr

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER

DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER DATENBANKEN SQL UND SQLITE VON MELANIE SCHLIEBENER INHALTSVERZEICHNIS 1. Datenbanken 2. SQL 1.1 Sinn und Zweck 1.2 Definition 1.3 Modelle 1.4 Relationales Datenbankmodell 2.1 Definition 2.2 Befehle 3.

Mehr

Grundlagen der PostgreSQL Administration

Grundlagen der PostgreSQL Administration Jens Wilke Vortrag bei der BELUG 16.03.2011 Der Vortrag behandelt die Installation und Konfiguration von PostgreSQL, dem fortschrittlichsten Open Source Datenbanksystem. Es wird auf die wichtigsten Konfigurationsparameter

Mehr

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen

Transaktionen Recovery Isolationslevel. Datenbanksysteme. Transaktionen. Burkhardt Renz. Fachbereich MNI Technische Hochschule Mittelhessen Transaktionen Fachbereich MNI Technische Hochschule Mittelhessen Sommersemester 2015 Motivation ACID-Eigenschaften Übersicht Transaktionen Motivation ACID-Eigenschaften Ursachen für Logging und Backup

Mehr

Key Value Stores. (CouchDB, BigTable, Hadoop, Dynamo, Cassandra)

Key Value Stores. (CouchDB, BigTable, Hadoop, Dynamo, Cassandra) Key Value Stores (CouchDB, BigTable, Hadoop, Dynamo, Cassandra) 1 Neue Herausforderungen große Datenmengen in Unternehmen Twitter, youtube, facebook, (social media) Daten als Ware bzw. Rohstoff x TB /

Mehr

Einführung in Hadoop

Einführung in Hadoop Einführung in Hadoop Inhalt / Lern-Ziele Übersicht: Basis-Architektur von Hadoop Einführung in HDFS Einführung in MapReduce Ausblick: Hadoop Ökosystem Optimierungen Versionen 10.02.2012 Prof. Dr. Christian

Mehr

Hauptspeicher- Datenbanksysteme. Hardware-Entwicklungen Column- versus Row-Store...

Hauptspeicher- Datenbanksysteme. Hardware-Entwicklungen Column- versus Row-Store... Hauptspeicher- Datenbanksysteme Hardware-Entwicklungen Column- versus Row-Store... Hauptspeicher-Datenbanksysteme Disk is Tape, Tape is dead Jim Gray Die Zeit ist reif für ein Re-engineering der Datenbanksysteme

Mehr

NoSQL. Einblick in die Welt nicht-relationaler Datenbanken. Christoph Föhrdes. UnFUG, SS10 17.06.2010

NoSQL. Einblick in die Welt nicht-relationaler Datenbanken. Christoph Föhrdes. UnFUG, SS10 17.06.2010 NoSQL Einblick in die Welt nicht-relationaler Datenbanken Christoph Föhrdes UnFUG, SS10 17.06.2010 About me Christoph Föhrdes AIB Semester 7 IRC: cfo #unfug@irc.ghb.fh-furtwangen.de netblox GbR (http://netblox.de)

Mehr

Red Hat Cluster Suite

Red Hat Cluster Suite Red Hat Cluster Suite Building high-available Applications Thomas Grazer Linuxtage 2008 Outline 1 Clusterarten 2 3 Architektur Konfiguration 4 Clusterarten Was ist eigentlich ein Cluster? Wozu braucht

Mehr

Wiederherstellung (Recovery)

Wiederherstellung (Recovery) Fragestellungen Aufgaben der Komponenten für das Recovery: Sicherstellung der Dauerhaftigkeit der gespeicherten Daten, d.h. Daten, die in einer Transaktion einmal bestätigt wurden (commit), bleiben auch

Mehr

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken - Speichern und Analysen von großen Datenmengen Lennart Leist Inhaltsverzeichnis 1 Einführung 2 1.1 Aufgaben einer Datenbank...................... 2 1.2 Geschichtliche Entwicklung

Mehr

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung

Mehr

SQL structured query language

SQL structured query language Umfangreiche Datenmengen werden üblicherweise in relationalen Datenbank-Systemen (RDBMS) gespeichert Logische Struktur der Datenbank wird mittels Entity/Realtionship-Diagrammen dargestellt structured query

Mehr

SimpleVOC-Yetanother. Bausteine für eine Key/Value- Datenbank

SimpleVOC-Yetanother. Bausteine für eine Key/Value- Datenbank SimpleVOC-Yetanother Memcached? Bausteine für eine Key/Value- Datenbank SimpleVOC Yet another memcached? Bausteine für eine Key/Value Datenbank. Theorie (Martin Schönert) Praxis (Frank Celler) Eine Weisheit

Mehr

MySQL Backup und Restore

MySQL Backup und Restore MySQL Backup und Restore DOAG Konferenz 2013 Nürnberg Oli Sennhauser Senior MySQL Consultant, FromDual GmbH oli.sennhauser@fromdual.com 1 / 22 Über FromDual GmbH FromDual bietet neutral und unabhängig:

Mehr

MapReduce in der Praxis

MapReduce in der Praxis MapReduce in der Praxis Rolf Daniel Seminar Multicore Programmierung 09.12.2010 1 / 53 Agenda Einleitung 1 Einleitung 2 3 Disco Hadoop BOOM 4 2 / 53 1 Einleitung 2 3 Disco Hadoop BOOM 4 3 / 53 Motivation

Mehr

Erweiterung des verteilten Datenspeichersystems Cassandra um eine Indexunterstützung

Erweiterung des verteilten Datenspeichersystems Cassandra um eine Indexunterstützung Leibniz Universität Hannover Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Datenbanken und Informationssysteme Erweiterung des verteilten Datenspeichersystems

Mehr

EHCache und Terracotta. Jochen Wiedmann, Software AG

EHCache und Terracotta. Jochen Wiedmann, Software AG EH und Terracotta Jochen Wiedmann, Software AG Autor Perl-Contributor DBD::mySQL 2, DBI::Proxy, DBI::Shell, DBD::CSV, Net::Daemon, RPC::Pl(Client Server) (Autor) DBI (Developer) ASF-Member (Apache Software

Mehr

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)

Mehr

Weniger ist mehr? Skalierbares Datenmanagement zwischen NoSQL und klassischen DBS

Weniger ist mehr? Skalierbares Datenmanagement zwischen NoSQL und klassischen DBS Weniger ist mehr? Skalierbares Datenmanagement zwischen NoSQL und klassischen DBS Herbsttreffen der FG DB, 17./18.11.2011 Kai-Uwe Sattler Ilmenau University of Technology, Germany www.tu-ilmenau.de/dbis

Mehr

Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen

Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen Brownbag am Freitag, den 26.07.2013 Daniel Bäurer inovex GmbH Systems Engineer Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und

Mehr

Alle Metadaten werden in Dateien gehalten

Alle Metadaten werden in Dateien gehalten 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6.3 Metadaten Alle Metadaten werden in Dateien gehalten Indexnummer 0 1 2 3 4 5 6 7 8 16 17 MFT MFT Kopie (teilweise) Log File Volume Information Attributtabelle

Mehr

NoSQL & Big Data. NoSQL Databases and Big Data. NoSQL vs SQL DBs. NoSQL DBs - Überblick. Datenorientierte Systemanalyse. Gerhard Wohlgenannt

NoSQL & Big Data. NoSQL Databases and Big Data. NoSQL vs SQL DBs. NoSQL DBs - Überblick. Datenorientierte Systemanalyse. Gerhard Wohlgenannt NoSQL & Big Data Datenorientierte Systemanalyse NoSQL Databases and Big Data Gerhard Wohlgenannt Die besprochenen Systeme haben nicht den Anspruch und das Ziel DBS zu ersetzen, sondern für gewisse Anwendungsfälle

Mehr

DATA WAREHOUSE. Big Data Alfred Schlaucher, Oracle

DATA WAREHOUSE. Big Data Alfred Schlaucher, Oracle DATA WAREHOUSE Big Data Alfred Schlaucher, Oracle Scale up Unternehmensdaten zusammenfassen Noch mehr Informationen aus Unternehmens- Daten ziehen! Datenmengen, Performance und Kosten Daten als Geschäftsmodell

Mehr

Big Data. Prof. Robert Jäschke Forschungszentrum L3S Leibniz Universität Hannover

Big Data. Prof. Robert Jäschke Forschungszentrum L3S Leibniz Universität Hannover Big Data Prof. Robert Jäschke Forschungszentrum L3S Leibniz Universität Hannover Agenda Was ist Big Data? Parallele Programmierung Map/Reduce Der Big Data Zoo 2 3Vs oder: Was ist Big Data? Deutsche Telekom:

Mehr

Replikation mit PostgreSQL 9.2

Replikation mit PostgreSQL 9.2 Replikation mit PostgreSQL 9.2 CLT 2013 16./17.03.2013 Andreas akretschmer Kretschmer, Andreas ads Scherbaum Web: http://a-kretschmer.de http://andreas.scherbaum.la/ / http://andreas.scherbaum.biz/ 16./17.03.2013

Mehr

IBM Informix Tuning und Monitoring

IBM Informix Tuning und Monitoring Seminarunterlage Version: 11.01 Copyright Version 11.01 vom 25. Juli 2012 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

NoSQL User Group Cologne

NoSQL User Group Cologne NoSQL User Group Cologne Dieser Vortrag wurde im Rahmen eines Treffens der NoSQL User Group Cologne am 07.09.2011 gehalten. Wir treffen uns immer am ersten Mittwoch des Monats. Weitere Informationen zur

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

Mehr

www.raber-maercker.de Herzlich willkommen!

www.raber-maercker.de Herzlich willkommen! www.raber-maercker.de Herzlich willkommen! Raber+Märcker GmbH Hochverfügbarkeit für Dynamics NAV-, Exchange- und SQL-Server Thomas Kuhn Microsoft Certified Solution Developer Teamleiter Server Applications

Mehr

NoSQL. Hintergründe und Anwendungen. Andreas Winschu

NoSQL. Hintergründe und Anwendungen. Andreas Winschu NoSQL Hintergründe und Anwendungen Andreas Winschu 1 Inhalt 1. Motivation 2. RDBMS 3. CAP Theorem 4. NoSQL 5. NoSql Overview 6. NoSQl Praxis 7. Zusammenfassung und Ausblick 2 1.Motivation Datenbanken Permanente

Mehr

Teil XI Spalten-orientierte DBMSs

Teil XI Spalten-orientierte DBMSs Teil XI Spalten-orientierte DBMSs Spalten-orientierte Datenbankmanagementsysteme 1 Motivation 2 Funktionsweise 3 Erweiterungen 4 Literatur c Sattler / Saake / Köppen Data-Warehouse-Technologien Letzte

Mehr

SQL- & NoSQL-Datenbanken. Speichern und Analysen von großen Datenmengen

SQL- & NoSQL-Datenbanken. Speichern und Analysen von großen Datenmengen SQL- & NoSQL-Datenbanken Speichern und Analysen von großen Datenmengen 1 04.07.14 Zitat von Eric Schmidt (Google CEO): There was 5 exabytes of information created between the dawn of civilization through

Mehr

NoSQL-Datenbanksysteme: Revolution oder Evolution?

NoSQL-Datenbanksysteme: Revolution oder Evolution? NoSQL-Datenbanksysteme: Revolution oder Evolution? Kolloquium Institut für Informatik, Universität Rostock 24.01.2013 Prof. Dr. Uta Störl Hochschule Darmstadt uta.stoerl@h-da.de NoSQL: DAS aktuelle Datenbank-Buzzword

Mehr

Oracle Datenbank Architektur nicht nur für Einsteiger. Martin Klier Klug GmbH integrierte Systeme, Teunz

Oracle Datenbank Architektur nicht nur für Einsteiger. Martin Klier Klug GmbH integrierte Systeme, Teunz Oracle Datenbank Architektur nicht nur für Einsteiger Martin Klier Klug GmbH integrierte Systeme, Teunz DOAG Webinar, 08.03.2012 Referent Martin Klier Datenbankadministrator für Fachliche Schwerpunkte:

Mehr

Cloud-Computing. 1. Definition 2. Was bietet Cloud-Computing. 3. Technische Lösungen. 4. Kritik an der Cloud. 2.1 Industrie 2.

Cloud-Computing. 1. Definition 2. Was bietet Cloud-Computing. 3. Technische Lösungen. 4. Kritik an der Cloud. 2.1 Industrie 2. Cloud Computing Frank Hallas und Alexander Butiu Universität Erlangen Nürnberg, Lehrstuhl für Hardware/Software CoDesign Multicorearchitectures and Programming Seminar, Sommersemester 2013 1. Definition

Mehr

Replikation mit PostgreSQL 9.0

Replikation mit PostgreSQL 9.0 Replikation mit PostgreSQL 9.0 FrOSCon 2010 21.-22.08.2010 Andreas ads Scherbaum Web: http://andreas.scherbaum.la/ E-Mail: andreas[at]scherbaum.biz PGP: 9F67 73D3 43AA B30E CA8F 56E5 3002 8D24 4813 B5FE

Mehr

Dokumentenorientierte Datenbanken - MongoDB

Dokumentenorientierte Datenbanken - MongoDB Dokumentenorientierte Datenbanken - MongoDB Jan Hentschel Ultra Tendency UG Übersicht Dokumente sind unabhängige Einheiten Bessere Performance (zusammengehörige Daten werden gemeinsam gelesen) Objektmodell

Mehr

NoSQL-Datenbanken. Markus Kramer. deren Probleme herauszuarbeiten und andere Grundlagen zu erläutern.

NoSQL-Datenbanken. Markus Kramer. deren Probleme herauszuarbeiten und andere Grundlagen zu erläutern. 1 NoSQL-Datenbanken Markus Kramer Zusammenfassung NoSQL-Datenbanken sind zu einer interessanten Alternative zu herkömmlichen Datenbanken geworden. In dieser Arbeit werden die dahinter liegenden Konzepte

Mehr

Verteilte Dateisysteme in der Cloud

Verteilte Dateisysteme in der Cloud Verteilte Dateisysteme in der Cloud Cloud Data Management Maria Moritz Seminar Cloud Data Management WS09/10 Universität Leipzig 1 Inhalt 1.) Anforderungen an verteilte Dateisysteme 2.) GoogleFS 3.) Hadoop

Mehr

Institut für Verteilte Systeme

Institut für Verteilte Systeme Institut für Verteilte Systeme Prof. Dr. Franz Hauck Seminar: Multimedia- und Internetsysteme, Wintersemester 2010/11 Betreuer: Jörg Domaschka Bericht zur Seminarssitzung am 2011-01-31 Bearbeitet von :

Mehr

Semantik und konzeptionelle Modellierung

Semantik und konzeptionelle Modellierung Semantik und konzeptionelle Modellierung Verteilte Datenbanken Christoph Walesch Fachbereich MNI der FH Gieÿen-Friedberg 18.1.2011 1 / 40 Inhaltsverzeichnis 1 Verteiltes Rechnen MapReduce MapReduce Beispiel

Mehr

Storage-Trends am LRZ. Dr. Christoph Biardzki

Storage-Trends am LRZ. Dr. Christoph Biardzki Storage-Trends am LRZ Dr. Christoph Biardzki 1 Über das Leibniz-Rechenzentrum (LRZ) Seit 50 Jahren Rechenzentrum der Bayerischen Akademie der Wissenschaften IT-Dienstleister für Münchner Universitäten

Mehr

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1 Datenbanksystem System Global Area Hintergrundprozesse Dr. Frank Haney 1 Komponenten des Datenbanksystems System Global Area Program Global Area Hintergrundprozesse Dr. Frank Haney 2 System Global Area

Mehr

Replikation in Datenbanken

Replikation in Datenbanken Replikation in Datenbanken Vortrag: Datenbanken II Yves Adler Hochschule für Technik, Wirtschaft und Kultur Leipzig Fachbereich Informatik, Mathematik und Naturwissenschaften Y. Adler (HTWK Leipzig) Replikation

Mehr

Microsoft Server 2012 Hyper-V Replica für Oracle Database

Microsoft Server 2012 Hyper-V Replica für Oracle Database Microsoft Server 2012 Hyper-V Replica für Oracle Database Seite 1 Inhalt 1 Executive Summary... 3 2 Windows Server 2012 R2 Hyper- V Replica Technologie- Review... 3 2.1 Begriffe... 3 2.2 Konfigurationsoptionen:...

Mehr

3. Architektur eines DBS (Oracle)

3. Architektur eines DBS (Oracle) 3. Architektur eines DBS (Oracle) aus Sicht des Datenbank Server Rechners Connectivity Komponente(n) des DBS (z.b. Oracle Listener) Installation ORACLE_HOME Instanz ORACLE_SID Datenbank Oracle: 1 (aktive)

Mehr

Transaktionsverwaltung und Recovery

Transaktionsverwaltung und Recovery Transaktionsverwaltung und Recovery Transaktionsverwaltung Transaktionsbegriff Synchronisation und Sperren Isolation Level in SQL MVCC Hierarchische Sperren Isolation Level und Sperren in relationalen

Mehr

Alternative Architekturen

Alternative Architekturen Die Architektur eines Datenbankmanagementsystems, wie wir sie bisher besprochen haben, geht von zwei grundlegenden Annahmen aus:. Die Daten sind sowohl auf der Platte als auch für das Zugriffssystem im

Mehr

Neo4J & Sones GraphDB. Graph-Datenbanken. Von Toni Fröschke. Problemseminar NoSQL-Datenbanken (WS 2011/12)

Neo4J & Sones GraphDB. Graph-Datenbanken. Von Toni Fröschke. Problemseminar NoSQL-Datenbanken (WS 2011/12) Neo4J & Sones GraphDB Graph-Datenbanken Von Toni Fröschke Problemseminar NoSQL-Datenbanken (WS 2011/12) Gliederung Neo4J Überblick Neo4J-Komponenten Datenhaltung/ -verwaltung Verfügbarkeit & Recovery I/O

Mehr

Hochverfügbarkeit mit MySQL: Eine Kartographie der Lösungen

Hochverfügbarkeit mit MySQL: Eine Kartographie der Lösungen Erkan Yanar (linsenraum.de) Hochverfügbarkeit mit MySQL: Eine Kartographie der Lösungen 20. November DOAG 2012 20121 / 24 Hochverfügbarkeit mit MySQL: Eine Kartographie der Lösungen DOAG 2012 Erkan Yanar

Mehr

Caching. Hintergründe, Patterns &" Best Practices" für Business Anwendungen

Caching. Hintergründe, Patterns & Best Practices für Business Anwendungen Caching Hintergründe, Patterns &" Best Practices" für Business Anwendungen Michael Plöd" Senacor Technologies AG @bitboss Business-Anwendung!= Twitter / Facebook & co. " / kæʃ /" bezeichnet in der EDV

Mehr

MySQL-Server im Teamwork - Replikation und Cluster

MySQL-Server im Teamwork - Replikation und Cluster MySQL-Server im Teamwork - Replikation und Cluster DOAG München, 2015-Sep-28 Jörg Brühe Senior Support Engineer, FromDual GmbH joerg.bruehe@fromdual.com 1 / 33 FromDual GmbH Support Beratung remote-dba

Mehr

Grundlagen der PostgreSQL Administration. Timo Pagel

Grundlagen der PostgreSQL Administration. Timo Pagel Grundlagen der PostgreSQL Administration Timo Pagel Agenda Installation/Konfiguration Backup/Restore Hochverfügbarkeit Überwachung Ausführungspläne 04.11.12 Grundlagen der PostgreSQL Administration 2/50

Mehr

MySQL Hochverfügbarkeitslösungen. Lenz Grimmer http://lenzg.net/ Twitter: @lenzgr 2010-04-24 Grazer Linuxtage Austria

MySQL Hochverfügbarkeitslösungen. Lenz Grimmer <lenz@grimmer.com> http://lenzg.net/ Twitter: @lenzgr 2010-04-24 Grazer Linuxtage Austria MySQL Hochverfügbarkeitslösungen Lenz Grimmer < http://lenzg.net/ Twitter: @lenzgr 2010-04-24 Grazer Linuxtage Austria Agenda Konzepte & Aspekte MySQL Replikation Disk replikation (DRBD)

Mehr

Datenbankanwendung. Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern. Wintersemester 2014/15. smichel@cs.uni-kl.de

Datenbankanwendung. Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern. Wintersemester 2014/15. smichel@cs.uni-kl.de Datenbankanwendung Wintersemester 2014/15 Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern smichel@cs.uni-kl.de MapReduce MapReduce - Veranschaulichung der Phasen Prof. Dr.-Ing. S. Michel TU Kaiserslautern

Mehr

SQL Server 2014 Roadshow

SQL Server 2014 Roadshow 1 SQL Server 2014 Roadshow Kursleitung: Dieter Rüetschi (ruetschi@ability-solutions.ch) 2 Inhalt Allgemeine Informationen Buffer Pool Extension Column Store Index In Memory OLTP Scripting Security SQL

Mehr

Datenbanken: Backup und Recovery

Datenbanken: Backup und Recovery Der Prozess der Wiederherstellung der Daten einer Datenbank nach einem Fehler im laufenden Betrieb in einen konsistenten, möglichst verlustfreien Zustand heißt Recovery. Beteiligt an diesem Recovery sind

Mehr

Weitere Decision-Support Anfrage- Typen

Weitere Decision-Support Anfrage- Typen Big Data Top-k / Ranking / Skyline Semantic Web: RDF Information Retrieval PageRank / HITS Map Reduce: Massiv parallele Verarbeitung Datenströme Peer to Peer Informationssysteme No SQL Systeme Multi-Tenancy/Cloud-Datenbanken

Mehr