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

Markus Weise. Parallele Cloud-DBS: Aufbau und Implementierung. Parallele Cloud-DBS. Abteilung Datenbanken am Institut für Informatik

Markus Weise. Parallele Cloud-DBS: Aufbau und Implementierung. Parallele Cloud-DBS. Abteilung Datenbanken am Institut für Informatik : Aufbau und Implementierung Markus Weise Markus Weise, Universität Leipzig Folie 1 Inhalt: 1. Einleitung 2. Google s Bigtable 3. Yahoo! s PNUTS 4. Zusammenfassung 5. Quellen Markus Weise, Universität

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

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

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

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

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

Big Data Management Thema 14: Cassandra

Big Data Management Thema 14: Cassandra Thema 14: Cassandra Jan Kristof Nidzwetzki Thema 14: Cassandra 1 / 25 Übersicht 1 Grundlagen Überblick Geschichte Datenmodel 2 Architektur Der logische Ring Persistenz der Daten Tunable Consistency Read

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

ANALYTICS, RISK MANAGEMENT & FINANCE ARCHITECTURE. NoSQL Datenbanksysteme Übersicht, Abgrenzung & Charakteristik

ANALYTICS, RISK MANAGEMENT & FINANCE ARCHITECTURE. NoSQL Datenbanksysteme Übersicht, Abgrenzung & Charakteristik ARFA ANALYTICS, RISK MANAGEMENT & FINANCE ARCHITECTURE NoSQL Datenbanksysteme Übersicht, Abgrenzung & Charakteristik Ralf Leipner Domain Architect Analytics, Risk Management & Finance 33. Berner Architekten

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

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

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

Soziotechnische Informationssysteme

Soziotechnische Informationssysteme Soziotechnische Informationssysteme 8. NoSQL Relationale Datenbank NoSQL Datenbank Relationale Datenbank? NoSQL Datenbank RDBM 2 Warum? Skalierbarkeit Riesige Datenmengen Performanz und Elastizität Auslastung

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

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

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

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

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

Recovery- und Buffermanager

Recovery- und Buffermanager Recovery- und Buffermanager Gesamtübersicht der Komponenten beim Zusammenspiel des lokalen Recovery Manager und des Datenbank Buffer Manager: persistenter Log Main memory Lokaler Recovery Manager (LRM)

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

Architektur von Cassandra

Architektur von Cassandra Seminar: NoSQL Wintersemester 201/2014 Cassandra Zwischenpräsentation 1 Ablauf Replica Partitioners Snitches Besteht aus mehrere Knoten Jeder Knoten kann (Lesen, Schreib. oder Löschen) Verwendet Hash Algorithm

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

Datenverwaltung in der Cloud. Überblick. Google File System. Anforderungen der Anwendungen an das Dateisystem

Datenverwaltung in der Cloud. Überblick. Google File System. Anforderungen der Anwendungen an das Dateisystem Überblick Datenverwaltung in der Cloud Datenverwaltung in der Cloud Motivation Windows Azure Storage: Zusammenfassung CAP-Theorem nach [Brewer] In einem verteilten System ist es nicht möglich gleichzeitig

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

Verteilte Datenbanken. Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München

Verteilte Datenbanken. Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München Kapitel 8 Verteilte Datenbanken Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München 2008 Thomas Bernecker, Tobias Emrich unter Verwendung der Folien des Datenbankpraktikums aus dem Wintersemester

Mehr

The R(E)volution of Data Stores

