Einführung: Probleme und Herangehensweise

Präsentation zum Thema: "Einführung: Probleme und Herangehensweise"—  Präsentation transkript:

1 Einführung: Probleme und Herangehensweise
Datenbankauswertungen in großen Datenmengen - Spaltenorientierte Datenbank Einführung: Probleme und Herangehensweise Sybase Adaptive Server IQ und IQM Prinzip-Überblick Speicherungsstruktur und Indextypen IQ Multiplex Beispiele, Ergebnisse Jürgen Bittner

2 Das „gewöhnliche“ Performance-Problem
Ein Select braucht zu viel Zeit,... was tun ? Schnellere Hardware ? Überprüfen des Kommandos Prüfen des Datenbank-Servers Prüfen der Datenbank

3 Ein Select braucht zu viel Zeit,... was tun ?
Überprüfen des Kommandos Liegt eine ungünstige (evt. vermeidbare) Formulierung vor ? Besonderheiten der Hersteller sind zu beachten

4 Anfragebeispiel Wieviele Gastronomie-Einrichtungen in Sachsen haben kein „Radeberger“ ? SELECT COUNT (DISTINCT Einr) FROM Absatz WHERE Land = ‘SA‘ AND Typ = ‘G‘ AND Einr = IS NOT IN (SELECT DISTINCT Einr Prod = ‘Radeb‘) SELECT COUNT (DISTINCT Einr) FROM Absatz WHERE Land = ‘SA‘ AND Typ = ‘G‘ AND Einr = IS NOT IN (SELECT DISTINCT Einr Prod = ‘Radeb‘) SELECT COUNT (DISTINCT Einr) - AnzRadeb FROM Absatz, (SELECT COUNT(DISTINCT Einr) AS AnzRadeb FROM Absatz WHERE Land = ‘SA‘ AND Typ = ‘G‘ AND Prod = ‘Radeb‘) Typ = ‘G‘ Eps solve the most fundamental business problem of all, staying close to our customers, It enables us all to emulate personal touch and relate to our customers on a one-to-one basis. Eps promise to streamline corporations and improve productivity by delivering the right information to users at precisely the right time

5 Ein Select braucht zu viel Zeit,... was tun ?
Überprüfen des Kommandos Liegt eine ungünstige (evt. vermeidbare) Formulierung vor ? Besonderheiten der Hersteller sind zu beachten Prüfen des Zugriffsplans: Wurde ein nicht erwarteter Ablauf generiert ? Index-Benutzung: Wurde ein wirkungsvoller Index nicht ausgewählt ? Fehlt ein Index ? Reihenfolge der Joins Maßnahmen: Diverse Eingriffe wie Hints (Force Index, Parallelization, number of pages per read,...) Zerlegung der Query in mehrere Schritte mit Hilfe temporärer Tabellen Update statistics, u.ä. Prüfen des Datenbank-Servers Einschalten eines Performance-Monitors

6 Ein Select braucht zu viel Zeit,... was tun ?
Prüfen des Datenbank-Servers Einschalten eines Performance-Monitors Index-Benutzung Prozessaktivität Sperren Cache-Benutzung Task switches Prüfen der Datenbank Modifikation des Datenbank-Schemas Anlegen weiterer Indizes Einbauen von Aggregaten und anderen Redundanzen Partitionierung Häufig ergibt sich neues Konfliktpotential !

7 Tuning stößt häufig an Grenzen
Beispiele: „Spezial-Queries“ legen das komplette System lahm. Die Kapazität des Systems ist bereits bei irgendeiner Benutzer-Anzahl ausgeschöpft, es sollen aber zusätzliche, z.B. auch Intranet-Anwender unterstützt werden. Die Datenmengen sind sehr groß. Das Select wird von einem Endbenutzer-Werkzeug generiert.

8 Die grundlegende Entscheidung: Isolieren der Anfragen von den Transaktionen
Daten Log OLTP Server Daten Log Query Server Replication Server Stable Device REP Agent Enterprise Connect

9 Data Warehouse Architektur
Benutzer- Tool RDBMS Relationale DB Data Staging (ETL) Datamart Benutzer- Tool Enterprise Data Warehouse SW-Pakete RDBMS Datamart Benutzer- Tool Altdaten ROLAP Benutzer- Tool Externe Quellen Datamart Daten- Bereinigungs- Tool Warehouse Admin. Tools MOLAP unternehmen- weites/ zentrales Data Warehouse Daten-Extraktion, Transformation und Laden neu strukturierte (‘Architected’) Data Marts Quell- daten 3

10 Die Warnung

11

