Benchmarks TPC-H
Der TPC Benchmark H ("TPC-H") ist ein Benchmark im Bereich Decision-Support, der aus einer fest definierten Datenbank und einer Reihe von Business-orientierten ad-hoc Queries mit gleichzeitiger Datenveränderung besteht.
Die Abfragen und Daten in der Datenbank repräsentieren Daten eines Unternehmens aus der Einzelhandelsbranche mit dessen typischen Fragestellungen.
Die TPC-H Queries geben Antworten auf reelle Fragen aus dem Geschäftsleben. Sie simulieren generierte ad-hoc Queries (z.B. mit Hilfe eines BI-Tools) und beinhalten ein breites Spektrum von Operatoren und Selektivitätskriterien. Dabei wird eine intensive Workload auf dem Datenbanksystem generiert.
Rahmenbedingungen
Der Benchmark repräsentiert ein Data Warehouse, für welches bestimme Annahmen vorausgesetzt wurden:
- Die Datenbank muss für mehrere Endnutzer und Prozesse durchgängig verfügbar sein (24x7). Die Ausnahme bildet ein Wartungsfenster pro Monat.
- Aus einem operativen System werden periodisch aktuelle Daten geliefert. Dieses Update (Refresh-Funktion) bündelt eine ganze Reihe an Modifikationen, die einen Teil der Datenbank verändern.
- Durch den internationalen Charakter der Geschäftsdaten, die in der TPC-H Datenbank gespeichert sind, sollen Anfragen und Refresh-Funktionen auf der Datenbank jederzeit ausgeführt werden können, insbesondere gleichzeitig und ohne, dass die ACID-Anforderungen verletzt werden.
- Um einen optimalen Kompromiss zwischen Performance und operativen Anforderungen zu erreichen, kann ein DBA einmalig Locking Level und Scheduling Regeln für Queries und Refresh-Funktionen setzen.
Die kleinste Datenbank verwaltet geschäftsrelevante Daten von 10000 Lieferanten. Diese Datenbank besteht insgesamt aus ca. 10 Mio Zeilen, was einer Rohdatenmenge von ca. 1GB entspricht.
Die Abfragen sind sehr typisch und werden in ähnlicher Form in vielen Unternehmen verwendet. Wichtige Charakteristika des Benchmarks sind Komplexität der Anfragen und großes zu verarbeitendes Datenvolumen. Durch den ad-hoc Charakter des Tests können und dürfen von Administratoren keine Vorberechnungen durchgeführt werden.
Schema
Der TPC-H Benchmark kann in verschiedenen Größenkategorien ausgeführt werden, von 1 GB bis 30 TB.
Die Anzahl Zeilen in den Tabellen wird dabei in Abhängigkeit zur Benchmarkgröße in GB gesetzt. So, enthält die Tabelle LINEITEM im 1 TB Test 1.000*6.000.000 = 6 Mrd. Zeilen. Im 10 TB Test sind das bereits 60 Mrd. Zeilen, die verarbeitet werden müssen. Beim Vergleich mit realen Datenbanken sollte unbedingt beachtet werden, dass im TPC-H keinerlei historische Daten vorhanden sind und somit alle Daten ausgewertet werden.
Minimum Cost Supplier: Komplexitätstest
Query 2 ist ein klassisches Beispiel eines Einzelhändlers, der einen Hersteller gegen den anderen ausspielt, um den besten Abgabepreis zu erhalten. Wenn es mehrere Hersteller gibt, die den gleichen Produkttyp (part type und size) anbieten, werden die Produkte der Hersteller mit den 100 höchsten Umsätzen aufgelistet.
Technisch gesehen bildet diese Query mit ihrem Join von 5 Tabellen und einer korellierten Subquery die Komplexitätsanforderung zusammen mit der Analyse von großem Datenvolumen ab.
Query 2: Minimum Cost Supplier
-
- SELECT
- s_acctbal,
- s_name,
- n_name,
- p_partkey,
- p_mfgr,
- s_address,
- s_phone,
- s_comment
- FROM
- part,
- supplier,
- partsupp,
- nation,
- region
- WHERE
- p_partkey = ps_partkey
- AND s_suppkey = ps_suppkey
- AND p_size = 28
- AND p_type LIKE '%COPPER'
- AND s_nationkey = n_nationkey
- AND n_regionkey = r_regionkey
- AND r_name = 'AFRICA'
- AND ps_supplycost = (
- SELECT
- MIN(ps_supplycost)
- FROM
- partsupp,
- supplier,
- nation,
- region
- WHERE
- p_partkey = ps_partkey
- AND s_suppkey = ps_suppkey
- AND s_nationkey = n_nationkey
- AND n_regionkey = r_regionkey
- AND r_name = 'AFRICA'
- )
- ORDER BY s_acctbal DESC, n_name, s_name, p_partkey
- LIMIT 100;
"WAS-WÄRE-WENN"-Analyse auf großem Datenvolumen
Große Table Scans sind im Data Warehousing Alltag insbesondere für ad hoc Analysen kritisch. Query 6 verknüpft keine Tabellen, sie adressiert vielmehr eine große Tabelle (LINEITEM) und selektiert ca. 12% aller Zeilen. Sie gibt einen Wert zurück, der eine potenzielle Umsatzsteigerung subsummiert.
Diese Query stellt eine typische "WAS-WÄRE-WENN"-Analyse dar und berechnet den Umsatz, der erzielt werden könnte, wenn es bestimmte Discounts nicht geben würde. Es werden hier alle Artikel (LINEITEM) betrachtet, die im gegeben Jahr mit einem Rabatt zwischen 2% und 4% verkauft wurden. Die Query berechnet den möglichen Umsatz, wenn die entsprechenden Rabatte nicht angewandt würden, wenn die Anzahl der verkauften Einheiten < 25 ist.
Solche Queries werden ebenfalls oft in der Telekommunikationsbranche verwendet, um festzustellen, welcher Umsatz generiert werden kann, wenn bestimmte Tarifoptionen nicht angeboten werden. Die Berechnung basiert dann an den in der Call Detail Record Tabelle enthaltenen Daten über die Gesprächsdauer und -ziel.
Query 6: Forecasting Revenue Change
-
- SELECT
- SUM(l_extendedprice * l_discount) AS revenue
- FROM
- lineitem
- WHERE
- l_shipdate >= DATE '1997-01-01'
- AND l_shipdate < ADD_MONTHS( DATE '1997-01-01' , 12)
- AND l_discount BETWEEN 0.02 AND 0.04
- AND l_quantity < 25;
Effektivität einer Kampagne bestimmen
Query 14 adressiert eine der Schlüssel-Businessfragen: "Wie effektiv waren Kampagnen wie z.B. Mailing oder TV-Werbung?" Interessant ist auch, dass diese Fragestellung weitestgehend branchenunabhängig ist.
Hier werden 2 Tabellen verknüpft, wobei die Analysebasis auf 1 Monat (von insgesamt 7 Jahren) beschränkt wird. Die Query bestimmt, welcher Anteil des Umsatzes aus Kampagnen stammt. Umsatz wird hier als (l_extendedprice * (1-l_discount)) definiert.
Aus unserer Kundenerfahrung ist es insbesondere für Retail-Firmen enorm wichtig, die Responsrate von Kampagnen zu bemessen. Erfolg verspricht hier die Analyse des tatsächlichen Bestellverhaltens auf Einzelpositionsebene. Oft wird man anschließend mit Hilfe von Query 14 Unterschiede im zweistelligen Prozentbereich zu allgemeinen Kampangnen feststellen können.
Query 14: Promotion Effect Query
-
- SELECT
- 100.00 * SUM(CASE
- WHEN p_type LIKE 'PROMO%'
- THEN l_extendedprice * (1 - l_discount)
- ELSE 0
- END) / SUM(l_extendedprice * (1 - l_discount)) AS promo_revenue
- FROM
- lineitem,
- part
- WHERE
- l_partkey = p_partkey
- AND l_shipdate >= DATE '1995-01-01'
- AND l_shipdate < ADD_MONTHS( DATE '1995-01-01', 1);
Benchmark-Durchführung und Ergebnis
Der Benchmark selbst besteht aus drei Bausteinen: initiale Beladung, Power-Test und Throughput-Test.
Die initiale Beladung startet mit der Erstellung der Datenbank und schließt alle Aktivitäten ein, die notwendig sind, um die späteren Performancetests auszuführen. Während dieser Phase dürfen keine Queries ausgeführt werden, die denen aus dem Performancetest ähneln. Die Zeit bzw. der Aufwand der Beladung geht nicht in die Benchmarkwertung ein.
Der Performancetest selbst besteht aus 2 Läufen, die jeweils den Power-Test und Throughput-Test beinhalten. Power- und Throughput-Test gehen jeweils zusammen in eine Wertung ein, von den beiden Läufen zählt die schlechtere Wertung dann als entgültiges Testergebnis. Dies liefert eine konservative Bewertung der Systemperformance und schließt Vorteile durch Caching-Effekte weitgehend aus.
Während des Power-Tests werden alle Queries von einem Nutzer nacheinander ausgeführt. Der Test bewertet damit die reine Rechenpower des Systems, basierend auf dem geometrischen Mittel der Einzellaufzeiten. Vor und nach der Ausführung des Powertests wird die Datenbank upgedated, so dass ein Caching von Ergebnissen das Messergebnis nicht beeinflussen kann.
Währen des Throughput-Tests werden alle Queries von jeweils mehreren Nutzern ausgeführt. Parallel dazu laufen Refresh-Funktionen, so dass die Systembeladung gleichzeitig zur Queryausführung getestet werden kann. Die Anzahl der konkurrierenden Nutzer kann frei gewählt werden und fliesst in die Bewertung ein, welche hier auf der Gesamtlaufzeit (Start erste Abfrage bis Ende letzte Abfrage) basiert.
Die Ergebniszahl wird als eine TPC-H Composite Query-per-Hour Performance Metrik (QphH@Size) berechnet und bildet mehrere Systemeigenschaften in Bezug auf Queryausführung ab. Die TPC-H Mertik Price/Performance wird als $/QphH@Size abgebildet.
Die Einhaltung der Benchmarkregeln und die Ausführung selbst wird von einem Mitarbeiter des TPC-Konsortiums überwacht, Ergebnisse dürfen nicht ohne Prüfung veröffentlicht werden. Die endgültige Veröffentlichung enthält einen genauen Bericht, der das genutzte System vollständig beschreibt, inklusive der eingesetzten Hardware und Tuning-Maßnahmen.
3 TB Ergebnisse
Konfiguration:
- EXASolution 2.1
- Cluster aus 80 Fujitsu Siemens Computers PRIMERGY RX300 S4 Servern
- Intel® Xeon® X5460, 3,16 GHz Quadcore-Prozessoren
