Ausarbeitung im Fach Datenbanken II

Transkript

1 Ausarbeitung im Fach Datenbanken II Datenbanken Benchmarks Michael Heinrich IN05

2 Inhalt OLTP... 3 OLAP / Decision Support... 4 Decision Support System... 4 Online Analytical Processing... 4 Benchmark... 5 TPC... 6 TPC A... 7 TPC B... 8 TPC C... 9 TPC E TPC H Quellen

3 OLTP OLTP [1] ist die Abkürzung für Online Transaction Processing und steht für die Verwendung von Datenbankensystemen im Hinblick auf die Verarbeitung von Transaktionen. Im Vordergrund stehen die Lese und Schreibtransaktionen auf der Datenbank. Dabei geht es um Daten die häufigen Änderungen unterliegen, wie zum Beispiel die Verarbeitung von Daten mit denen eine Firma tagtäglich arbeiten muss, also das Verwalten von Aufträgen, Abfragen und Änderungen. Allgemein werden diese Anwendungen als operationales Tagesgeschäft oder Geschäftsprozesse eines Unternehmens bezeichnet. Wichtige Merkmale von OLTP Systemen sind Transaktionssicherheit bei parallelen Anfragen Minimierung der Antwortzeit von Anfragen Datendurchsatz Wahrung der Konsistenz der Daten nach dem ACID Prinzip Mit Datendurchsatz ist die Anzahl von Transaktionen pro Zeiteinheit gemeint. ACID steht für Atomarität (atomicity) Konsistenz (consistency) Isoliertheit (isolation) Dauerhaftigkeit (durability) und spielt eine Rolle bei allen Datenbankenmanagementsystemen und verteilten Systemen. [2] Weitere Anwendungen [1] sind Content Management Wissensdatenbanken Webshops Verzeichnisdienste 3

4 OLAP / Decision Support Decision Support System (engl. Entscheidungsunterstützungssystem ) Ein Decision Support System hilft Spezialisten, z.b. Beratern und Manager eines Unternehmens, die Planung von Vorgehensweisen auf der Basis von gesammelten Daten zu begründen und zu entscheiden. Auf diesen Daten können durch mathematische Methoden und Modelle Berechnungen, Statistiken und ähnliches erstellt werden, die Möglichkeiten zum weiteren Verlauf des Unternehmens aufzeigen und Stärken bzw. Schwächen aufdecken können. [3] Online Analytical Processing OLAP wird zur Analyse von Unternehmensdaten verwendet. Ziel ist es aus mehrdimensionalen Daten verschiedene Dimensionen zu erstellen und zusammen zu fassen, um daraus Informationen abzuleiten, die Entscheidungen unterstützen können. Die Analysefunktionen können durch den Entscheidungsträger selbstständig eingesetzt werden, ohne dass Fachpersonal mit speziellen Programmierkenntnissen diese erstellen muss [4]. Besagte Zielgruppe wäre vor allem das Management eines Unternehmens, das durch OLAP als System für Decision Support unterstützt werden soll [5]. Die Daten können aus den operationalen Datenbeständen eines Unternehmens oder einem Data Warehouse bezogen werden. Im Vordergrund stehen komplexe Anfragen, die den Datenbestand analysieren. Im Unterschied zu OLTP Anfragen wird durch die Komplexität ein hohes Datenaufkommen erzeugt [5]. Die OLAP zugrunde liegende Struktur ist ein Data Cube, der aus der operationalen Datenbank erstellt wurde. Dieser ist meist nach dem Sternschema aufgebaut: mit einer Faktentabelle und den jeweiligen Dimensionstabellen [5]. 4

