Folien

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
SQL Projekt AG FSU 290610, 1
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
SQL Projekt AG FSU 290610, 2
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
SQL Projekt AG FSU 290610, 3
Anfragebeispiel
Mon
Einr
Typ
Land
Prod
Abs
0105
32
G
SA
Werne
12
0105
36
G
MV
Becks
9
0105
38
G
SA
Radeb
28
0105
41
K
NS
Jever
11
SELECTCOUNT
COUNT(DISTINCT
(DISTINCTEinr)
Einr) - AnzRadeb
SELECT
0105
43
G
SA
Radeb
9
FROMAbsatz
Absatz,
FROM
0105
46
G
BY
Paula
3
47
M
NW
Dortm
70
49
K
SA
Lands
12
Wieviele Gastronomie-Einrichtungen
in Sachsen
haben kein „Radeberger“ ?
COUNT(DISTINCT
Einr) AS AnzRadeb
WHERE(SELECT
Land = ‘SA‘
AND
0105
FROM
Absatz
Typ = ‘G‘
AND
0105
WHERE
AND DISTINCT Einr
Einr = ISLand
NOT=IN‘SA‘
(SELECT
Typ = ‘G‘ AND
FROM Absatz
Prod = ‘Radeb‘)
WHERE Land = ‘SA‘ AND
WHERE Land = ‘SA‘ AND
Typ = ‘G‘
SQL Projekt AG FSU 290610, 4
Typ = ‘G‘ AND
Prod = ‘Radeb‘)
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
SQL Projekt AG FSU 290610, 5
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 !
SQL Projekt AG FSU 290610, 6
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.
SQL Projekt AG FSU 290610, 7
Die grundlegende Entscheidung:
Isolieren der Anfragen von den Transaktionen
OLTP
Server
Daten Log
SQL Projekt AG FSU 290610, 8
REP
Agent
Replication
Server
Stable Device
Enterprise
Connect
Query
Server
Daten
Log
Data Warehouse Architektur
BenutzerTool
RDBMS
Relationale DB
SW-Pakete
Data
Staging
(ETL)
Enterprise
Data
Warehouse
Datamart
RDBMS
Datamart
Altdaten
BenutzerTool
BenutzerTool
ROLAP
Externe Quellen
DatenBereinigungsTool
Quelldaten
Datamart
Warehouse
Admin. Tools
Daten-Extraktion,
Transformation
und Laden
SQL Projekt AG FSU 290610, 9
MOLAP
unternehmenweites/
zentrales
Data
Warehouse
neu strukturierte
(‘Architected’)
Data Marts
BenutzerTool
SQL Projekt AG FSU 290610, 11
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.“
SQL Projekt AG FSU 290610, 12
(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

SQL Projekt AG FSU 290610, 13
Hohe Performance
bei Datenbankauswertungen
•Einführung: Probleme und Herangehensweise
• Sybase Adaptive Server IQ und IQM
• Prinzip-Überblick
• Speicherungsstruktur und Indextypen
• IQ Multiplex
• Beispiele, Ergebnisse
SQL Projekt AG FSU 290610, 14
Der traditionelle RDBMS-Ansatz
Berechne den
durchschnittlichen Absatz
von „Radeberger“ in GastronomieEinrichtungen in Sachsen je Monat
der letzten 3 Jahre
SELECT AVG (Abs), SUM(Abs)/AnzGSA/36
FROM Absatz,
Mon
Einr
Typ
Land
Prod
Abs
0105
32
G
SA
Werne
12
0105
36
G
MV
Becks
9
0105
38
G
SA
Radeb
28
0105
41
K
NS
Jever
11
0105
43
G
SA
Radeb
9
0105
46
G
BY
Paula
3
0105
47
M
NW
Dortm
70
0105
49
K
SA
Lands
12
(SELECT COUNT(DISTINCT Einr) AS AnzGSA
Traditioneller
FROM Absatz Ansatz:
WHERE
Land
= ‘SA‘
AND verfügbar
• Benutze
einen
Index
wenn
-
benötigt normalerweise
Table Scan
Typ = ‘G‘)
•WHERE
Gehe Land
zu den
ausgewählten
Datenseiten und addiere die Zahlen
= ‘SA‘
AND
Zufällige
Verteilung der Daten führt dazu, daß fast alle Seiten gelesen werden
Typ = ‘G‘ AND
müssen.
‘Radeb‘
- AufProd
jeder= Seite
müssen alle - auch die irrelevanten - Daten gelesen werden.
-
SQL Projekt AG FSU 290610, 15
Das Problem: Große Datenmengen
Berechne den
durchschnittlichen Absatz
von „Radeberger“ in GastronomieEinrichtungen in Sachsen je Monat
der letzten 3 Jahre

360 Millionen Zeilen
Mon
Einr
Typ
Land
Prod
Abs
0105
32
G
SA
Werne
12
0105
36
G
MV
Becks
9
0105
38
G
SA
Radeb
28
0105
41
K
NS
Jever
11
0105
43
G
SA
Radeb
9
0105
46
G
BY
Paula
3
0105
47
M
NW
Dortm
70
0105
49
K
SA
Lands
12

200 Bytes pro Zeile

16K Seitengröße

4.500.000 I/O’s pro Table Scan werden benötigt,
mit schneller Platte, d.h. 40MB/sec
30 Minuten !!!
Sehr teuer und unflexibel bei Ad-hoc-Anfragen
SQL Projekt AG FSU 290610, 16
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
SQL Projekt AG FSU 290610, 17
Einr
Typ
Einr
Typ
9805
32
G
0105
32
G
9805
36
G
0105
36
G
9805
38
G
0105
38
G
9805
41
K
0105
41
K
9805
43
G
0105
43
G
9805
46
G
0105
46
G
9805
47
M
0105
47
M
9805
49
K
0105
49
K
Mon
Mon
Land
Land
SA
SA
MV
MV
SA
SA
NS
NS
SA
SA
BY
BY
NW
NW
SA
SA
Prod Abs
Prod
Abs
Werne
6
Werne
12
Becks
9
Becks
9
Radeb
5
Radeb
28
Jever
11
Jever
11
Radeb
9
Radeb
9
Paula
3
Paula
3
Dortm
7
Dortm
70
Lands 12
Lands
12
Vertikale Partitionierung
Berechne den
durchschnittlichen Absatz
von Radeberger in GastronomieEinrichtungen 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
SQL Projekt AG FSU 290610, 18
Mon
Einr
Typ
Land
Prod
Abs
9805
32
G
SA
Werne
12
9805
36
G
MV
Becks
9
9805
38
G
SA
Radeb
28
9805
41
K
NS
Jever
11
9805
43
G
SA
Radeb
9
9805
46
G
BY
Paula
3
9805
47
M
NW
Dortm
70
9805
49
K
SA
Lands
12
Ergebnis im Beispiel:
Reduzierung des Disk-I/O
auf maximal 5% (ohne einen Index zu
benutzen)
Komprimieren der Daten
SQL: Create table ABC
OLTP
Engine
yellow, blue, red..magenta
IQ
SQL:Select sum (red) from ABC






1 2 3 4 ….. 100
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 4 - 10 mal mehr
Speicherplatz als IQM
Db page
2-32KB
SQL Projekt AG FSU 290610, 19
DB Page bis
2048 KB
1 2 3 4 …. 100
Platten-Laufwerke
SQL: Create table ABC
OLTP
Engine
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

1 2 3 4 ….. 100
IQ
yellow, blue, red..magenta
+90% braucht die Platte zum Suchen
Suchzeiten verbessern sich nur langsam, CPUs schneller => mehr
Laufwerke pro CPU
Zeilen-orientiertes DBMS: 10 Laufwerke pro CPU (bevorzugt
kleine Platten: 18-36GB)
IQ : 0.5 -1 Laufwerke pro CPU (bevorzugt große Platten: 73-180320GB)
Zeilen-orientierte DBMS benötigen 10 – 20 mal mehr
Laufwerke als IQM pro CPU
Db page
2-32KB
Db page bis
2048 KB
1 2 3 4 …. 100
SQL Projekt AG FSU 290610, 20
Datenkompression - Radikale Senkung
von Speicherbedarf und Wartung
Herkömmliche DBMS
Summaries
Aggregates
1 – 2 TB
Gleiche INPUT-Daten: “Konventionelles DW”
ist 6x-10x größer als Sybase IQ DW
Indexes
0,5 – 3 TB
1 TB
INPUT DATA:
Source: Flat Files,
ETL, Replikation,
ODS
LOAD
LOAD
SQL Projekt AG FSU 290610, 21
0.25 0.9 TB
Aggr/Summ: 0 – 0,1 TB
Indexes: 0,05 – 0,3 TB
Base table: 0,2 – 0,5 TB
Base table
“RAW data”
no indexes
0,9 – 1,1 TB
2.4-6
TB
Sybase IQ – Praxisergebnisse
Performance vs. Oracle - (Kundenbeispiel Citibank)
Oracle
Sybase IQ
Durchschnittl.
Antwortzeit
Ladezeit
Plattenplatz
3.1 Std.
6.9 Min.
8.4 Std.
47 GB
3.1 Std.
8 GB
Plattform
2-CPU
1-CPU
Ausführen von sechs komplexen Anfragen - Bankenanwendung
(select customer ID, group by product and account)
SQL Projekt AG FSU 290610, 22
Hohe Performance
bei Datenbankauswertungen
• Einführung: Probleme und Herangehensweise
• Sybase Adaptive Server IQ und IQM
• Prinzip-Überblick
• Speicherungsstruktur und Indextypen
• IQ Multiplex
• Beispiele, Ergebnisse
SQL Projekt AG FSU 290610, 23
4 Basis-Index-Typen und
weitere Spezial-Typen
Bezeichnung
Abkürzung
Fast Projection
FP
High Group
HG
Low Fast
LF
High Non Group
HNG
Comparison Index
CMP
Word Index
WD
Join Index
JI
Date-, Time-, Datetime
SQL Projekt AG FSU 290610, 25
Date,TIME,DTTM
Wird für jede Spalte grundsätzlich
Verwendet, Default Index
Für UNIQUE und PRIMARY KEY
notwendig
Fast Projection (FP)
Die Daten einer Spalte werden komprimiert gespeichert,
abhängig von Datentyp und Kardinalität.
Land
Sachsen
Sachsen-Anhalt
Thüringen
Niedersachsen
Hessen
Brandenburg
Sachsen
Hessen


SELECT Land
FROM Landtabelle
WHERE Land LIKE ‘Sa%‘
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
SQL Projekt AG FSU 290610, 26
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
SQL Projekt AG FSU 290610, 27
Fast Projection (FP)
Subtype: FP(1)
Land
Sachsen
Sachsen-Anhalt
Thüringen
Niedersachsen
Hessen
Brandenburg
Sachsen
Hessen
SQL Projekt AG FSU 290610, 28
Sachsen
Sachsen-Anhalt
Thüringen
Niedersachsen
Hessen
Brandenburg
1
1
2
2
3
3
4
4
5
5
6
6
1
5
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
SQL Projekt AG FSU 290610, 29
Fast Projection (FP)
Subtype: FP(2)
Prod
Radeberger
Wernesgrüner
Radeberger
Landskron
Becks
Radeberger
Paulaner
Wernesgrüner
Klosterbräu
SQL Projekt AG FSU 290610, 30
Radeberger
Wernesgrüner
Landskron
Becks
Paulaner
Klosterbräu
1
1
1
1
2
2
2
2
3
3
1
1
4
4
3
3
5
5
4
4
6
6
1
1
5
5
2
2
6
6
Fast Projection (FP)

Falls die Werteanzahl der Spalte > 256 und < 65.536 ist,
werden die Daten der Spalte als FP(2) anstelle von FP
gespeichert
 2-Byte look-up table


Setzt auf FP(3) nachdem 65.536 Werte erkannt wurden
Der Datenbank-Administrator kann die Kardinalität der
Spalte in der create table syntax durch Benutzung des
UNIQUE Parameters angeben
SQL Projekt AG FSU 290610, 31
Low Fast (LF)
Bitmap Index einschl. B-tree, der für Spalten mit kleiner Kardinalität
benutzt wird
Prod
Radeberger
Wernesgrüner
Radeberger
Landskron
Becks
Radeberger
Paulaner
Wernesgrüner
Klosterbräu



Radeber
ger
Wernes
grüner
Landskr
on
1
0
0
0
1
0
1
0
0
0
0
1
0
0
0
1
0
0
0
0
0
0
1
0
0
0
0
SELECT *
FROM Absatz
WHERE Prod = ‘Radeberger‘
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
SQL Projekt AG FSU 290610, 32
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)
SQL Projekt AG FSU 290610, 33
Dramatische I/O-Reduzierung
“Wieviele Männer sind in Kalifornien nicht versichert?“
RDBMS
800 Bytes x 20M
Geschlecht
Staat
Versichert
= 1.000,000 I/Os
M
CA
J
16K Seite
M
W
M
M
W
20M
Sätze
CA
NY
CA
MA
CT
N
J
N
J
N