12 Bei sehr großen Datenmengen – prinzipielle Performanceprobleme
Beispielsituationen: „Das Analysesystem steht erst ab 11:00 Uhr morgens zur Verfügung.“ „Die Informationen sind immer auf dem Stand vom Vortag, benötigt werden aber Informationen, die max. 60 Minuten alt sind.“ „Das Data Warehouse speichert die Geschäftsvorgänge der letzten 6 Monate, benötigt werden aber die Trends über die letzten 2 Jahre oder mehr.“

13 (Häufige) Probleme in Business Intelligence Anwendungen
Antwortzeiten - sind zu lang Flexibilität und komplexe Abfragen - mit ständiger Erweiterung der Anforderungen (Ad-Hoc SQL) sind sehr problematisch Wachsende Nutzerzahl/ Datenmenge – Performance sinkt und genügt nicht mehr den Anforderungen Analyse auf Detaildatenebene - nicht alle Daten werden abgespeichert aufgrund der Größe des Datenbestandes  Arbeit mit verdichteten Daten Speicherung und Analyse von (sehr) großen Datenbeständen – zu teuer in Speicher, Administration und Antwortzeit Online-Loads - parallel zum Auswerten nicht (immer) möglich

14 Hohe Performance bei Datenbankauswertungen
Einführung: Probleme und Herangehensweise Sybase Adaptive Server IQ und IQM Prinzip-Überblick Speicherungsstruktur und Indextypen IQ Multiplex Beispiele, Ergebnisse

15 Der traditionelle RDBMS-Ansatz
Berechne den durchschnittlichen Absatz von „Radeberger“ in Gastronomie-Einrichtungen in Sachsen je Monat der letzten 3 Jahre SELECT AVG (Abs), SUM(Abs)/AnzGSA/36 FROM Absatz, (SELECT COUNT(DISTINCT Einr) AS AnzGSA FROM Absatz WHERE Land = ‘SA‘ AND Typ = ‘G‘) Typ = ‘G‘ AND Prod = ‘Radeb‘ Benutze einen Index wenn verfügbar benötigt normalerweise Table Scan Gehe zu den ausgewählten Datenseiten und addiere die Zahlen Zufällige Verteilung der Daten führt dazu, daß fast alle Seiten gelesen werden müssen. Auf jeder Seite müssen alle - auch die irrelevanten - Daten gelesen werden. Traditioneller Ansatz: Eps solve the most fundamental business problem of all, staying close to our customers, It enables us all to emulate personal touch and relate to our customers on a one-to-one basis. Eps promise to streamline corporations and improve productivity by delivering the right information to users at precisely the right time

16 Das Problem: Große Datenmengen
Berechne den durchschnittlichen Absatz von „Radeberger“ in Gastronomie-Einrichtungen in Sachsen je Monat der letzten 3 Jahre 360 Millionen Zeilen 200 Bytes pro Zeile 16K Seitengröße I/O’s pro Table Scan werden benötigt, mit schneller Platte, d.h. 40MB/sec Minuten !!! Sehr teuer und unflexibel bei Ad-hoc-Anfragen 36 Monate, Einrichtungen, 10 Produkte durchschnittlich pro Einrichtung

17 Vertikale Partitionierung
Sybase IQ: Daten sind in Spalten statt in Zeilen gespeichert. Vorteile: Es werden nur die relevanten Daten gelesen Einheitliche Datentypen deshalb Komprimierung möglich Datenbank ist einfach zu ändern und zu verwalten

18 Vertikale Partitionierung
Berechne den durchschnittlichen Absatz von Radeberger in Gastronomie-Einrichtungen in Sachsen je Monat der letzten 3 Jahre Sybase IQ: Es werden nur die relevanten Spalten gelesen Vorteile: Ohne weitere Techniken kann IQ den Disk-I/O sehr stark reduzieren Ergebnis im Beispiel: Reduzierung des Disk-I/O auf maximal 5% (ohne einen Index zu benutzen)

19 Komprimieren der Daten
SQL: Create table ABC yellow, blue, red..magenta ….. 100 OLTP Engine …. 100 IQ SQL:Select sum (red) from ABC Komprimieren in Zeilen bringt wenig wegen wechselnder Datentypen, sehr wirkungsvoll innerhalb einer Spalte Dekomprimieren von Zeilen ist ineffizient (CPU overhead) weil meist nur ein Teil benötigt wird Relative kleine Seitengröße bei OLTP bewirkt ungenutzten Platz Bit-wise and bit-mapped sehr platzgünstig Null values benötigen viel Platz in zeilen-orientierten DBMS Zeilen-orientierte DBMS benötigen mal mehr Speicherplatz als IQM Db page 2-32KB DB Page bis 2048 KB

