Caching: In-Memory Column Store oder im BI Server

Caching:
In-Memory Column Store oder BI Server?
Andreas Buckenhofer / Analytics / Daimler TSS
1Caching: In-Memory Column Store oder BI Server? | Analytics | 18-Nov-2015

Zur Person
Caching: In-Memory Column Store oder BI Server? | Analytics | 18-Nov-2015
Andreas Buckenhofer
Senior DB Professional
E-Mail: andreas.buckenhofer@daimler.com
Seit 2009 bei Daimler TSS
im Fachgebiet Data Warehouse & Data Integration (Cognos/Informatica) –
Department Analytics
Schwerpunkt DWH/CRM seit 1998 als
• Entwickler
• Administrator
• Berater

Daimler TSS IT-Exzellenz: Ganzheitlich, innovativ, nah
Wir sind Spezialist und strategischer Business-Partner für innovative IT-Lösungen im Daimler-Konzern. Als
100%ige Daimler-Tochter leben wir die Kultur der Exzellenz mit dem Anspruch der Innovations- und
Technologieführerschaft.
Mit herausragender Technologie- und Methodenkompetenz verstehen wir uns als kompetenter Anbieter von
wettbewerbsdifferenzierenden IT-Dienstleistungen. Unsere Geschäftspartner im Konzern begleiten wir
lösungsorientiert im Rahmen eines ganzheitlichen Ansatzes.
Wir denken und arbeiten partnerschaftlich und agil, sind technologieneutral und hersteller-unabhängig. Das macht
uns frei für maßgeschneiderte End-to-End-Lösungen mit hoher Effektivität. Die Aufnahme wichtiger Trends und
Impulse von außen zusammen mit dem tiefen Verständnis der Daimler-Geschäftsprozesse garantieren eine
umfassende Sicht und überzeugenden Mehrwert.
Unser Anspruch ist es, die Geschäftsprozesse, die Wettbewerbsfähigkeit und die Innovations-kraft von Daimler mit
marktführenden IT-Lösungen voranzutreiben. Als attraktiver Arbeitgeber wollen wir mit Menschen arbeiten, die durch
unser Unternehmen und das menschlich geprägte Umfeld inspiriert sind ihr Bestes zu geben und mit uns ihr volles
Potential zu entwickeln.

Standorte Daimler TSS

Ganzheitliche Betreuung (Erhebung, Auswertung,
Visualisierung und Interpretation), unabhängige
Beratung und Optimierung der Geschäftsabläufe.
Von klassischer BI bis hin zu predictive und prescriptive
Analytics bieten wir Leistungen unter Berücksichtigung
der Datensicherheit.
Dabei verknüpfen wir fachliche Erfahrung und IT-Know-
how im Daimler-Kontext mit dem Blick fürs große
Ganze.
Analytics. Das große Ganze verstehen, um Daten nutzbar machen.

Gliederung
Motivation und Konzepte spaltenorientierter In-Memory DBs (IMDB)
OLAP/Cognos In-Memory Cubes und IMDB
Testszenario und –durchführung mit Oracle
Erkenntnisse/Folgerungen
Zusammenfassung

DWH Reference Architecture
Backend
Frontend
Acquisition Layer (Input Layer)
Core Warehouse Layer (Storage Layer)
Information Mart Layer (Output Layer)
Ad-hoc
Reporting
Standard
Reporting
Dash-
boards
Predictive
Analytics
Prescriptive
Analytics
Star OLAP
3NF Data Vault
Keine FK, PKFlat

DWH Reference Architecture PoC
Backend
Frontend
Cognos BI Cognos SPSS / R
Star Cognos Cubes
Data Vault
Keine FK, PKFlat

Information und Analytics Mart Layer
Ausgangssituation/Fragestellung im Projekt:
• Modellierung: Relationales Starschema mit In-Memory DB oder weiterhin
Nutzung von Cubes?
• Analysen / Reporting direkt auf Core Warehouse Layer möglich (=
performant)?

In-Memory … nicht neu
Datenbank Buffer Cache
Datenspeicherung auf RAM-Disk
Datenspeicherung auf SSD
OLAP In-Memory Cubes
Datenanalyse mit Qlikview, TM1, u.a.

