Zeilen- vs. spaltenorientierte Datenhaltung im … · Einführung und Überblick Aufbau einer Speicherhierarchie, wobei: –Abfragen über oft abgerufene, große Datenmengen im Hauptspeicher

Die Datenbank-Spezialisten.

Begriffe, Modellierung und reale Probleme mit der Oracle InMemory-Technologie

Zeilen- vs. spaltenorientierte Datenhaltung im Hauptspeicher

Frank Effenberger, Dresden – 28.10.2015


Zahlen und FaktenRobotron Datenbank-Software GmbH

Gründungsjahr 1990

Geschäftsform GmbH (9 Gesellschafter)

Mitarbeiterzahl 349 (Stand 01/2015)

Stammkapital 2,4 Mio. EUR

Umsatz 2013 31,1 Mio. EUR

Umsatz 2014 31,2 Mio. EUR

Oracle-Partner

ISO 9001 zertifiziert

Hauptsitz

Schulungs- und Kongresszentrum


Robotron-Firmengruppe

Tschechien: Robotron Database Solutions s.r.o.

Schweiz: Robotron Schweiz GmbH

Österreich: Robotron Austria GmbH

Russland: Robotron Rus GmbH

Deutschland: Robotron|ECG solutions GmbH

Deutschland: SASKIA® Informations-Systeme GmbH


Unsere Kernkompetenz


0. Gliederung

1. Einführung und Überblick

2. Oracle InMemory-Technologie und SQL-Befehle

3. Oracle InMemory für das DWH

4. Technische Rahmenbedingungen

5. Fazit

6. Quellen



Motivation:

DWHs sind read mostly (ohne Betrachtung ETL-Prozess)

Abfragen über mehrere Millionen Datensätze mit hoher Datendichte (wenige Null-Werte) => hohe Abfrage- und Antwortzeiten bei komplexen Analysen

Ablehnung gegenüber langsamen Produkten, Konkurrenten mit höherer Effizienz werden bevorzugt

Idee der spaltenorientierten Abfragen im Hauptspeicher



– Speicherchip im Prozessor -> Nachdenken

– Hauptspeicher -> Im Bücherregal eine Informationsuchen

– Festplatte -> Mit dem Auto in die nächste Büchereifahren, Information suchen undzurückfahren

Schnelligkeit des Hauptspeichers anhand eines Beispiels:

Quelle Erzählung: Erzählung Prof. Gräfe zur Studienzeit



Aufbau einer Speicherhierarchie, wobei:

– Abfragen über oft abgerufene, große Datenmengen im Hauptspeicher durchgeführt werden (‚Wegfall‘ des I/O, aber Erhöhung CPU-Last)

– Abfragen über seltener abgerufene Datenmengen auf der Festplatte durchgeführt werden

Langfristiges Ziel zur Steuerung der Abfragezeiten:



Nutzung von Hauptspeichertechnologien(zeilen- und spaltenorientiert)

Bedeutung der Oracle InMemory Option:

Spaltenorientierte Speicherung im Hauptspeicher

Cache (zeilenorientierte Speicherung) gibt es schon seit langer Zeit beiOracle und ist nicht neu!

Bedeutung von InMemory im eigentlichem Sinne:



Oracle Database InMemory Option:

Datenbankobjekte wahlweise (!) im Hauptspeicher

Reservierung von Hauptspeicher in SGA für InMemory

Keine Änderung in der Anwendung nötig (auf den ersten Blick)

Spaltenorientiert

Komprimiert (2-20fach)

Parallelisierung

Nutzung bestehender DB-Architektur und Funktionalität

Quelle Aufzählung: TiF Seminar, Oracle München, 2015


Technologische Konzepte des Vortrags

Cache InMemory Compression

SIMD Bloomfilter



Oracle Database InMemory Option:

Schlüsselwörter:

InMemorySpaltenorientiert

Cache = Zeilenorientiert

Quelle Abbildung: TiF Seminar, Oracle München, 2015




SIMD Bloomfilter



Erklärung zu Cache:

Cache lässt z. B. eine Tabelle ständig als ‚most recently used‘(MRU) für das ‚last recently used‘ (LRU) gelten

MRU

LRU

Daten im Cache




SIMD Bloomfilter



Erklärung zu InMemory (Voraussetzungen):