20 yellow, blue, red..magenta
Platten-Laufwerke SQL: Create table ABC yellow, blue, red..magenta ….. 100 OLTP Engine …. 100 IQ SQL:Select sum (red) from ABC Problem kleine I/O Größe der zeilen-orientierten DBMS +90% braucht die Platte zum Suchen random I/O der zeilen-orientierten DBMS Suchzeiten verbessern sich nur langsam, CPUs schneller => mehr Laufwerke pro CPU Zeilen-orientiertes DBMS: 10 Laufwerke pro CPU (bevorzugt kleine Platten: 18-36GB) IQ : Laufwerke pro CPU (bevorzugt große Platten: GB) Zeilen-orientierte DBMS benötigen 10 – 20 mal mehr Laufwerke als IQM pro CPU Db page 2-32KB Db page bis 2048 KB

21 1 TB Datenkompression - Radikale Senkung
von Speicherbedarf und Wartung Herkömmliche DBMS Summaries Aggregates 1 – 2 TB Indexes 0,5 – 3 TB Base table “RAW data” no indexes 0,9 – 1,1 TB 2.4-6 TB Gleiche INPUT-Daten: “Konventionelles DW” ist 6x-10x größer als Sybase IQ DW LOAD Base table: 0,2 – 0,5 TB Indexes: 0,05 – 0,3 TB Aggr/Summ: 0 – 0,1 TB 0.25 - 0.9 TB INPUT DATA: 1 TB Source: Flat Files, ETL, Replikation, ODS

22 (select customer ID, group by product and account)
Sybase IQ – Praxisergebnisse Performance vs. Oracle - (Kundenbeispiel Citibank) Oracle Sybase IQ Durchschnittl Std. Antwortzeit Ladezeit Std. Plattenplatz GB Plattform CPU Ausführen von sechs komplexen Anfragen - Bankenanwendung (select customer ID, group by product and account) 6.9 Min. 3.1 Std. 8 GB 1-CPU

23 Hohe Performance bei Datenbankauswertungen
Einführung: Probleme und Herangehensweise Sybase Adaptive Server IQ und IQM Prinzip-Überblick Speicherungsstruktur und Indextypen IQ Multiplex Beispiele, Ergebnisse

24 Index in RDBMS am meisten angewendet: balanced-tree (B*)

25 4 Basis-Index-Typen und weitere Spezial-Typen
Bezeichnung Abkürzung Fast Projection FP Wird für jede Spalte grundsätzlich Verwendet, Default Index High Group HG Für UNIQUE und PRIMARY KEY notwendig Low Fast LF High Non Group HNG Comparison Index CMP Word Index WD Join Index JI Date-, Time-, Datetime Date,TIME,DTTM

26 Fast Projection (FP) Die Daten einer Spalte werden komprimiert gespeichert, abhängig von Datentyp und Kardinalität. Default Speicherung, die automatisch durch IQ realisiert wird und nicht entfernt werden kann für alle Spalten: notwendig für select list Spalten, string Suche, ad-hoc joins SELECT Land FROM Landtabelle WHERE Land LIKE ‘Sa%‘

27 Fast Projection (FP) Häufig wird dieser Default Index mit einem oder mehreren Indizes anderer IQ Index Typen verbunden. benutzt bei wildcard string Suche—z.B., LIKE ’%sys%’ Günstig für Berechnungen — z.B. SUM (A + B) Einzige Möglichkeit für Datentyp BIT Spaltenbeispiele: Addresse Name Texte

28 Fast Projection (FP) Subtype: FP(1)

29 Fast Projection (FP) Falls die Werteanzahl der Spalte < 256 ist, werden die Daten der Spalte als Fast Projection FP(1) anstelle von FP gespeichert 1-Byte look-up table Der Server versucht beim Laden FP(1) Setzt auf FP(2) nachdem 256 Werte erkannt wurden Der Datenbank-Administrator kann die Kardinalität der Spalte in der create table syntax durch Benutzung des UNIQUE Parameters angeben

30 Fast Projection (FP) Subtype: FP(2)

31 Fast Projection (FP) Falls die Werteanzahl der Spalte > 256 und < ist, werden die Daten der Spalte als FP(2) anstelle von FP gespeichert 2-Byte look-up table Setzt auf FP(3) nachdem Werte erkannt wurden Der Datenbank-Administrator kann die Kardinalität der Spalte in der create table syntax durch Benutzung des UNIQUE Parameters angeben