5 Wie aus den Beschreibungen der einzelnen Varianten von Datenbanksystem hervorgeht, sind sie in der Art und Weise wie sie verwendet werden sehr unterschiedlich. Auf der einen Seite steht das schnelle parallele Ausführen von einfachen Transaktionen auf kurzlebigen Datenbeständen und auf der anderen komplexe Analysen auf Daten, die einen längeren Zeitraum gesammelt, quasi archiviert wurden und bei der Auswertung ein hohes Datenaufkommen verursachen. Daraus lässt sich ableiten, dass die Systeme, die diese Anwendungen zulassen, sehr unterschiedlich aufgebaut und konfiguriert werden können, um die Anforderungen bestmöglich zu erfüllen. Das heißt für eine vergleichende Analyse dieser Systeme müssen unterschiedliche Richtlinien herangezogen werden. Ein Vergleich zwischen verschiedenen Systemen zieht man am besten, indem man unabhängige Benchmarks durchführt. Benchmark Benchmark (engl. Maßstab ) oder Benchmarking (engl. Maßstäbe setzen ) Ein Benchmark ist eine vergleichende Analyse mit einem festgelegten Referenzwert. Benchmarking ist in vielen verschiedenen Gebieten mit unterschiedlichen Methoden und Zielen angewendet. Es ist ein systematischer und kontinuierlicher Prozess des Vergleichens von Produkten, Dienstleistungen und Prozessen. Erstellt werden sie oft, um die eigenen Systeme mit dem Referenzwert zu vergleichen und daraus Stärken und Schwächen abzuleiten [6][7]. Für den Vergleich der verschiedenen Datenbanksysteme werden also Benchmarks benötigt, die möglichst System unabhängig sind und für alle, die eine gewisse Grundfunktionalität bieten, durchführbar sein müssen. Diese Benchmarks zu erstellen hat sich eine Organisation auf den Leib geschrieben, die sich TPC nennt. Bevor die Benchmarks von TPC erschienen sind, wurden vor allem Hersteller eigene Benchmark Ergebnisse veröffentlicht, also z.b. von IBM, und teilweise auch deren öffentlich gemachte Varianten (TP1 [8]). Problem an diesen war das liegt in der Natur der Sache geringe Aussagekraft im Vergleich mit anderen Systemen mit anderer Soft und Hardware. Aus diesem Grund wurde die TPC 1989 gegründet und schuf seitdem einige Standard Benchmarks, die eine objektivere Bewertung der Systeme möglich macht und einen ersten Anlaufpunkt bei der Konzipierung von Datenbanksystemen im Bereich OLTP/OLAP darstellen. 5

6 TPC TPC ist die Abkürzung für Transaction Processing Performance Council Das TPC wurde 1989 als gemeinnützige Organisation gegründet, mit dem Ziel allgemeingültige Benchmarks für Transaktionssysteme und DBMS zu entwerfen und zur Verfügung zu stellen. Heute gehören alle namhaften Systemhersteller dieser Organisation an. Einige Beispiele [11] sind HP Fujitsu Siemens Oracle IBM Benchmarks von TPC werden stets mit dem Kürzel TPC * bezeichnet. [10] Es folgt ein Überblick zu einigen TPC Benchmarks Allgemein zu allen Benchmarks muss angemerkt werden, was das Preis/Leistungsverhältnis bedeutet. Gemeint ist jeweils, was es kostet das erreichte Benchmark Ergebnis zu ermöglichen. Berechnet werden die Kosten der eingesetzten Soft und Hardware, sowie die Wartung des Systems für einen Zeitabschnitt von 5 Jahren. 6

7 TPC-A TPC A ist das erste Benchmark, was von der TPC 1989 herausgegeben wurde. Es soll ein einfaches OLTP System darstellen. Einfach insofern, dass es nicht ein wirkliche OLTP Anwendung simuliert, sondern nur Teile daraus aufgreift und diese anwendet. Zum Beispiel ist eine normale OLTP Anwendung darauf ausgelegt ein Datenbanksystem häufig mit vielen parallelen Anfragen zu konfrontieren, die jeweils eine unterschiedliche Komplexität besitzen. Ziel ist die schnellstmögliche Beantwortung der Anfragen. Daher wird in diesem Benchmark gemessen wie viele Transaktionen das System pro Sekunde bearbeiten kann und was es kostet diese Leistung zu erreichen. Das System wird mit einer einfachen Schreibtransaktion (update) unter Last gesetzt und die Anzahl der bearbeiteten Transaktionen gemessen. Das Benchmark kann von mehreren Rechnern aus parallel gestartet und angewendet werden. Gemessen wird in tpsa (Transaktionen pro Sekunde) und Preis/tpsA (Preis/Leistung). Da dieses Benchmark 1995 für veraltet erklärt wurde, gibt es keine Statistiken mehr. Es wird nicht empfohlen dieses Benchmark weiter zu verwenden. 7

