5.4 Benchmarks für Data Warehouses

Transkript

1 5.4 Benchmarks für Data Warehouses Benchmark ( Massstab ) zum Vergleich der Leistungsfähigkeit von Systemen Für Datenbanken: Serie von Benchmarks des Transaction Processing Performance Council ( TPC-C: klassischer OLTP Benchmark TPC-E: ecommerce Benchmark (ebenfalls mit OLTP-Charakteristik) TPC-H: Ad-hoc Decision Support (Data Warehousing) Vorgegeben sind jeweils Schemata Schema-, Query- und Datengeneratoren Messungen erfolgen mit unterschiedlichen Datenbank-Grössen 5-77 TPC-C Benchmark System-Performanz mit OLTP-Workload Simultane Ausführung einer Mischung aus lese- und schreibintensiven Transaktionen Viele konkurrierende Benutzer On-line und asynchrone Ausführungen ormale CPU-Last, aber starke Disk-I/O ACID Eigenschaften Metrik: transactions-per-minute-c (tpmc) Anzahl der orders bearbeitet pro Minute business throughput 5-78

2 TPC-C-Schema Remote-W W * 0 Warehouse W District W * 0 Die Zahlen in den Entitätstypen geben die Kardinalitäten der einzelnen Tabellen (# Tupel) an Stock History W * 30k+ Customer W * 30k + bedeutet variable Grösse (Tupel werden während des TPC-C Durchlaufs neu erzeugt) W * 00k Skalierung de gesamten Datenbank erfolgt über die Anzahl Entitäten im Entitätstyp Warehouse (W) Item OrderLine W*2700k+ Order W*90k+ 00k eworder W*9k TPC-C Transaktionen 0/23 0/23 /23 Customer-Inquiry Customer-Inquiry Customer-Inquiry ew-order Payment Order-Info. Select txn from menu:. ew-order n/a 2. Payment 43% 3. Order-Status 4 % 4. Delivery 4 % 5. Stock-Level 4 % /23 Customer-Inquiry 2 /23 Stock-Info. 3 Input screen Emulierter Benutzer wählt zufällig eine Transaktion aus Delivery-Transaktion läuft asynchron (als Batch) Vorgegebene Verteilung 80:20 read-write Output screen Go back to

3 TPC-C Benchmark-Resultate nach Performance Stand: 05/200, Quelle: Transaction Processing Performance Council, TPC-H: Schema Der TPC-H-Benchmark bildet eine Data Warehousing-Umgebung nach Messungen in TPC-H erfolgen mit den folgenden Grössen: 00 GB 300 GB TB 3 TB 0 TB 30 TB PART REGIO ATIO SUPPLIER PARTSUPP REGIO ATIO CUSTOMER ORDERS LIEITEM

4 SELECT FROM WHERE AD AD GROUP BY ORDER BY TPC-H: Beispiel einer Anfrage c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, SUM(l_quantity) customer, orders, lineitem o_orderkey I (SELECT l_orderkey FROM lineitem GROUP BY l_orderkey HAVIG SUM(l_quantity) > :) c_custkey = o_custkey o_orderkey = l_orderkey c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice o_totalprice desc, o_orderdate; 5-83 TPC-H: Benchmark-Resultate (3 TB) Stand: 05/200, Quelle: Transaction Processing Performance Council,

5 TPC-H: Benchmark-Resultate (0 & 30 TB) Stand: 05/200, Quelle: Transaction Processing Performance Council, Column Stores für Data Warehousing Klassische relationale Datenbanken verwenden 'Row Stores' Speicherung kompletter Tupel auf Datenbankseiten Optimiert für OLTP-Anwendungen Kurzlebige ACID-Transaktionen Schreiben / Ändern gesamter Tupel / g p Kunden Kr ame Stadt Saldo Rabatt 0 Legrand Genf - 080, Marty Basel -8 00, Frei Basel 0,00 0,0 04 Janvier Genf 0,00 0,0 05 Rossi Lugano 0,00 0,05 06 Meier Zürich ,00 0,05 07 Hürlimann St. Gallen -00,00 0,05 08 Schmid Luzern ,00 0,0 09 Müller-Lüdenscheid Zürich -550,00 0,00 0 Schumacher Genf ,00 0,20 Datenseiten

6 Column Store Column Store-Datenbanksysteme Wenige Änderungen Optimiert für (langlebige) Leseanwendungen (OLAP), nur bedingt geeignet für Updates Kunden Kr ame Stadt Saldo Rabatt 0 Legrand Genf - 080, Marty Basel -8 00, Frei Basel 0,00 0,0 04 Janvier Genf 0,00 0,0 05 Rossi Lugano 0,00 0,05 06 Meier Zürich ,00 0,05 07 Hürlimann St. Gallen -00,00 0,05 08 Schmid Luzern ,00 0,0 09 Müller-Lüdenscheid Zürich -550,00 0,00 0 Schumacher Genf ,00 0,20 FS 200 Datenseiten Data Warehousing (CS242) Data Warehousing 5-87 C-Store C-Store: Beispiel eines Column Store-Systems Writeable Store: erlaubt beliebige Insert und Update-Operationen Read-Optimized Store: Einzige erlaubte Schreiboperation ist Batch-Update aus Writeable store (= lazy replication) Tuple Mover: führt Batch-Update durch Relationenmodell als logisches Datenmodell, SQL an der Schnittstelle Physische Speicherung: Projektionen einzelner (oder mehrerer) Attribute Writeable Store (WS) Tuple Mover Read-optimized Store (RS)

7 C-Store: Read-Optimized Store Einzelne Attribute können (in unterschiedlichen Projektionen) mehrfach im Readoptimized Store gespeichert werden Für jede Projektion wird ein Sort Key angegeben (das Attribut, nach dem die Projektion sortiert wird) Jede Projektion wird horizontal partitioniert in mehrere Segmente. Jedes Segment ist durch einen Segment Identifier (Sid) gekennzeichnet. Also enthält jedes Segment einer Projektion ein Intervall des Sort Keys Tabelle ame Age Dept Salary Projektion P Sort key SID ame 2 Dept Key range Segmente 3 P2 ame Sort key Salary Sort key P3 Age Salary Logische Repräsentation 5-89 C-Store: Read-Optimized Store Die einzelnen Attribute jedes Segments sind durch einen Storage Key (SK) gekennzeichnet Die Verknüpfung zu weiteren Attributen desselben Tupels erfolgt über spezielle Join-Indexe Annahme: P (M Segmente) und P2 ( Segmente) sind Projektionen derselben Relation Join-Index besteht aus M Tabellen (eine pro Segment von P) Eintrag im Join-Index für P-Segment S P enthält für jeden Eintrag von S P einen Verweis auf die zugehörigen Einträge in der Projektion P2 Dieser Verweis besteht aus dem Segment Identifier Sid und dem Storage Key (SK) innerhalb des Segments Join-Indexe stellen also nur eine unidirektionale Verbindung zwischen Projektionen her

8 C-Store Join-Index Segment S P,i : i-tes Segment von Projektion P S P,i ame SK Dept ame Salary S P2,j S P2,j+2 Join-Index für Segment S P,i ame Salary SID SK S P2, j 3 S P2, j Weitere Column Store-Systeme Google s Bigtable Verwendet Projektion und Segmentierung Verteilung der Segmente auf mehrere Rechner Basiert auf GFS (Google File System) Vertica Kommerzielle Implementierung der C-Stores MonetDB Forschungsprototyp, CWI Amsterdam Sybase IQ Erstes kommerzielles Column Store-System und viele weitere mehr (Open Source & kommerziell)

9 Literatur [BG 09] A. Bauer, H. Günzel (Hrg.): Data Warehouse Architektur, Entwicklung, Anwendung; dpunkt.verlag, 3. Auflage, [GCB + 97] J. Gray et al.: Data Cube: A relational aggregation operator generalizing group-by, cross-tab, and sub-totals. In: Data Mining and Knowlegde Discovery, 29-53, 997. [Inm 96] W. Inmon: Building the Data Warehouse, John Wiley & Sons, 996 [Leh 03] W. Lehner: Datenbanktechnologie für Data-Warehouse-Systeme, dpunkt.verlag,