32 Low Fast (LF) Bitmap Index einschl. B-tree, der für Spalten mit kleiner Kardinalität benutzt wird Für jeden Spaltenwert ein Bitmap Menge solcher Bitmaps für Bearbeitung fast aller Anfragen angewendet Ideal für Spalten mit einer Kardinalität <1500 SELECT * FROM Absatz WHERE Prod = ‘Radeberger‘

33 Low Fast (LF) wird angewendet bei folgenden Anfrageoperationen:
Suchargumente in where-Klauseln Joins GROUP BY ORDER BY Spaltenbeispiele: Geschlecht Ja/nein Produktname Land Datum (falls < 1500 verschiedene Werte)

34 Dramatische I/O-Reduzierung
“Wieviele Männer sind in Kalifornien nicht versichert?“ Geschlecht M W 800 Bytes/Satz 20M Sätze Staat CA CA NY CA MA CT RDBMS Versichert J N J N J 800 Bytes x 20M 16K Seite = ,000 I/Os Verarbeitet grosse Mengen nicht benötigter Daten Erfordert oft “Full Table Scan” 20M Bits x 3 Spalten / 8 16K Seite = 470 I/Os M CA J M CA N W NY J 1 2 4 3 Geschlecht Staat Versichert = + 20M Bits

35 High Non Group (HNG) Beispiel:
Bit-weiser Index, optimiert für Bereichs-Suche und Aggregations-Funktionen Beispiel: SELECT SUM(Abs) FROM Absatz (1 * 64) + (0 * 32) + (1 * 16) + (6 * 8) + (4 * 4) + (3 * 2) + (4 * 1) = 154

36 High Non Group (HNG) Nicht-werte-basierter Bitmap-Index
Ideal für Spalten, die benutzt werden in: Ranges BETWEEN SUM( ) und AVG( ) Funktionen Spaltenbeispiele: Datum (falls > 1500 verschiedene Werte) Beträge Mengen

37 Index für Daten mit hoher Kardinalität
High Group (HG) Index für Daten mit hoher Kardinalität

38 High Group (HG) Verbesserter B-tree Index zur Ausführung von = und GROUP BY Operationen auf Spalten mit hoher Kardinalität Für Spalten mit großer Anzahl eindeutiger Werte (>1500) Wird benutzt, wenn die Spalte an einem Join beteiligt ist Spaltenbeispiele: Produkt Id Mitarbeiter ID

39 Prinzipielle Herangehensweise bei der Indexierung von Tabellen