8 TPC-B TPC B ist in derselben Zeit wie TPC A entstanden. Es gibt Ähnlichkeiten bei den Profil und Datenbankschemata, jedoch können die Ergebnisse nicht verglichen werden, da TPC B andere Anwendungen des Systems testet. Gedacht ist es für Anwender die Batch Anwendungen von Datenbankmanagementsystemen oder back end Datenbanken einsetzen wollen. Mit Batch Anwendungen sind Programme gemeint, die zum Beispiel über Nacht laufen, also zu Zeiten von geringer Belastung der Datenbank, und mit den Daten der Datenbank arbeiten. TPC B besteht aus verschiedenen Benchmark Programmen, die direkt auf dem System, dass das DBS ausführt, gestartet werden können und ein Stresstest für das komplette System in Gang setzen. Dabei setzt jedes dieser Programme, ohne die Simulation einer realitätsnahen OLTP Umgebung, Transaktionen ab. Das heißt es wird zum Beispiel nicht wie in moderneren Benchmarks von einer Bedenkzeit für Folgeanfragen von einem bestimmten Nutzer ausgegangen, sondern ohne Pause werden hintereinander Anfragen gestellt, auf die Antwort gewartet und neue angestoßen. Dabei wird gemessen zu wie vielen Transaktionen das System in der Lage ist. Sinnvoll ist dieser Benchmark auf Systemen, die viele verschiedene Transaktionen verarbeiten sollen und bei denen der maximale Durchsatz interessant ist. Es belastet alle Systemkomponenten (CPU, RAM, Laufwerke) stark, da zum einen die erwähnten Wartezeiten fehlen und zum anderen Softwarekomponenten, wie das Betriebssystem und der Datenbank Manager getestet werden. Das System muss bei dieser Ausführung ständig zwischen den Prozessen umschalten und ist so gezwungen die Balance zu finden. Für TPC B sind zusätzlich Tests zu der Transaktionssicherheit, also der Einhaltung des ACID Konzeptes vorgesehen: ausschalten des Systems, damit das DBS gezwungen wird, Recovery Funktionen zu starten Simulation eines Festplattenfehler Wie für TPC A gilt, dass es 1995 für veraltet erklärt wurde und daher keine Statistiken mehr geführt werden. Es wird nicht empfohlen dieses Benchmark weiter zu verwenden. 8

9 TPC-C TPC C wurde konzipiert um einen Vergleich von OLTP Systemen zu ermöglichen. Freigegeben wurde es 1992 und seitdem beständig weiter entwickelt. Heute ist dieses bereits in der Version 5 zu bekommen. TPC C ist wesentlich komplexer als TPC A. Es werden verschiedene Transaktionsarten unterstützt, die Datenbank und die Ausführung sind komplexer geworden. Verwendet werden 5 verschiedene Transaktionen, die sich im Typ und der Komplexität unterscheiden. Die Datenbank ist aus 9 Tabellen mit unterschiedlichen Füllgrad und Größe zusammengesetzt. Das heißt die Tabellen sind mit unterschiedlich vielen Datensätzen besetzt und die Datentypen variieren von Tabelle zu Tabelle. Gemessen wird in Transaktionen pro Minute (tpmc) und im Zusammenhang zusätzlich Preis/Leistungsverhältnis (Preis/tpmC). TPC C simuliert eine komplette OLTP Umgebung mit verschiedenen Benutzern und deren Anfragen an eine Datenbank. Die Beispielumgebung ist ein Großhandelsunternehmen mit kleineren Aktionen wie der Verwaltung von Bestellungen (also Aufnahme, Auslieferung und Bezahlung) und Statusabfragen, sowie einer größeren Anfrage, die die Überwachung des Warenbestands darstellen soll. 90 % der Anfragen macht die Transaktion, die neue Bestellungen anlegt, aus. TPC C gibt Grenzen für die Antwortzeiten vor, das heißt alle Anfragen müssen innerhalb einer Zeitspanne beantwortet werden, ansonsten zählen sie nicht. Beispiel für eine Ergebnis Tabelle von der TPC C [9] 9