Verarbeitet grosse Mengen nicht
benötigter Daten

Erfordert oft “Full Table Scan”
800 Bytes/Satz
Geschlecht
1
2
3
4
M
M
W
M
Staat
Versichert
CA
CA
NY
CA
SQL Projekt AG FSU 290610, 34
J
N
J
N
20M Bits x 3 Spalten / 8 = 470 I/Os
16K Seite
20M
Bits
1
1
0
1
+
1
1
0
1
+
0
1
0
1
=
2
High Non Group (HNG)
Bit-weiser Index, optimiert für Bereichs-Suche und
Aggregations-Funktionen
Binäre Darstellung
HNG-Index für Abs
Abs
12
9
28
11
9
3
70
12

0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
1
1
1
1
1
0
0
1
1
0
1
0
0
0
1
1
0
0
0
1
0
1
1
0
0
1
0
1
1
1
0
0
64
32
16
8
4
2
1
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
1
1
1
1
1
0
0
1
1
0
1
0
0
0
1
1
0
0
0
1
0
1
1
0
0
1
0
1
1
1
0
0
1
0
1
6
4
3
4
Beispiel:
SELECT SUM(Abs) FROM Absatz
(1 * 64) + (0 * 32) + (1 * 16) + (6 * 8) +
(4 * 4) + (3 * 2) + (4 * 1) = 154
SQL Projekt AG FSU 290610, 35
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
SQL Projekt AG FSU 290610, 36
High Group (HG)
Index für Daten mit hoher Kardinalität
SQL Projekt AG FSU 290610, 37
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
SQL Projekt AG FSU 290610, 38
Prinzipielle Herangehensweise bei der
Indexierung von Tabellen
SQL Projekt AG FSU 290610, 39
Prinzipielle Herangehensweise bei der
Indexierung von Tabellen (Forts.)
SQL Projekt AG FSU 290610, 40
4 Basis-Index-Typen und weitere Spezial-Typen
Bezeichnung
Abkürzung
Fast Projection
FP
High Group
HG
Low Fast
LF
High Non Group
HNG
Comparison Index
CMP
Word Index
WD
Join Index
JI
Date-, Time-, Datetime
SQL Projekt AG FSU 290610, 41
Date,TIME,DTTM
Wird für jede Spalte grundsätzlich
Verwendet, Default Index
Für UNIQUE und PRIMARY KEY
notwendig
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
SQL Projekt AG FSU 290610, 42
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
4 “High Group” Indizes für die Aggregatbildung, die JoinVerarbeitung und das Gruppieren pro Kunde
2 “Low Fast” Indizes für die Suchbedingung und das
Gruppieren auf Monatsebene
1 Word Index für Zeichenkettensuche
SQL Projekt AG FSU 290610, 43
Beispiel
SELECT AVG (Abs), SUM(Abs)/AnzGSA/36
FROM Absatz,
(SELECT COUNT(DISTINCT Einr) AS AnzGSA
FROM Absatz
WHERE Land = ‘SA‘ AND
Typ = ‘G‘)
WHERE Land = ‘SA‘ AND
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
SQL Projekt AG FSU 290610, 44
Vertikale Partitionierung
Berechne den
durchschnittlichen Absatz
von Radeberger in GastronomieEinrichtungen 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
SQL Projekt AG FSU 290610, 45
Mon
Einr
Typ
Land
Prod
Abs
9805
32
G
SA
Werne
12
9805
36
G
MV
Becks
9
9805
38
G
SA
Radeb
28
9805
41
K
NS
Jever
11
9805
43
G
SA
Radeb
9
9805
46
G
BY
Paula
3
9805
47
M
NW
Dortm
70
9805
49
K
SA
Lands
12
Ergebnis im Beispiel:
Reduzierung des Disk-I/O
auf maximal 5% (ohne einen Index zu
benutzen)
Vertikale Partitionierung
Berechne den
durchschnittlichen Absatz
von Radeberger in GastronomieEinrichtungen in Sachsen je
Monat der letzten 3 Jahre
Mon
Einr
Typ
Land
Prod
Abs
9805
32
G
SA
Werne
12
9805
36
G
MV
Becks
9
9805
38
G
SA
Radeb
28
9805
SELECT AVG (Abs), SUM(Abs)/AnzGSA/36
41
K
NS
Jever
11
9805
43
G
SA
Radeb
9
Sybase
IQ: Es
werden nur die Einr) 9805
(SELECT
COUNT(DISTINCT
ASrelevanten
AnzGSA Spalten gelesen
46
G
BY
Paula
3
9805
47
M
NW
Dortm
70
9805
49
K
SA
Lands
12
FROM Absatz,
FROM Absatz
WHERE Land = ‘SA‘ AND
Typ = ‘G‘)
WHERE Land = ‘SA‘ AND
Typ = ‘G‘ AND
Prod = ‘Radeb‘
SQL Projekt AG FSU 290610, 46
Ergebnis im Beispiel:
Reduzierung des Disk-I/O
auf max. 2%
Eurostat : wide table – 10 Mio rows
SQL Projekt AG FSU 290610, 47
Eurostat : Horizontale Partitionierung
SQL Projekt AG FSU 290610, 48
Eurostat : Vertikale Partitionierung
SQL Projekt AG FSU 290610, 49
Eurostat : In IQ-M
SQL Projekt AG FSU 290610, 50
Sybase IQ und überprüfte
Einsparungen bei Plattenspeicher
Sybase IQ
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
15 TB
7 TB
45 TB bis 105 TB
Nielsen Media Research
12 TB
12 TB
36 TB bis 84 TB
Large Credit Card Company
10 TB
4 TB
30 TB bis 70 TB
SQL Projekt AG FSU 290610, 51
Hohe Performance
bei Datenbankauswertungen
• Einführung: Probleme und Herangehensweise
• Sybase Adaptive Server IQ und IQM
• Prinzip-Überblick
• Speicherungsstruktur und Indextypen
• IQ Multiplex
• Beispiele, Ergebnisse
SQL Projekt AG FSU 290610, 52
Skalierbarkeit
“Starte klein und wachse” mit Sybase IQ Multiplex Konfiguration
IQ-M
IQ-M
IQ-M
IQ-M
IQ-M
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
Fiber Channel Storage Area Network
Skaliert wie ein Grid
SQL Projekt AG FSU 290610, 53
 Starten mit einem Server
 Hinzufügen von CPUs u.
Speicher nach Bedarf
 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
 Terabytes an Festplatten
können ins SAN eingefügt
werden
 IQ-M wird diese effektiv
nutzen
Skalierbarkeit
Nachgewiesen im Labor und bei Kunden
Sybase IQ Multiplex Test der Skalierfähigkeit
Anwender
500
400Users
400
360
98%
320
300
280
240
200
100
200
40 User Antw-Zeit: 31 sec
120
80
40
0
400 User Antw-Zeit = 31.6 sec
Erhöhung : 1.9% (0.6 sec)
160
31.6 sec
Knoten
31 sec
1
2
3
4
5
6
7
Workload: Each user executing random sequence of (TPC/H-like) queries
(Source : HP Lab in San Bruno, CA)
SQL Projekt AG FSU 290610, 54
8
9
10
Skalierbarkeit
Einfache Administration und implizite Hochverfügbarkeit
Read/ Write Read/ Write Read/ Write
Knoten
Knoten
Knoten
IQ-M
IQ-M
IQ-M
Read
Knoten
Read
Knoten
IQ-M
IQ-M
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
CPU
SKALIERBARKEIT
Nach hinzufügen eines Knotens
KEIN globaler Lock Manager nötig
KEINE Datenumverteilung erforderlich
KEINE Änderungen im Schema
SEHR geringe I/O Contention
HOCHVERFÜGBARKEIT
Fiber Channel Storage Area Network
Skaliert wie ein Grid
SQL Projekt AG FSU 290610, 55
- 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
Technische Limits
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:
4.293.918.719
248
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:
Anzahl Spalten pro Tabelle:
SQL Projekt AG FSU 290610, 56
64 KB bis 512 KB
45.000
Speicherung ALLER relevanten Daten
in EINEM System
Internet
Anwender können weiter
ihren bisherigen Email Client
nutzen – können aber auch
auf das System zugreifen
(E-mail und
Dokumente)
•Dokumente
•Bilder
•Video
•Audio
•Fax
•Datei und DB Backup
•Andere Daten
Partnerlösung

( Optional )
•DW
•Transaktionen
Sybase
IQ
SQL Projekt AG FSU 290610, 57
Vorhandener
E-mail
Server
Partnerlösung
Dokumente und
E-mail Clients
Weitere Daten
können in der
Lösung nach Bedarf
hinzugefügt werden
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” (Emails,
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 (Emails, Attachements und andere unstrukturierte Dokumente) erreicht

Es wurde eine Ladegeschwindigkeit von zwei Millionen Emails pro Stunde und 6 Millionen
Dokumente pro Stunde erreicht – dabei wurden weniger als 7% der verfügbaren CPU Leistung
benötigt
SQL Projekt AG FSU 290610, 58
Sun DWH Reference Architecture
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 Emails
Quelle: Sun Data Warehouse
Reference Architecture for
Structured and Unstructured
Data,
InfoSizing, August 20, 2007
SQL Projekt AG FSU 290610, 59
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
Hohe Performance
bei Datenbankauswertungen
• Einführung: Probleme und Herangehensweise
• Sybase Adaptive Server IQ und IQM
• Prinzip-Überblick
• Speicherungsstruktur und Indextypen
• IQ Multiplex
• Beispiele, Ergebnisse
SQL Projekt AG FSU 290610, 60
Online-Archiv auf Basis Sybase IQ
Sybase ASE und heterogene Umgebungen
CICS Trx
IBM MVS (z/OS)
DB2(CICS) PLACE_
Direct
DB2(IMS)
DB2(DRDA)ORDER
Connect IDMS
IMS
VSAM
TABLE
KUNDE
Applikation
ASE
CIS
Technologische Grundlagen:
TABLE
ORDER
ODBC
Informix
Direct
Connect Microsoft
VERTRAG
Oracle
PLACE_..
DB2/UDB
Component Integration
Services von Sybase ASE
Proxy Tabellen
Union in Views
Instead-of-Trigger (ASE 15.0.2)
Transparent für SQL
Physik. Speicherung/ Logik
Proxy Tabelle
SQL Projekt AG FSU 290610, 61
AS/400
TABLE
VERTRAG
ORDER_
HISTORY
Archiv: Sybase IQ
TABLE
ORDER_
HISTORY
Partnerlösungen (Auswahl)

PBS (Deutschland)


Rent-a-Brain (Deutschland)



SAP BI Archivlösung
iMarc-Emailarchivierung
Dokumentenarchivierung
BMMSoft (USA)

Email/-/ Dokumentenarchivierung
SQL Projekt AG FSU 290610, 62
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)
Access: Queries,
Reload, ...
PBS CBW
NLS IQ
Interface
Read Data
server
CBW NLS IQ Infrastrutcure (without adk components)
SQL Projekt AG FSU 290610, 63
Load Data
CBW-Architektur mit NLS und Sybase IQ
DB und Nearline lesen
(in Query-Attributen aktivieren)
InfoCube
DataStore Objekt
SAP BW
Datenbank
SQL Projekt AG FSU 290610, 64
SAP BW Query
SAP
Nearline
Provider
PBS
Nearline Services
für Sybase IQ
Sybase IQ
Spalten-basierte
Data Warehouse DB,
Kompression bis 1:10
Kompressionen InfoCubes Kundenbeispiel
InfoCube
Größe arch. Daten
Größe Daten in Sybase IQ
Kompression auf
INDIA03
9.042.943.028 Bytes
691.322.880 Bytes
8%
INDIA21
1.944.346.768 Bytes
81.305.600 Bytes
4%
FAKT01
59.532.053.152 Bytes
6.299.435.008 Bytes
11 %
FAKT21
4.617.352.608 Bytes
247.070.720 Bytes
5%
831.113.280 Bytes
63.963.136 Bytes
8%
19.097.371.560 Bytes
1.046.978.560 Bytes
5%
0FIAR_C02
480.045.888 Bytes
45.178.880 Bytes
9%
0FIAR_C03
7.932.706.440 Bytes
963.600.384 Bytes
12 %
FAKTP02
ERG002
SQL Projekt AG FSU 290610, 65
Query „Markthierarchie“ – Speed (I)
Query
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
Oracle DB
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]
SQL Projekt AG FSU 290610, 66
Query „Fakturen“ – Speed (I)
Query
Query M_FAKT01/STD_M_FAKT01_ASS_PC
12.2007
Anzahl Datensätze: 57 Mio.
Fakturaauswertung
Zugriffsart
Sybase IQ
Oracle DB
mit Aggregaten
Oracle DB
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]
SQL Projekt AG FSU 290610, 67
Erfahrungsbericht – Fazit
Kundeninstallation
Speed
Kompression
Administration
Bis zu 14 x
schnellere
Antwortzeiten
Kompression
der Archivdaten
bis zu 95 %
Keine Indexkeine AggregatModellierung
SQL Projekt AG FSU 290610, 68
Mehr als 1500 Kunden
Erfolgreich etablierte und schnell wachsende Kundenbasis

