Datenbanksysteme - Wintersemester 2016/17
Werbung
Datenbanksysteme Wintersemester 2016/17 Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern [email protected] Data Layouts, OLTP/OLAP, In-Memory DBS Komprimierung Komprimierung Schauen wir uns das Beispiel von zuvor nochmal an: o0 C4 o1 C3 o2 C3 o3 C3 o4 C4 o5 C4 o6 C4 Die Anordnung in Spalten bringt ähnliche (vom Datentyp her, aber auch oft lexikographisch/numerisch nah) Attributwerte zusammen. Idee: Ersetze Daten durch kompaktere Repräsentation. Potentielle Nachteile: Rechenaufwand bei Dekomprimierung (CPU Kosten) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 2 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Komprimierung Komprimierung: Run-Length-Encoding (RLE) Fasse Bereiche mit identischen Attributwerten zusammen. Ideal geeignet für Column-Stores, im Vergleich zu Row-Stores, da Daten eines einzelnen Attributs zusammen liegen. Durch Sortierung kann noch besser komprimiert werden. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Rang C4 C3 (C4, 1) C3 ⇒ (C3,3) C3 (C4,3) C4 C4 C4 Datenbanksysteme, WS 16/17 3 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Komprimierung Delta Coding Speichere anstelle des tatsächlichen Attributwerts die Differenz zum vorherigen Attributwert. Wie beim LRE kann Sortierung Effektivität der Komprimierung erhöhen. Ebenfalls perfekt geeignet für Column-Stores. VorlNr VorlNr 4052 4052 4630 578 5001 371 5022 21 5041 ⇒ 19 5043 2 5049 6 5052 3 5216 164 5259 43 Die nun kleineren Zahlen benötigen nun offensichtlich weniger Bits und können dementsprechend kompakter gespeichert werden (Bit Packing). Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 4 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Komprimierung Dictionary Encoding Benutze Dictionary, das Daten (Attributwerten) eine kompaktere Stellvertreter-Repräsentation zuordnet. Fachbereich Informatik Wirtschaftswissenschaften Physik Informatik Elektrotechnik und ... ⇒ Mathematik Biologie Informatik Wirtschaftswissenschaften Elektrotechnik und ... Prof. Dr.-Ing. S. Michel Fachbereich 0000 0001 0010 0000 0011 0100 0101 0000 0001 0011 TU Kaiserslautern Dictionary: Fachbereich Informatik Wirtschaftswissenschaften Physik Elektrotechnik und ... Mathematik Biologie Datenbanksysteme, WS 16/17 Encoding 0000 0001 0010 0011 0100 0101 5 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Weitere Data Layouts Wiederholung: Speicher Hierarchie und Zugriffskosten L1 cache reference 0,5 ns L2 cache reference 7 ns Main memory reference 100 ns Disk seek 10 000 000 ns D.h. unabhängig davon wie “langsam” ein wahlfreier Zugriff auf die Festplatte ist, auch zwischen L1 Cache und L2 Cache bzw. zwischen L2 und RAM liegen je eine bzw. insgesamt zwei Größenordnungen! Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 6 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Weitere Data Layouts Das PAX (Partition Attributes Across) Layout Beobachtung: Anfragen brauchen oft nur wenige Attribute eines Tupels. Column-Store hat potentiell hohe Kosten bei Tupel-Rekonstruktion. Idee: Gruppiere die Attribute innerhalb einer Seite, damit der (CPU) Cache besser ausgenutzt werden kann. NSM PAGE PAGE HEADER Jane RH1 0962 30 RH2 7658 John 45 RH3 3589 Jim 20 RH4 5523 Susan 52 PAX PAGE PAGE HEADER CACHE 0962 7658 3859 5523 Jane John Jim 30 52 45 20 block 1 Susan .... 30 52 45 20 : Partition Attributes Across (PAX), and its cache behavior. PAX partitions records into minipages within each page. As we scan R to read attribute age,values are much more efficiently mapped onto cache blocks, and the cache space is now fully utilized. source: A. Ailamaki, D. DeWitt, M. Hill. Data Page Layouts for Relational Databases on Deep Memory Hierarchies. VLDB Journal, 2002. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 7 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Weitere Data Layouts Fractured Mirrors Um sowohl OLTP als auch OLAP Anfragen effizient auswerten zu können wird im Fractured-Mirrors Ansatz vorgeschlagen sowohl NSM als auch DSM anzubieten. D.h. Daten werden in zwei Layouts gespeichert: Zeilenorientiert und Spaltenorientiert. Man hat also eine Kopie der kompletten Datenbank, bloß in unterschiedlichen Layouts. Paper: R. Ramamurthy, D. DeWitt, Q. Su. A Case for Fractured Mirrors. VLDB, 2002. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 8 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Genealogy of Relational Database Management Systems v6.0, 1986 OpenIngres 2.0, 1997 vR3, 2004 v9.0, 2006 v10, 2010 Monet Database System (Data Distilleries) DABA (Robotron, TU Dresden) Ingres v5.x, 1970s Postgres PostgreSQL v1, 1995 v6, 1997 MonetDB IBM v7, 2000 Illustra Informix v1.0, 1980s v4.0, 1990 v5.0, 1992 v6.0, 1994 C-Store Informix Sybase SQL Server v4.0, 1990 PostgreSQL v12.10, 2013 Red Brick Microsoft SQL Server H-Store H-Store Informix Vertica Analytic DB Volt DB v11.9, 1998 Expressway 103 Sybase IQ v11, 1995 Watcom SQL Powersoft CODD RIVER Microsoft SQL Server v12.5, 2001 v12.5.1, 2003 v15.0, 2005 v3, 1995 Vertica v16.0, 2012 SAP Sybase ASE v15, 2009 Sybase SQL Anywhere v1, 1992 v2, 1993 Microsoft Access v12.0, 1999 v12, 1999 VoltDB HP code brand v1.0, 1987 v1.0, 1981 Greenplum v11.70, 2010 DATAllegro v3.0, 1988 BAY AREA PARK v11.5, 1996 Sybase ASE v10, 1993 v11, 2007 IBM Red Brick Warehouse v7.0, 1995 Netezza v9, 2010 IBM Informix v10, 2005 v9.0, 2000 alpha, 1979 Pivotal EMC v8, 2005 Red Brick Empress Embedded VectorWise Netezza Greenplum Berkeley Ingres Ingres VectorWise (Actian) MonetDB (CWI) v4, 1997 v5, 1999 v10, 2001 v11, 2003 Sybase IQ v12, 2007 SQL Anywhere v14, 2010 Access v1, 1989 FoxPro Oracle v4.21, 1993 VisualFoxPro (Microsoft) v6, 1994 v6.5, 1995 v7, 1998 mSQL v3, 1983 v4, 1984 v5, 1985 v3.1, 1997 MySQL v2, 1979 v9, 2005 v9i, 2001 v10g, 2003 v3.23, 2001 v4, 2003 v10, 2008 v10gR2, 2005 v4.1, 2004 1980s ShareBase (BrittonLee) MariaDB v10, 2013 v5.5, 2010 Paradox Oracle v13.10, 2010 Aster Database v5.1, 2004 v4, 1995 RELATIONAL CREEK v1, 1988 Cloudscape DB2/400 v6.0, 2005 v6.2, 2006 v12, 2007 v13.0, 2009 v14.0, 2012 Teradata Teradata Empress Embedded RDB v10.2, 2008 v8.1, 1998 Informix Apache Derby 2010s v6, 2008 IBM DB2 z/OS v7, 2001 v6, 1999 v4, 1992 DB2 for VSE & VM DB2 UDB v3, 1993 v2, 1988 Derby DB2 UDB for iSeries v5, 1997 v2, 1992 Solid DB v1, 1983 TimesTen TimesTen JBMS v7, 2010 SQL/DS System/38 Infobright Oracle MariaDB Corel v6.1, 1997 v3, 1993 SQL/400 DB2 Oracle v12c, 2013 Infobright MySQL Sun NCR DB2 MVS System-R (IBM) v11gR2, 2009 v5.1, 2008 Oracle 1990s RDB (DEC) BAY AREA PARK v11, 2012 v11g, 2007 v5, 2005 InnoDB (Innobase) Borland Teradata v1, 1983 persons v8i, 1999 v3.21, 1998 v7, 1992 Paradox (Ansa) Multics Relational Data Store (Honeywell) v8, 2000 v8, 1997 v5.1, 1986 DB2 for iSeries Derby v9, 2007 v8, 2004 Transbase v10, 2010 DB2 for z/OS DB2 for VSE & VM v5, 1996 v4, 1994 v6, 1999 v7, 2001 v8, 2003 TinyDB Transbase (Transaction Software) IBM v9, 2006 Solid DB EXASolution EXASolution dBase REDABAS (Robotron) dBase (Ashton Tate) Borland IBM IS1 InterBase GDBM 1970s Berkeley DB DBM v1, 1991 v3, 1999 FileMaker (Nashoba) Siemens Nonstop SQL (Tandem) v1, 1987 v2, 1989 AdabasD (Software AG) Claris (Apple) II, 1988 v1, 1985 v1.5, 2004 CODD RIVER SQLite v5, 2010 SAP HANA P*TIME SAP DB BerkeleyDB SAP v1.7, 2002 HANA MaxDB MaxDB Nonstop SQL v3, 2011 Compaq HP FileMaker Pro v2, 1992 v3, 1995 v4, 1997 FileMaker Inc. v5, 1999 v7, 2004 v6, 2002 AdabasD v11, 2011 v14, 2015 v8, 2005 Neoview v9, 2007 v10, 2009 FileMaker Felix Naumann, Jana Bauckmann, Claudia Exeler, Jan-Peer Rudolph, Fabian Tschirschnitz Key to lines and symbols Contact - Hasso Plattner Institut, Potsdam, [email protected] v9, 2006CC Publishing Date v2, 2012 v1.8, 2005 Oracle v1.6, 2001 DB2 for LUW HSQLDB v2.0, 2010 v2, 2006 2000s v4, 2001 HSQLDB Mariposa (Berkeley) DDB4 (Nixdorf) v1, 2003 SQLite Sleepycat v2, 1997 NDBM Gamma (Univ. Wisconsin) VDN/RDS Firebird Firebird Ashton Tate Groton Database Systems IBM Peterlee Relational Test Vehicle dBase Inc. InfiniDB Acquisition Versions Discontinued Branch (intellectual and/or code) Crossing lines have no special semantics Design - Alexander Sandt Grafik-Design, Hamburg Version 5.0 - October 2015 http://www.hpi.uni-potsdam.de/naumann/projekte/rdbms_genealogy.html Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 9 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Hardware Enwicklung “Tape is Dead, Disk is Tape ...” (Jim Gray, 2006) Anschaffung unserer AG aus 2016: Server mit 48 Kernen (4 Intel E7-4830 v3, mit je 12 Cores/24 Threads), 1TB RAM ∼ 20k Euro. Rechenbeispiel (aus Kemper): Amazon hat 2010 Umsatz von 30 Mrd Euro erwirtschaftet. Durchschnittlicher Produktpreis ca. 15 Euro. Also 2 Mrd Bestellpositionen. 100 Byte pro Bestellposition, ergeben eine Relation mit “nur” 200GB Speichervolumen. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 10 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Hyperthread 1 Core 1 Core 2 Core 3 Core 4 Core 5 Core 6 Core 7 Core 8 Core 9 Hyperthread 2 768KB L1D 768KB L1I 3MB L2 Cache Core 10 Core 11 Core 12 256GB RAM 256GB CPU RAM CPU RAM 256GB 30MB LLC RAM 256GB Quick Path Interconnect (QPI) CPU Prof. Dr.-Ing. S. Michel CPU TU Kaiserslautern Datenbanksysteme, WS 16/17 11 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken New Hardware Beispiel: Intels Xeon Phi Quelle: Intel Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 12 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken New Hardware Beispiel: Intels Xeon Phi Quelle: Intel Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 13 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Profiling eines traditionellen DBS 35% Puffer-Verwaltung 30% MehrbenutzerSynchronisation 12% Logging 7% nützlich 16% OptimierungsPotential Abbildung nach Kemper&Eickler. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 14 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Optimierungsmöglichkeiten eines HauptspeicherDBS Pufferverwaltung: Man verlässt sich auf die extrem effiziente virtuelle Speicherverwaltung des Betriebssystems. D.h. keine Seitenverwaltung mit Tuple-Indentifiers, keine Pufferverwaltung. Mehrbenutzer- und Thread-Synchronisierung: Parallelitätsgrad kann eingeschränkt werden. Wieso? Zeit pro TA sehr viel geringer (keine Page-Misses mehr, die ∼ 10ms kosten). D.h. sogar im sequentiellen (Ein-Benutzer) Betrieb viele tausend TAs pro Sekunde möglich (bei einfachen OLTP Anfragen). Logging/Protokollierung: Auch in Hauptspeicherdatenbanken müssen Log-Einträge geschrieben werden, wegen Durability Anforderung. Idee: Durchsatzerhöhung durch Commit einer ganzen Gruppe von Transaktionen. Dieses Verfahren nennt man Group Commit. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 15 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Ziel: OLAP und OLTP im gleichen System Hybride OLTP&OLAP Hauptspeicher-Datenbanksysteme ++OLTP ++OLAP Dedizierte OLAP-Engines MonetDB, Vertica, SAP T-Rex (BWA), IBM ISAO (BLINK) Dedizierte OLTP-Engines VoltDB, SAP P*Time, TimesTen, SolidDB, viele Startups --OLTP --OLAP Abbildung nach Kemper. Nachfolgend werden einige neuere Ansätze beschrieben, die das Ziel haben, gemischte Workloads von OLAP und OLTP Anfragen effizient zu unterstützen. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 16 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Update Staging Idee: Änderungen (updates, inserts, deletes) werden in einem sogenannten Delta gesammelt und nur periodisch in die (lese-optimierte Haupt-Datenbank) eingebracht. OLTP Transaktionen a b c d e i f g h j ... OLAP Transaktionen Haupt-Datenbank (lese-optimiert) a' Delta e rg me j' Abbildung nach Kemper. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 17 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Memory Snapshots via Fork OLAP Transaktionen OLTP Transaktionen Read a c d Read a b a fork Abbildung nach Kemper. Idee: Mit dem Unix fork Systembefehl wird Kindprozess mit identischem Speicherabbild des Vaterprozesses erzeugt. Aber (virtueller) Addressraum des Vater-Prozesses wird nicht sofort komplett kopiert. Sondern erst bei Änderung. Diesen Vorgang nennt man copy on write/update. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 18 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Memory Snapshots via Fork: Copy on Write OLAP Transaktionen OLTP Transaktionen c Update a a' b d Read a a b a' copy on write Abbildung nach Kemper. Bei Änderungen der OLTP Transaktion wird eine Kopie des ursprünglichen Speicherinhaltes für die lesenden (OLAP) Transaktionen beibehalten. Wenn fork zu einem Zeitpunkt aufgerufen wird, an dem keine TA aktiv ist, dann bekommt OLAP Anfrage einen transaktionskonsistenten Zustand. Datenbanksysteme, WS 16/17 Prof. Dr.-Ing. S. Michel TU Kaiserslautern 19 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken // e i n f a c h e r B e i s p i e l −Code f u e r f o r k und S i c h t b a r k e i t von A e n d e r u n g e n #i n c l u d e <u n i s t d . h> #i n c l u d e <v e c t o r > #i n c l u d e <i o s t r e a m > using std : : vector ; using std : : endl ; using std : : cout ; struct Professor { unsigned persnr ; c h a r name [ 2 0 ] ; char rang [ 3 ] ; u n s i g n e d raum ; char t e l e f o n [ 2 0 ] ; }; i n t main ( ) { v e c t o r <P r o f e s s o r > p r o f e s s o r e n ; // ' ' Row−S t o r e ' ' p r o f e s s o r e n . p u s h b a c k ( ( P r o f e s s o r ) {2125 , ” S o k r a t e s ” , ”C4” , 2 2 6 } ) ; pid t pid = fork ( ) ; i f ( p i d >0) { // V a t e r−P r o z e s s p r o f e s s o r e n . p u s h b a c k ( ( P r o f e s s o r ) {2127 , ” K o p e r n i k u s ” , ”C3” , 3 1 0 } ) ; c o u t << ” V a t e r−P r o z e s s : ” << p r o f e s s o r e n . s i z e ( ) << ” T u p e l ” << e n d l ; sleep (2); } e l s e { // Kind−P r o z e s s sleep (1); c o u t << ” Kind−P r o z e s s : ” << p r o f e s s o r e n . s i z e ( ) << ” T u p e l ” << e n d l ; } } Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 20 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Multiple zeitlich versetzte OLAP-Snapshots c OLTP Transaktionen d b a b c' d Read a b a' b a'' a''' it Ze OLAP Transaktionen Abbildung nach Kemper. Neuer Snapshot bei eintreffender OLAP-Anfrage. Oder periodische Snapshots (z.B. alle paar Sekunden) + Warten oder auf altem Snapshot ausführen. Wozu kann letzteres führen? Client mit OLTP und OLAT Anfragen sieht evtl. eigene Änderungen nicht. Bei neuem Snapshot bei Eintreffen kann dies nicht passieren (d.h. read your writes). Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 21 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Hauptspeicherdatenbanken und ACID OLAP-Snapshots sind transaktionskonsistent und können als Sicherungspunkte auf persistenten Speicher (oder Storage Server) geschrieben werden. Undo-Logs müssen nur zur Laufzeit einer Transaktion gehalten werden und nicht darüber hinaus. Dazu braucht man noch Redo-Informationen der abgeschlossenen OLTP Transaktionen. Diese werden nicht einzeln, sondern als größere Menge geschrieben, vgl. group commit. OLTP Transaktionen sind trivialerweise synchronisiert, da rein sequentiell. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 22 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Redo-Logging und Datenbank-Backup OLTP Transaktionen UndoLog c b d OLAP Transaktionen a b c' d a'' Ba b a' b it s es z ro -P Ze up ck a''' SpeicherServer RedoLog (Transaktionskonsistente Datenbank) Abbildung nach Kemper. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 23 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Weitere aktuelle Themen Auswirkungen von nichtflüchtigem RAM (Non-volatile Memory), z.B. Phase-change memory, auf Datenmanagement Hardware-Transactional-Memory (HTM) Indexstrukturen und Algorithmen zur Verbesserung der Cache-Lokalität Hochparallele Algorithmen (z.B. Sort-Merge-Joins) Berücksichtigung von Non-Uniform-Memory-Access (NUMA) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 24 / 25 Data Layouts, OLTP/OLAP, In-Memory DBS Hauptspeicherdatenbanken Literatur Buch von Kemper & Eickler. Kapitel 20. D. Abadi et al. The Design and Implementation of Modern Column-Oriented Database Systems. http://db.csail.mit.edu/pubs/abadi-column-stores.pdf Jens Dittrich. Patterns in Data Management. “Flipped Textbook” mit Videos und vielen Quizzes. G. Copeland and S. Khoshafian. A Decompositional Storage Model. SIGMOD, 1985. http://users.csc.calpoly.edu/~dekhtyar/ 560-Fall2012/papers/DSM-columns.pdf S. Harizopoulos, D. J. Abadi, S. Madden, M. Stonebraker. OLTP through the looking glass, and what we found there. SIGMOD, 2008. A. Ailamani, D. DeWitt, M. Hill. Data Page Layouts for Relational Databases on Deep Memory Hierarchies. VLDB Journal, 2002. Alfons Kemper, Thomas Neumann: HyPer: A hybrid OLTP&OLAP main memory database system based on virtual memory snapshots. ICDE, 2011. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 16/17 25 / 25