In-Memory - Cache Latenz
Quelle: Brendan Gregg: “Systems Performance: Enterprise and the Cloud”
Flüchtig
Nicht flüchtig
„In-Memory“
Festplatte

Datenverteilung, z.B. partitionierte Umsatzdaten
In-Memory – Speicherhierarchien Kosten vs Nutzen
Festplatte SSD RAM
1/2015
2/2015
…
1/2013
…
12/2014
<= 12/2012
Wenig genutzte
Daten
Häufig genutzte
Daten

Spaltenorientierung … nicht ganz so neu
1993 1995 > 2004
KDB
Sybase IQ
(heute SAP)
Relational:
Monet
C-Store
Vertica
Greenplum
(Nicht-Relational:
BigTable
HBASE
Cassandra)

Spaltenorientierung: Speicherung Zeilen- vs Spalten
Id Name Geburtsdatum
1 Maier 1967
2 Schmitt 1980
3 Maier 1993
4 Berger 1980
5 Müller 1967
6 Maier 1970
7 Müller 1980
Spaltenorientierte Speicherung
1, Maier,
1967, 2
Schmitt,
1980, 3
Maier, 1993,
4, Berger,
1980, 5
Müller, 1967,
6, Maier,
1970, …
1, 2, 3, 4, 5,
6, 7, …
Maier,
Schmitt,
Maier,
Berger,
Müller,
Maier,
Müller, …
Zeilenorientierte Speicherung
Block / Page / In-Memory Unit

Zeilen- vs Spaltenorientierung: Vor und Nachteile
Zeilenorientierung Spaltenorientierung
Vorteile • Datensatz wird zusammen
abgespeichert
• Einfache/Performante
Updates und Deletes
• Select auf eine oder mehrere
Spalten liest keine unnötigen
Spalten
• Spalte kann als Index verstanden
werden
Nachteile • Es wird der gesamte
Datensatz gelesen – auch
wenn nur einzelne Spalten
benötigt werden
• Nach der Selektion muss ein
Datensatz aus den einzelnen
Spalten rekonstruiert werden
• Inperformante Datenänderungen
• Cache-Aufbau

Vorteil: Komprimierungsverfahren je nach Datentyp
Dictionary Encoding
• Zentrale Wörterbücher zur Kodierung.
Run-length Encoding
• Mehrfache Wiederholungen werden durch ein Anzahl-Attribut kodiert.
Null-Suppression
• Unterdrückung von Nullwerten.
Bit-Vector
• Kodierung von 0 bzw1 für eine vorhandene bzw. nicht vorhandene Ausprägung.

Vorteil: Data Skipping (Column Store Storage Index)
• Automatische Registrierung minimaler und maximaler Werte in einer IMU
• „Interner Index“: Ignorieren/Überlesen nicht relevanter Pages
Cache mit InMemory Units (IMU)
1,9,20,34,4,100,…Min: 1 Max: 100
22,1,19,34,4,10,…Min: 1 Max: 34
SQL-Abfrage
SELECT …
FROM …
WHERE spalte > 50
72,60,60,61,60,69,…Min: 60 Max: 72
32,44,30,50,50,…Min: 30 Max: 50
skip

Vorteil: SIMD-Prozessoren (Single Instruction Multiple
Data)
CPU
Vector
Register
z.B. where x=12
1
12
3
12
5
5
12
12
12
12
12
12
Cache (RAM)
1
12
3
12
5
5
12
12

Zusammenfassung Auswahl Konzepte
Spaltenorientierte
IM DB
RAM
(In-Memory)
Spalten-
orientierung
KomprimierungData Skipping
SIMD

Gliederung
Zusammenfassung

OLAP Cubes
Multidimensionales
Format

OLAP Cubes
• Multi-dimensionales Datenarray „Würfel“
• Fakten, Dimensionen, Hierarchien, Aggregate
• Eine Struktur ohne Joins
• Ziel: schnell / interaktiv
• KPIs (Kennzahlen) nötig + Dimensionen
• Typisch für BI Reporting, aber auch inflexibel
• Beladung meist mittels Batch
Kunde
Produkt
KPI
Umsatz

Cognos Dynamic Cubes
• In-Memory OLAP-Würfel, die Daten direkt aus relationalen DBs laden
• Voraussetzung: Star-Schema oder Snowfalke-Schema (Views möglich, aber
nicht empfohlen)
• In Cognos BI integriert– keine seperate Installation oder Lizenz
• Verschiedene Caches