The R(E)volution of Data Stores The R(E)volution of Data Stores Willkommen Schön, dass sie in diese Session kommen, ich bin Dominik Wagenknecht NoSQL Initiative Lead Technology Architect Accenture Wien Mobil: +43 676 8720 33921 dominik.wagenknecht@accenture.com

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

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

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

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

Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung

Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Datenbanksysteme Technische Grundlagen Transaktions-Konzept, Mehrbenutzer-Synchronisation, Fehlerbehandlung Prof. Dr. Manfred Gruber FH München Transaktions-Konzept (1) Beispiel: op 1 BOT op 2 read(k 1

Mehr

9. Cloud-Datenspeicherung und MapReduce-Parallelisierung

9. Cloud-Datenspeicherung und MapReduce-Parallelisierung 9. Cloud-Datenspeicherung und MapReduce-Parallelisierung Einführung Cloud Data Management Verteilte Datenhaltung Dateisysteme (GFS) Hbase (Google Big Table) Amazon Dynamo MapReduce Idee Open Source-Realisierung

Mehr

www.informatik-aktuell.de

www.informatik-aktuell.de www.informatik-aktuell.de Flashback Reise in die Vergangenheit einfach. gut. beraten. Warum Oracle Zeitreisen anbieten kann, der Microsoft SQL Server aber leider nicht. IT-Tage Datenbanken 18.12.2015,

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

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

Überblick und Vergleich von NoSQL. Datenbanksystemen

Überblick und Vergleich von NoSQL. Datenbanksystemen Fakultät Informatik Hauptseminar Technische Informationssysteme Überblick und Vergleich von NoSQL Christian Oelsner Dresden, 20. Mai 2011 1 1. Einführung 2. Historisches & Definition 3. Kategorien von

Mehr

Einführung in CouchDB

Einführung in CouchDB Einführung in CouchDB Zurücklehnen und entspannen! http://slog.io Thomas Schrader (@slogmen) 12/2010 Übersicht Bestandsaufnahme Ansatz Geschichte Technologien Features Skalierbarkeit Kurz & Gut Fazit Relationale

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

In-Memory Technologie Hekaton

In-Memory Technologie Hekaton Einleitende Worte 11. Juli 2014 Inhaltsverzeichnis I Einleitende Worte 1 Einleitende Worte 2 3 4 5 6 Hekaton... I Einleitende Worte griech:hekaton 100 (Zahlwort) Einsatz für OLTP (Echtzeit-Transaktionsverarbeitung)

Mehr

Aktuelle SE Praktiken für das WWW

Aktuelle SE Praktiken für das WWW Aktuelle SE Praktiken für das WWW SQL vs. NoSQL W. Mark Kubacki 23.06.2010 Gliederung Zusammenfassung Entstehungsgeschichte SQL vs. NoSQL Systemarchitekturen und Wachstumsmuster SQL NoSQL Überblick und

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

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

Hadoop. Eine Open-Source-Implementierung von MapReduce und BigTable. von Philipp Kemkes

Hadoop. Eine Open-Source-Implementierung von MapReduce und BigTable. von Philipp Kemkes Hadoop Eine Open-Source-Implementierung von MapReduce und BigTable von Philipp Kemkes Hadoop Framework für skalierbare, verteilt arbeitende Software Zur Verarbeitung großer Datenmengen (Terra- bis Petabyte)

Mehr

View. Arbeiten mit den Sichten:

View. Arbeiten mit den Sichten: View "individuelle Sicht" (vgl. 3-Schichten-Modell) virtuelle Tabellen: in der DB wird nicht deren Inhalt, sondern nur die Ableitungsregel gespeichert. Arbeiten mit den Sichten: Anfragen: kein Problem.

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

Tag 4 Inhaltsverzeichnis

Tag 4 Inhaltsverzeichnis Tag 4 Inhaltsverzeichnis Normalformen Problem Formen (1-4) Weitere Formen Transaktionen Synchronisationsprobleme Überblick Autocommit Locking Savepoints Isolation levels Übungen RDB 4-1 Normalformen Problematik

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

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

Vorlesung 30.03.2009 1) Einführung

Vorlesung 30.03.2009 1) Einführung Vorlesung 30.03.2009 1) Einführung Was versteht man unter dem Begriff Datenbank? - Eine Datenbank ist eine Struktur zur Speicherung von Daten mit lesendem und schreibendem Zugriff - Allgemein meint man

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

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

Stefan Edlich Achim Friedland Jens Rampe Benjamin Brauer. NoSQL. Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken HANSER

Stefan Edlich Achim Friedland Jens Rampe Benjamin Brauer. NoSQL. Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken HANSER Stefan Edlich Achim Friedland Jens Rampe Benjamin Brauer NoSQL Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken HANSER Geleitwort 1 Vorwort 1 1 Einführung 1 1.1 Historie 1 1.2 Definition und

Mehr

DATENBANK LÖSUNGEN. mit Azure. Peter Schneider Trainer und Consultant. Lernen und Entwickeln. www.egos.co.at

DATENBANK LÖSUNGEN. mit Azure. Peter Schneider Trainer und Consultant. Lernen und Entwickeln. www.egos.co.at DATENBANK LÖSUNGEN mit Azure Peter Schneider Trainer und Consultant Agenda Cloud Services, Data Platform, Azure Portal Datenbanken in Virtuelle Maschinen Azure SQL Datenbanken und Elastic Database Pools

Mehr

Bedeutung der Metadateien. Alle Metadaten werden in Dateien gehalten. NTFS ist ein Journal-File-System

Bedeutung der Metadateien. Alle Metadaten werden in Dateien gehalten. NTFS ist ein Journal-File-System 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6 Beispiel: Windows NT (NTFS) 6.3 Metadaten 6.3 Metadaten 6.3 Metadaten (2) Alle Metadaten werden in Dateien gehalten Indexnummer 0 1 2 3 4 5 6 7 8 16 17 MFT

Mehr

! DBMS organisiert die Daten so, dass minimal viele Plattenzugriffe nötig sind.

