Column Stores

699 Aufrufe

Veröffentlicht am

Veröffentlicht in: Bildung
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
699
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
6
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Column Stores

  1. 1. Column Stores Arno Schmidhauser Letzte Revision: Januar 2011
  2. 2. Neues technisches Umfeld• RAM Zugriff: 1 GB/sec Random (Seek Time 1-3 nsec, 3-6 Bus- Cycles, 64 Byte Block), 10 GB/sec Maximum(Peak)• Diskzugriff: 1 MB/sec Random (Seek Time 1 msec, 1 KB Block), 100 MB/sec Stream.• Sehr performante Vektorverarbeitung in modernen CPUs mit mehreren Cache-Levels.• Das Absuchen eines Vektors mit 106 Datensätzen à 10 Bytes dauert ca 0.01sec bei 1GB/sec, 0.001sec bei 10 GB/sec.• Verfügbares Memory problemlos > 4 GB für Standard Server.• Memory hat kleinere Random/Stream Problematik, Durchsatz ist unabhängiger vom Ort der Daten im Ggs. zu Disk.
  3. 3. Neue AnfragetypenFrüher vorallem OLTP Heute zunehmend OLAP select * from Bestellung select avg( betrag ) where id = 4711 from Bestellung insert into Bestellung values (…)  datensatzweise Abfragen  spaltenweise Abfragen
  4. 4. Leseoperation überwiegen• Frühe Annahme: Einfügen, Ändern, Löschen machen einen relevanten Anteil der Datenbankoperationen aus.• Neue Untersuchungen: Selbst bei OLTP-Systemen überwiegen heute die Anzahl Leseoperationen deutlich.
  5. 5. Viele Spalten mit wenig Werten• Sehr viele Spalten in Datenbanksystem enthalten tatsächlich nur wenig verschiedene Werte.• Beispiel: 29% aller Spalten (Attribute) enthalten lediglich 2 bis 32 verschiedene Werte.
  6. 6. Column Stores, wofür?• Für viele Anwendungen ist die Architektur klassischer Datenbanksysteme nicht optimal. Der Datensatz als logische und technische Einheit ist nicht immer sinnvoll.• Column Stores sind eine neue technologische Richtung. Im Fokus steht dabei: – Leseoperationen überwiegen gegenüber Änderungen. – Abfragen überstreichen oft einen grossen Teil der vorhanden Daten. – Spaltenorientierte Abfragen überwiegen. – Ganze Spalten oder ganze DB wird im Speicher gehalten. – Vorallem numerische und kleine Datentypen, wenig Strings.
  7. 7. Zeilenspeicherung• Die klassische Datenbank-Technologie geht von OLTP- Applikationen aus: 1. Datensatzorientierte Speicherung 2. Sequentielle Anhäufung von Datensätzen 3. Seitenorientierte Zusammenfassung von Datensätzen Page 1 (Disk und Memory) Page 2 (Disk und Memory) Datensatz 1 Date- Datensatz 9 Date- satz 2 Datensatz 3 satz 10 Datensatz 11 Datensatz 4 Datensatz Datensatz 12 Datensatz 5 Datensatz 6 13 Datensatz 14 Datensatz 7 Datensatz 8 Datensatz 15 Datensatz 16
  8. 8. Spaltenspeicherung Spalte C Spalte A Spalte B• Wenn OLAP-Anfragen dominieren, sind spaltenorientierte Datensatz 1 w1 w1 w1 Speichertechnologien Datensatz 2 w2 effizienter: Datensatz 3 w3 w2 Datensatz 4 w4 w2 Datensatz 5 w5 w3• Nur benötigte Spalten ins Memory laden, w4 w3 dafür Spalte in der ganzen Länge. w5• Effiziente Aggregatbildung. w4• Zugehörigkeit eines Attributwertes in einer Spalte zu einem Datensatz: w5 1. duch die Position (Array) 2. durch einen Schlüssel (ObjectId, RecordId)
  9. 9. Zeilen- und Spaltenspeicherung Datensatzorientierte Spaltenorientierte Speicherung Speicherung Spalte C Spalte D Spalte N Spalte A Spalte B Spalte E Datensatz 1 Datensatz 2 OLTP Datensatz 3 ineffizient Datensatz 4 Datensatz n effizient Datensatz 1 Datensatz 2 OLAP Datensatz 3 effizient Datensatz 4 Datensatz n ineffizient
  10. 10. Komprimierung• Ein wesentlicher Vorteil von Column-Stores liegt darin, dass Spalten oft eine hohe Anzahl gleicher Werte enthalten.• Komprimierung der Daten auf der Disk beschleunigt das Laden und Speichern der Datenbank bei den Checkpoints.• In der Regel heute im Memory dekomprimiert.• Neueste Entwicklungen jedoch so, dass Daten auch im Memory komprimiert abgelegt sind, und erst für die Verarbeitung in der CPU (Level 2 Cache) dekomprimiert werden.
  11. 11. Run Length Encoding• Sehr effizient für sortierte Spalten, Beispiel: Quantity Quantity unkompr. (Wert;Anzahl) 1 1;5 1 3;2 1 10;5 1 1 3 3 10 10 10 10 10
  12. 12. Delta Encoding• Variante 1: Numerische Werte werden als Differenz zum kleinsten Wert codiert.• Variante 2: Numerische Werte werden als Differenz zum jeweils vorhergehenden Wert dargestellt.
  13. 13. Bit Vector Encoding• für Spalten mit wenig Bit Vektor Werte 1000000 Montag verschiedenen Werten, 0100000 Dienstag z.B. Geschlecht, Wochentag, 0010000 Mittwoch Land, Status usw. 0001000 Donnerstag 0000100 Freitag 0000010 Samstag 0000001 Sonntag Tabelle mit Bit Vektor Werten WochenTag Artikel ID Kunden ID Menge 0000001 43 4711 1.00 0000010 56 4711 2.00 0000100 43 6900 1.00 Bit Vektor Index 0000001 heisst: Datensatz 1 hat den Wert 0000001 0000010 heisst: Datensatz 2 hat den Wert 0000010 0000100 heisst: Datensatz 3 hat den Wert 0000100
  14. 14. Dictionary Encoding• Lange und wiederholt vorkommende Werte werden in einen Dictionary ausgelagert: Dokument URL Begriff ID ti.bfh.ch Studium ti.bfh.ch Bachelor hkb.bfh.ch Studium hkb.bfh.ch Kunst Dokument Dictionary URL dict ID dict ID Begriff ti.bfh.ch 1 1 Studium ti.bfh.ch 2 2 Bachelor hkb.bfh.ch 1 3 Kunst hkb.bfh.ch 3• Wird z.B. auch bei der XML Speicherung für Element- namen verwendet!
  15. 15. Indexierungsstrategie• Bei klassischen Datenbanken werden alle Index auf Disk gespeichert. Indexstrukturen können grösser als die Datenbank selbst sein, oft sogar bis Faktor 10.• Column Stores und In Memory Datenbank halten Indexe nur im Memory. Indexe unterliegen keinem Recovery bei einem System Crash, sondern werden neu gebaut.• Indexzugriffe erfordern bei Column Stores nie Disk-I/O. Indexe referenzieren nur Memory-Adressen oder Arraypositionen in Spalten, jedoch keine externen Datensatz IDs, Primary Keys o.ä.
  16. 16. Produktbeispiel MonetDB• Open Source, Enge Zusammenarbeit mit Open Source Datawarehouse Tools von Pentaho.• SQL 93 kompatibel.• ACID kompatibel, Snapshot-Isolation.• Schnelles Erzeugen und Laden von Spalten-Files mit COPY Utility.• Extrem schnell bei spaltenorientierten Abfragen (Bis zu Faktor 100 gegenüber mySQL).• Performance bezüglich Einfügen, Ändern, Löschen mit SQL ist kritisch, da bei Checkpoints ganze Spalten-Files geschrieben werden.• Kommerzielle Weiterentwicklung im Rahmen von Ingres Vectorwise.
  17. 17. Tabellen, Aufspaltung in Spalten• Originale Tabelle• Pro Attribut eine binäre Relation (BAT) im Memory mit Objekt- IDs und Attributwerten• Binary Association Tables (BATs) sind die Grundstruktur der Tabellenspeicherung in MonetDB (und anderen ColumnStores)
  18. 18. Binary Association Table (BAT)Hash Zugriff mitOID als Schlüssel Memory Mapped File (.tail) Kompression auf Disk, um I/O zu Werden beim Laden erzeugt vermindern. Kompressiosnsvarianten siehe weiter unten
  19. 19. Indexierung• Beim ersten Zugriff auf ein Attribut wird eine Kopie seiner BAT erstellt. Diese Kopie wird als Index nachgeführt und schrittweise verfeinert, z.B. bei der ersten Abfrage wie folgt: select … from Discount where Discount > 0.1 Kopie > 0.1 ≤ 0.1
  20. 20. Einfaches Query• Abfrage: select * from Discount where Discount > 0.1• Ausführung: 1. Sequentielles Scannen der Discount-BAT: alle OIDs suchen, für die Discount > 0.1. 2. Mit den OIDs in den übrigen BATs die anderen Attribute des Datensatzes suchen.
  21. 21. Aggregat Query• Abfrage: select Day, avg(Discount) from Discount where Discount = 0.065 and Day = 9/4/98• Ausführung ohne Index: 1. Spalten sequentiell scannen und je einen Bit-Vektor bilden: 1 = Bedingung erfüllt, 0 = Bedingung nicht erfüllt. 2. and-Verknüpfung der beiden Bit-Vektoren durchführen. 3. Korrespondierende Array-Positionen in der Day- und Discount-BAT entnehmen, avg() bilden und ausgeben.
  22. 22. Aggregat Queryselect Day, avg(Discount) from Discountwhere Discount = 0.065 and Day = 9/4/98 0 1 0 0 0 0 1 AND 0 0 0 0 1 0 0 1
  23. 23. Aggregat Query mit Joins• Beispiel einer Join-Abfrage select o.year, sum(o.quantity) from Order o, Customer c, Product p where o.custID = c.custID and o.prodID = p.prodID and p.name = P1 and c.region = europe group by o.year• Im folgenden soll die spaltenorientierte Verarbeitung dieser Abfrage gezeigt werden.
  24. 24. Join, TabellenCustomer Product custID name region prodID name 1 C1 europe 1 P1 2 C2 europe 2 P2 3 C3 asia 3 P3 4 C4 asia 4 P4 5 C5 pacific 5 P5 Order custID prodID year quantity 1 1 2009 10 1 5 2010 10 2 1 2009 1000 3 1 2009 500 3 4 2009 500 3 2 2010 500 2 1 2007 100
  25. 25. Join, Spalten• Achtung: Die Datenbank besteht physisch aus einer Sammlung von Spalten (BATs in MonetDB) BAT BAT BAT BAT BAT OID c.custID OID c.name OID c.region OID p.prodID OID p.name 101 1 101 C1 101 europe 201 1 201 P1 102 2 102 C2 102 europe 202 2 202 P2 103 3 103 C3 103 asia 203 3 203 P3 104 4 104 C4 104 asia 204 4 204 P4 105 5 105 C5 105 pacific 205 5 205 P5 BAT BAT BAT BAT OID o.custID OID o.prodID OID o.year OID o.quantity 1001 1 1001 1 1001 2009 1001 10 1002 1 1002 5 1002 2010 1002 10 1003 2 1003 1 1003 2009 1003 1000 1004 3 1004 1 1004 2009 1004 500 1005 3 1005 4 1005 2009 1005 500 1006 3 1006 2 1006 2010 1006 500 1007 2 1007 1 1007 2007 1007 100
  26. 26. Join, Ablauf, Schritt 1 und 2 c.region = europe BV1 TB1 OID c.region Bit OID c.custID custID 101 102 europe europe 1 1 101 102 1 2 1 2 103 asia 0 103 3 104 asia 0 104 4 105 pacific 0 105 5 p.name = P1 BV2 TB2 OID p.name Bit OID p.prodID prodID 201 202 P1 P2 1 0 201 202 1 2 1 203 P3 0 203 3 204 P4 0 204 4 205 P5 0 205 5
  27. 27. Join, Ablauf Schritt 1 und 2 Operation Algorithmus Resultat c.region = europe linearer Scan über c.region (Verbesserung BV1: Bit Vektor, ermittelt über c.region, auswerten für Stringdaten:Indexzugriff, Dictionary welcher pro Position in der Customer Lookup, Komprimierte Daten usw.) Tabelle angibt, ob der Datensatz die Bedingung erfüllt. BV1 auf c.custID anwenden Scan über BV1 und c.custID, jeweils in TB1: Temoräre BAT mit allen custID. beiden Vektoren Position für Position CustID als Hashkey vorrücken, da beide gleichviele Einträge haben. Alle custID entnehmen, welche an entsprechender Positione im Bit Vektor eine 1 haben. p.name = P1 auswerten linearer Scan über p.name (Verbesserung BV2: Bit Vektor, ermittelt über c.region, für Stringdaten:Indexzugriff, Dictionary welcher pro Position in der Product Lookup, Komprimierte Daten usw.) Tabelle angibt, ob der Datensatz die Bedingung erfüllt BV2 auf p.prodID anwenden Scan über BV2 und p.prodtID, jeweils in TB1: Temoräre BAT mit allen prodID. beiden Vektoren Position für Position ProdID als Hashkey vorrücken, da beide gleichviele Einträge haben. Alle prodID entnehmen, welche an entsprechender Positione im Bit Vektor eine 1 haben.
  28. 28. Join-Ablauf, Schritt 3 bis 7 TB1 1 Scan über o.custID mit Lookup in TB1. Wenn custID 2 BV3 custID in TB1 vorkommt, dann in BV3 1 eintragen. OID o.custID Bit 1001 1 1 1002 1 1 1003 2 1 1004 3 0 1005 3 0 BV4 1006 3 0 Bit OID o.year OID o.quantity 1007 2 1 1 1001 2009 1001 10  0 1 1002 2010 1003 2009 1002 10 1003 1000 AND Verknüpfung 0 1004 2009 1004 500 TB2 1 0 1005 2009 1005 500 prodID 0 1006 2010 1006 500 1 1007 2007 1007 100 Scan über o.prodID mit Lookup in TB2. Wenn custID in TB2 Aus den BATs o.year und o.quantity Zeilen vorkommt, dann in BV4 1  gemäss Bit Vektor BV4 entnehmen. BV4 OID o.prodID Bit OID o.year o.quantity 1001 1 1 1001 2009 10 1002 5 0 1003 2009 1000 1003 1 1 1007 2007 100 1004 1 1 1005 4 0 1006 2 0 Gruppiert = Sortiert o.year o.quantity 1007 1 1 und zusammen- 2009 1010  gefasst, z.B. über Merge-Sort 2007 100
  29. 29. Join-Ablauf, Schritt 3 bis 7 c.region = europe auswerten linearer Scan über c.region (Verbesserung für BV1: Bit Vektor, ermittelt über c.region, welcher pro Stringdaten:Indexzugriff, Dictionary Lookup, Komprimierte Daten usw.) Position in der Customer Tabelle angibt, ob der Datensatz die Bedingung erfüllt. BV1 auf c.custID anwenden Scan über BV1 und c.custID, jeweils in beiden Vektoren TB1: Temoräre BAT mit allen custID. CustID als Hashkey Position für Position vorrücken, da beide gleichviele Einträge haben. Alle custID entnehmen, welche an entsprechender Positione im Bit Vektor eine 1 haben. p.name = P1 auswerten linearer Scan über p.name (Verbesserung für BV2: Bit Vektor, ermittelt über c.region, welcher pro Stringdaten:Indexzugriff, Dictionary Lookup, Komprimierte Daten usw.) Position in der Product Tabelle angibt, ob der Datensatz die Bedingung erfüllt BV2 auf p.prodID anwenden Scan über BV2 und p.prodtID, jeweils in beiden Vektoren TB1: Temoräre BAT mit allen prodID. ProdID als Hashkey Position für Position vorrücken, da beide gleichviele Einträge haben. Alle prodID entnehmen, welche an entsprechender Positione im Bit Vektor eine 1 haben. Vergleich o.custID mit Einträgen in TB1 Scan über o.custID, lookup jeder custID in TB1 BV3: Bit Vektor, welcher pro Eintrag in o.custID angibt, ob die entsprechende custID in TB1 vorkommt. Vergleich o.prodID mit Einträgen in TB2 Scan über o.prodID, lookup jeder custID in TB2 BV4: Bit Vektor, welcher pro Eintrag in o.custID angibt, ob die entsprechende custID in TB2 vorkommt. AND Verknüpfung auswerten AND Verknüpfung von BV3 und BV4 BV5: Bit Vektor, welcher pro Eintrag für Tabelle Order angibt, ob er den Bedingungen c.region = europe und p.name = P1 genügt. BV5 auf o.year anwenden linearer Scan über BV5 und o.year TB3: Temporäre BAT mit year• BV5 auf o.quantity anwenden linearer Scan über BV5 und o.quantity TB4: Temporäre BAT mit quantity Algorithmus zum Gruppieren anwenden Verbund von TB3 und TB4 TB5: Temporäre BAT mit 2 Attributen (year, quantity) TB5 sortieren nach year, Irgendeine Gruppier-Algorithmus, z.B. Sortieralgorithmus, Ausgabe von year und sum(quantity) summieren von quantity z.B. Merge-Sort, dann zusammenfassen.
  30. 30. Produktbeispiel Ingres Vectorwise• kommerzielles Produkt. 64 Bit auf Windows, Linux und als Amazon Webservice (Amazon Machine Image).• Datensätze, resp. Werte in den Spalten werden in Einfügereihenfolge gespeichert (RAW Mode).• Parameter block_size definiert Blockgrösse, die für das Ablegen von Spalten benützt werden. Ein Block ist die I/O Einheit zur Disk. Jeder Block beinhaltet Statistikangaben, z.B. grösster und kleinster Spaltenwert.• Blöcke werden komprimiert. Datenbank bestimmt automatisch Algorithmus pro Block: Run Length Encoding, Dictionary Encoding und Delta Encoding.
  31. 31. Produktbeispiel Ingres Vectorwise• Von jedem Datenblock einer Spalte wird der Minimum und Maximumwert im Memory gehalten ("Index" ).• Jede Tabellen kann einen Clustered Index haben (create index Befehl). Keine anderen Indexe sind möglich.• Indexstrukturen werden ausschliesslich im Memory gehalten (Bei Crash zerstört).• Änderungen werden über Positional Delta Trees verwaltet. Bei einem bestimmtem Umfang an Änderungen wird die gesamte DB auf Disk propagiert (Checkpoint).
  32. 32. Änderungen in Column Stores• Einfügen/Ändern/Löschen in Column Stores werden als "notwendiges Übel" angesehen, im Gegensatz zur klassischen DB-Technologie. Änderungen über eine bestimmte Zeit hinweg in einer "Delta-Struktur" Hauptstruktur Delta-Struktur Nach sammeln. Disk/Memory (Änderungen) Checkpoint Spalte/Datensatz Bei Checkpoint anwenden auf A a einfügen a Hauptstruktur B C a einfügen a einfügen a a der Datenbank. D d einfügen A E B ändern auf b b F C löschen d D E F
  33. 33. Positional Delta Tree, PDT• Der Positional Delta Tree ist eine hocheffiziente Delta- Struktur, damit beim Lesen von Spalten auch Änderungen miteinbezogen werden.• Ausgangslage: – Spalten (oder Datensätze) liegen in einer bestimmten Sortierung vor, die bei Abfragen verwendet wird. – Die Sortierung von Spalten und Datensätzen muss daher zusammen mit der Delta-Struktur jederzeit rekonstruiert werden können. – Die Delta-Struktur darf Abfragen nur minimal verlangsamen.
  34. 34. PDT-Beispiel, Tabelle• Die SID ist die Position des Datensatzes, respektive der Spaltenwerte, auf Disk oder im Memory, wenn noch keine Änderungen stattgefunden haben. Sortier-Schlüssel, physische Reihenfolge
  35. 35. PDT-Beispiel, Änderungsbefehle• Folgende Änderungen sollen nun vorgenommen werden:1. INSERT INTO inventory VALUES (Berlin,table,Y,10)2. INSERT INTO inventory VALUES (Berlin,cloth,Y,5)3. INSERT INTO inventory VALUES (Berlin,chair,Y,20)4. INSERT INTO inventory VALUES (Paris,sofa,Y,3)5. UPDATE inventory SET qty=13 WHERE store=London AND product=stool6. DELETE FROM inventory WHERE store=London AND product=table
  36. 36. Durch die Änderungen erzeugter PDT
  37. 37. PDT-Beispiel, neue Tabelle• Die nach dem Checkpoint erzeugte Tabelle sieht wie folgt aus:
  38. 38. Mehrschichtige Deltastruktur• Delta-Strukturen können auch zur Realisierung von Snapshot-Isolation verwendet werden.• Für jede neue Transaktion: Datenbankweite Delta-Struktur für die Transaktion kopieren, und mit Zeitstempel resp. Versionennummer der Transaktion versehen.• Transaktion arbeitet mit der kopierten Delta-Struktur lokal für sich weiter.• Beim Commit: lokale Delta-Struktur der Datenbank übergeben. Diese gleicht mit der datenbankweiten Delta- Struktur ab (Siehe Versionenverfahren für Concurrency Control).
  39. 39. Spaltenspeicherung in klassischen DBs• Ideen der Spaltenspeicherung zur Abfrage-Beschleunigung existieren bereits in den klassischen Datenbanksystemen. Beispiel mit MSSQL 2008: create index on Bestellung ( bestDatum ) include ( menge ) Das Attribut menge wird damit in den Blattknoten des Index abgelegt. So wird für folgende Abfragen der Zugriff auf die Haupttabelle überflüssig: select bestDatum, sum( menge ) from Bestellung group by bestDatum
  40. 40. Spaltenspeicherung in klassischen DBs• Pros: – Perfekt integriert in bestehende DB-Lösung. – 100% unsichtbar gegenüber Applikationen und Clientsystemen. – Macht das Laden der Basistabelle überflüssig, wenn die Abfrage aus allen Attributen des Index befriedigt werden kann.• Cons: – Klassische I/O Technologie: der Index muss zuerst geladen werden. I/O Pages sind nicht immer garantiert im Memory. – Index kann andere Daten aus dem Memory verdrängen, da er zusätzlich Platz benötigt.
  41. 41. Zusammenfassung Column Stores• Für grosse Datenbanken mit Schwergewicht OLAP Abfragen.• Abfrage-Performance kann sich um Faktor 100 verbessern, bei vergleichbarer Hardware.• Schlechtere Update-Performance.• Gute Bulk-Load Performance, da einfache Datenstrukturen (wenig Indexe). Eignung als Datawarehouse oder Data Mart. ETL Column Store Load Data Mart Quelldaten Quelldaten DWH Quelldaten Data Mart
  42. 42. Produkte• MonetDB• SybaseIQ• Ingres Vectorwise• SyncSort• Vertica• Informatica

×