Cognos Dynamic Cubes – Cache Hierarchie

Cognos Dynamic Cubes – Cache Hierarchie
Start Cube
• Member Cache wird komplett geladen
• Aggregate Cache wird komplett
geladen
Reporting/Daten-Analyse
• Weitere Caches werden nach Bedarf
geladen
• Sobald Cache voll ist, werden Daten
aus DB gelesen

Oracle
Das duale Format in der Datenbank

Oracle – Buffer Cache (row) and IMDB (columnar)
Quelle: Guy Harrison: “Next Generation Databases”

Gliederung
Zusammenfassung

Testszenario mit Oracle DB
Daten: 60GB komprimiert sowie RAM: 60GB
• Testlauf 1: Zeilenorientierte Speicherung „Baseline“ mit Basic compression
• Testlauf 2: Spaltenorientierte Speicherung „Vergleich“ mit Low compression
• Verschiedene parallele Abfragen (simulieren User-Parallität)
• 3 Datenmodelle

Testzenario – 3 Datenmodelle
Data Vault
Strukturierte
Modellierung
für das Core
Warehouse
Star
Fakten und
Dimensionen
typisch für
Data Mart
Layer
Flat
Flache
Tabelle =
MeinExcel

Testzenario – 3 Datenmodelle (Auszug Datenmodell)
Data Vault Star Flat

Testszenario – Abfragen (Beschränkung auf Standard-
Abfragen)
Typ 1
•Simuliert Report-Einstieg
•Keine where-Bedingung, Aggregation auf höchster Ebene
Typ 2
•Simuliert Drill Down von Typ 1
•1-2 where-Bedingungen
Typ 3
•Simuliert Drill Down von Typ 2
•3-4 where-Bedingungen
4 parallele Sessions
führen Abfragen aus in der Reihenfolge
Typ1->Typ2->Typ3->Typ3->Typ2->Typ3->Typ3
Verhältnis Häufigkeit Typ1:Typ2:Typ3 = 1:2:4

• Testlauf 1: Zeilenorientierte Speicherung „Baseline“ mit Basic
compression
• Testlauf 2: Spaltenorientierte Speicherung „Vergleich“ mit Low compression
• 3 Datenmodelle

0
10
20
30
40
50
60
70
Buffer Cache
Laufzeit (sek)
Buffer Cache
Größe (GB)
Testlauf 1: zeilenorientierte Speicherung, Cache
3 1 1 2 32

Testlauf 1: Bewertung
Ergebnis bestätigt die Erwartungen: Star Schema performant für Reporting
Star Schema (= empfohlene Modellierung für Standardreports im Data Mart)
• Klar beste Performanz und sehr gute Komprimierung (kleine Indexe)
Data Vault (eine mögliche Modellierung im Core Warehouse Layer)
• Schlechte Leseperformanz, da für Beladung optimiert
• Hash Keys verwendet, daher relativ großer Speicherverbrauch
Flat
• Hohe Datenmenge aufgrund großer Redundanz

• Testlauf 1: Zeilenorientierte Speicherung „Baseline“ mit Basic compression
• Testlauf 2: Spaltenorientierte Speicherung „Vergleich“ mit Low
compression
• 3 Datenmodelle

0
5
10
15
20
25
30
IMDB
Laufzeit (sek)
IMDB
Größe (GB)
Testlauf 2: spaltenorientierte Speicherung, Cache
3 2 1 1 23

Vergleich Testlauf 1 und Testlauf 2
0
5
10
15
20
25
30
35
40
45
Buffer Cache
Laufzeit (sek)
IMDB
Laufzeit (sek)
0
10
20
30
40
50
60
70
Buffer Cache
Größe (GB)
IMDB
Größe (GB)
Laufzeit Cache Größe

Testlauf 2: Bewertung 1(2)
Ergebnis (Anmerkung: Indexe gelöscht außer PK, UK, FK)
Star Schema
• Gute Performanz und gute Komprimierung
Data Vault
• Performanzverbesserung beim Lesen
Flat
• Beste Performanz in diesem Beispiel! Jedoch nicht unbedingt empfehlenswert
zukünftig so zu modellieren!