! DBMS organisiert die Daten so, dass minimal viele Plattenzugriffe nötig sind. Unterschiede von DBMS und files Speichern von Daten! DBMS unterstützt viele Benutzer, die gleichzeitig auf dieselben Daten zugreifen concurrency control.! DBMS speichert mehr Daten als in den Hauptspeicher

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

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

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96

Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Fragenkatalog zum Kurs 1666 (Datenbanken in Rechnernetzen) Kurstext von SS 96 Dieser Fragenkatalog wurde aufgrund das Basistextes und zum Teil aus den Prüfungsprotokollen erstellt, um sich auf mögliche

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

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

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

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird.

Dieser Foliensatz darf frei verwendet werden unter der Bedingung, dass diese Titelfolie nicht entfernt wird. Thomas Studer Relationale Datenbanken: Von den theoretischen Grundlagen zu Anwendungen mit PostgreSQL Springer, 2016 ISBN 978-3-662-46570-7 Dieser Foliensatz darf frei verwendet werden unter der Bedingung,

Mehr

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL

1 Transaktionen in SQL. 2 Was ist eine Transaktion. 3 Eigenschaften einer Transaktion. PostgreSQL 1 Transaktionen in SQL Um Daten in einer SQL-Datenbank konsistent zu halten, gibt es einerseits die Möglichkeit der Normalisierung, andererseits sog. Transaktionen. 2 Was ist eine Transaktion Eine Transaktion

Mehr

Übungen zur Vorlesung. Datenbanken I

Übungen zur Vorlesung. Datenbanken I Prof. Dr. S. Böttcher Adelhard Türling Übungen zur Vorlesung Datenbanken I WS 2002/2003 Blatt 6 Aufgabe 1: In der Vorlesung haben Sie für die Einbringstrategie Update in Place die Vorgehensweisen steal,

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

Listener: Bei Oracle erfolgt die Steuerung (konventionell) via listener.ora (Listener Konfiguration), tnsnames.ora (Client Konfiguration)

Listener: Bei Oracle erfolgt die Steuerung (konventionell) via listener.ora (Listener Konfiguration), tnsnames.ora (Client Konfiguration) Protokoll 1: Listener: Bei Oracle erfolgt die Steuerung (konventionell) via listener.ora (Listener Konfiguration), tnsnames.ora (Client Konfiguration) Abschnitt 2.1 (Ausführungen zum Shutdown / Startup)

Mehr

Überblick. Aufbau einer Datenspeicher-Cloud Motivation Windows Azure Storage Zusammenfassung. c td MWCC (WS14/15) Aufbau einer Datenspeicher-Cloud 6 1

Überblick. Aufbau einer Datenspeicher-Cloud Motivation Windows Azure Storage Zusammenfassung. c td MWCC (WS14/15) Aufbau einer Datenspeicher-Cloud 6 1 Überblick Aufbau einer Datenspeicher-Cloud Motivation Windows Azure Storage Zusammenfassung c td MWCC (WS14/15) Aufbau einer Datenspeicher-Cloud 6 1 Motivation Weltumspannendes System zur Speicherung von

Mehr

Transaction Validation for XML Documents based on XPath

Transaction Validation for XML Documents based on XPath Transaction Validation for XML Documents based on XPath @ Informatik 2002, m-dbis Stefan Böttcher Adelhard Türling Universität Paderborn Überblick Transaktionen für XML - Daten & mobile Clients Motivation

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

ISBN: 978-3-8428-0679-5 Herstellung: Diplomica Verlag GmbH, Hamburg, 2011

ISBN: 978-3-8428-0679-5 Herstellung: Diplomica Verlag GmbH, Hamburg, 2011 Nils Petersohn Vergleich und Evaluation zwischen modernen und traditionellen Datenbankkonzepten unter den Gesichtspunkten Skalierung, Abfragemöglichkeit und Konsistenz Diplomica Verlag Nils Petersohn Vergleich

Mehr

Datenbanken Konsistenz und Mehrnutzerbetrieb III

Datenbanken Konsistenz und Mehrnutzerbetrieb III Datenbanken Konsistenz und Mehrnutzerbetrieb III 1. Oracle Architektur! Komponenten des Oracle Servers! Zugriff über Netzwerk 2. Zugriffsrechte! Starten und Schließen der Datenbank! Nutzer und Rollen!

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

Kapitel 8 Verteilte Datenbanken

Kapitel 8 Verteilte Datenbanken Kapitel 8 Verteilte Datenbanken Flien zum Datenbankpraktikum Wintersemester 2012/13 LMU München 2008 Thmas Bernecker, Tbias Emrich 2010 Tbias Emrich, Erich Schubert unter Verwendung der Flien des Datenbankpraktikums

Mehr

Datenbankadministration

