Big Data - Bildungsportal Sachsen
Werbung
Prof. Dr. G. Gräfe Lehrveranstaltung Erweiterte Datenbanktechnologien / Medienarchive (Datenbanksysteme III) Gliederung Prof. Dr. G. Gräfe 5. „Big Data“-Datenbanktechnologien 5.1 5.2 5.3 5.4 5.5 Einführung Data Warehouse und OLAP Spaltenbasierte DBS-Technologien In-Memory-DBS und parallele DB NoSQL-Datenbanken EDBT/MA - 5. “Big Data”-Technologien | 1 Was versteht man unter „Big Data“? Wikipedia: „Als Big Data werden besonders große Datenmengen bezeichnet, die mit Hilfe von Standard-Datenbanken und Daten-Management-Tools nicht oder nur unzureichend verarbeitet werden können. Problematisch sind hierbei vor allem • die Erfassung, • die Speicherung, • die Suche, • Verteilung, • Analyse und • Visualisierung von großen Datenmengen. Das Volumen dieser Datenmengen geht in die Terabytes, Petabytes, Exabytes und Zettabytes.“ Anwendungsszenarien von Big Data Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 2 Das „Big Data“-Problem VLDB - Very Large Database 1980 100.000.000 1996 1.000.000.000 2012 2008 10.000.000.000 100.000.000.000 Herausforderungen im Management von Big Data: − Große Datenmengen besser und schneller verfügbar machen − Mit Hilfe von Analysetechniken Reaktionen und Leistungen zu verbessern. − Sinnvolle Segmentierung durchzuführen und ständig anzupassen. − Durch automatisierte Algorithmen die Entscheidungsfindung zu unterstützen und zu automatisieren Studie von Gartner: Big Data „Extreme Information Processing“ nicht nur pure Speicherung von Daten, sondern insbesondere schnelle und flexible Verarbeitung von Massendaten Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 3 Beispiele für große Datenbanken WalMart Data Warehouse Produktinfos (Verkäufe etc.) von 60.00 Märkten ca. 480 TB (2004) > 4.096 TB = 4 PB (2008) SAP R/3-Installation der Deutschen Telekom AG (2005) Financial Accounting: Rechnungen, Zahlungsaufforderungen, Lastschriften, Mahnungen etc. 15 SAP R/3-Systeme; jedes verarbeitet 200.000 Rechnungen, 12.000 Mahnungen, 10.000 Änderungen von Kundendaten pro Tag bis zu jeweils 1000 Nutzer gleichzeitig, > 13.000 Datenbanktabellen NASA Earth Observing System (EOS) 1,9 TeraByte Datenvolumen pro Tag (10 PetaByte Gesamtvolumen) Erfassungszeitraum: 15 Jahre nur 10% des Datenmaterials wird analysiert Echtzeit-Übernahme des Messdatenstroms (51 MegaBit/sec bzw. 553 GigaByte pro Tag) jährlich ca. 100.000 Benutzer der EOS-Datenbank mittlere Objektgröße als Resultat einer Anfrage: 10 MegaByte Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 4 Datenbank-Technologien für BigData − Data Warehousing – Speicher- und Analysesysteme zur Verwaltung strukturierter (aktueller und historischer) Datenbestände Beispiele: SAP BW, Oracle DW, Sybase IQ − Massively Parallel Processing (MPP) or parallel DBMS – Systeme zur Verwaltung von massiven Datenbankzugriffen, die konkurrierend und schreibend auf große Datenbestände zugreifen. Beispiele: EBay DW, Yahoo! Everest Architecture, Greenplum, AsterData − Column-oriented database – Spaltenorientierte Speicherung von Datenbankinhalten mit der Zielrichtung eines schnellen lesenden Zugriffs Beispiele: Vertica, Sybase IQ, MonetDB − Streaming processing (ESP or CEP) – Systeme zur Verwaltung konstanter (oder ereignisabhängiger) Datenströme, die über einen bestimmten Zeitraum gespeichert und ausgewertet werden müssen. Beispiele: Truviso, DataGRID − Key-value storage (with MapReduce programming model) – Systeme zur Verwaltung von Datenmassen, bei denen der Fokus auf einen lesenden Zugriff mit höchster Performance liegt Beispiele: viele der NoSQL DBS (Google, Facebook) Siehe Park Kieun: Database Technology for Large Scale Data Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 5 5.2. Data Warehouse und OLAP - Ziele und Definitionen allgemeine Zielsetzungen: Verwaltung großer Datenbestände (mit Historisierung, aber keine Archivierung !) Aufbau einer zentralen und konsistenten Datenbasis losgelöst betrieben von den operativen Datenbanken zur Unterstützung von analytischen Aufgaben (Data Mining, Business Intelligence) Ein Data Warehouse ist eine aus einer oder mehreren operativen Datenbanken extrahierte Datenbank, die alle für den Analyseprozess relevanten Daten (eines Unternehmens) zusammenfasst, aufbereitet und aggregiert. Ein Data Warehouse umfasst die Meta-, die Dimensions- und die Aggregationsdaten sowie die Fakten, um Informationen verfügbar und informationsgestützte Entscheidungen möglich zu machen. Darüber hinaus beinhaltet es die notwendigen Verwaltungsprozesse wie Einfügen, Warehousing und Abfrage. Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 6 Beispiel für eine Data Warehouse - Architektur Clientanwendung Mitarbeiter Analyse und Präsentation Datenbankverwaltung Methodenbankverwaltung Informationskatalog DataWarehouse Datenbank Datensammlung und -transformation Interne Daten aus den operativen IS Prof. Dr. G. Gräfe Externe Daten aus diversen Quellen Modellbankverwaltung Methodendatenbank Modellbank Metadaten • Welche Daten gibt es? • Wo befinden sie sich? • In welchen Formaten liegen sie vor? • Wo kommen die Daten her? • Wann war das letzte Update? • Ist der gewünschte Bericht schon vorhanden? • Wie wird die Auswertung durchgeführt? Entscheidungsrelevante Daten • In unterschiedlichen Dimensionen (z.B. nach Organisations-, Mitarbeiter-, Produkt-, Regional-, Kunden- und Zeitstrukturen ..) • In unterschiedlichen Verdichtungsstufen (hoher oder geringer Detaillierungsgrad, in Abh. von Gegenstand und Alter der Daten) • Für unterschiedliche Zeiträume (Tage, Wochen, Monate, Quartale, Jahre) EDBT/MA - 5. “Big Data”-Technologien | 7 Veranschaulichung der Multidimensionalität Dimensionalität Anzahl der Dimensionen Kanten = Dimensionen Zellen = Fakten Bsp. für einen Würfel Zeit (Dimension) Visualisierung • 2 Dimensionen: Tabelle • 3 Dimensionen: Würfel • >3 Dimensionen: Multidim. Domänenstruktur Jahr Quartal Monat Produkt (Dimension) Umsatz (Fakt = Kennzahl) Kategorie Artikel Region (Dimension) Prof. Dr. G. Gräfe Filiale Stadt Bundesland EDBT/MA - 5. “Big Data”-Technologien | 8 Beispiel eines OLAP-Datenwürfels PRODUKT REGION Einheit Sicht des Verkaufsmanagers R E G I O n ZEIT Kundengruppe Artikelgruppe Prof. Dr. G. Gräfe Sicht des Regionalmanagers Sicht des Produktmanagers Region Artikelgruppe Kundengr. Süd Rennräder Discounter Bruttoerlöse Menge DB-Abweichung 256.000 € 4.260 StK. Einzelner Datensatz 11.500 € EDBT/MA - 5. “Big Data”-Technologien | 9 Vergleich OLTP - OLAP Klassische operative DBS Online Transactional Processing (OLTP) HW-Nutzung OLTP-Systeme operative DV-Systeme Zeit Data Warehouse Systeme Online Analytical Processing (OLAP) HW-Nutzung OLAP-Systeme Data Warehouse-Systeme − Erfassung und Verwaltung von Daten im Mittelpunkt − Transaktionale Verarbeitung − kurze Lese-/ Schreibzugriffe auf − wenige Datensätze Zeit − Analyse im Mittelpunkt − lange Lesetransaktionen auf vielen Datensätzen − Integration, Konsolidierung und Aggregation der Daten Vergleich der Systemauslastung Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 10 Abgrenzung DW zu operativen Systemen Kriterium OLTP-Sytem DWH/OLAP-System Anfragearten Lesen, Schreiben, Ändern, Löschen Lesen, periodisches Hinzufügen Transaktionsdauer und typ kurze Lese- und Schreibtransaktionen lange Lesetransaktionen Anfragestruktur einfach strukturiert komplex Datenvolumen je Anfrage wenige Datensätze viele Datensätze Datenmodell anfragebezogen analysebezogen Datenquelle meist eine mehrere Eigenschaften der Daten nicht abgeleitet, zeitpunkt-bezogen, autonom, dynamisch abgeleitet, konsolidiert, zeitraumbezogen, integriert, stabil Datenvolumen MByte … GByte GByte … TByte Zugriffsart Einzeltupelzugriff Tabellenzugriff Anwendertyp Ein- und Ausgabe durch Angestellte oder Anwendungssoftware Manager, Controller, Analyst Anwenderzahl sehr viele wenige (bis einige hundert) Antwortzeit ms … sec sec … min Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 11 Strategien zur Speicherung multidimensionaler Daten relational Datenspeicherung im relationalen DBMS Modellierung der Cubestruktur mittels Relationen (Tabellen) Verwendung des SQL-Standards zur Datenabfrage und -manipulation Beispiele: Star Schema Snowflake Schema ROLAP (Relational Online Analytical Processing) Prof. Dr. G. Gräfe nicht relational Datenspeicherung nicht in relationaler Art Speicherung des Cube mit klassischen Methoden der Informatik Fehlende Standards für Datenabfrage und -manipulation Beispiele: arrays hash-tables bitmap-indices MOLAP (Multidimensional Online Analytical Processing) EDBT/MA - 5. “Big Data”-Technologien | 12 Star - Schema Ein Star-Schema ist ein Datenbankschema, welches so strukturiert ist, dass eine typische Abfrage zur Entscheidungsfindung unterstützt wird. Im Zentrum des Schemas befindet sich die Fakttabelle, um welche die Dimensionstabellen angeordnet sind. Die Verbindung zwischen den Dimensions-und der Fakttabellen wird über FremdschlüsselPrimärschlüssel-Beziehungen realisiert. Verwendung des relationalen Datenmodells zur Abbildung multidimensionaler Strukturen Aufbau eines Starschemas: 1. Dim-Tabelle Dim1 Schlüssel Attribut 1 Attribut 2 ... 3. Dim-Tabelle Dim3 Schlüssel Attribut 1 Attribut 2 ... Prof. Dr. G. Gräfe Fakt-Tabelle Dim1 Schlüssel Dim2 Schlüssel Dim3 Schlüssel Dim4 Schlüssel Fakt 1 Fakt 2 ... 2. Dim-Tabelle Dim2 Schlüssel Attribut 1 Attribut 2 ... 4. Dim-Tabelle Dim4 Schlüssel Attribut 1 Attribut 2 ... EDBT/MA - 5. “Big Data”-Technologien | 13 Ausschnitt aus dem Schema einer operativen Datenbank Bsp.: Datenverwaltung für die Rechnungslegung auf Filialbasis Produkt ... ProdNr Bezeichnung Preis Farbe ... ProdGruppeNr Rechnung 1 1 RNr FilNr KuNr Summe … Datum Position n RNr PosNr n ProdNr Menge Prof. Dr. G. Gräfe Filiale n 1 FilNr Ort Leiter … RegNr n 1 Kunde KuNr Name Ort … RegNr n Region 1 RegNr Name LandNr ... EDBT/MA - 5. “Big Data”-Technologien | 14 Beispiel für ein Star Schema DTZeit DTProdukt ZeitID ProdNr Monat Jahr level Bezeichnung Preis Farbe Modell level DTFiliale FilialeNr Ort Leiter RegionName LandNr level DTVerkäufer VerkäuferNr Name Prof. Dr. G. Gräfe FTMain ZeitID FilialeNr ProdNr KategorieNr VerkäuferNr KuNr … Umsatz Menge DTxxxx Dimensionstabelle DTKategorie KategorieNr KategorieBez DTKunde FTxxx Faktentabelle KuNr Name Ort Region EDBT/MA - 5. “Big Data”-Technologien | 15 Beispiel für ein Snowflake Schema Jahr Quartal Dimension Zeit Monat Dimension Filialstruktur Filiale Region Faktentabelle KZeit FilialeNr ProdNr KategorieNr VerkäuferNr KuNr … Modell Dimension Prod.-kategorie Produkt Kategorie Kundengruppe Kunde Umsatz Menge Land Dimension Verkäufer Verkäufer Prof. Dr. G. Gräfe Dimension Produkt Region Dimension Geographie Dimension Kundengr. Land EDBT/MA - 5. “Big Data”-Technologien | 16 Multidimensionale Analyse [Quelle: Lehner – DBST 2003] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 17 ETL-Prozeß 3. Laden der Daten in die Zieldatenbank 2. Transformation der Daten in das Schema und Format der Zieldatenbank 1. Extraktion der relevanten Daten aus verschiedenen Quellen [Quelle: SAP] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 18 Aufgaben der Transformation BESTANDTEILE DES TRANSFORMATIONSPROZESSES Filterung: Extraktion und Bereinigung syntaktischer und inhaltlicher Defekte der Daten Harmonisierung: Betriebswirtschaftliche Abstimmung der gefilterten Daten Aggregation: Verdichtung der gefilterten und harmonisierten Daten Anreicherung: Berechnung und Speicherung betriebswirtschaftlicher Kennzahlen Syntaktische Transformation: Verbesserung, Umsetzung oder Korrektur der Daten basierend auf formalen Aspekten Semantische Transformation: Prüfung und Modifizierung inhaltlicher Aspekte z.B. − Eliminierung von Duplikaten (Sicherung der Objektidentifizierung), − Schlüsselanpassung (z. B. unterschiedliche Ländercodierungen hin zu DIN ISO Ländercodes), − Anpassung von Datenwerten (z. B. unterschiedliche Codierung des Geschlechts wie 1 (weiblich), 2 (männlich) hin zu f (female) und m (male)), − Umrechnung von Maßeinheiten (z. B. unterschiedliche Volumina wie Gallone und Hektoliter hin zu Liter) Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 19 Data Mining - Clustersuche Problem • Auffinden von Häufungen im multidimensionalen Datenraum Ziel des Clustering • Identifikation einer endlichen Menge von Kategorien/Klassen (Clustern) • Objekte im gleichen Cluster sind möglichst ähnlich zueinander • Objekte aus verschiedenen Clustern sind möglichst unähnlich zueinander [Quelle: Lehner – DBST 2003] notwendig: Distanzfunktion / Metrik • Für Datensätze x = (x1, ..., xd) mit numerischen Attributswerten xi Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 20 Klassen von Clusterverfahren ❏ Partionierende Verfahren • Konstruktion zentraler Punkte (Centroide) / repräsentativer Punkte (Medoide) ❏ Hierarchische Verfahren • Erstellung von Dendogrammen ❏ Dichtebasiertes Clustering • Erreichbarkeit / Verbundenheit innerhalb einer ε-Umgebung Prof. Dr. G. Gräfe [Quelle: Lehner – DBST 2003] EDBT/MA - 5. “Big Data”-Technologien | 21 Dichtebasiertes Clustering ❏ Vorgehensweise bei dichtebasierten Verfahren • Trennung von Dichteschätzung und Clusterermittlung ❏ Dichteschätzung • ... basierend auf Histogrammen • ... basierend auf Repräsentanten [Quelle: Lehner – DBST 2003] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 22 5.3. Technologien spaltenbasierter DBS Performanceprobleme bei Abfragen Berechne den durchschnittlichen Absatz von Radeberger in Gastronomie-Einrichtungen in Sachsen Beispiel: 360 Millionen Zeilen 200 Bytes pro Zeile 16K Seitengröße Mon Einr Typ Land Prod Abs 1211 32 G SA Werne 12 0112 36 G MV Becks 9 0112 38 G SA Radeb 28 0112 41 K NS Jever 11 0112 43 G SA Radeb 9 0112 46 G BY Paula 3 0112 47 M NW Dortm 70 0112 49 K SA Lands 12 4.500.000 I/O‟s pro Table Scan werden benötigt, mit Platte z.B. 40MB/sec 30 Minuten !!! Sehr teuer und unflexibel bei Ad-hoc-Anfragen [Quelle: Bittner – 160. Datenbank-Stammtisch] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 23 Zugriffsoperationen von DBMS Charakteristika von Operationen in verschiedenen Anwendungsszenarien: • OLTP: Lese- und Schreiboperationen auf einzelnen Datensätzen − beim kompletten Lesen einer Tabelle werden viele nicht benötigte Datensätze gelesen − Optimierung des gezielten Zugriffs auf Datensätze mit Indexen • OLAP: Leseoperationen auf vielen Datensätzen (wobei i.a. nur einzelne Attribute relevant sind) − beim kompletten Lesen einer Tabelle werden viele nicht benötigte Attributwerte gelesen Optimierung durch viele Indexe (ggf. Index auf jedem Attribut) Alternative: vertikale Partitionierung Neuer Ansatz: Column-Oriented Database Systems (Spaltenorientierte DBMS) Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 24 Zeilen- und spaltenorientierte Speicherung Zeilenorientierte Speicherung: Spaltenorientierte Speicherung Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 25 Spaltenorientierte Datenbank [Quelle: Bittner – 160. Datenbank-Stammtisch] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 26 Vertikale Partitionierung und Bitmap Index vertikale Partitionierung Bitmapindex am Beispiel der Spalte Land Bitmap Index für Land Mon Einr Typ Land Prod Abs 9805 32 G SA Werne 6 9805 36 G MV Becks 9 9805 38 G SA Radeb 5 9805 41 K NS Jever 11 9805 43 G SA Radeb 9805 46 G BY 9805 47 M 9805 49 K … row-id BY MV NS NW SA 1 0 0 0 0 1 2 0 1 0 0 0 3 0 0 0 0 1 4 0 0 1 0 0 9 5 0 0 0 0 1 Paula 3 6 1 0 0 0 0 NW Dortm 7 SA Lands 12 7 8 0 0 0 0 0 0 1 0 0 1 … [Quelle: Bittner – 160. Datenbank-Stammtisch] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 27 Vergleich zeilenorientiertes und spaltenorientierte DB Zeilenorientierte DB Spaltenorientierte DB + Einfaches Insert / Update − Lesen nicht benötigter Daten + Nur Lesen relevanter Daten + Bessere Kompressionsmöglichkeiten − Insert / Update aufwändig − Zusammenfügen versch. Daten aufwändig Geeignet für große Datenbestände, in denen überwiegend zeitintensive Leseoperationen gefordert sind Anwendungen: − Sybase Adaptive Server IQ seit 1996 IQ Multiplex − SAP HANA − ParAccel, Vertica seit 2008 − Spaltenorientierung im Hauptspeicher In-Memory-Basistechnik TREX (SAP) Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 28 Spaltenorientierte DBMS: Alternativen Simulation einer spaltenorientierten Speicherung in einem zeilenbasierten Datenbankmanagementsystem: Quelle: Harizopoulos/Abadi/Boncz: VLDB2009 Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 29 5.4. InMemory-DBS und parallele DB Speicherhierarchie: [Quelle: Härder – 150. Datenbank-Stammtisch] Zugriffs- und Lesezeiten von Festplatte und Hauptspeicher: Aktion Main Memory Access Read 1 MB Sequentially from Memory Disk Seek Read 1 MB Sequentially from Disk Prof. Dr. G. Gräfe Zeit 100 ns 250,000 ns 5,000,000 ns 30,000,000 ns EDBT/MA - 5. “Big Data”-Technologien | 30 Beispiele für Datenzugriff [Quelle: Härder – 150. Datenbank-Stammtisch] Google • 20 PB strukturierte Daten, Text, Bilder, Video täglich verarbeiten • 15 h Video-Upload jede Minute • 20 PB von Disk lesen: bei 50 MB/s = 12 Jahre Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 31 Parallele Datenbanken 1. Problem Platten-Laufwerke • kleine I/O Größe der klassischen DBMS >90% der Zeit braucht die Platte zum Suchen CPU • Größe der Phys. Datenseiten (2 KB … 16 KB) viele I/O-Operationen • Suchzeiten in HD verbessern sich durch technische Entwicklung nur langsam, schneller mehr Laufwerke pro CPU I/OController CPUs 2. Problem Prozessor MPP Storage Area Network Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 32 Massive Parallele Verarbeitung Massively Parallel Processing (Massive Parallele Verarbeitung – MPP): − koordinierte Verarbeitung eines Programms durch mehrere Prozessoren, wobei jeder Prozessor über ein eigenes Betriebssystem und eigenen Speicher verfügt − MPP-Prozessoren kommunizieren mithilfe einer Messaging-Schnittstelle − In großen DB-Implementierungen arbeiten über 200 Prozessoren an derselben Anwendung. − Eine Maschenanordnung der Datenpfade ermöglicht die Übertragung von Nachrichten zwischen den Prozessoren. − MPP ist komplex und erfordert grundlegende Überlegungen in Bezug auf die Partitionierung einer gemeinsamen Datenbank unter den Prozessoren sowie auf die Verteilung der Arbeitslast zwischen den Prozessoren. Data Center Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 33 Microsoft Massive Data Center Northlake, Illinois (US) [Quelle: Lehner – 155.DBST] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 34 Speicherhierarchie bei Main-Memory-DBMS CPU Size Latency 1st Level Cache 64KB ~4 cycles 2 ns 2nd Level Cache 256KB ~10 cycles 5 ns 8MB 35-40+ cycles 20 ns several GBs up to TBs ~ 200 cycles ~ 100ns several TB several million cycles several ms Core Core Core Core 1st Level Cache 1st Level Cache 1st Level Cache 2nd Level Cache 2nd Level Cache 2nd Level Cache Shared 3rd Level Cache Laden des TopLevel-Index Initial-Laden der DB Main Memory Disk Vereinfachte Speicherhierarchie (Intel Nehalem) Prof. Dr. G. Gräfe Snapshot Backup Quelle: Färber – SAP AG EDBT/MA - 5. “Big Data”-Technologien | 35 Merkmale von InMemory-DBS InMemory- bzw. MainMemory-DBS Caching der Datenbank im Hauptspeicher Möglichkeiten: - Preis/MB RAM fällt immer weiter - 64-Bit-Architekturen ermöglichen Nutzung von 4 GB Hauptspeicher „Disk is Tape“ - Festplattenzugriff 105 mal langsamer als Hauptspeicherzugriff - Kein Festplattenzugriff während der normalen Operationen - Nutzung der Festplatte für Backup bzw. Archiv Problem: Flaschenhals Hauptspeicher Cache Main Memory Bottleneck CPU Core CPU Cache CPU Cache Performance bottleneck today: CPU waiting for data to be loaded from memory into cache MainMemory Performance bottleneck in the past: Disk I/O Disk Quelle: Färber – SAP AG Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 36 InMemory-Computing und ACID In-Memory-Datenbanken speichern Daten in flüchtigem Arbeitsspeicher, dieser kann erfolgreich abgeschlossene Transaktionen aber beispielsweise bei Systemabstürzen nicht dauerhaft halten. ACID-Prinzip wird verletzt Strategien: − Snapshot Dateien speichern den Zustand der Datenbank zu bestimmten Zeitpunkten (zeitgesteuert oder beim kontrollierten Abschalten der Datenbank) neueste Änderungen gehen ggf. verloren − Transaction Logs speichern Änderungen auf Dateien und ermöglichen somit die automatische Wiederherstellung der Datenbank. − Non-Volatile Random-Access Memory (Kombination eines herkömmlichen flüchtigen RAM-Speichers mit einem Energiespeicher) − 2PC mit Replikation und Failover auf eine identische herkömmliche Datenbank Problem Performance Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 37 Information LifeCircle Management bei InMemory-DBS Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 38 Oracle Exadata Vorkonfigurierte RAC Database Machine • DBS: 64 Nehalem Cores, 576 GB RAM • Netzwerk: InfiniBand 40 Gbit/s • Exadata Storage Server: • 112 Nehalem Cores, 336 GB RAM • 100 TB SAS HDD • 5 TB Flash Cache (SSD) Flash Cache • automatischer Write-through Cache • von Hand: create table emp( ... ) storage (flash_cache keep) [Quelle: Oracle] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 39 Energieverbrauch von Main-Memory-DBMS IKT heute: >10% der erzeugten Energie (35 Mio. Server, ? PCs, etc.) >25% CO2-Verbrauch aller Autos [Quelle: Härder – 150. Datenbank-Stammtisch] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 40 Service-Modelle des Cloud Computing IaaS SaaS PaaS XaaS (Ressourcen werden als virtuelle Instanzen einer kompletten Hardware und BetriebssystemPlattform bereitgestellt ) (Software wird verfügbar in Form einer Anwendung, die auf der Hardware des Providers läuft) (Der Anbieter stellt die Hosting-Umgebung und Programmier-Tools bereit, um Lösungen für die spezifische Umgebung zu entwickeln) (X=D,.. für D=Data oder Data base; X=B für B=Business) Quelle: IOUG ResearchWire member study on Cloud Computing, conducted in Aug-Sept 2011 Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 41 Cloud database vendors by deployment and data model Virtual Machine Deployment Database as a Service SQL Data Model Oracle Database IBM DB2 Ingres (database) PostgreSQL MySQL Amazon Relational Database Service (MySQL) Microsoft SQL Azure (MS SQL) Heroku PostgreSQL as a Service (shared and dedicated database options) Xeround Cloud Database - MySQL frontend EnterpriseDB Postgres Plus Cloud Database NoSQL Data Model CouchDB on Amazon EC2 Hadoop on Amazon EC2 Apache Cassandra on Amazon EC2 Neo4J on Amazon EC2 or Microsoft Azure MongoDB on Amazon EC2 or Microsoft Azure Amazon SimpleDB Database.com by SalesForce Google App Engine Datastore CouchDB Hosted Database[ MongoDB Database as a Service (several options) [Quelle: http://en.wikipedia.org/wiki/Cloud_database] Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 42 5.5. NoSQL - (Mögliche) Kategorisierung NoSQL-Systeme: Schlanke, effiziente DBS, die auf eine performante und kostengünstige Verwaltung einfach strukturierter, sehr sehr großer Datenmengen (Big Data) spezialisiert sind Merkmale: - im Wesentlichen Select- und Insert-Operationen - geringe Anforderungen an Konsistenz der DB (Noch) keine einheitliche Klassifikation eine mögliche und relativ verbreitete Kategorisierung in Anlehnung an http://nosql-database.org/ Core NoSQL Systems: − Key Value / Tuple Store − Wide Column Store / Column Families − Document Store − Graph Databases Soft NoSQL Systems: − Object Databases − Grid & Cloud Database Solutions − XML Databases − Multivalue Databases − … Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 43 NoSQL und Transaktionskonzept Transaktionsbegriff in NoSQL-Systemen Viele NoSQL-Systeme garantierten nur Atomarität einer einzelnen Operation – manche Systeme bieten operationsübergreifende Konsistenzmodelle Konsistenzmodelle Häufig BASE mit Eventual Consistency − Read-/Write-Operationen teilweise unter Angabe des gewünschten Konsistenzlevels möglich − Ermittlung der korrekten Version: häufig Verwendung von Vector Clocks (siehe Edlich:2010, ursprünglich eingeführt von Lamport:1978) Aber auch „klassisches“ ACID – i.a. mit MVCC zur Reduzierung von Sperrkonflikten − Teilweise wird MVCC auch abgewandelt, d.h. mehrere konkurrierende Schreibzugriffen zugelassen – Konfliktauflösung ggf. automatisch oder manuell (z.B. CouchDB) ACID oder BASE teilweise konfigurierbar zur Auswahl Prof. Dr. G. Gräfe EDBT/MA - 5. “Big Data”-Technologien | 44