Testlauf 2: Bewertung 2(2)
• Testläufe sind nicht beliebig zu verallgemeinern, zeigen aber Vor/Nachteile auf. Es gibt auch
Ausreißer.
• Ergebnis stark abhängig von Anzahl Typ1 / Typ2 / Typ3 Abfragen
• Viele Typ3-Abfragen = gut für Spaltenorientierung und Flat-Tabellen
• Viele Typ1-Abfragen = geringer/kein Vorteil für Spaltenorientierung
• Testen, Testen, Testen bei Migration in eine spaltenorientierte In-Memory DB.
• Nicht immer Performanzvorteile
• Oft ist das Problem in der Anwendung und nicht in der DB

Gliederung
Zusammenfassung

• Data Vault Hub-Tabelle H_CUSTOMER mit Hash-Keys
• Schmale Tabelle mit eindeutigen Hash-Keys und eindeutigen Business-Keys
• Tabellen mit solchen Daten (nicht nur bezogen auf Data Vault) sind
ungeeignet für Dictionary-Compression
Ausreißer Komprimierung am Beispiel Hub-Tabelle
Größe in GB Verfahren
9 GB Buffer Cache, Basic compression
9.7 GB (größer!) IMDB, FOR QUERY LOW compression
8.4 GB IMDB, FOR QUERY HIGH compression

Allgemeine Faustformel
The greater the ratio of
the total data accessed by a query to
the data actually processed by the query,
the greater the potential benefit from IMDB.
Quelle: Oracle White Paper: When to use Oracle IMDB

Anzahl selektierter Spalten
Beschreibung Gut geeignet für
Spalten InMemory
Weniger geeignet für
Spalten InMemory
Je mehr Spalten abgefragt
werden, umso geringer ist der
Vorteil des spaltenorientierten
Zugriffs. Bei der
Modellierung im BI Tool
darauf achten, dass nicht
automatisch select *
verwendet wird
SELECT cust_name FROM
customer;
SELECT * FROM customer;

Anzahl zurückgelieferter Zeilen
Spalten InMemory
Spalten InMemory
Je mehr Zeilen zurückgeliefert
werden, umso geringer ist der
Vorteil des spaltenorientierten
Zugriffs, da die
Werteübergabe zum BI
Server und der
Berichtaufbau die
Performanz dominiert.
SELECT sum(revenue)
FROM sales;
SELECT revenue FROM
sales;

Komplexe SQL-Funktionen (Expressions)
Spalten InMemory
Spalten InMemory
Rechenintensive SQL-
Funktionen sind weniger
geeignet, da die Performanz
für die Berechnung benötigt
wird.
SELECT I.id,
sum(S.revenue)
FROM Sales S, Items I
WHERE S.item_id = I.id
AND
I.name LIKE “%LED%TV”
GROUP BY I.id;
SELECT I.id,
sum(S.revenue)
FROM Sales S, Items I
WHERE S.item_id = I.id
AND
MyMatch(I.name,”LED
TV”)=1
GROUP BY I.id;

DWH Reference Architecture PoC
Backend
Frontend
Cognos BI Cognos SPSS / R
Star Cognos Cubes
Data Vault
Keine FK, PKFlat

Use Case: Standardreporting
IMDB Cognos Dynamic Cubes (OLAP)
Skalierbar Skalierbar
Wenn IMDB-Cache voll, wird der
Buffercache verwendet
Nur Membercache und Aggregatecache
kritisch (alle Daten müssen reinpassen).
Faktendaten müssen nicht in den Cache
(Abhängigkeit von der DB-Performanz; IBM
empfiehlt Einsatz IMDB)
DML-Operationen verlangsamen Aktualität Kompletter Refresh: dauert täglich länger
mit größer werdender Datenmenge
(RealTime Differential Refresh möglich)

Use Case: Ad-hoc Reporting
• Cubes sind nicht für ad-hoc geeignet. OLAP Cubes setzen bekannte Abfragen
voraus, deren Daten zuvor festgelegt/implementiert werden müssen.

Use Case: Flexibilität und Virtualisierung
• Information / Analytics Mart Layer besteht nur aus Views auf Tabellen im
Core Warehouse Layer
• Einschätzung nach
Performanztests:
Vereinzelt machbar
mit guter Performanz

Gliederung
Zusammenfassung