Datenbankadministration Datenbankadministration 6. Hochverfügbarkeit AG DBIS University of Kaiserslautern, Germany Karsten Schmidt kschmidt@informatik.uni-kl.de (Vorlage TU-Dresden) Wintersemester 2008/2009 Hochverfügbarkeit

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

MySQL Replikationstechnologien

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

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

Datenbanken: Datenintegrität. www.informatikzentrale.de

Datenbanken: Datenintegrität. www.informatikzentrale.de Datenbanken: Datenintegrität Definition "Datenkonsistenz" "in der Datenbankorganisation (...) die Korrektheit der gespeicherten Daten im Sinn einer widerspruchsfreien und vollständigen Abbildung der relevanten

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

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

Gliederung Datenbanksysteme

Gliederung Datenbanksysteme Gliederung Datenbanksysteme 5. Datenbanksprachen 1. Datendefinitionsbefehle 2. Datenmanipulationsbefehle 3. Grundlagen zu SQL 6. Metadatenverwaltung 7. DB-Architekturen 1. 3-Schema-Modell 2. Verteilte

Mehr

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Transaktionskonzepte 1 Der Transaktionsbegriff Eine Transaktion ist eine Folge von Operationen, die die Datenbank von einem konsistenten Zustand in einen neuen überführen.

Mehr

NoSQL HANSER. Einstieg in die Web 2.0 Datenbanken. Stefan Edlich Achim Friedland Jens Hampe Benjamin Brauer Markus Brückner

NoSQL HANSER. Einstieg in die Web 2.0 Datenbanken. Stefan Edlich Achim Friedland Jens Hampe Benjamin Brauer Markus Brückner Stefan Edlich Achim Friedland Jens Hampe Benjamin Brauer Markus Brückner NoSQL Einstieg in die Web 2.0 Datenbanken 2., akutalisierte und erweiterte Auflage HANSER Geleitwort Vorwort Vorwort zur 2. Auflage

Mehr

Grundlagen von Datenbanken

Grundlagen von Datenbanken Grundlagen von Datenbanken Aufgabenzettel 1 Grundlagen Datenbanken: Kurzer historischer Überblick (1) Anwendung 1 Anwendung 2 Datei 1 Datei 2 Datei 3 Zugriff auf Dateien ohne spezielle Verwaltung 2 Exkurs:

Mehr

Peter Dikant mgm technology partners GmbH. Echtzeitsuche mit Hadoop und Solr

Peter Dikant mgm technology partners GmbH. Echtzeitsuche mit Hadoop und Solr Peter Dikant mgm technology partners GmbH Echtzeitsuche mit Hadoop und Solr ECHTZEITSUCHE MIT HADOOP UND SOLR PETER DIKANT MGM TECHNOLOGY PARTNERS GMBH WHOAMI peter.dikant@mgm-tp.com Java Entwickler seit

Mehr

Datenintegrität und Transaktionskonzept

Datenintegrität und Transaktionskonzept und Transaktionskonzept 1. / Datenkonsistenz 1 Mögliche Gefährdung der : Missachtung von Konsistenzbedingungen ("Semantische Integrität") Inkorrekte Verweise auf Datensätze in verschiedenen Tabellen ("Referentielle

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

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

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7.

Verteilte Systeme SS 2015. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 7. Verteilte Systeme SS 2015 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 7. Juli 2015 Betriebssysteme / verteilte Systeme Verteilte Systeme (1/13) i

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

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Wesentliche Inhalte Begriff DBS Datenbankmodelle Datenbankentwurf konzeptionell, logisch und relational

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

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

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

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 II Speicherung und Verarbeitung großer Objekte (Large Objects [LOBs])

Datenbanken II Speicherung und Verarbeitung großer Objekte (Large Objects [LOBs]) Datenbanken II Speicherung und Verarbeitung großer Objekte (Large Objects [LOBs]) Hochschule für Technik, Wirtschaft und Kultur Leipzig 06.06.2008 Datenbanken II,Speicherung und Verarbeitung großer Objekte

Mehr

Replikation und Synchronisation. in mobilen Datenbanksystemen

Replikation und Synchronisation. in mobilen Datenbanksystemen in mobilen Datenbanksystemen 6. Juni 2002 Von Thomas Hoffmann und Sebastian Seidler E-Mail: {hothomas,bastl14w}@minet.uni-jena.de 1 Inhalt Einleitung Was ist Replikation? Was ist Synchronisation? Replikationsverfahren

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

Oracle BI&W Referenz Architektur Big Data und High Performance Analytics

Oracle BI&W Referenz Architektur Big Data und High Performance Analytics DATA WAREHOUSE Oracle BI&W Referenz Architektur Big Data und High Performance Analytics Alfred Schlaucher, Oracle Scale up Unternehmensdaten zusammenfassen Noch mehr Informationen

Mehr