Performance-Vergleich zwischen InterSystems Caché und Oracle in einer Data-Mart-Applikation

Ähnliche Dokumente
Antwortzeitverhalten von Online Storage Services im Vergleich

Systemvoraussetzungen

NEVARIS Build Systemvoraussetzungen

NEVARIS Build Systemvoraussetzungen

Technische Voraussetzungen und Kompatibilitätsliste GemDat/Rubin

Inhaltsverzeichnis. BüroWARE Systemanforderungen ab Version Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2

Technische Voraussetzungen und Kompatibilitätsliste GemDat/Rubin

Business Intelligence Praktikum 1

Systemanforderungen (Mai 2014)

Inhaltsangabe zu den Systemvoraussetzungen:

dg portal 7.0 Produktdatenblatt

NEVARIS Build Systemvoraussetzungen

EINSATZ VON MICROSOFT TERMINAL-SERVICES ODER CITRIX METAFRAME

Performante Selektionen im Massendatenbereich. Eine technische Skizze am Beispiel des Tools AZ Select

Inhaltsangabe zu den Systemvoraussetzungen:

Technische Voraussetzungen und Kompatibilitätsliste GemDat/Rubin

Data Cubes PG Wissensmangement Seminarphase

Optimiertes Laden in die F-Fakten-Tabelle des SAP BW

Hardware- und Softwareanforderungen für die Installation von California.pro

PMD R2/DMM R2 Local V2.0.4

Hardware- und Softwareanforderungen für die Installation von California.pro

Systemvoraussetzungen:

PLATO-Systemanforderungen

Systemvoraussetzungen: DOMUS 4000 Stand 02/15

Perceptive Document Composition

Vorlesung Wissensentdeckung in Datenbanken

Systemanforderungen. Sage Personalwirtschaft

Dokumentation QuickHMI Erste Schritte

mobilepoi 0.91 Demo Version Anleitung Das Software Studio Christian Efinger Erstellt am 21. Oktober 2005

Systemvoraussetzungen: DOMUS NAVI für DOMUS 1000 Stand 09/15

Zugriff aus Oracle via Proc SQL: Performanceprobleme

Systemvoraussetzungen:

NEXT LEVEL HOSTING VON 1&1 PERFORMANCE LEVEL: LEISTUNG, DIE MIT IHREN ANFORDERUNGEN WÄCHST

Systemvoraussetzungen:

Oracle 9i Einführung Performance Tuning

Systemvoraussetzungen:

ISIS MED Systemanforderungen. Die innovative Software-Lösung für die Arbeitsmedizin und Sozialarbeit

Performance Zertifizierung

Ihr Benutzerhandbuch F-SECURE PSB AND SERVER SECURITY

Systemvoraussetzungen:

Partitionierungsstrategien für Data Vault

Hard- und Softwareanforderungen für WinSped

Systemvoraussetzungen: DOMUS 4000 Stand 06/16

Systemanforderungen. Finanzbuchführung. Anlagenbuchführung. Kostenrechnung. Personalwirtschaft

Projektbericht Gruppe 12. Datenbanksysteme WS 05/ 06. Gruppe 12. Martin Tintel Tatjana Triebl. Seite 1 von 11

Tuning von PostGIS mit Read- Only-Daten von OpenStreetMap

KINDERMANN TCV GmbH. Systemanforderungen (PC-Systeme, Server, Drucker, Netzwerk)

Systemanforderungen (Oktober 2016)

cytan Systemvoraussetzungen

ISIS MED Systemanforderungen

Systemvoraussetzungen: DOMUS NAVI für DOMUS 4000 Stand 02/15

Erzeugung und Veränderung von Tabellen

Systemvoraussetzungen. Titel

Softwarelösungen. Systemvoraussetzung E+S Anwendung Forms10

Softwarelösungen. Systemvoraussetzung E+S Anwendung Forms11

Systemvoraussetzungen Stand

Funktion Sage SalesLogix Windows Systemvoraussetzungen

Client: min. Intel Pentium IV oder höher bzw. vergleichbares Produkt