40 Prinzipielle Herangehensweise bei der Indexierung von Tabellen (Forts

41 4 Basis-Index-Typen und weitere Spezial-Typen
Bezeichnung Abkürzung Fast Projection FP Wird für jede Spalte grundsätzlich Verwendet, Default Index High Group HG Für UNIQUE und PRIMARY KEY notwendig Low Fast LF High Non Group HNG Comparison Index CMP Word Index WD Join Index JI Date-, Time-, Datetime Date,TIME,DTTM

42 Optimierte Speicher - / Indexstrukturen
Beispiel – Abfrage: Berechne die Summe des Umsatzes, den durchschnittlichen Wert eines Verkaufs und die Anzahl der Verkäufe je Monat und Kunde für eine spezielle Produktart SELECT Kunde.Name, Verkauf.Monat, SUM(Verkauf.Wert), AVG(Verkauf.Wert), Count(Verkauf.Verkauf_id) FROM Kunde, Verkauf Where Kunde.Kunde_id = Verkauf. Kunde_id AND Verkauf.Produkt_Name LIKE “%anzug%” AND Verkauf.Jahr = 2000 GROUP BY Verkauf.Monat, Kunde.Name So let’s consider what happens when a predicate is to be evaluated. Suppose we want the names and addresses of all the customers whose birthdays are in July… In a typical database engine, the optimizer would first estimate the percentage of rows to be returned. This would be 1 out of 12, assuming that birthdays are equally frequent in all months. Next, the optimizer would determine that it’s not worthwhile to use an index. It would therefore do a full-table scan. In order to get a rough estimate of the cost of this scan, lets assume that each customer row is 3200 bytes, and that there are a million customers. Then a full table scan entails reading 3.2 billion bytes of data.

43 Optimierte Speicher - / Indexstrukturen
SELECT Kunde.Name, Verkauf.Monat, SUM(Verkauf.Wert), AVG(Verkauf.Wert), Count(Verkauf.Verkauf_id) FROM Kunde, Verkauf Where Kunde.Kunde_id = Verkauf. Kunde_id AND Verkauf.Produkt_Name LIKE “%anzug%” AND Verkauf.Jahr = 2000 GROUP BY Verkauf.Monat, Kunde.Name 2 “Fast Projection” Indizes für die Projektion 1 “High Non Group” Index für die Aggregatbildung So let’s consider what happens when a predicate is to be evaluated. Suppose we want the names and addresses of all the customers whose birthdays are in July… In a typical database engine, the optimizer would first estimate the percentage of rows to be returned. This would be 1 out of 12, assuming that birthdays are equally frequent in all months. Next, the optimizer would determine that it’s not worthwhile to use an index. It would therefore do a full-table scan. In order to get a rough estimate of the cost of this scan, lets assume that each customer row is 3200 bytes, and that there are a million customers. Then a full table scan entails reading 3.2 billion bytes of data. 4 “High Group” Indizes für die Aggregatbildung, die Join-Verarbeitung und das Gruppieren pro Kunde 2 “Low Fast” Indizes für die Suchbedingung und das Gruppieren auf Monatsebene 1 Word Index für Zeichenkettensuche

44 Beispiel 1 “High Non Group” Index für die Aggregatbildung
SELECT AVG (Abs), SUM(Abs)/AnzGSA/36 FROM Absatz, (SELECT COUNT(DISTINCT Einr) AS AnzGSA FROM Absatz WHERE Land = ‘SA‘ AND Typ = ‘G‘) Typ = ‘G‘ AND Prod = ‘Radeb‘ 1 “High Non Group” Index für die Aggregatbildung 1 “High Group” Index für die Aggregatbildung 3 “Low Fast” Indizes für die Suchbedingung

45 Vertikale Partitionierung
Berechne den durchschnittlichen Absatz von Radeberger in Gastronomie-Einrichtungen in Sachsen je Monat der letzten 3 Jahre Sybase IQ: Es werden nur die relevanten Spalten gelesen Vorteile: Ohne weitere Techniken kann IQ den Disk-I/O sehr stark reduzieren Ergebnis im Beispiel: Reduzierung des Disk-I/O auf maximal 5% (ohne einen Index zu benutzen)

46 Vertikale Partitionierung
Berechne den durchschnittlichen Absatz von Radeberger in Gastronomie-Einrichtungen in Sachsen je Monat der letzten 3 Jahre SELECT AVG (Abs), SUM(Abs)/AnzGSA/36 FROM Absatz, (SELECT COUNT(DISTINCT Einr) AS AnzGSA FROM Absatz WHERE Land = ‘SA‘ AND Typ = ‘G‘) Typ = ‘G‘ AND Prod = ‘Radeb‘ Sybase IQ: Es werden nur die relevanten Spalten gelesen Ergebnis im Beispiel: Reduzierung des Disk-I/O auf max. 2%

47 Eurostat : wide table – 10 Mio rows

48 Eurostat : Horizontale Partitionierung

49 Eurostat : Vertikale Partitionierung

50 In IQ : 757 FP, 45 HG, 512 LF, 103 HNG = 1417 index
Eurostat : In IQ-M In IQ : 757 FP, 45 HG, 512 LF, 103 HNG = 1417 index

51 Sybase IQ und überprüfte Einsparungen bei Plattenspeicher
DATA COMPRESSION Beispiele Geladene Rohdaten Sybase IQ komprimiert Erwartete Datenexplosion bei anderen Anbietern Sun DWH Reference Architecture (InfoSizing – August 2007) 1 PB 260 TB 3 PB bis 7 PB Sun DWH Reference Architektur (InfoSizing – June 2004) 155 TB 55 TB 500 TB bis 1,000 TB Telefonica 70TB 15 TB 210 TB bis 490 TB comScore Networks 40 TB 16 TB 120 TB bis 280 TB Health Insurance Review Agency 27 TB 12 TB 81 TB bis 189 TB Samsung Card 7 TB 45 TB bis 105 TB Nielsen Media Research 36 TB bis 84 TB Large Credit Card Company 10 TB 4 TB 30 TB bis 70 TB Make the point here much disk space is saved and therefore cost

52 Hohe Performance bei Datenbankauswertungen
Einführung: Probleme und Herangehensweise Sybase Adaptive Server IQ und IQM Prinzip-Überblick Speicherungsstruktur und Indextypen IQ Multiplex Beispiele, Ergebnisse

53 Fiber Channel Storage Area Network
Skalierbarkeit “Starte klein und wachse” mit Sybase IQ Multiplex Konfiguration IQ-M CPU IQ-M CPU IQ-M CPU IQ-M CPU IQ-M CPU Starten mit einem Server Hinzufügen von CPUs u. Speicher nach Bedarf CPU Multiplexing ermöglicht es, weitere Server und CPUs hinzuzufügen dabei kein bis minimaler Verlust an Skalierbarkeit; die 1000ste CPU wird so gut wie die erste CPU performen Fiber Channel Storage Area Network Terabytes an Festplatten können ins SAN eingefügt werden IQ-M wird diese effektiv nutzen Skaliert wie ein Grid

54 Skalierbarkeit Nachgewiesen im Labor und bei Kunden 98% 31.6 sec
Sybase IQ Multiplex Test der Skalierfähigkeit Anwender 500 Users 400 400 98% 360 320 300 280 240 200 200 400 User Antw-Zeit = 31.6 sec Erhöhung : 1.9% (0.6 sec) 40 User Antw-Zeit: 31 sec 160 120 100 80 40 31.6 sec 31 sec Knoten 1 2 3 4 5 6 7 8 9 10 Workload: Each user executing random sequence of (TPC/H-like) queries (Source : HP Lab in San Bruno, CA)

55 Fiber Channel Storage Area Network
Skalierbarkeit Einfache Administration und implizite Hochverfügbarkeit Read/ Write Knoten Read/ Write Knoten Read/ Write Knoten Read Knoten HOCHVERFÜGBARKEIT - Keine Unterbrechung des Datenbankzugriffs für andere Knoten - Andere Knoten werden durch Ausfall nicht beeinflußt -Anwender können Queries nach Start des Knotens einfach wiederholen oder automatisch auf anderen Knoten ausweichen (Sybase Open Switch, HW, …) -Bei gespiegelten Platten “no single point of failure” Architektur Read Knoten SKALIERBARKEIT Nach hinzufügen eines Knotens KEIN globaler Lock Manager nötig KEINE Datenumverteilung erforderlich KEINE Änderungen im Schema SEHR geringe I/O Contention IQ-M CPU IQ-M CPU IQ-M CPU IQ-M CPU IQ-M CPU CPU Fiber Channel Storage Area Network Skaliert wie ein Grid

56 Technische Limits Datenbankgröße: Betriebssystemabhängig
Geeignet für sehr große Datenbanken Datenbankgröße: Betriebssystemabhängig Maximal 192 PByte Anzahl Tabellen pro Datenbank: Zeilen pro Tabelle: Tabellen/ Views in einer Query: 512 Feldgröße für “Long Varchar” oder “Long Binary” IQ Page Größe 128K: bis zu 512 TB IQ Page Größe 512K: bis zu 1 PB Größe einer Page: 64 KB bis 512 KB Anzahl Spalten pro Tabelle:

57 Speicherung ALLER relevanten Daten in EINEM System
Internet ( und Dokumente) Anwender können weiter ihren bisherigen Client nutzen – können aber auch auf das System zugreifen Dokumente Bilder Video Audio Fax Datei und DB Backup Andere Daten Partner- lösung Vor- handener Server Partnerlösung Dokumente und Clients ( Optional ) DW Transaktionen Sybase IQ Weitere Daten können in der Lösung nach Bedarf hinzugefügt werden

58 Sun Reference Warehouse Architecture Juli 2007 - weltgrößtes DWH
Die Sun Data Warehouse Referenz Architektur, bestehend aus SolarisTM 10 OS, Sybase® IQ und BMMsoft DataFusionTM mit einem Sun SPARC® Enterprise M9000 Server erbrachte folgende wichtige Ergebnisse: Es wurden ein 1 PByte transaktionale Rohdaten (6 Trillionen Sätze mit Kursdaten von Börsen) in ein voll indexiertes Starschema geladen Es wurde eine Ladegeschwindigkeit von 285 Milliarden Sätze pro Tag (3 Millionen Sätze pro Sekunde) erzielt Es wurde eine 85%-ige Datenkompression bei der Speicherung von einem PByte transaktionaler Rohdaten erreicht – diese Daten belegten weniger als 260 TByte Plattenplatz im System Es zeigte eine durchschnittliche „Ready-Time“ von kleiner zwei Sekunden nach dem Hinzufügen von neuen Daten in das Data Warehouse Es wurde die Hälfte der „T“ (Transaktional) Daten mit über 72 Terabyte an “EDM” ( s, Dokumente und Multimedia) Daten ersetzt – Aufbau eines 572 TByte großen Data Warehouse mit „EDMT“ Daten Es wurde eine Ladegeschwindigkeit von 26 TByte pro Tag beim Aufbau eines Data Warehouse mit 185 Millionen Dokumenten ( s, Attachements und andere unstrukturierte Dokumente) erreicht Es wurde eine Ladegeschwindigkeit von zwei Millionen s pro Stunde und 6 Millionen Dokumente pro Stunde erreicht – dabei wurden weniger als 7% der verfügbaren CPU Leistung benötigt Audit show show The Sun Data Warehouse Reference Architecture, powered by SolarisTM 10 OS, a Sybase® IQ analytic server and BMMsoft DataFusionTM on a Sun SPARC® technology Enterprise M9000 server interconnected to three Sun StorageTekTM 6540 arrays, demonstrated several significant achievements: 􀂃 It loaded 1 Petabyte of raw transactional data (6 Trillion stock quote records) in a fully indexed star schema; creating a new, independently verified record for the world’s largest data warehouse. 􀂃 It reached a load speed of 285 billion rows per day (3 Million rows per second) and sustained that database population pace for a period of over 3 weeks. 􀂃 It showed an 85% data compression ratio by storing a Petabyte of raw transactional data in less than 260 Terabytes of actual disk space. 􀂃 It demonstrated an average Ready-Time of less than 2 seconds for data freshly added to the data warehouse. 􀂃 It replaced half of the “T” (Transactional) data with over 72 Terabytes of “EDM” ( s, Documents and Multimedia) data, creating a data warehouse populated with 572 Terabytes of raw “EDMT” data. 􀂃 It showed a load speed of 26 Terabytes per day when populating the data warehouse with 185 million documents ( s, attachments and other unstructured documents.) 􀂃 It reached loading rates of 2 million s per hour and 6 million documents per hour while consuming less than 7% of the available CPU power, leaving 93% of the M9000’s CPUs available for other activities. 􀂃 It demonstrated a substantial reduction in the number of disk drives needed for storage, translating directly into at least 90% reduction in CO2 emission over the lifetime of the Sun Data Warehouse Reference Architecture using Solaris 10 OS, Sybase IQ and BMMsoft DataFusion.

59 Sun DWH Reference Architecture
Ein Sun SPARC® Enterprise M9000 Server mit Solaris™ 10 Drei Sun StorageTek™ 6540 Storage Arrays verbunden mit dem Server über Fiber Channel Sybase® IQ 12.7 Enterprise Edition BMMsoft DataFusion für die Verwaltung unstrukturierter Daten und s Hauptspeichernutzung Sybase IQ Writer nutzte 64 Cores (mit zusammen 128 Threads) und 100 GB Hauptspeicher 45 GB Hauptspeicher für den Sybase IQ Ladeprozess und als Cache für Teile der geladenen Dateien Der BMMsoft DataFusion Ladeserver nutzte 64 Cores (mit zusammen 128 Threads) und 40 GB Hauptspeicher 20 GB Hauptspeicher für Solaris 10 zur Optimierung von Swapping und Paging Quelle: Sun Data Warehouse Reference Architecture for Structured and Unstructured Data, InfoSizing, August 20, 2007

60 Hohe Performance bei Datenbankauswertungen
Einführung: Probleme und Herangehensweise Sybase Adaptive Server IQ und IQM Prinzip-Überblick Speicherungsstruktur und Indextypen IQ Multiplex Beispiele, Ergebnisse

61 Online-Archiv auf Basis Sybase IQ
Sybase ASE und heterogene Umgebungen CICS Trx IBM MVS (z/OS) DB2(CICS) DB2(IMS) DB2(DRDA) IDMS IMS VSAM PLACE_ ORDER Direct Connect TABLE KUNDE Applikation TABLE ODBC AS/400 Informix Microsoft Oracle DB2/UDB ASE CIS ORDER Direct Connect TABLE VERTRAG PLACE_.. ORDER_ HISTORY Technologische Grundlagen: Component Integration Services von Sybase ASE Proxy Tabellen Union in Views Instead-of-Trigger (ASE ) Transparent für SQL VERTRAG TABLE ORDER_ HISTORY Archiv: Sybase IQ Physik. Speicherung/ Logik Proxy Tabelle 12 12 5 6 3 3

62 Partnerlösungen (Auswahl)
PBS (Deutschland) SAP BI Archivlösung Rent-a-Brain (Deutschland) iMarc- archivierung Dokumentenarchivierung BMMSoft (USA) /-/ Dokumentenarchivierung

63 PBS CBW NLS IQ Introduction
PBS CBW NLS IQ for Sybase IQ is a powerful and complete Nearline Storage Solution for SAP Business Intelligence SAP BI Sybase IQ Administration/ Monitoring SAP NLS Data Archiving Process (DAP) PBS CBW NLS IQ Interface Load Data Access: Queries, Reload, ... Read Data server CBW NLS IQ Infrastrutcure (without adk components)

64 CBW-Architektur mit NLS und Sybase IQ
SAP Nearline Provider InfoCube DataStore Objekt DB und Nearline lesen (in Query-Attributen aktivieren) SAP BW Datenbank SAP BW Query PBS Nearline Services für Sybase IQ Spalten-basierte Data Warehouse DB, Kompression bis 1:10 Sybase IQ

65 Kompressionen InfoCubes - Kundenbeispiel
Größe arch. Daten Größe Daten in Sybase IQ Kompression auf INDIA03 Bytes Bytes 8 % INDIA21 Bytes Bytes 4 % FAKT01 Bytes Bytes 11 % FAKT21 Bytes Bytes 5 % FAKTP02 Bytes Bytes ERG002 Bytes Bytes 0FIAR_C02 Bytes Bytes 9 % 0FIAR_C03 Bytes Bytes 12 %

66 Query „Markthierarchie“ – Speed (I)
M_INDIA01/WEB1_M_INDIA01_MARHIE_ZJVJB Kundenhierarchie über Attribut KDUNIQUE 2003 – 2007 Anzahl Datensätze: 17 Mio. Zugriffsart Sybase IQ Oracle DB mit Aggregaten ohne Aggregate Primärliste 16 s 71 s 416 s Sybase IQ (16s) Oracle mit Aggregaten (71s -> Faktor 4) Oracle ohne Aggregate (416s -> Faktor 26) Zeit [s]

67 Query „Fakturen“ – Speed (I)
Query M_FAKT01/STD_M_FAKT01_ASS_PC Fakturaauswertung Anzahl Datensätze: 57 Mio. Zugriffsart Sybase IQ Oracle DB mit Aggregaten ohne Aggregate Primärliste 12 s 164 s nach 2000 s abgebrochen Sybase IQ (12s) Oracle mit Aggregaten (164s -> Faktor 14) Oracle ohne Aggregate (abgebrochen) Zeit [s]

68 Erfahrungsbericht – Fazit Kundeninstallation
Speed Bis zu 14 x schnellere Antwortzeiten Kompression Kompression der Archivdaten bis zu 95 % Administration Keine Index- keine Aggregat- Modellierung

69 Mehr als 1500 Kunden Erfolgreich etablierte und schnell wachsende Kundenbasis Mehr als 3000 Kundenprojekte bei mehr als 1500 Kunden weltweit But it’s not just want the analysts are saying. Customers are getting the message, as some of our recent successes indicate.

70 Analysten Gartner Gartner Data Warehouse Magic Quadrant Position: Challenger IDC “Wir haben beobachtet und darauf gewartet, dass Firmen, die Datenbanken implementieren, sich vermehrt für Sybase IQ und seine einzigartige Tabellen- und Indexstruktur entscheiden. Denn diese sichert eine beeindruckende Performance bei komplexen Abfragen auf großen Data Warehouses. Gemessen an den Markterfolgen der letzten Jahre scheint es so, dass der Markt endlich ‘begriffen‘ hat.” Carl Olofson, Research Vice President Information Management and Data Integration Software Research IDC 2007

71 Telekommunikations-DB
Zeilen 24 72 12

72 Voraussetzungen und Laden

73 Anfragebeispiele

74 Anfragebeispiele

75 Anfragebeispiele

76 Anfragebeispiele

77 Anfragebeispiele

78 Anfragebeispiele

79 EDS Report: IQM vs “konventionelles” RDBMS

80 Sun‘s iForce Enterprise Data Warehouse Reference Architecture
Basiert auf Sybase Adaptive Server IQ Multiplex mit 156 CPUs und 160 GB RAM Ergebnisse: 48,2 Terabyte Rohdaten korrespondieren mit 22 Terabyte Speicherverbrauch 5-160 Millionen Records werden täglich geladen in < 1h Konkurrenz zwischen Laden und Anfragen der gleichen Tabelle bringt nur 6,9 % Verlangsamung Bis zu 1000 x schnellere Analyse-Laufzeiten 80% weniger Installationsaufwand Unterstützt Tausende Anwender gleichzeitig

81 Kunden in Deutschland (Auszug)
1&1 Internet AG Bertelsmann Music Group EMI Electrola RTL Television Allianz-Dresdner Bausparkasse Dresdner Bank Vodafone D2 GmbH DekaBank Deutsche Bank Citibank DEVK Allgemeine Versicherungen AG Risk Consulting Raiffeisen Hauptgenossenschaft Nord Müller (Drogeriemärkte) European Southern Observatory … In the Financial Services Industry, again we’ve enjoyed considerable success. As you can see, this list is mostly from North America. This would indicate an untapped market in Europe and Asia. As all of you in FSI know, this is a tight lipped bunch – primarily because of government regulations - not generally doing success stories, but these accounts are often very referenceable.