Ausarbeitung zu Datenbanken II SS08 Thema: TPC
Werbung
Ausarbeitung zu Datenbanken II SS08 Thema: TPC-Benchmarks OLAP-Benchmark Von Mirco Barth 1 Inhaltsverzeichniss: TPC-Benchmark 1. Allgemeines 2. TPC-Preiskalkulation 3. TPC-App 4. TPC-A 5. TPC-B 6. TPC-C 7. TPC-D 8. TPC-E 9. TPC-H 10.TPC-W 3 3 3 5 6 8 12 13 13 14 OLAP-Benchmark 11.APB-1 15 2 Allgemeines: TPC steht für Transaction Processing Performance Council. Die TPC beschäftigt sich mit Vorschläge für die nächste Online Transaction Processing (OLTP) Arbeitsbelastung zu einem neuen TPC-Benchmark. Die TPC verfügt über mehr als ein Jahrzehnt Erfahrung bei der Bereitstellung von Industrie-Standard Arbeitslasten wie TPC-A / B (einfache OLTP), TPC-C (komplexe OLTP), TPC-D (Decision Support), TPC-H (Ad-hoc-Entscheidung unterstützt), TPC-R (Business Reporting) und TPC-W (Web-basierte E-Commerce). Preiskalkulation Der amtlich zugelassene TPC-Kosten-Unterausschuss beschaftigt sich mit Änderungen der bestehenden Preiskalkulationsmethode, so dass die Preise in veröffentlichten Ergebnissen nachprüfbar sind. Im Zuge dieser Aktivität wurde die Entwicklung einer einheitlichen Preisspezifikation aller TPC-Benchmarks beschlossen. Diese Spezifikation ist abgeschlossen. TPC-App Transaction Processing Performance Council (TPC) TPC-Benchmark ™ App (TPC-APP) ist ein Application-Server und Web Services Benchmark. Die Arbeitsbelastung ist einer verwalteten Umgebung performeed und simuliert die Aktivitäten einer Business-to-Business Transactional Application Server in einem 24x7 Umfeld. TPC-App zeigt die Leistungsfähigkeit der Applikations-Server-Systeme. Die Arbeitsbelastungsübungen beinhaltet im Handel erhältliche Application Server-Produkte, Messaging-Produkte und Datenbanken im Zusammenhang mit derartigen Umgebungen, die sich auszeichnen durch: Mehrere Online-Geschäft Sessions Im Handel erhältlich Anwendungsumgebung Die Verwendung von XML-und SOAP-Dokumente für den Datenaustausch Business-to-Business-Anwendungs Logik Distributed Transaction Management Zuverlässig und langlebig Messaging Dynamische generierte Web-Service-Anfragen Datenbankzugriff und Update Gleichzeitige Ausführung von mehreren Transaktionstypen über eine Anzahl von Business-Funktionen Datenbanken, bestehend aus vielen Tabellen mit einer Vielzahl von Größen, Eigenschaften und Beziehungen Transaktions-Integrität (ACID-Eigenschaften) 3 TPC-A (Veraltete seit 06.06.1995) TPC-A Performance Benchmark wurden im November 1989 ausgestellt und misst die Leistung in Update-Datenbank-Umgebungen, die typisch für Online-Transaction-ProcessingAnwendungen sind. Diese Umgebungen zeichnen sich aus durch: Mehrere Online-Terminal-Sessions Wichtige Ein- / Ausgaben Moderate Systeme und Anwendungsausführungszeit Transaktions-Integrität Dieser Benchmark verwendet eine einzige, einfache, update-intensiven Transaktion zum laden, um das System getestet. Diese Arbeitsbelastung reflektiert eine OLTP-Anwendung, aber nicht den gesamten Bereich von OLTP-Anforderungen, der in der Regel durch mehrere Transaktionsarten von unterschiedlicher Komplexität gezeichnet wird. Die einzige Art der Transaktion bietet eine einfache, reproduzierbare Einheit an Arbeit, und ist so konzipiert, dass die Ausübung zentrale Elemente eines OLTP-System beinhaltet. Die TPC-Benchmarks messen, wie viele Transaktionen pro Sekunde (TPS) ein System ausführen kann, wenn es von mehreren Terminals betreiben wird. Der TPC-A kann die Anzahl der Terminals, die ein Unternehmen zum skalieren verlangt, für den Durchsatz oder TPS-Rating, nicht festgelegen. TPC-A kann in einem weiten Bereich oder lokalen Netzwerk-Konfiguration genutzt werden, wobei nicht zwischen Ergebnissen für Wide-Area und Local-Area-Konfigurationen unterschieden wird. Die Leistung wird durch die beiden Metriken "TPC-A local Throughput" und "TPC-A wide Throughput" beschrieben und wird in Transaktionen pro Sekunde (TPS) gemessen. Diese beiden Metriken sind unterschiedlich und können nicht miteinander verglichen werden. Die TPC-Benchmark-Spezifikation verlangt, dass alle Unternehmen in vollem Umfang die Einzelheiten ihrer Benchmark, ihre Konfiguration des Systems und die damit verbundenen Kosten (einschließlich 5 Jahre Wartungskosten) offen legen. Eine Benchmark TPC-Übungen wendet für das System notwendigen Komponenten zur Ausführung von Aufgaben im Zusammenhang mit dieser Klasse von Online-Transaction Processing-Umgebungen um die update-intensiven Dienstleistungen einer Datenbankzu betonen. Dieser Benchmark verwendet Terminologien und Metriken, die ähnlich wie in anderen Benchmarks sind,aber nicht bedeuten,dass man die Ergebnisse vergleichen kann.Die Metriken in TPC-A sind Durchsatz, gemessen in Transaktionen pro Sekunde (TPS), der vorbehaltenen Reaktionszeit und der damit verbundene Preis-pro-TPS. Der Vergleich der Preis-Leistungs-Ergebnisse in einem Land, sind vielleicht nicht sinnvoll in einem anderen, durch Preis- und Produktunterschiede. Das Ausmaß, was ein Kunde erreichen kann, die Ergebnisse berichtet von einem Lieferanten ist in hohem Maße auf, wie eng TPC-A gleicht der Kunden-Anwendung. Relative Performance der Systeme aus der TPC-A nicht unbedingt halten für andere Workloads oder Umgebungen. Extrapolationen im Gegensatz zu Umgebungen werden nicht empfohlen. Eine vollständige Offenlegung Bericht über die Durchführung Einzelheiten zur Verfügung gestellt werden müssen zusammen mit den berichteten Ergebnissen. 4 Benchmark-Ergebnisse sind in hohem Maße abhängig von der Arbeitsbelastung, den spezifische Anforderungen, demSystem-Design und der Umsetzung. Die relative Systemperformance variieren infolge dieser und anderer Faktoren. Daher sollte TPC-A nicht als Ersatz für spezifische Kunden-Anwendungen verwendet werden, wenn eine kritische Kapazitätsplanungen und / oder Produktauswertung betrachtet wird. TPC-B (Veraltete seit 06.06.1995) TPC-B-Maßnahmen in Bezug auf Durchsatz, wie viele Transaktionen pro Sekunde ein System ausführen kann. Zusammenfassung. Im August 1990 hat der TPC genehmigt seiner zweiten Benchmark TPC-B. Im Gegensatz zu TPC-A, TPC-B ist kein OLTP-Benchmark. Vielmehr TPC-B kann man in so einer Datenbank Stress-Test, zeichnen sich aus durch: Wichtige Ein- / Ausgaben Moderate Systeme und Anwendungsausführungszeit Transaktions-Integrität TPC-B-Maßnahmen in Bezug auf Durchsatz, wie viele Transaktionen pro Sekunde ein System ausführen kann. Da gibt es erhebliche Unterschiede zwischen den beiden Benchmarks (OLTP-vs-Datenbank Stress-Test), TPC-B Ergebnisse können nicht mit TPC-A verglichen werden. Detaillierte Beschreibung Alle TPC Benchmarks sind formuliert, um einen Vergleich von Computersystemen (Hard-und Software zusammen) in der Datenbank-und Transaktionsverarbeitung zu ermöglichen. Das einzige, was bei TPC-B und TPC-A gleich ist, sind die Transaktion, das Profil-und Datenbankschema. Dies geschah für die Bequemlichkeit der Benutzer für den Aufbau der Datenbanken beider Tests. Dies bedeutet nicht, dass TPC-B ist eine Teilmenge von TPC-A ist, noch bedeutet es, dass TPC-B "schwächer" als TPC-A ist, da die Terminals weggelassen wurden. TPC-B ist nicht zur Front-End-OLTP-Messung: Es ist für Back-End-DatenbankServer Messungen. TPC-Benchmark-B richtet sich an Datenbank-Management-Systeme (DBMS) BatchAnwendungen und der Back-End-Datenbank-Server-Markt-Segment, und zwar entweder Stand-alone-oder Client-Server. Es lässt sich messen, wie viele gleichzeitige Transaktionen insgesamt ein System verarbeiten kann. Es gibt keine "Nutzer", es werden keine Kommunikationslinien und keine Terminals verwendet. Dies ist analog zur elektronischen Datenverarbeitung (EDV) Batch-Processing-Applikationen, die über Nacht laufen, wenn gerade keine Nutzer angemeldet sind. Die Transaktionen werden von allen Programmen gleichzeitig ausgeführt. Jedes Programm startet eine Transaktion, wartet auf seine Vollendung 5 und startet dann eine neue. Es gibt keine menschliche Denkzeit, so dass jedes serienmäßige Programm so schnell wie möglich läuft. Viele Benchmark-Programme können gleichzeitig gestartet werden und das System verarbeitet so viele Transaktionen, wie sie handhaben kann, vorbehaltlich einer einschränkenden Verweilzeit (die maximale Zeit Transaktionen kann die Ausführung im System). TPC-B kann überall dort eingesetzt, wo gleichzeitige MultiplexTransaktionen vorhanden sind, wobei die maximale Durchsatzleistung gemessen wird. TPC -B ist so konzipiert, dass ein Stresstest auf den Kerngeschäftsteil eines Datenbanksystems augeführt wird. Er konzentriert sich auf den einen Teil des Systems und führt die eigentliche Transaktionsverarbeitung durch. Er betont die CPU-Hardware, weil die Transaktionen nicht durch das menschliche Denken pausiert werden. Weiterhin stresst er den Speicher und Ein-/Ausgabe-Subsysteme durch große mengen von kleine Lese- und Schreibzugriffe. Abhängig davon, wie ein System konfiguriert ist, kann es zu viel höheren Festplatteaktivitäten im TPC-B als im TPC-A kommen. Ausserdem wird das Betriebssystem getestet, indem TPC-B unendliche Kontextwechsel zwischen Front-End-Prozessen (die Benchmark-Code) und Back-End-Prozessen (Der Database Manager) bei Anfechtung der Speicherverwaltung und I / O-Treiber durchgeführt werden. Der Datenbank-Manager wird im Umgang mit der maximale Rate gleichzeitiger Streams über Aktuelles, also Leseanweisungen und Schreibanweisungen müssen durchgeführt und protokoliert werden. Insbesondere gibt es drei Tests zur Haltbarkeit. Man muss die Beseitigung eines Gerätes (oder Speicher) berücksichtigen, während das System weiterhin voll Funktionsfähig und mit laufenden Geschäften geladen bleiben soll. Dies führt dazu, dass die Manager-Datenbank ihre Recoveryfunktion ausübt, wenn das Gerät (oder Speicher) wird bereitgestellt wurde. Ein zweiter Test erfordert das Scheitern eines Teils der Datenbank. Auch hier wird der Datenbank-Manager zur Wiederherstellung der Datenbank in einem konsistenten Zustand gezwungen. Der dritte Test erfordert das Scheitern einer Protokollierung oder eines Aufzeichnungsgerät während einer Transaktion und der Datenbank-Manager muss auch weiterhin auf gleicher Leistung laufen. Datenbank-Server Tune Up Die meisten kompletten EDV-Shop komplett mit Terminals und Betreiber und können so keine Benchmark brauchen. Das Geschäft wird dann Frage: "Wie bekomme ich das meiste aus meinem Shop? Upgrades Wie kann ich meine Produktivität maximieren?" TPC-B kann diese Antworten quantifizieren, und kann sagene wieviel Back-End-Leistung hinzuzufügt werden kann. Es bietet einen fokussierten Blick in die Transaktionsverarbeitung und Fähigkeit des Systems, was nützlich für die Kapazitätsplanung ist. Monitoring und Tuning ist sehr einfach mit TPC-B. Da es sich um eine einfache Sammlung von kleinen Programmen handelt. TPC-B bietet eine bequeme Möglichkeit, eine wiederholbare, konsistente und stressige Datenbank auf einem System zu laden. Das System kann dann durch verfügbare Performance Monitoring-Tools überwacht werden, indem die. CPU-Auslastung, I / O-Verkehr, Lagerung und Layout untersucht und für für maximale Performance abgestimmt wird. Das Betriebssystem und Datenbankmanageparameter können 6 angepasst werden. Shared-Memory-Segmente, Spinlocks, Logfile-Größen, Checkpointabststände, usw. können alle untersucht und abgestimmt werden. So wird ein Systemgleichgewicht erreicht mit der maximalen Belastung un Effizenz. TPC-B ist die TPC der offiziellen Datenbank Stress-Test für einfache Batch-Profil-ModusAnwendungen in einem Back-End-Datenbank-Server-Szenario. Es gibt Antworten auf EDVShop Kapazitätsplanungsrobleme, Client-Server-Architekturen und SQL (oder andere interne Datenbank Sprache) Operationen für ein Netzwerk. Es kann auch mit TPC-A zusammen verwendet werden um andere Szenarien, wie die Transaktion und überwachen von TuningParameter, zu messen. TPC-B wird konzentriert zum Systemvergleich (Hard-und Software) von Datenbanksystemfähigkeiten in Ihrer EDV-Situation. TPC-C TPC-C simuliert eine komplette IT-Umgebung, wo eine Anzahl von Nutzern Transaktionen gegen eine Datenbank ausführt. Die Benchmark ist rund um die wichtigsten Aktivitäten (Transaktionen) ein, um Umwelt-Eintrag. Diese Transaktionen umfassen die Eingabe und Bereitstellung von Bestellungen, erfassen von Zahlungen, Statusüberprüfung von Aufträgen und die Überwachung der Ebenen in den Lagern. Der Benchmark porträtiert die Tätigkeit eines Groß-Lieferanten. TPC-C ist nicht beschränkt auf die Aktivitäten eines bestimmten Geschäftsbereichs, sondern steht für eine beliebige Branche, mit Verwaltung, Verkauf und Vertrieb eines Produkts oder einer Dienstleistung. TPC-C beinhaltet eine Mischung von fünf gleichzeitigen Transaktionen verschiedener Art und Komplexität, entweder vollständig online oder in Warteschlange für latente Ausführung. Dabei werden eine Breite von System-Komponenten im Zusammenhang mit derartigen Umgebungen ausgeführt, die sich auszeichnen durch: Die gleichzeitige Ausführung mehrerer Transaktionarten mit einen bestimmten Umfang der Komplexität Online- und latente Transaktions- Ausführungsmodi Mehrere Online-Terminal-Sessions Moderate Systeme und Anwendungsausführungszeit Bedeutende Ein- und Ausgaben Transaktions-Integrität (ACID-Eigenschaften) Ungleichmäßige Verteilung der Datenzugriffe über Primär- und Sekundärschlüssel Datenbanken, bestehend aus vielen Tabellen mit einer Vielzahl von Größen, Eigenschaften und Beziehungen Auf Daten zugreifen und diese aktualisieren Im Juli 1992 wird der C-Benchmark von TPC als Online-Transaction-Processing(OLTP)Benchmark bestätigt und ist der dritte genehmigte in seiner Reihe von Benchmarks für die Messung der Performance und Preis / Leistung Transaction-Processing-Systeme. Der TPC-C ist komplexer als frühere Benchmarks auf Grund seiner verschiedenen Transaktionstypen und komplexeren Datenbanken. Die aktuelle TPC-C-Benchmark-Version ist 5,9. Die Benchmarks der TPC-C wurden weiter entwickelt um aktuell repräsentativ für die derzeitige Praxis zu sein. Der TPC-C Benchmark 7 ist nach wie vor ein beliebter Maßstab für den Vergleich der OLTP-Performance auf verschiedenen Hardware- und Softwarekonfigurationen. Für eine kurze Zeit nach der Einführung der Version 5 durften Upgrades früherer Benchmarks laufen wo sie erforderlich waren, aber einem Prüfer mussten die neuen vollständigen Berichte zur Überprüfung und Aktualisierung offengelegt werden. Diese Ergebnisse lassen sich durch eine Tabelle der verfügbaren Daten und der übermittelten Daten unterscheiden. Im Vergleich zu vorherigen Versionen beinhaltet eine Preiskalkulationsänderung das Redzuzieren der Wartungsunterstützung von 5Jahren auf 3, die Versorgungserhöhung, die Minderung von terminalen Netzwerken (Hubs, Swichtes) und die Preisgestaltung von Webseiten und Druckmaterialien. Durch Laufzeitänderungen konnte der benötigte Festplattenspeicher reduziert und das Messinterval von 20 Minuten auf 2 Stunden erhöht werden.Weiterhin waren Berichterstattungen mit der Anzahl der verlorenen Nutzerverbindgungen möglich. Diese Neuregelung veränderte die Preis-Leistungs-Metrik, sodass Version 5 Ergebnissse nicht mit früheren Ergebnissen verglichen werden können. TPC-C beinhaltet eine Mischung von fünf gleichzeitigen Transaktionen verschiedener Art und Komplexität entweder vollständig online oder Warteschlange für latente Ausführung. Die Datenbank besteht aus neun Arten von Tabellen mit einer breiten Palette von der Bevölkerung zu erfassen und Größen. Das Ziel der TPC-Benchmarks ist die Definition einer Reihe von funktionalen Anforderungen an Transaktionen und Verarbeitungen, unabhängig von Hardware oder Betriebssystem. Es ist dann nachweisbar (in Form einer vollständigen Offenlegung Bericht), dass alle Anforderungen erfüllt werden. Diese Methodik erlaubt es jedem Anbieter mit "proprietären" oder "offene" Systemen zu arbeiten und die Umsetzung des TPC Benchmark und garantiert dem Endnutzer den Vergleich von „ Äpfel und Äpfel“. Dies ist eine dramatische Abkehr von den meisten anderen Benchmarks, wo Tests von Sponsoren auf den Vergleich von Maschinen, die auf nur einem Betriebssystem oder auf dem gleichen Softwareanweisungen laufen, beschränkt werden. TPC-Benchmarks sind nach dem Vorbild der tatsächlichen Erzeugung, Anwendungen und Umgebungen entwickelt, anders als bei Stand-alone-Computer-Tests, bei denen möglicherweise Key-Performance-Faktoren wie zB User-Interface-, Kommunikations-, disk I / Os, Datenspeicherung, Backup- und Erholung nicht berücksichtigt werden. Die Schwierigkeit bei der Gestaltung von TPC Benchmarks liegt bei der Verringerung der Vielfalt von Operationen in einer Produktionsanwendung, unter Beibehaltung ihrer wesentlichen Leistungsmerkmale, nämlich das Niveau der Auslastung des Systems und die Komplexität der Vorgänge. Eine große Zahl von Funktionen muss für die Verwaltung eines Produktionssystems ausgeführt werden. Da viele dieser Funktionen sind verhältnismäßig klein sind im Hinblick auf die Ressourcenauslastung, des Systems oder in Bezug auf die Häufigkeit der Ausführung, sind sie nicht von primärem Interesse für die PerformanceAnalyse. Obwohl diese Funktionen von entscheidender Bedeutung für ein Produktionssystem sind, würden sie im Rahmen eines Standard-Benchmark lediglich übermäßige Vielfalt und Kosten schaffen und werden deshalb weggelassen. 8 TPC-C Benchmark-Modell Als OLTP-Benchmark-System simuliert TPC-C ein komplettes Umfeld, in dem eine Bevölkerung von Terminal-Betreibern Transaktionen gegen eine Datenbank ausführt. Der Benchmark konzentriert sich auf die wichtigsten Aktivitäten (Transaktionen) eines Bestellungseingaben-Umfeld. Diese Transaktionen umfassen die Eingabe und Bereitstellung von Bestellungen, die Erfassung von Zahlungen, die Überprüfung des Status von Aufträgen und die Überwachung der Lagerebene. Es ist nicht die Absicht der TPC-C zu spezifizieren, wie sie am besten ein Order-Entry System umsetzt. Während die Benchmark die Tätigkeit eines Groß-Lieferanten porträtiert, ist TPC-C nicht auf die Aktivität eines bestimmten Geschäftsbereich beschränkt, sondern steht für eine beliebige Branche mit Verwaltung,Verkauf und Vertrieb eines Produkts oder einer Dienstleistung. Im TPC-C-Geschäftsmodell betreibt ein Großhandel eine Reihe von Lagerhäusern und die damit verbundenen Umsätze und Bezirken. Der Benchmark ist so konzipiert, dass er ein Maßstab für die Firmenexpansion sowie für neu geschaffene Lagerräume bietet. Allerdings werden bestimmte Anforderungen konsequent aufrecht erhalten, je nachdem, wie der Benchmark skaliert wurde. Jedes Lager im TPC-C-Modell muss zehn Umsatzbezirken und jeder Bezirk dreitausend Kunden besitzen. Der Leiter von einem Umsatzbezirk kann zu jeder Zeit eine der fünf Operationen oder Transaktionen, die von dem Frimensystem angeboten werden, wählen. Wie die Geschäfte selbst, werden auch die Häufigkeiten individueller Transaktionen nach realistischen Szenarien modelliert. Die häufigste Transaktion besteht aus der Eingabe, welche im Durchschnitt zehn verschiedenen Artikel umfast. Jedes Lager versucht den Bestand von 100000 Artikeln zu halten und Bestellungen aus diesem Lager zu erfüllen. Doch in Wirklichkeit wird ein Lager vermutlich nicht mehr alle Artikel benötigen um jeden Auftrag erfüllen. Daher setzt TPC-C voraus, dass in der Nähe von zehn Prozent aller Aufträge, Unterlagen von anderen Lagern des Unternehmens vorliegen müssen. Eine weitere häufige Transaktion besteht in der Erfassung einer Zahlung von einem Kunden. Weniger häufig, werden die Leiter den Status einer früherer Bestellungen, einen Batch-Prozess von zehn Bestellungen zur Auslieferung oder potenzielle Engpässe während einer Lagerbestandsprüfung abfragen. Insgesamt fünf Arten von Transaktionen werden verwendet um alle unternehmerischen Tätigkeiten dieses Modells zu erfassen. Die Leistungs-Metrik von TPC-C gibt die Anzahl der Bestellungen, die vollständig pro Minute verarbeitet werden kann in tpm-C an. Um die Benchmark für Systeme unterschiedlicher Anforderungen zu implementieren, müssen Maßstäbe, sowohl die Anzahl der Terminals und der Größe der Datenbank proportional auf die Rechenleistung des Systems gemessen werden. Um das gemessene System auf Vollproduktionbereictschaft mit ausreichender Wartungzu testen, musste für die Datenbank die ACID-Eigenschaften: Atomicity, Konsistenz, Isolation und Dauerhaftigkeit definuiert werden. Zur Erleichterung der unabhängigen Überprüfung der Benchmark-Ergebnisse, mussten Tester vollständige Bericht offenlegung, sowie alle notwendigen Informationen. Diese Leistung muss mit den gesamten Systemkosten verglichen und an tatsächliche Kosten 9 angeglichen werden. Es beinhaltet die Kosten für alle Hard-und Software-Komponenten, Wartungskosten über 5 Jahre, und ausreichend Speicherkapazität, um die Daten über einen Zeitraum von 180 8-Stunden-Tage zu speichern. Mit der Einführung von TPC-C, besitzt die Industrie ein zusätzliches, komplexeres OLTPMess-Tool. TPC-C beinhaltet eine Mischung von fünf gleichzeitigen Transaktionen verschiedener Art und Komplexität, entweder vollständig Online oder in Warteschlange für latente Ausführung. Dies ist einer der bedeutendsten Erweiterungen des grundlegenden OLTP Benchmarking-Modell, denn neue Komponenten des Systems können gemessen werden. Die neue Datenbank besteht aus neun Arten von Datensätzen mit einer breiten Palette von der Bevölkerung zu erfassenden Daten und Größen. Die eingegebenen Daten von Betreibern in TPC-C sind einige der grundlegenden Merkmale des realen Daten-Input. Beispielsweise zwingen Eingaben ungültiger Artikelnummer die Transaktionen abzubrechen. TPC-C reduziert die Anzahl der künstlichen Grenzen, die in anderen Benchmarks gelten. Zum Ein Maß für den Business-Durchsatz Der Durchsatz der TPC-C ist eine direkte Folge des Niveaus der Aktivität in den Terminals.. Jedes Lager verfügt über zehn Terminals und alle fünf Geschäfte sind zu finden unter jedem Terminal. Ein Remote-Terminal-Emulator (RTE) wird verwendet, um die geforderte Mischung von Transaktionen über die Performance-Messung. Diese Mischung macht das komplette Geschäft Verarbeitung einer Bestellung, wie sie eingegeben wird, bezahlt, kontrolliert und geliefert. Genauer gesagt, die Mischung erforderlich ist definiert, um eine gleiche Anzahl von New-Order-und Zahlungstransaktionen und produzieren eine Zustellung Transaktion, ein Bestell-Status Transaktion und ein Lager-Level-Transaktion für alle zehn New-Order-Transaktionen. Die TPM-C-Metrik ist die Anzahl der New-Order-Transaktionen pro Minute. Angesichts der erforderlichen Mischung und das breite Spektrum der Komplexität der Transaktionsarten simuliert dieser Messwert stärker eine komplette unternehmerische Tätigkeit stärker. Aus diesem Grund wird die tpm-C-Metrik als ein Maß des Wirtschaftsdurchsatzes gesehen. Die TPC-C-Performance wird in Transaktionen pro Minute gemessen. Die primären Metriken sind die Transaktionrate (tpmC), der Preis pro Transaktion ($ / tpmC) und der Verfügbarkeitszeitpunkt des Konfigurationspreises. 10 Top-Ten TPC-C Performance Ergebnisse von Version 5 Platz Firma 1 IBM * Bull System IBM Power 595 Server Model 9119-FHA Bull Escala PL6460R HP Integrity SuperdomeItanium2/1.6GHz/ 24MB iL3 IBM System p5 595 10.12.2008 IBM DB2 9.5 IBM AIX 5L V5.3 6.085.166 2.81 $ 15.12.2008 IBM DB2 9.5 IBM AIX 5L V5.3 2.97 $ 22.01.2007 IBM DB2 9 IBM AIX 5L V5.3 3.210.540 5.07 $ 14.05.2005 IBM DB2 UDM 8.2 IBM AIX 5L V5.3 2.196.268 4.70 $ 30.04.2008 Oracle 10g Enterprise Ed R2 w/ Partitioning Red Hat Enterprise Linux 4 AS 1.616.162 3.54 $ 21.07.2007 IBM DB2 Enterprise 9 IBM AIX 5L V5.3 1.616.162 3.54 $ IBM eServer p5 IBM 595 1.601.784 5.05 $ NEC Express5800/132 NEC 0Xf (16p/32c) 1.245.516 4.57 $ Fujits PRIMEQUEST u 540 16p/32c 1.238.579 3.94 $ 16.12.2007 IBM DB2 9.1 IBM AIX 5L V5.3 20.04.2005 Oracle Database 10g Enterprise Edition IBM AIX 5L V5.3 30.04.2008 Oracle Database 10g R2 Enterprise Edt w/Partitioning Red Hat Enterprise Linux 4 AS 15.12.2006 Oracle Database 10g Enterprise Edition Red Hat Enterprise Linux AS 4.0 5 IBM Fujits u 6 IBM Bull Bull Escala PL1660R 10 2.81 $ 4.033.378 IBM eServer p5 595 PRIMEQUEST 580 32p/64c IBM System p 570 9 6.085.166 06.08.2007 IBM 8 Operating System 2.93 $ 3 7 Datenbank 4.092.799 HP * Preis/ Systemverfüg tpmC barkeit Oracle Database 10g R2 Enterprise Edt w/Partitioning 2 4 tpmc HP HP Integrity SuperdomeItanium2/1.6GHz64p/64c 1.231.433 4.82 $ 05.06.2006 Microsoft SQL Server 2005 Enterprise Edt SP1 HP-UX 11i v3 Microsoft Windows Server 2003 Datacenter Ed.(64bit) SP1 TPC-D (Veraltete seit 04.06.1999) Die TPC genehmigt ihren vierten Benchmark im April 1995. Er unterscheidet sich von den bestehenden Benchmarks. TPC-D steht für ein breites Spektrum von Decision Support (DS) Anwendungen, die komplexe, lange Abfragen gegen große komplexe Datenstrukturen stellen. Real-World Business Fragen wurden schriftlich auf diese Modell angewendet, was zu 17 komplexere Abfragen führte. 11 TPC-E TPC-Benchmark ™ E (TPC-E) ist eine neue OnLine Transaction Processing (OLTP) Arbeitsbelastung entwickelt von der TPC. Der TPC-E Benchmark verwendet eine Datenbank zum modellieren einer Beziehung zwischen Unternehmen und Kunden, generierten Transaktionen im Zusammenhang mit Handel, Konto-Anfragen, und Marktforschung. Die Unternehmen wiederum interagieren mit den Finanzmärkten zur Ausführung von Aufträgen im Namen der Kunden und aktualisieren relevante Kontoinformationen. Der Benchmark ist Skalierbar, was bedeutet, dass die Anzahl der Kunden definiert für die jeweiligen Unternehmen und somit die Arbeitsbelastung verschieden großer Unternehmen variiert werden kann. Der Benchmark definiert sich durch die Aufrechterhaltung der erforderlichen Kombination aus den Benchmark-Transaktio. Die TPC-E-Metrik wird in für Transaktionen pro Sekunde (TPS) angegeben und bezieht sich ausdrücklich auf die Anzahl der Trade-Result-Transactions welche über ein gewissen Zeitraum aufrechterhalten werden. Obwohl dieses Business-Model der TPC-E für eine Marklerfirma steht, wurden Datenbankschemen, Datenbevölkerung, Transaktionen, Durchführungen und Regeln so gestaltet, dass es weitgehend repräsentativ für moderne OLTP-Systeme ist. TPC-H Der TPC-Benchmark ™ H (TPC-H) ist ein Decision-Support-Benchmark. Es besteht aus einer Folge von businessorientierten Ad-hoc-Abfragen und gleichzeitigen Datenänderungen. Die Abfragen und die Daten der Datenbank wurden so ausgewählt, dass sie eine breite, industrieweite Bedeutung besitzen. Dieser Benchmark zeigt Decision-Support-Systeme, die große Mengen von Daten und Abfragen mit hoher Komplexität prüfen und auf wichtige geschäftliche Fragen antworten. Die Leistungsmetrik von TPC-H heißt „Composite Query-per-Hour Performance Metric“ (QphH@Size) und spiegelt mehrere Aspekte der Fähigkeit des Systems zur Verarbeitung von Abfragen wieder. Die verschiedenen Aspekte sind die ausgewählten Datenbankgrößen gegen die ausgeführten Abfragen, die Rechenleistung, wenn Anfragen von einem einzigen Stream übermittelt werden, sowie den Durchsatz von Abfragen bei der Übermittelung von mehreren Abfragen von gleichzeitigen Benutzern. Die TPC-H Preis-Pro-Performance-Metrik wird als $/QphH@Size ausgedrückt. 12 TPC-W (Veraltet seit 28.06.2005) TPC-W ist ein transaktionaler Web E-Commerce-Benchmark. Die Arbeitsbelastung wird in einer kontrollierten Internet-Commerce-Umgebung simuliert, dass die Aktivitäten eines Unternehmens ausgerichtet transaktionale Web-Server. Die Arbeitsbelastung wird einer Breite von System-Komponenten im Zusammenhang mit derartigen Umgebungen getestet, die sich auszeichnen durch: Mehrere Online-Browser-Sitzungen Dynamische Seitegeneration mit Datenbankzugriffen und Updates Konsequente Web-Objekte gleichzeitige Ausführung mehrerer Transaktionarten mit bestimmten Umfang und kompelxität Komplexität Online-Transaktion-Ausführungsmodi Datenbanken, die aus vielen Tabellen mit einer Vielzahl von Größen, Eigenschaften und Beziehungen bestehen Transaktions-Integrität (ACID-Eigenschaften) Wettbewerb zwischen Dtenzugriff und Datenupdate Die Leistungs-Metrik steht für die Anzahl der Web-Interaktionen, die pro Sekunde verarbeitet werden können. Mehrere Web-Interaktionen simulieren die Tätigkeit eines Einzelhandelsgeschäfts, und jede Interaktion ist Gegenstand einer Reaktionszeit. TPC-W simuliert drei verschiedene Profile durch Variation der Rate von Bestellungen: in erster Linie shopping (WIPS), Browser (WIPSb) und Web-basierte Bestellung (WIPSo). Die primäre Metrik ist die WIPS-Rate, dem damit verbundenen Preis pro WIPS ($ / WIPS) und dem Zeitpunkt der Verfügbarkeit der Konfigurationspreise. 13 OLAP-Benchmark APB-1 Die Entwicklung des OLAP-Benchmarks, des Analytic Processing Benchmark (APB-1) wurde vom OLAP-Council gefördert. Der Benchmark simuliert realistische OLAP-BusinessSituationen, die auf Server-basierter Software laufen. Das Ziel des APB-1 ist die Messung der gesamten OLAP-Performance eines Servers. Die (sorgfältig ausgewählten) Operationen des Benchmarks sollen häufige Operationen in der Praxis widerspiegeln und so sicherstellen, daß die Ergebnisse des Benchmarks praxisrelevant sind. Diese Operationen umfassen: umfangreiche Laden von Daten aus in- und externen Quellen inkrementelles Laden von Daten aus operationalen Systemen Aggregationen Datenumverteilung entsprechend dem Business-Modell Zeitreihenanalysen Queries mit einem hohen Komplexitätsgrad drill-down durch Hierarchien ad-hoc-Queries multiple Online-Sessions Analytische Prozeßapplikationen sind Informationssysteme. Das Hauptaugenmerk liegt auf der Antwortzeit des Systems: Wie groß ist die Zeitspanne, die das System benötigt, um Ergebnisse zu liefern, gemessen ab dem Zeitpunkt, von dem an das System Zugriff auf die Daten hat. Diese Zeit definiert der APB-1 als analytic throughput. Die Performance-Metrik bezeichnet man als analytical query time (AQT). Sie berechnet sich aus der gesamten ServerRechenzeit geteilt durch die Anzahl der verarbeiteten Queries. Die Server-Rechenzeit ergibt sich aus der verstrichenen Zeit zwischen Zugriff auf die Input-Daten und Abarbeitung der letzten Query. Die Berechnung der AQT umfaßt die Zeit für: Laden der Daten in das System Ausführung der Berechnungen Durchführung der Queries Die verwendete OLAP-Applikation ist ein Verkaufs- und Marketing-Analysesystem. Der Benchmark ist eine Synthese genereller Business-Praktiken und kein Modell einer spezifischen Industrie oder eines spezifischen Marktes. Die Datenbank enthält Informationen zur Analyse von Produktverkäufen an Kunden durch Verteilkanäle über einen bestimmten Zeitraum. Die logische Datenbankstruktur besteht aus sechs Dimensionen: Zeit, Szenario, Maßstab sowie drei Aggregations-Dimensionen zur Definition der Datenbankgröße 14 Produkt: Die Produkt-Dimension hat die meistens Einträge. Die Anzahl der Einträge in der Dimension Produkt ist das zehnfache der Dimension Kunde. Die minimale Anzahl der Einträge ist 10.000. Die Produkthierarchie erstreckt sich über sieben Level und ist als Baumstruktur organisiert, dabei enthalten die Blätter 90% der Einträge. Die Levelnamen der Produkthierarchie: Top Division Line Family Group Class Code Kunde: Die Anzahl der Kunden ist die hundertfache der Anzahl der Kanäle, das Minimum liegt bei 1.000. Die Hierarchie erstreckt sich über drei Level, der unterste enthält 90% der Einträge. Die Namen der Level: Top Retailer Store Kanal: die Anzahl der Einträge hier ist die geringste; die Anzahl der Kanäle ist ein Eingabeparameter des Programms APB1GEN (Beschreibung siehe unten). Das Minimum liegt bei zehn, und die Hierarchie umfaßt zwei Level: Top Base Zeit: die Zeit umfaßt zwei Jahre (1995 und 1996) mit je zwölf Monatseinträgen. Die ZeitHierarchie schließt Vierteljahr-, Jahr- und Jahr-zu-Datum-Aggregationen ein. Als aktueller Monat dient der Juni 1996. Zeitperioden vor diesem Monat gelten als „historisch", Perioden danach als zukünftige. Szenario: Es existieren drei Basiswerte in dieser Dimension: zwei sind Input von Datenfiles, der dritte ist aus den anderen beiden modelliert. Die Input-Szenarien umfassen Gegenwart und Budget, das modellierte Szenario enthält Vorhersagen. Maßstab: Diese Dimension enthält zehn Einträge; fünf Input und fünf berechnete. Die Input- Einträge sind: verkaufte Einheiten: nach Produkt, Kunde, Kanal, Zeit und Szenario Einnahmen: nach Produkt, Kunde, Kanal, Zeit und Szenario Inventar: nach Produkt, Kunde und Zeit Standard-Produktkosten: nach Produkt, Zeit und Szenario (SPK) Standard-Vertriebskosten: nach Kunde, Zeit und Szenario (SVK) 15 die berechneten: durchschnittlicher Verkaufspreis = Einnahmen / verkaufte Einheiten Kosten = verkaufte Einheiten * (SPK + SVK) Gewinn = Einnahmen - Kosten Gewinn in % = Gewinn / Einnahmen smoothes sales = 6-Monats-Durchschnitt der Einnahmen Es existieren zwei Sätze von Datenfiles. Das erste wird zur Initialisierung der Datenbank benötigt, das zweite für das inkrementelle Laden. Das Programm APB1GEN generiert alle diese Dateien. OLAP-Queries sind ad-hoc-Queries und sehr dynamisch. Die benötigten Informationen umfassen alle vorhandenen Daten. Der APB-1 umfaßt folgende Queries: Kanal-Verkaufs-Analyse: Die Query zeigt aktuelle verkaufte Einheiten, Einnahmen und den durchschnittlichen Verkaufspreis für einen angegebenen Kanal. Produkt, Kunde, Kanal und Zeitperiode variieren bei jeder Ausführung der Query. Kunden-Gewinn-Analyse: Diese Query zeigt aktuelle Verkäufe, Kosten und Gewinn für einen angegebenen Kunden. Produkt, Kunde und Zeitperiode variieren bei jeder Ausführung der Query. Produkt-Inventory-Analyse: Diese Query zeigt aktuelle Verkäufe, Kosten und Bestand für ein gegebenes Produkt ungeachtet des Kanals. Produkt und Kunde variieren bei jeder Ausführung der Query. Zeitreihen-Analyse: Die Query zeigt aktuelle Verkäufe und einen Sechs-MonatsDurchschnitt für einen angegebenen Kunden und eine Gruppe von Zeitintervallen über alle Kanäle. Produkt, Kunde und Zeitperiode variieren bei jeder Ausführung der Query. Kundenbudget: Diese Query zeigt das Kundenbudget über alle Kanäle für alle Monate des Jahres 1996. Der Kunde variiert bei jeder Ausführung der Query. Produktbudget: Diese Query zeigt das Produktbudget für eine angegebene Zeitperiode im Jahr 1996. Das Produkt variiert bei jeder Ausführung der Query. Vorhersage-Analyse: Diese Query zeigt die Kanalvorhersage für eine angegebene Zeitperiode im Jahr 1996. Produkt, Kunde, Kanal und Zeitperiode variieren bei jeder Ausführung der Query. Budget-Performance: Die Query vergleicht die Budget-Performance des aktuellen mit der des vergangenen Jahres für den aktuellen Monat und aktuellem Jahr-zu-Datum. Produkt und Kunde variieren bei jeder Ausführung der Query. Vorhersage-Performance: Diese Query vergleicht die vorhergesagte Performance des letzten Monats mit aktuellen dieses Monate für den aktuellen Monat und aktuellem Jahr-zu-Tag. Produkt und Kunde variieren bei jeder Ausführung der Query. ad-hoc: Beantwortet ad-hoc-Queries auf der Datenbank. Maßstab, Szenario, Produkt, Kunde Kanal und Zeitperiode variieren bei jeder Ausführung der Query. 16 Die folgende Übersicht zeigt den Anteil der Queries an der Laufzeit des Benchmarks: 10% Kanal-Verkaufs-Analyse 10% Kunden-Gewinn-Analyse 15% Produkt-Bestands-Analyse 3% Zeitreihen-Analyse 5% Kundenbudget 5% Produktbudget 15% Vorhersage-Analyse 20% Budget-Performance 15% Vorhersage-Performance 2% ad-hoc Der APB-1 wird in sechs Schritten ausgeführt: Ausführung von APB1GEN zum Anlegen der Hierarchiefiles und historischen Daten Datenbankinitialisierung und Laden der historischen Daten Ausführung von APB1GEN zum Anlegen der inkrementellen Datenfiles inkrementelles Laden und Vorberechnung Ausführung von APB1GEN zum Anlegen der Query-Datenfiles Query-Ausführung Das Programm APB1GEN wird zur Generierung von Daten und Query-Informationen für den Benchmark genutzt. Bei jeder Publikation von Ergebnissen des APB-1-Benchmarks ist von Seiten des OLAPCouncils eine vollständige Offenlegung gefordert. Folgende Informationen müssen veröffentlicht werden: der Audit-Report das Datenbankschema der benötigter Code zum Laden der Daten der benötigter Code zur Vorberechnung die Anzahl der Nutzer die Größe jedes einzelnen Benchmark-Datenfiles Datenbankgröße Datenbank-Serversoftware Datenbank-Tuning-Parameter Hardware-Plattform und Konfiguration (CPU, Speicher) Betriebssystem und Konfigurationsparameter 17