elpromonitor Software - Systemvoraussetzungen

Möglichkeiten für bestehende Systeme

Seminar im Sommersemester 2004 an der Universität Karlsruhe (TH)

enerpy collaborative webased workflows collaborative webbased groupware INDEX 1. Netzwerk Überblick 2. Windows Server 2008

Systemanforderungen. Sage Personalwirtschaft

NEVARIS Build Systemvoraussetzungen

Enterprise Portal - Abbildung von Prozessen, SAP-Datenintegration und mobile Apps

Systemanforderungen ab Version 5.31

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen

Systemanforderungen für MSI-Reifen Release 7

A Datenbanken. A.1 Firebird. A.1.1 Installation des Servers. A.1.2 Installation der Beispieldatenbanken. Datenbanken 1

Systemvoraussetzungen winvs office winvs advisor

Fachbereich Informatik Praktikum 1

app.telemetry Statistiken zu Suchanfragen ad-hoc Reports und Statistik Dashboard Charts Version 2017 Summer Release

ComfortsAutomatic-Datamodel

4/5 Copyright All R e t ech e vorb al eh : ten

Dokumentation QuickHMI Runtime Manager

In diesem Abschnitt wollen wir uns mit der Architektur von Datenbank Managements Systemen beschäftigen.

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Systemanforderungen. Sage Personalwirtschaft

Checkliste Systemvoraussetzungen. Systemvoraussetzungen für den Datenbank-Server von MKS Goliath

DOAG Demo Kino: Advisors, Monitoring Werkzeuge in der Datenbank Ulrike Schwinn Business Unit Database Oracle Deutschland B.V.

Hochschule Darmstadt Data Warehouse SS 2015 Fachbereich Informatik Praktikumsversuch 5

Professionelle betriebswirtschaftliche Software. Sage New Classic (5.0) Systemvoraussetzungen

Caché auf OpenVMS. Peter Burnes Abteilungsleiter Services & Technology SHD Datentechnik GmbH & Co. KG

Data Warehouse in der Telekommunikation

Data Cube. Aggregation in SQL. Beispiel: Autoverkäufe. On-line Analytical Processing (OLAP) 1. Einführung. 2. Aggregation in SQL, GROUP BY

Einsatzszenarien und Erfahrungen mit Adobe Connect. Holger Hansen

wiko Bausoftware GmbH

GROUP BY, HAVING und Sichten

Hardware- und Softwareanforderungen für die Installation von California.pro

3. Stud.IP-Entwickler-Workshop 2. Juni 2006 Workshop 3c: Stud.IP-Enterprise-Edition André Noack, Frank Elsner

Erfahrungsbericht, Konsolidierung und Administration Real Application Cluster

WHITEPAPER SanDisk DAS Cache: OLTP-Performance

Fleischhacker MediConnect 2 Systemanforderungen

Perceptive Document Composition

Oracle In-Memory & Data Warehouse: Die perfekte Kombination?


Freiberuflicher IT-Berater Schwerpunkte: Unix, Oracle, Netzwerk. Dipl.-Inform. Joachim Jäckel

Data Warehousing. Sommersemester Ulf Leser Wissensmanagement in der Bioinformatik

Transkript:

Performance-Vergleich zwischen InterSystems Caché und Oracle in einer Data-Mart-Applikation Kurzfassung Im Rahmen einer simulierten Data-Mart-Applikation testete ein globaler Anbieter von Software für die mobile Telekommunikation die Datenbank- Performance von InterSystems Caché und Oracle. Der Test ergab, dass sich ein Data-Mart mit Caché 41 % schneller als mit Oracle erzeugen lässt. Beim Testen der Reaktionszeit des Data-Marts auf SQL-Abfragen lag die Performance von Caché bis zu 513 Mal höher als bei Oracle. Mark Massias Systems Engineer InterSystems Corporation