Mehr als 3000 Kundenprojekte bei mehr als 1500 Kunden
weltweit
SQL Projekt AG FSU 290610, 69
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.”


SQL Projekt AG FSU 290610, 70
Carl Olofson, Research Vice President
Information Management and Data Integration Software Research
IDC 2007
Telekommunikations-DB
telco_facts
month_key
customer_key
service_key
status_key
combined_revenue
number_of_lines
local_call_count
local_call_minutes
long_distance_call_count
long_distance_call_minutes
minutes_online
integer
integer
integer
integer
numeric(19,4)
integer
integer
integer
integer
integer
integer
<pk,fk1>
<pk,fk2>
<pk,fk3>
<pk,fk4>
1.200.000 Zeilen
FK_TELCO_FA_REFERENCE_RESIDENT
FK_TELCO_FA_REFERENCE_MONTH
24
residential_customer
month
month_key
month_text
month_number
fiscal_period
year
period_and_year
month_and_year
integer <pk>
char(9)
integer
char(2)
integer
char(7)
char(7)
FK_TELCO_FA_REFERENCE_STATUS
FK_TELCO_FA_REFERENCE_SERVICE
status
72
status_key
new_customer
new_address
call_waiting_status
caller_id_status
voice_mail_status
cellular_status
internet_status
isdn_status
closed_this_period
SQL Projekt AG FSU 290610, 71
customer_key
customer_first_name
customer_last_name
customer_gender
street_address
city
state
postal_code
phone_number
service
integer <pk>
char
char
char(10)
char(10)
char(10)
char(10)
char(10)
char(10)
char
service_key
call_waiting_flag
caller_id_flag
voice_mail_flag
cellular_flag
internet_flag
isdn_flag
integer <pk>
char
char
char
char
char
char
12
integer <pk>
char(11)
char(15)
char
char(18)
char(20)
char(2)
char(9)
char(10)
100.000
Voraussetzungen und Laden
Merkmal
Version
ASIQ
ASE
ASE12.5.0. 12.4.3
1
PC 333 MHZ ,128 MB, Platte Toshiba
MK2018GAS
Windows 2000
Hardware
OS
Rohdaten (MB)
Daten (MB)
geladen u. ind.
Daten (MB)
( Index)
Zusatzindexe
Ladezeit (min)
bcp / load table
Indizierungszeit
(min)
SQL Projekt AG FSU 290610, 72
Bemerkung
54
271,9
54
66,8
Bei ASIQ einschließlich Indexe
4
Bei ASIQ Laden und Indizieren
78,8
(189)
4
40
Anfragebeispiele
Merkmal
Query1 (ms)
Query2 (ms)
SQL Projekt AG FSU 290610, 73
ASE
2.033
1.120
.993
1.003
ASIQ
1.362
.200
.150
.160
372.116
359.960
359.896
338.756
9.975
.841
.741
.721
Bemerkung
Query displays service types by month
Valid values are 1- 12 for month_key
select month_key ,service_key,count(*)
from telco_facts
where month_key = 1
group by month_key,service_key
A look at customers who have the
following
service call waiting , caller id, and
voice mail by
-- fiscal period
i.e. Q1,Q2,Q3,Q4 for
year= 1998
select service_key,fiscal_period,count(*)
from telco_facts T,month M
where T.month_key=M.month_key
and service_key = 4
group by fiscal_period,service_key
order by fiscal_period,service_key
Anfragebeispiele
Merkmal
Query3 (ms)
ASE
295.553
168.803
215.466
234.336
ASIQ
2.784
.952
.931
.871
Query4 (ms)
195.470
191.816
192.996
192.036
8.352
.761
.771
.892
SQL Projekt AG FSU 290610, 74
Bemerkung
-- A count of customers who have
dropped call
-- waiting from their service palns by
Quarter
select service_key,fiscal_period,count(*)
from telco_facts T,month M,status S
where T.month_key=M.month_key
and S.status_key = T.status_key
and call_waiting_status='Dropped'
group by fiscal_period,service_key
order by fiscal_period,service_key
-- female Customers in Massachusetts
that do not
-- have caller id
select distinct(C.customer_key),
C.Customer_first_name,
C.customer_last_name,
C.phone_number
from residential_customer
C,service,telco_facts
where C.customer_key =
telco_facts.customer_key
and telco_facts.service_key =
service.service_key
and caller_id_flag = 'N'
and state = 'MA'
and customer_gender = 'F'
Anfragebeispiele
Merkmal
Query5 (ms)
ASE
444.800
437.720
421.606
460.183
ASIQ
5.288
3.425
3.405
3.395
Bemerkung
-- Find prospects for voice mail based on
the criteria
-- that customers with call waiting and
caller id are
-- good prospects for call Waiting
select state, count(*)
from telco_facts T,service S,
residential_customer C,
month M
where T.service_key = S.Service_key
and T.customer_key = C.customer_key
and T.month_key = T.month_key
and call_waiting_flag = 'Y'
and caller_id_flag = 'Y'
and voice_mail_flag = 'N'
and state in ('NY','NJ','PA')
and fiscal_period = 'Q1'
group by state
SQL Projekt AG FSU 290610, 75
Anfragebeispiele
Merkmal
Query6 (ms)
SQL Projekt AG FSU 290610, 76
ASE
17.576
15.803
15.423
15.763
ASIQ
6.849
6.079
6.129
6.069
Bemerkung
-- Find customers that had ISDN service
in February
-- 1998
select customer_last_name
,customer_first_name
from residential_customer R ,telco_facts
T, service S, month M
where M.month_text = 'February '
and M.year = 1998
and s.isdn_flag = 'Y'
and M.month_key = T.month_key
and S.service_key = T.service_key
and R.customer_key = T.customer_key
Anfragebeispiele
Merkmal
Query7 (ms)
SQL Projekt AG FSU 290610, 77
ASE
468.433
470.726
468.143
466.470
ASIQ
2.544
1.292
1.272
1.262
Bemerkung
-- Look at the local call minutes to see if
they
-- have increased after adding call waiting
select
fiscal_period,count(*),sum(local_call_min
utes)
from residential_customer R ,telco_facts
T, status S, month M
where s.call_waiting_status='Added'
and state = 'OH'
and M.month_key= T.month_key
and S.status_key = T.service_key
and R.customer_key = T.customer_key
group by fiscal_period
order by fiscal_period
Anfragebeispiele
Merkmal
Query8 (ms)
SQL Projekt AG FSU 290610, 78
ASE
629.456
629.656
627.180
627.933
ASIQ
2.303
1.862
1.863
1.883
Bemerkung
-- Look at the call usage for customers
with call
-- waiting "service type 2" compared with
customers
-- with both call waiting and Caller id for
Q4 for
-- customers in CA
select fiscal_period, T.service_key,
sum(local_call_minutes),
sum(local_call_count), count(*)
from telco_facts T,residential_customer
C,service S, month M
where T.customer_key = C.customer_key
and T.service_key = S.service_key
and T.month_key = M.Month_key
and fiscal_period = 'Q4'
and T.service_key in (02,03)
and state = 'CA'
group by fiscal_period,T.service_key
EDS Report: IQM vs “konventionelles” RDBMS
#CPUs in Sun SF 6800 (750 MHz)
DB cache size
DW installation time (ready for data)
Major DBMS
(not NCR)
8
4 GB
5-10 days
Sybase
IQ Multiplex 12.4.3
8
4 GB
1 day
table partitioning
& table placement
ratio
5x10x
880 Million
Input data size (total size of input files)
270 GB
Loading speed (records/hour)
#Records
45 M/hour
208 M/hour
4.5x
63 GB
128 GB
128 GB
4.7x
4.3x
7x
Storage efficiency
Base table (NO indexes)
Base table+indexes
Base table+index+MVs+aggr.
300 GB
550 GB
900 GB
Query speed
50 sequential queries
50 concurrent queries
50 concurrent queries against
tables being loaded on the same
SMP server. IQM slowdown (28%)
due to CPU (and not db) contention
50 concurrent queries
SQL Projekt AG FSU 290610, 79
114 min
180 min
180 min
(NO DW load)
180 min
50 min
13 min
18 min
(with DW
(HDS)
(HDS)
(HDS)
2.3x
14x
10x
Load)
13 min (*) (T3)
14x
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
SQL Projekt AG FSU 290610, 80
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 …
SQL Projekt AG FSU 290610, 81