Parameter INMEMORY_SIZE in z.B. Init.ora gesetzt:

show parameter inmemory_size;

Eigene SGA neben Cache für In-Memory mit SGA_Target Parameter gesetzt (Init.ora):

select * from V$SGA; (In-Memory Area muss zugewiesen sein)

ALTER SESSION|SYSTEM set inmemory_query = enable; (disable)

ALTER TABLE fact_table inmemory; (no inmemory)

ALTER TABLE dimension_table cache; (nocache)

Kein Migrationsprojekt (wenn man 12c hat)


Nach einem „ALTER TABLE X inmemory;“ muss ein Select auf die Tabelle ausgeführt werden, ehe sie in den Hauptspeicher geladen wird (oder Priority auf Critical setzen, dann laden bei Öffnung der DB)

Bei Abfragen entscheidet der SQL-Optimizer je nach Größe der Tabelle und Wiederholerwerten, ob IN-Memory oder normal auf der Datenbank abgefragt wird

Wenn Parallelisierung möglich, tut dies der SQL-Optimizerautomatisch (ggf. Parameter aktivieren)


Voraussetzungen:




SIMD Bloomfilter



Zeilenorientiert:

– 01, Alice , Golf; 02, Bob , Jacht; 03, Mallory, Jacht;

Spaltenorientiert mit Komprimierung (Spalten-ID):

– 01, 02, 03; Alice, Bob, Mallory; Golf, Jacht:002,003;

Komprimierung (vereinfacht):



Komprimierung:

Komprimierung allgemein (auch partitionsweise, da extra Partitionierungslizenz nötig)

In spaltenorientierten Systemen viele Wiederholer (Komprimierung 4-20fach möglich)

Create Table fact_table (

column1 number,

column2 varchar(2),

column3 number) INMEMORY [PRIORITY CRITICAL]MEMCOMPRESS FOR DML(column2);



InMemory kann bereits komprimierte Werte ohne Dekompression untereinander vergleichen (Komprimierung benötigt keine Advanced-Compression-Option!)

Spaltenorientierte, komprimierte Werte können auch parallelisiert werden und mithilfe von Buckets (Max/Min-Werte) noch performanter gemacht werden

Es ist möglich, nur ausgewählte Spalten in den Hauptspeicher zu laden und den Rest bei Bedarf nachzuladen

Zusätzliche Performancesteigerung:




SIMD Bloomfilter



SIMD*: Parallele CPU-Verarbeitung von Where-Bedingungen

Quelle Abbildung: Oracle White Paper: Oracle Database In-Memory, S. 11. (Oktober 2014)

* = Single Instruction processing Multiple Data values




SIMD Bloomfilter



Bloom-Filter (Anwendung bei InMemory-Hash-Joins):


ID V

1 A

2 B

3 C

Tabelle 1 Tabelle 2Bisheriges Vorgehen

FK ID V

1 1 C

2 2 A

3 3 B

2 4 A

2 5 C

1 6 D

77 7 F

- 8 G

- 9 H

(…) (…) (…)




Anmerkung: V = Value. Die Hashtabellen sind vereinfacht dargestellt.

ID V

1 A

2 B

3 C

Tabelle 1

Hash V

97 1,A

98 2,B

99 3,C

FK ID V

1 1 C

2 2 A

3 3 B

2 4 A

2 5 C

1 6 D

77 7 F

- 8 G

- 9 H

(…) (…) (…)

Tabelle 2

Hash (ID)

Bisheriges Vorgehen





ID V

1 A

2 B

3 C

FK ID V

1 1 C

2 2 A

3 3 B

2 4 A

2 5 C

1 6 D

77 7 F

- 8 G

- 9 H

(…) (…) (…)

Tabelle 1 Tabelle 2

Hash V

97 1,A

98 2,B

99 3,C

Hash (ID)

Hash (FK)Hash (FK)

Bisheriges Vorgehen





ID V

1 A

2 B

3 C

FK ID V

1 1 C

2 2 A

3 3 B

2 4 A

2 5 C

1 6 D

77 7 F

- 8 G

- 9 H

(…) (…) (…)

Tabelle 1 Tabelle 2

Hash V

97 1,A

98 2,B

99 3,C

Hash (ID)

Neues Vorgehen

Hash V

97 1,1,A

98 2,2,B

99 3,3,C