Performance-Vergleich zwischen InterSystems Caché und Oracle in einer Data-Mart-Applikation Vorwort In der Telekommunikationsbranche werden enorme Datenmengen erzeugt, die es zu analysieren gilt. Das stellt höchste Ansprüche an die genutzten Datenbanken. Um angesichts dieser Herausforderungen brauchbare Business Intelligence-Lösungen zu entwickeln, werden in der Regel wichtige Teile der Rohdaten in ein sogenanntes Data-Mart ausgelagert, dort indiziert, aufbereitet und anschließend für die Analyse freigegeben. Doch selbst diese Data- Marts können Hunderte von Gigabyte groß werden. Eine gute Datenbank- Performance sowohl bei der Erzeugung des Data-Marts als auch hinsichtlich der Reaktionszeit bei Abfragen ist die entscheidende Voraussetzung für die zeitnahe Analyse der Daten und damit letztlich dafür, ob ein Unternehmen in der Lage ist, Änderungen in seiner Geschäftsumgebung zu erkennen und entsprechend auf sie zu reagieren. Dieses White Paper stellt die Ergebnisse der vergleichenden Performance- Tests zwischen InterSystems Caché und Oracle vor. Die Tests fanden bei einem globalen Anbieter von Software für die mobile Telekommunikation statt, der Datenbanktechnologie zur Einbindung in neue Business Intelligence- Applikationen für die Analyse der Nutzung von Mobiltelefonen evaluierte. Der Test Für den Test simulierte man ein typisches Data-Mart-Szenario. Im ersten Teil des Tests wurden große Mengen Mobiltelefondaten geladen, indiziert und aggregiert. Dabei wurde gemessen, wie viel Zeit die einzelnen Schritte beanspruchten und wie groß die erzeugte Datenbank war. Im zweiten Teil des Tests ermittelte man die Reaktionszeiten bei verschiedenen SQL-Abfragen. Alle Tests fanden auf einem dedizierten Server des Typs HP DL380 statt, auf dem Linux Red Hat A.S. 3.0 in der 32-bit-Version lief. Der Server war mit 4 GB RAM und 2 GB Shared Memory sowie einem 3,4-GHz-XEON-Prozessor bestückt. 2

Teil 1 Laden, Indizieren und Aggregieren von Daten Das im Test verwendete simulierte Data-Mart bestand aus einer Faktentabelle, die folgende Elemente enthielt: Hersteller Hersteller des Mobiltelefons Modell Mobiltelefonmodell MSISDN (internationale ISDN-Rufnummer der Mobilstation, d. h.: die Telefonnummer) Roaming (Ja/Nein) Nutzt der Teilnehmer Roaming? Wechsel (Ja/Nein) Hat ein Teilnehmer die Region gewechselt? Region In welcher Region befindet sich der Teilnehmer (Anbieter bedienen u. U. mehrere Regionen)? Die Faktentabelle wurde mittels einer Kombination aus Standard- und Bitmap- Indizes indiziert, um die Reaktionszeiten auf Abfragen zu verkürzen. Darüber hinaus wurden mehrere Summentabellen erzeugt, in denen die Daten geordnet nach Hersteller, Modell, Region und Permutationen dieser Elemente aggregiert wurden. Das System wurde mit 10 jeweils 500 MB großen Dateien beschickt also insgesamt 5 GB Daten. Abbildung 1 zeigt, wie viele Sekunden das Laden, Indizieren und Aggregieren dauerte. Caché benötigte für den kompletten Prozess insgesamt 2.819 Sekunden. Gemessen an den 3.967 Sekunden, die Oracle benötigte, ist das ein Geschwindigkeitsvorteil von 41 Prozent. Abbildung 1: Zeiten für das Laden, Indizieren und Konsolidieren der Daten Zeit (s) 4. 0 00 3. 500 3. 000 2. 500 2. 000 1. 500 1. 000 500 0 Caché Oracle Laden (s) Indizieren (s) Aggregieren (s) Insgesamt (s) 649 1. 878 2 92 2. 819 1. 018 1. 413 1. 536 3. 967 3