OLAP Cubes / Cognos Dynamic Cubes
Use Cases werden weniger
• Sinnvoll bei rechenintensiven KPIs (Aggregation, Expression Cache)
• Sinnvoll, wenn Abfragen komplett feststehen (reines Standardreporting)
• Keine weitere Lizenz nötig sobald Cognos BI lizensiert
• Cognos Dynamic Cubes: Nicht alle Daten müssen im Cache gehalten werden
(nur Member + Aggregate)
• Zugriff auf DB bei Daten, die nicht im Cognos Cache sind
• Performanz schwankt, je nach DB-Performanz

OLAP, OLTP und OLTAP
OLAP
OLTP
OLTAP –
gemischte
Workloads
• großes Potential für spaltenorientierte In-Memory DBs
• auch mit reinen Views als Data Marts denkbar („Datenvirtualisierung“)
• vereinzelt sinnvoll, z.B. große Stammdatentabellen
• große Herausforderung in der Vergangenheit
• Potential für spaltenorientierte In-Memory DBs
• aber: gegenläufiger Trend Microservices = „kleinere“ DBs

One size does not fit all
„In 10 years there will be no row
stores in the data warehouse world.“
Quelle: Stonebreaker, O'Reilly webcast http://radar.oreilly.com/2015/06/the-future-of-data-at-scale.html

Vielen Dank!
Daimler TSS GmbH
Wilhelm-Runge-Straße 11
89081 Ulm
Telefon +49 731 505-06
Fax +49 731 505-65 99
tss@daimler.com
Internet: www.daimler-tss.com
Daimler TSS GmbH
Sitz und Registergericht: Ulm, HRB-Nr.: 3844
Geschäftsführung: Dr. Stefan Eberhardt (Vorsitzender), Steffen Bäuerle
Jobportal
https://jobs.daimler-tss.de/PORTAL/jobs.html
z.B.:

In-Memory: IBM, Microsoft, Oracle, SAP 1(3)
SQL Server IBM DB2 BLU Oracle IMDB SAP HANA
Ersteinführung 07/2014 06/2013 04/2014 10/2010
Befehl zur
Erzeugung der
spaltenorienti
erten Tabelle
Create index … Create table … Eigenschaft
einer Tabelle
Create table …

Datenkomprim
ierung
Ja Ja Ja Ja
Data Skipping Ja Ja Ja Ja
Datenhaltung • Zeilen (In-
Memory
Organized
Tables)
• Spalten
(Columnstor
e Index)
• Zeilen und
Spalten
(Column-
organized
Tables oder
Schattentab
ellen)
• Zeilen und
Spalten
simultan
(BufferCache
für Zeilen)
• Zeilen und
Spalten
(Spalten
präferiert)

In-Memory
Analytics / R
Ja Nein Ja Ja
Persistenz
Columnstore
Ja Ja Nein Ja
Aggregate
Pushdown
Ja (ab 2016) Ja
Limitierung
durch RAM
Nein Nein Nein Nein (nicht
mehr)
SIMD Ja Ja Ja Ja

1 Technologie - 4 Hersteller – 4 Implementierungen
Spaltenorientierte
IM DB
RAM
(In-Memory)
Spalten-
orientierung
KomprimierungData Skipping
SIMD

SAP HANA
Aufhebung Trennung operative
(OLTP) und analytische (OLAP)
Workloads

Workload OLTP und OLAP
Quelle: http://www.vldb.org/pvldb/vol5/p061_jenskrueger_vldb2012.pdf

SAP Hana
Eine Tabelle ist
entweder
zeilenorientiert
oder
spaltenorientiert.Row Store
Column Store Delta L2 Delta L1
Select + DML
DML
Select
Logs Snapshots

IBM DB2 BLU
Seven Big Ideas

IBM DB2 BLU – 7 Big Ideas
Big Idea 1: Simplicity and ease of use
Big Idea 2: Column store
Big Idea 3: Adaptive compression
Big Idea 4: Parallel vector processing (SIMD)
Big Idea 5: Core-friendly parallelism
Big Idea 6: Scan-friendly memory caching
Big Idea 7: Data skipping

IBM DB2 BLU – Variante 1: OLAP
Eine Tabelle ist
entweder
zeilenorientiert
oder
spaltenorientiert.