10 TPC-E TPC E ist der Nachfolger von TPC C und damit ein Benchmark für die OLTP Performance. Es wurde entwickelt, damit Hersteller weniger Möglichkeiten zur Manipulation der Benchmark Ergebnisse haben. Vor allem bei einfacheren Benchmarks, die sehr speziell auf einzelne einfache Transaktionen bzw. ein kleines Spektrum von Anwendungsfällen spezialisiert sind, könnten Hersteller ihre Systeme auf diese zuschneiden und so bessere Ergebnisse erzeugen. TPC E soll günstiger beim Aufsetzen und Durchführen der Test sein, sowie mehr den Anwendungen von moderneren Datenbanksystemen entsprechen. Daher wurde das Umfeld der Simulation angepasst und in ein neues Szenario versetzt. Es wird eine Umgebung einer Firma mit Brokern und Tradern, also Vermittlern zwischen Anlegern und der Börse, simuliert. Hinzu gekommen sind verschiedene Transaktionstypen: Consumer To Business und Business To Business. Es entsteht ein weiterer Unterschied des Benchmarks, nämlich das einzelne Transaktionen von anderen abhängig sein können [16]. Die normalerweise im Hintergrund ablaufenden komplexen Transaktionen zwischen den Systemen werden in diesem Benchmark ebenfalls nur simuliert. Gemessen wird in tpse (Transaktionen pro Sekunde) und Preis/tpsE (Preis/Leistung). Beispiel Ergebnisse zu TPC E [12] 10

11 TPC-H TPC H ist als Benchmark für OLAP / Decision Support Systeme entworfen und hat daher andere Schemata, Datenmengen und Anfragen als die bisher betrachteten Benchmarks. Bei OLAP werden häufig Anfragen mit hohem Komplexitätsgrad benötigt, um überhaupt unterstützende Analysen der (Geschäfts )Prozesse zu erhalten. Daher ist das Benchmark auf große Datenmengen und entsprechende Anfragen ausgelegt. Gestellt werden nur ad hoc Anfragen, das heißt die Datenbankensysteme haben kein Vorwissen über die Anfragen und können diese somit nicht im Vorfeld optimieren oder andere Aktionen ausführen, die eventuell im normalen Betrieb die Ausführungsgeschwindigkeit der Anfragen erhöhen würden. Das Modell für das Benchmark sieht vor, dass davon ausgegangen wird, dass die Datenbank ist 24 Stunden am Tag und 7 Tage die Woche verfügbar ist, mit Ausnahme eines Wartungstermins im Monat Anfragen Ad hoc von verschiedenen Benutzer formuliert und ausgeführt werden Daten in allen Tabellen verändert werden können Aktualisierung der Daten zu jeder Zeit unter Beachtung des ACID Konzeptes durchgeführt werden Das Modell für die Daten des Benchmarks sieht vor, dass ein Minimum von Geschäftsdaten für Lieferanten enthalten ist. Dies entspricht 10 Millionen Datensätze, die etwa einer Größe von einem Gigabyte entsprechen. Das Benchmark ist skalierbar und kann damit von der Menge der Datensätze abhängig gemacht werden. Wesentlich größere Datenmengen von 100 GB und mehr sind möglich. Gemessen wird in QphH@Size (Anfragen pro Stunde ( Query per Hour )). Entscheidender Unterschied gegenüber den Einheiten für die OLTP Benchmarks TPC C und TPC E ist, dass hierbei die Größe der Datenmenge und die Komplexität der Anfragen beachtet und in das Ergebnis mit eingerechnet werden. Zusätzlich wird unterschieden in welchem Umfeld die Anfrage ausgeführt wurde, das heißt, ob sie als einzige Anfrage bearbeitet wurde oder weitere gleichzeitig ausgeführt werden mussten. Zusätzlich muss das Preis/Leistungsverhältnis in Preis/QphH@Size angegeben werden. Laut dem TPC sind Vergleiche der Ergebnisse nur zulässig, wenn die Benchmarks mit derselben Datenbankgröße durchgeführt wurden. [13] 11

12 12 Datenbank Schema für TPC H [14]

13 Benchmark Ergebnisse für TPC H: 100GB Performance [15] Benchmark Ergebnisse für TPC H : 1000GB Performance [15] 13

14 Quellen [1] [2] [3] glossar/5 3_1.htm [4] leipzig.de/~kudrass/lehrmaterial/infosysteme/03 Informationsmanagement.ppt Prof.Dr. Ing. T.Kudrass, Skript zum Fach Informationssysteme HTWK Leipzig SS08 [5] [6] [7] Harm Knolle: Optimierung von Datenbanken und Leistungsbewertung, in: Taschenbuch Datenbanken, Hanser, [8] The State of Nature [9] [10] [11] [12] [13] [14] Kapitel 1.2. [15] [16] 14