In Abbildung 2 werden die Größen der erzeugten Datenbanken und Indizes verglichen. Caché ist 7,8 Prozent kleiner und belegt damit etwas weniger Speicherplatz. Abbildung 2: Datenbankgrößen Größe (MB) 7. 000 6. 000 5. 000 4. 000 3. 000 2. 000 1. 000 0 Caché Oracle Tabellengröße (MB) Indexgröße (MB) Gesamtgröße (MB) 5. 065 1. 080 6. 145 5. 544 1. 126 6. 670 Teil 2 Reaktionszeit bei Abfragen Fünf verschiedene SQL-Abfragen wurden jeweils an die Caché- und die Oracle- Datenbank geschickt: Abfrage 1: select count(*) from fact_table where MSISDN like %579% Abfrage 2: select count(*) from fact_table where MSISDN like %356% and Manufacturer= Nokia Abfrage 3: select * from fact_table where MSISDN like %59421% Abfrage 4: select * from fact_table where MSISDN like %21%46% and ISRoamer = 0 and ISChanged = 1 Abfrage 5: select * from fact_table where MSISDN = 161323202273 and ISRoamer = 0 Alle Abfragen wurden ohne vorheriges Aufwärmen der Datenbank gestartet. Damit vermied man, dass auf gecachte Daten zurückgegriffen werden konnte, und schuf so eine aussagekräftigere Basis für den Performance-Vergleich. 4

Bei der Erzeugung der Oracle-Datenbank wurden mehrere Indizierungsstrategien getestet. Eine von ihnen stellte die von der Caché-Datenbank genutzte Strategie nach. Andere waren speziell auf die Optimierung der Performance der Oracle-Datenbank ausgelegt. Die in der Abbildung aufgeführten Reaktionszeiten stellen die jeweiligen Bestwerte dar, die für die Oracle-Datenbank erzielt wurden. Abbildung 3 zeigt die Reaktionszeiten in Millisekunden für jede der fünf SQL- Abfragen. Caché war bei jeder der Abfragen die schnellere Datenbank. Tabelle 1 zeigt, um wie viel schneller Caché war. Dazu ist für jede Abfrage das Verhältnis zwischen Caché- und Oracle-Reaktionszeit aufgelistet. Abbildung 3: Performance bei Abfragen (in ms) Zeit (ms) 2.000.000 1.800.000 1.600.000 1.400.000 1.200.000 1.000.000 800.000 600.000 400.000 200.000 0 Caché Oracle Abfrage 1 Abfrage 2 Abfrage 3 Abfrage 4 Abfrage 5 31.316 340.106 218 19. 724 990.750 146.831 6 02.596 111.961 122. 737 1.838.704 Abfrage Tabelle 1: Verhältnis der Reaktionszeit von Caché/Oracle Abfrage Caché schneller als Oracle um den Faktor 1 4,7 X 2 1,8 X 3 513 X 4 6,2 X 5 1,9 X 5

Schlussbemerkung Im Rahmen von Tests, bei denen eine Datenanalyse-Applikation simuliert wurde, wie sie für einen Anbieter von TK-Software typisch ist, erwies sich Caché beim Erzeugen eines Data-Marts mit Mobiltelefondaten 41 % schneller als Oracle. Bei SQL-Abfragen am erzeugten Data-Mart waren die Reaktionszeiten von Caché um das 1,8- bis 513-Fache besser. Es zeigte sich eindeutig, dass die einzigartige multidimensionale Data Engine von Caché eine hervorragende Wahl für Applikationen ist, bei denen in kurzer Zeit große Datenmengen analysiert werden müssen. 6

Deutschland InterSystems GmbH Hilpertstr. 20a D-64295 Darmstadt Tel.: +49.6151.1747-0 Fax: +49.6151.1747-11 InterSystems.de Schweiz InterSystems B.V. In der Luberzen 42 CH-8902 Urdorf Tel.: +41.43.455.7711 Fax: +41.43.455.7722 InterSystems.ch Copyright 2011 InterSystems Corporation. Alle Rechte vorbehalten. 07-11