98 2,4,A

98 2,5,C

97 1,6,D

135 3,7,F

- 3,8,G

- 3,9,H

(…) (…)

Bit-vektor

0

1

1

0

0

0

1

1





ID V

1 A

2 B

3 C

FK ID V

1 1 C

2 2 A

3 3 B

2 4 A

2 5 C

1 6 D

77 7 F

- 8 G

- 9 H

(…) (…) (…)

Tabelle 1 Tabelle 2

Hash V

97 1,A

98 2,B

99 3,C

Hash (ID)

Neues Vorgehen

Hash V

97 1,1,A

98 2,2,B

99 3,3,C

98 2,4,A

98 2,5,C

97 1,6,D

135 3,7,F

- 3,8,G

- 3,9,H

(…) (…)

Bit-vektor

0

1

1

0

0

0

1

1




Hashtabelle 1

Hash V

97 1,1,A

98 2,2,B

99 3,3,C

98 2,4,A

98 2,5,C

97 1,6,D

135 3,7,F

- 3,8,G

- 3,9,H

(…) (…)

SIMD

Hashtabelle 2

Hash V

97 1,1,A

98 2,2,B

99 3,3,C

98 2,4,A

98 2,5,C

97 1,6,D

Hash V

97 1,A

98 2,B

99 3,C


Bit-vektor

0

1

1

0

0

0

1

1

Gefilterte Hashtabelle 2



Für die Oracle Database InMemory Option, ebenso wie für die Erhöhung des Caches wird RAM benötigt und muss gekauft werden. Unabhängig von diesen notwendigen Ausgaben stellt sich folgende Frage:

Lohnt es sich, zusätzliches Geld für die InMemory-Option auszugeben oder sollte der bereits vorhandene Cache weitergenutzt werden?



Nutzung im DWH:

Vermutung: Spaltenorientierung ist im OLAP sinnvoll und erhöht die Performance.

– Dimensionstabellen lohnen sich wegen den Wiederholerwerten und Virtualisierung (Materialized View) spaltenorientiert zu speichern?

– Faktentabellen lohnen sich in der spaltenorientierten Speicherung, wenn nur wenige Spalten abgefragt werden?

Praxis: Kann man das wirklich so pauschal sagen?

– Test der Fragestellung anhand vom mehreren Testfällen

– spannende Ergebnisse



Erkenntnisse aus den Tests:

Ziel ist eine Sensibilisierung: Nicht jede Query im DWH wird automatisch durch In-Memory schneller. Nicht nur Abfragen auf ‚viele Spalten‘ bremsen Performance, sondern:

– Anzahl der Joins und damit beteiligte Tabellen

– Art der Where-Bedingung

– Art der DML (Select, Insert, Update, …)




Manchmal ist Cache genauso gut wie ‚InMemory‘:

Abfrage 1:SELECT sum(STUNDEN_STZ_KST), sum(STUNDEN_STZ_PROJEKT), sum(STUNDEN_BUDGET_KST)

FROM FAKT_KFP;

Abfrage 2:SELECT sum(STUNDEN_STZ_KST), sum(STUNDEN_STZ_PROJEKT), sum(STUNDEN_BUDGET_KST)

FROM FAKT_KFP, DIM_PROJEKTE, DIM_MITARBEITER

WHERE DIM_PROJEKTE.Projektname = :p_projektname

AND DIM_MITARBEITER.Mitarbeitername= :p_mitarbeitername

AND DIM_PROJEKTE.Projekt_ID = FAKT_KFP.Projekt_ID

AND DIM_MITARBEITER.Mitarbeiternummer = FAKT_KFP.Mitarbeiternummer

(Abfrage aus Datenschutzgründen parametrisiert)



Erkenntnisse aus den Tests (Extrembeispiel):

Zeitfaktor = Dauer gecachte Abfrage / Dauer InMemory-Abfrage

13,28

1,07

0

2

4

6

8

10

12

14

Abfrage 1, keine joins Abfrage 2, spezifische joins

Zeitfaktor

Abfrage 1, keine joins Abfrage 2, spezifische joins

Anmerkung: Ergebnisse sind arithmetische Mittel mehrerer Kontrollabfragen, um ggf. andere parallel laufende Prozesse auszuschließen.




Abfragen des BI-Servers meist komplex (bei lange dauernden, zu optimierenden Anfragen)