IBM DB2 BLU – Variante 2: OLTAP (Schattentabellen)
Eine Tabelle ist
zeilenorientiert
und
spaltenorientiert.

MS SQL Server
Dedizierte In-Memory stores für
OLTP und OLAP

MS SQL Server – NonClustered Columnstore Index
Eine Tabelle
(„Index“) ist
zeilenorientiert
und
spaltenorientiert.

MS SQL Server – Clustered Columnstore Index
Eine Tabelle
(„Index“) ist
entweder
zeilenorientiert
oder
spaltenorientiert.

Oracle
Das duale Format in der Datenbank

Oracle – Buffer Cache (row) and IMDB (columnar)
Row Store Column Store
Logs Datendateien
Eine Tabelle ist
zeilenorientiert
und
spaltenorientiert.
Row Store
DML
Select

Cognos Cube Technologien

RDBMS vs OLAP vs IMDP
Datenmodell Abfrage-
Sprache
Interaktion Vorteile
RDBMS Star-Schema SQL Abfrage und
Antwort
Skalierbar
Flexibel
OLAP Cube MDX Interaktiv Performant
IMDB Star-Schema
Oder andere
relationale
Form
SQL Interaktiv Skalierbar
Flexibel
Performant
RDBMS (In-Memory) nähert sich OLAP Cubes an (interaktiv, schnell)

Selektivität von Join-Bedingungen
Spalten InMemory
Spalten InMemory
Selektive Join-Bedingungen
nutzen den Vorteil des
schnellen Filterns von Daten.
SELECT
S.id, P.name, S.revenue
FROM
Sales S, Products P
WHERE
S.prod_id=P.id AND
P.type=‘Footwear’;
SELECT
Si.d, S.revenue, P.name
FROM
Sales S,Products P
WHERE
S.prod_id=P.id;

Anzahl der Tabellen im Join
Spalten InMemory
Spalten InMemory
Je größer die Anzahl der
Tabellen im Join ist, umso
geringer ist der Vorteil, da die
Performanz für den Join
benötigt wird.
Aber typisch im Reporting!
SELECT <select list>
FROM Sales, Products,
Customers
WHERE <join condition>
SELECT <select list>
FROM Sales, Products,
Customers, Shipments,
Stores, Suppliers,
Warehouses
WHERE <Join Condition>

Selektivität von Spalten-Prädikaten
Spalten InMemory
Spalten InMemory
Selektive Prädikate
nutzen den Vorteil des
schnellen Filterns von
Daten.
SELECT MEDIAN(revenue)
FROM Sales
WHERE revenue < 2;
Vorteilhaft, da weniger Zeilen
und dadurch weniger Daten für
die Median-Berechnung nötig
sind.
SELECT MEDIAN(revenue)
FROM Sales
WHERE revenue > 2;

OLTP - Mögliche Anwendungsfälle
Sinnvoll bei
• Größeren Stammdatentabellen
• Weniger Indexe
• Vermeidung ständiges Tuning dieser Tabellen
• Klassiker: Adress-Suche (siehe folgendes Beispiel)

Klassiker: Adress-Suche
Kunden-Tabelle Adress-Tabelle
Kundennummer Ort
Vorname PLZ
Nachname Straße
Geburtsdatum Kundennummer
etc etc

Herausforderung Suchabfrage: Müller AND Berlin
Buckenhofer: ca. 100
Müller: ca. 700.000
Berlin: ca. 3.5 Mio
Dornstadt: ca. 8.500
Buck
enho
fer
Berlin Müller Dornst
adt
Müller Berlin
21 12
? ?
1 2 = Reihenfolge der Abarbeitung / Joins
Kleine Tabelle zuerst

Lösungsansätze Adress-Suche
• Materialized Views
• Text Index
• Bitmap Join Index
• Index Backbone Join: Patent US8103658 (Lothar Flatz, Bjorn Kisbye Engsig)
http://www.google.com/patents/US8103658
• Spaltenorientierte In-Memory DB

Zusammenfassung Konzepte
Rohdaten Komprimierung Spalten Skipping SIMD

Caching: In-Memory Column Store oder im BI Server

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (17)

Ähnlich wie Caching: In-Memory Column Store oder im BI Server

Ähnlich wie Caching: In-Memory Column Store oder im BI Server (20)

Caching: In-Memory Column Store oder im BI Server