Oft werden spaltenorientierte Systeme gezwungen, zeilenorientiert zu arbeiten und kein Performancegewinn durch InMemory

Bei OBIEE Hoffnung auf 12c-Version

Für OLTP-Systeme und dem bisherigen ETL-Prozess ist InMemorynicht geeignet

SQL-Review und Code-Review nötig, um optimale Nutzung für In-Memory zu garantieren!




InMemory bringt bei DWH-Abfragen mit großen Datenmengen und FULL Table Scans Performancegewinne, I/O sollte aber das einzige Bottleneck sein!

Deutliche Reduzierung der physical und logical (!) reads aufgrund der spaltenorientierten Abbildung im Speicher

Statistiken

-----------------------------------------------------

335678 consistent gets (NO INMEMORY)

34321 physical reads (NO INMEMORY)

…

252 consistent gets (INMEMORY)

0 physical reads (INMEMORY)

…

4430634 rows processed


4. Techn. Rahmenbedingungen

Die Tests wurden unter folgenden Rahmenbedingungen durchgeführt:

Testsystem 1 (kleines System):

– Oracle Release: 12.1.0.2

– DB-Host: rdslinux40 mit 2 GB RAM (nur für InMemory)

Testsystem 2 (großes System):

– Oracle Release: 12.1.0.2

– DB-Host: rdslinux17 mit 64 GB RAM (nur für InMemory)

Anmerkung: Es wurde keine Partitionierung verwendet.


5. Fazit

Es wurde festgestellt, dass:

InMemory nur in bestimmten Situationen Performancegewinne bringt (lesende Abfragen, Joins, Where-Bedingungen, gekoppelte Programme)

Das Bottleneck auf die CPU verschoben wird

Die von Oracle angebotenen BI-Tools Optimierungsbedarf haben

Die Alternative ‚Cache‘ sinnvoll sein kann

Deswegen:

Vorher SQL- und Codereviews durchführen und Optimierungspotentiale abschätzen

Verhältnis von Kosten und Nutzen untersuchen


5. Fazit

Soll ich den Hauptspeicher zeilen- oder spaltenorientiert nutzen?

Mit dem Hauptspeicher ist man immer schneller als im Vergleich zur Festplatte. Die eigentliche Frage / Diskussion sollte sein:


Fragen?

M.Sc. Frank EffenbergerSystemberater Business Analytics

externer Doktorand TU Dresden,Business Intelligence Research

Telefon: 0351 [email protected]

www.robotron.de


[6. Quellen]

Literatur:

[AbMH08 S. 5ff] Abadi; Madden; Hachem, (2008). Column-Stores vs.

Row-Stores: How Different Are They Really?

[DOAG15 S. 16ff] Pokolm, Jens-Christian, (2015). Datenbank-Konsolidierung mit Multitenant und In Memory. DOAG SOUG News, Konsolidierung räumt die IT auf.Erste Ausgabe Februar 2015.

[Orac14 S. 7] Oracle White Paper: Oracle Database In-Memory . (Oktober 2014). Von http://www.oracle.com/technetwork/database/in-memory/overview/twp-oracle-database-in-memory-2245633.html abgerufen

Kursmaterial aus TiF-Seminar, Oracle München (Schlaucher), 2014. Folie 251,252:

http://oracledwh.de/downloads/AutoIndex-2.2.4/index.php?dir=downloads/01_DWH_Seminare_Kurs_Materialien_Folien_und_Skripte/01_01_DWH%20Technik%20im%20Fokus%20Reihe_TIF/

Bilder:

http://us.123rf.com/450wm/brostock/brostock1301/brostock130100011/17533122-cpu-processor-chip-on-white-isolated.jpg

http://images.gutefrage.net/media/fragen/bilder/was-sieht-man-denn-alles-auf-einem-ram-riegel/0_big.jpg

http://upload.wikimedia.org/wikipedia/commons/7/75/Samsung_HD753LJ_03-Opened.jpg

https://images.otto.de/asset/mmo/formatz/helit-papierkorb-silber-8114573.jpg

Documents

Zeilen- vs. spaltenorientierte Datenhaltung im … · Einführung und Überblick Aufbau einer Speicherhierarchie, wobei: –Abfragen über oft abgerufene, große Datenmengen im Hauptspeicher