KK10_14 Performance und Index

Datenbanken
14 Performance und Index
Karl Meier
[email protected]
07.12.2010
Inhalt
Performance


Allgemeines
Benchmarking
Index


Allgemeines
Index
07.12.2010
14 Performance und Index
2
1
Performance
Performance ist ein subjektives Mass für die
Geschwindigkeit, mit der eine Applikation
verwendet werden kann.
Die Bewertung der Performance kann nur relativ sein:
• schneller als vorher
• schneller als auf einem anderen Rechner
• schneller als mit der alten Version
07.12.2010
14 Performance und Index
3
Was wenn?
Was passiert, wenn die Anzahl
Datensätze verzehnfacht wird?
Hilft mehr RAM?
Ist der neue Server doppelt so schnell wie
der alte?
Was bringt Query Cache?
Was ist effizienter? Subquery oder
einzelne kurze Queries?
Was passiert bei mehrmaliger Abfrage?
07.12.2010
14 Performance und Index
4
2
Warteschlangentheorie
Latenz = Wartezeit + Bearbeitungszeit
Systemverhalten am Sättigungspunkt nicht linear
Das System kollabiert an Wartezeit
-
Wer wartet wann worauf?
Kürzere Verarbeitungszeit
Parallelisierung
07.12.2010
14 Performance und Index
5
Performancemessung
Wer misst, misst Mist!
Wie wird die Performance von Datenbanksystemen
gemessen? Latenz - Durchsatz - Skalierbarkeit
Die wohl bekannteste Methode sind die verschiedenen
TPC-Benchmarks, deren Resultate auch in den
entsprechenden Produktblättern erscheinen.
07.12.2010
14 Performance und Index
6
3
TPC-Benchmarks
Datenbank Performance
http://www.tpc.org
TPC ist eine Organisation, der ca. 40 HW-Hersteller,
SW-Hersteller, Endbenutzerorganisationen und
Beratungsfirmen angehören. TPC definiert DatenbankBenchmarks, legt Regeln für deren Durchführung fest
und auditiert die von Herstellern eingereichten
Benchmarkergebnisse.
07.12.2010
14 Performance und Index
7
TPC Mitglieder
07.12.2010
14 Performance und Index
8
4
TPC Benchmarks
TPC-C / TPC-E (Order entry transactions, OLTP)
Simulates a complete computing environment
where a population of users executes
transactions against a database.
TPC-H (Decision support, OLAP)
Business oriented ad-hoc queries and
concurrent data modifications.
07.12.2010
14 Performance und Index
9
OLTP / OLAP
ORACLE
DB2
DW
MySQL
OLAP
OLTP
07.12.2010
14 Performance und Index
10
5
TPC-E / TPC-C
Characteristic
TPC-E
TPC-C
Tables
33
9
Columns
188
92
Min Cols / Table
2
3
Max Cols / Table
24
21
Data Type Count
Many
4
Data Types
UID, CHAR, NUM,
DATE, BOOL, LOB
UID, CHAR, NUM,
DATE
Primary Keys
33
8
Foreign Keys
50
9
Tables w/ Foreign
Keys
27
7
Check Constraints
22
0
Referential Integrity
Yes
No
07.12.2010
14 Performance und Index
11
TPC-H
07.12.2010
14 Performance und Index
12
6
TPC-H
Effizienzvergleich der verschiedenen
Architekturen mit Hilfe des TPC-H Benchmarks
TPC-H: Decision Support Benchmark für
Datenbankgrössen von 100-10000 GB:
Dabei werden die Zeiten für Ad-Hoc-Queries
gemessen, so dass es kein Vorwissen bzgl. der
Anfragen gibt, welches zur Optimierung der
Datenbank genutzt werden könnte.
07.12.2010
14 Performance und Index
13
SPEC Benchmarks
CPU Performance
Standard Performance
Evaluation Corporation
http://www.spec.org
Aktuelle Benchmarks:
SPECapc
SPEC HPC2002
SPEC OMP2001
SPEC appPlatform
SPEC jAppServer2004
SPEC JBB2000
SPEC MAIL2009
SPEC WEB2009
07.12.2010
14 Performance und Index
SPECviewperf 7.1
SPEC HPC2002
SPEC CPU2000
SPEC CPU2006
SPEC jAppServer2004
SPEC JVM2008
SPEC SFS2008
SPEC WEB2005
14
7
SPEC CPU2006
Eine Neuauflage ist notwendig geworden, da bei neuen CPUs die
Laufzeiten einzelner Testverfahren in der bisher gültigen CPU2000 auf
weniger als 1 Minute sinken. Ausserdem spiegelt die bisherige Suite die
Komplexität und die Struktur heutiger Anwendungen kaum noch wider. Ab
November 2006 veröffentlicht und prüft die SPEC nur noch Messungen, die
mit der CPU2006 zustande kamen.
Nach wie vor besteht die gesamte Suite aus einer Gruppe von Tests für
Festkomma- (CINT2006) und einer für das Gleitkommarechnen (CFP2006).
Es gibt wie bisher Resultate für eine nach strengen Regeln festlegte
Parametrisierung der Compiler (base) und solche mit höchster Optimierung
(peak).
Als Referenz dient nach wie vor eine betagte Ultra Enterprise von Sun mit
einer UltraSPARCII-CPU, 296 MHz "schnell", die mit 2 GByte
Hauptspeicher auskommen muss. Der schnellste Rechner beim
SPECint_base2006 stammt von Fujitsu Siemens. Die Celsius V830 mit
Opteron 256 (3 GHz) unter Linux 64 Bit ist knapp 12-mal schneller als die
Ultra von Sun. Ein Durchlauf des SPECfp_base2006 auf der Celsius
dauerte 12 Stunden.
07.12.2010
14 Performance und Index
15
Benchmark Kriterien
Kriterien für Standard-Benchmarks sind:




Relevanz
Portabilität
Skalierbarkeit
Einfachheit
07.12.2010
14 Performance und Index
16
8
Benchmark Strategien
Performance Test vs. Stress Test
„Change one thing at a time“
Iterative Tests
Tests wiederholen

Restart MySQL / Reboot
Reale Daten verwenden (Art und Menge)
Nicht zu viele Clients verwenden
Client/Server trennen
07.12.2010
14 Performance und Index
17
Benchmark Funktion
mysql> SELECT BENCHMARK(1000000,10+10);
+--------------------------+
| BENCHMARK(1000000,10+10) |
+--------------------------+
| 0
|
+--------------------------+
1 row in set (0.14 sec)
Ein schneller Test für die CPU Geschwindigkeit ist die MySQL
Funktion BENCHMARK().
SELECT BENCHMARK(1000000, EXTRACT(YEAR FROM NOW()));
ACHTUNG: Query Cache !!!
07.12.2010
14 Performance und Index
18
9
MySQL Benchmark Suite
Bestandteil der MySQL Distribution
Perl Scripts (DBI und Benchmark Modul)
MySQL, PostgreSQL, MS-SQL, Oracle,…
Nicht für Multi-CPU Rechner geeignet
http://dev.mysql.com/doc/refman/5.1/en/mysql-benchmarks.html
Mit einem Linux Client können Tests auch auf einen
Windows DB-Server getätigt werden.
07.12.2010
14 Performance und Index
19
MySQL Bench Dateien
File
Description
Data/ATIS
Data/Wisconsin
Results
Makefile.am
test-ATIS.sh
test-connect.sh
test-create.sh
test-insert.sh
test-wisconsin.sh
run-all-tests
compare-results
server-cfg
Contains data for 29 related tables used in the ATIS tests.
Contains data for the Wisconsin benchmark.
Contains old benchmark results.
Automake Makefile
Creation of 29 tables and a lot of selects on them.
Test how fast a connection to the server is.
Test how fast a table is created.
Test create and fill of a table.
A port of the PostgreSQL version of this benchmark.
Use this to run all tests.
Generates a comparison table from different RUN files.
Contains the limits and functions for all supported SQL
servers. If you want to add a new server, this should be the
only file that needs to be changed.
07.12.2010
14 Performance und Index
20
10
Wisconsin Benchmark
„The Wisconsin Benchmark described in [Bitton, DeWitt,
and Turbyfill 1983] [Boral and DeWitt 1984] [Bitton and
Turbyfill 1985] [Bitton and Turbyfill 1988], and [DeWitt
1993] is the first effort to systematically measure and
compare the performance of relational database systems
with database machines. The benchmark is a single-user
and single-factor experiment using a synthetic database
and a controlled workload. It measures the query
optimization performance of database systems with 32
query types to exercise the components of the proposed
systems. The query suites include selection, join,
projection, aggregate, and simple update queries.“
http://firebird.sourceforge.net/download/test/wisconsin_benchmark_chapter4.pdf
07.12.2010
14 Performance und Index
21
Resultate
Testing server 'MySQL 4.1.7 nt' at 2005-02-21 11:26:55
ATIS table test
Creating tables
Time for create_table (28): 2 wallclock secs ( 0.02 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.02 CPU)
Inserting data
Time to insert (9768): 392 wallclock secs ( 1.46 usr 0.34 sys + 0.00 cusr 0.00 csys = 1.80 CPU)
Retrieving data
Time for select_simple_join (500): 2 wallclock secs ( 0.71 usr 0.29 sys + 0.00 cusr 0.00 csys = 1.00 CPU)
Time for select_join (100): 1 wallclock secs ( 0.49 usr 0.44 sys + 0.00 cusr 0.00 csys = 0.93 CPU)
Time for select_key_prefix_join (100): 8 wallclock secs ( 6.08 usr 2.19 sys + 0.00 cusr 0.00 csys = 8.27 CPU)
Time for select_distinct (800): 4 wallclock secs ( 2.36 usr 0.80 sys + 0.00 cusr 0.00 csys = 3.16 CPU)
Time for select_group (2400): 2 wallclock secs ( 1.42 usr 0.42 sys + 0.00 cusr 0.00 csys = 1.84 CPU)
Removing tables
Time to drop_table (28): 1 wallclock secs ( 0.01 usr 0.00 sys + 0.00 cusr 0.00 csys = 0.01 CPU)
Total time: 412 wallclock secs (12.56 usr 4.50 sys + 0.00 cusr 0.00 csys = 17.05 CPU)
07.12.2010
14 Performance und Index
22
11
Testdatenbank für MySQL
https://launchpad.net/test-db
07.12.2010
14 Performance und Index
23
Tuning
Tuning ist eine Tätigkeit, welche die
Performance steigert.
Diese Tätigkeit wird vor, während und nach der
Entwicklung einer Applikation durchgeführt.
07.12.2010
14 Performance und Index
24
12
Tuning im Entwicklungsprozess
07.12.2010
Im
pl
em
en
ta
tio
n
eb
tri
Be
Performance
Tuning
e
lys
a
An
/
n
n
ig
sig des
De Re
Performance
Erwartungen
14 Performance und Index
Ermöglichen der
Performance
Performance
Überprüfung
25
Testkriterien
Am aussagekräftigsten sind Tests unter
realistischen Bedingungen.
Diese lassen sich aber oft nur schwer finden und
daher beschränkt man sich in der Praxis mit
einer realistischen Menge von Testdaten.
Steht das System schon im produktiven Einsatz,
kann die Belastung von Server und Netzwerk
mitberücksichtigt werden.
07.12.2010
14 Performance und Index
26
13
Aspekte des Tunings
 Design
Aufbau der DB bestimmt die möglichen SQL Statements
 Applikation
Aufbau der Applikationen bestimmt die SQL Statements
 Speicher
Grösse der Speicher bestimmt die Anzahl Festplattenzugriffe
 I/O
Festplattenzugriffe und Netzwerkverkehr
 Contention
Locking Probleme durch Anzahl Benutzer und Prozesse
07.12.2010
14 Performance und Index
27
Typische Performancemängel
Wenn die Datenbank im Betrieb nicht die
gewünschte Performance aufweist sind meist
folgende Ursachen ausschlaggebend:





07.12.2010
Nicht optimales Datenbankdesign
Ineffiziente Abfragen
Fehlende Indizes
Konfigurationsmängel
Hardware
14 Performance und Index
28
14
Datenbankdesign
Beim Entwurf des Datenbankmodells mit dem
Entity-Relationship-Modelling (ERM) Verfahren
wird die Grundlage für eine gute Performance
gelegt (oder eben nicht).
In der Praxis geht es dabei darum, einen guten
Kompromiss zwischen strenger Normalisierung
und einfachen (schnellen) Modellen zu finden.
07.12.2010
14 Performance und Index
29
Fehlender Index
Steht kein Index für die SQL Abfrage zur
Verfügung, wird ein Full Scan über die ganze
Tabelle durchgeführt.
Somit wird für jede noch so spezifische Abfrage
die gesamte Tabelle durchlaufen, was enorm
zeitaufwändig ist!
O(n) Problem in der Informatik.
07.12.2010
14 Performance und Index
30
15
Index
Auch bei MySQL ist die Indizierung von Daten eine der
einfachsten und effizientesten Massnahmen zur
Steigerung der Performance.
Die Praxis zeigt, dass etwa 90% aller Probleme bei
MySQL wegen mangelhafter Indizes auftreten.
Da jeder Index auf ein bestimmtes Datenfeld aber auch
den Datenbestand erhöht, gilt es, eine optimale Balance
zwischen Speicherbedarf und Performance zu finden.
07.12.2010
14 Performance und Index
31
Partieller Index
Weil der Index für eine grosse Tabelle auch viel
Platz braucht, beschränkt man sich auf einen
Teil des Wertes.
ALTER TABLE t_ma ADD INDEX (name(4));
Besteht der Name aus durchschnittlich 8 Bytes, werden im
obigen Beispiel nur die ersten 4 Bytes indiziert. Dazu kommt
noch der Datensatzzeiger, der 4-8 Bytes pro Datensatz benötigt.
07.12.2010
14 Performance und Index
32
16
Ein- / Mehrspalten Index
Der Index kann auf eine oder mehrere Spalten definiert
werden (single-/multicolumn).
id
vorname
name
ort
…
…
…
…
…
…
273
Martin
Huber
Chur
…
274
Martin
Graf
Chur
…
275
Martin
Huber
Basel
…
276
Roland
Hofer
Bern
…
277
Martin
Graf
Zürich
…
…
…
…
…
…
SELECT id FROM telbuch WHERE vorname=`Martin`
AND name=`Huber` AND ort=`Chur`;
07.12.2010
14 Performance und Index
33
Frage
Sind drei einzelne Indizes auf die Spalten
vorname, name und ort geichbedeutend einem
Mehrspaltenindex auf (vorname, name, ort)?
ALTER TABLE t_ma ADD INDEX (vorname, name, ort);
07.12.2010
14 Performance und Index
34
17
Leftmost Prefixing
Mehrspaltenindizes haben in MySQL eine
weitere angenehme Eigenschaft, bekannt als
„Leftmost Prefixing“
Der Mehrspaltenindex aus dem vorherigen
Beispiel kann für die Suche nach folgenden
Kombinationen verwendet werden:



vorname, name, ort
vorname, name
vorname
07.12.2010
14 Performance und Index
35
Grundsatz
MySQL verwendet höchstens einen
Index pro Tabelle und Abfrage.
07.12.2010
14 Performance und Index
36
18
Index Sortierung
MySQL bietet ab der Version 4.0 eine gute
Optimierung für die Abfrage der Indizes.
SELECT * FROM t_ma WHERE name=„Huber“
ORDER BY vname DESC;
SELECT * FROM t_ma WHERE name=„Huber“
ORDER BY vname ASC;
MySQL merkt, wenn ein Index „rückwärts durchlaufen“
werden muss.
07.12.2010
14 Performance und Index
37
Index Typen
„Normaler“ Index


Meistverwendeter Index, keine Einschränkung
CREATE INDEX …
Primary Key

Werte sind UNIQUE, Spalte als NOT NULL definiert
Unique Index


Werte sind UNIQUE
CREATE UNIQUE INDEX …
Fulltext Index


Verwendung zur Volltext Suche
ALTER TABLE ADD FULLTEXT …
07.12.2010
14 Performance und Index
38
19
Index
Ein Index (Indexdatei) ist ein Zugriffspfad auf eine
Datei, der selbst wieder als Datei dargestellt wird.
Mit einem Index wird eine effizientere Verwaltung der
Daten möglich, indem auf jeden Datensatz schneller
zugegriffen werden kann als bei der einfachen
sequentiellen Suche in einer Datei. Zugriffspfade werden
u.a. durch Hashing, B-Trees und deren Varianten, GridFiles, R-Trees oder K-D-Trees unterstützt.
07.12.2010
14 Performance und Index
39
Geclusterte Indizes
Bei geclusterten Indizes werden der
Primärschlüssel und der Datensatz selbst
„geclustert“, d.h. zusammengefasst, und
die Datensätze werden in der Reihenfolge
des Primärschlüssels gespeichert.
InnoDB verwendet geclusterte Indizes.
Auf dem Primärschlüssel basierende Queries werden
sehr schnell ausgeführt.
07.12.2010
14 Performance und Index
40
20
Aufbau des Index
Jeder Indexeintrag besteht aus einem
Schlüsselelement K, dem Datensatz T und
eventuell einem Pointer P für die weitere Suche
im Zugriffspfad.




P zeigt auf die nächste Indexseite der Indexdatei
T kann vollständig im Index gespeichert sein
T kann auch als Datensatzidentifikator TID vorliegen
Im RDBS ist K ein Attribut der indizierten Tabelle
07.12.2010
14 Performance und Index
41
Sekundäre Indizides
Sekundäre Indizes verweisen auf den
Primärschlüssel (K) und nicht auf den
Datensatz.
Probleme:
- Langer Primärschlüssel
- Änderung des Primärschlüssels
07.12.2010
14 Performance und Index
42
21
Dünn- vs. dichtbesetzter Index
dünnbesetzter Index: Es existiert nicht für jeden
Zugriffsattributwert K ein Eintrag in der
Indexdatei.
Tabelle ist sortiert nach Zugriffsattributen und es
gilt: Ki ≤ Kx < Ki+1.
Indexsequentielle Datei: sortierte Datei mit
dünnbesetztem Index als Primärindex
dichtbesetzter Index: Für jeden Datensatz
existiert ein Eintrag in der Indexdatei
07.12.2010
14 Performance und Index
43
Unique Index / Primärschlüssel
Bei MyISAM ist der Primärschlüssel ein NOT NULL
UNIQUE INDEX mit Namen PRIMARY. MyISAM
Tabellen müssen keinen Primärschlüssel haben.
InnoDB- und BDB-Tabellen verlangen Primärschlüssel.
Die Storage Engine fügt einen intern generierten
Schlüssel (AUTOINCREMENT) ein, wenn bei der Erstellung
kein Primärschlüssel angegeben wird.
HEAP-Tabellen benötigen keinen Primärschlüssel,
erzeugen aber ebenfalls einen.
07.12.2010
14 Performance und Index
44
22
Index und NULL
NULL Werte können in normalen Indizes
vorkommen.
MySQL (ab 4.0) erlaubt das Vorkommen
von NULL auch im UNIQUE INDEX.
NULL Werte im Index wirken sich nicht auf
die Performance aus!
07.12.2010
14 Performance und Index
45
Index Strukturen
B-Tree
Hash
R-Tree
07.12.2010
14 Performance und Index
46
23
Suchbaum
Suchbäume haben eine Ordnung p, so dass in
jedem Knoten p-1 Werte und p Pointer auf
weitere Knoten vorhanden sind.
Suchbäume erlauben es, Werte in den
Suchbaum aufzunehmen, ohne die zugrunde
liegenden Daten zu sortieren.
Suchbäume werden nicht automatisch balanciert!
07.12.2010
14 Performance und Index
47
B-Tree (B-Baum)
Der B-Tree ist ein Algorithmus zur Erstellung eines
Index. Er generiert einen Mehrwege-Baum, d.h. jeder
Knoten hat mehrere Nachfolger. Haupteigenschaft ist,
dass jeder Pfad im Baum gleich lang und das ganze
Gebilde daher balanciert ist.
Jeder Knoten entspricht einer Seite in der Datei. Jede
Seite (bis auf die Wurzel) ist mit mindestens m und
höchstens 2*m Indexeinträgen gefüllt. Jede Seite enthält
eine Sequenz von sortierten Schlüsseln.
( Vereinfachte Annahmen: Primärindex und TID als Referenz auf
den eigentlichen Datensatz )
07.12.2010
14 Performance und Index
48
24
B-Tree Eigenschaften
Am weitesten verbreiteter Indextyp
Kombination aus Flexibilität und Grösse
z.B. für bereichsbasierte Abfragen
O(log n) Performance für einfaches Query
Flacher als binäre Bäume
07.12.2010
14 Performance und Index
49
B-Tree
07.12.2010
14 Performance und Index
50
25
Beispiel
07.12.2010
14 Performance und Index
51
Hash Index
ebenfalls weit verbreitet
Flache Strukturen (vgl. mit Bäumen)
basierend auf Hash Funktion

Der Hash Wert wird genutzt, um zu ermitteln, in
welchem Fach (Bucket) der Schlüssel abgelegt wird.
Sehr schnelle Lookups möglich

O(1), solange Hash Werte gut verteilt sind
Geringere Flexibilität

Bereichsbasierte Abfragen nutzen Index nicht
07.12.2010
14 Performance und Index
52
26
Hash Theorie
Der MD5 Algorithmus erzeugt 128Bit-Werte (die standardmässig in
Base-64 dargestellt werden), also gibt es über 3.4 * 1038 mögliche
Werte. Weil die meisten Rechner nicht über derart viel Plattenplatz
verfügen (und schon gar nicht Arbeitsspeicher), sind die HashTabellen immer auf den verfügbaren Speicherplatz beschränkt.
Eine gängige Technik, den Schlüsselplatz zu beschränken, besteht
darin, eine feste Zahl von Speicherplätzen (Buckets) zu allozieren
(meist eine relativ grosse Primzahl wie 35149). Der Hash-Wert wird
nun durch diese Primzahl dividiert und der Rest legt fest, in welchen
Bucket der Wert eingetragen wird.
Die Implementierung ist aber meist noch etwas komplexer.
07.12.2010
14 Performance und Index
53
MyISAM Tabellen
Default B-Tree
Präfix Komprimierung

z.B. wird bei URL http:// komprimiert
Gepackte Schlüssel PACK_KEYS=1

höherwertige Bytes werden komprimiert bei
INTEGER Werten
Verzögertes Schreiben von Indizes

delay_key_write (on, off, all)
07.12.2010
14 Performance und Index
54
27
MEMORY Tabellen
ursprünglich nur Hash Index
ab 4.1 auch B-Tree möglich

CREATE TABLE …
INDEX USING BTREE (name) …
Höchste Query Performance

Kombination von B-Tree Flexibilität und
Memory basierten Tabellen und Indizes
07.12.2010
14 Performance und Index
55
InnoDB Tabellen
B-Tree
Keine Präfix Komprimierung, kein Packen
Primärschlüssel notwendig

Wenn nicht definiert, wird 64-Bit-Wert bereitgestellt
Geclusterte Indizes
Indizes im InnoDB Tablespace
gespeichert
07.12.2010
14 Performance und Index
56
28
Volltextindex
Nur in MyISAM
Normaler zweiteiliger MyISAM-B-Tree


erstes Feld: indiziertes Wort als VARCHAR
zweites Feld: Gewichtung innerhalb Zeile als FLOAT
Ein Datensatz für jedes Wort jedes indiziertes
Feldes (Platz vs. Performance)
SELECT * FROM t_bücher WHERE titel = “%mysql%“;
SELECT * FROM t_bücher (titel) MATCH AGAINST (‘mysql‘);
07.12.2010
14 Performance und Index
57
Weitere Performance Engpässe
Wildcard Matching

LIKE „%string%“
Reguläre Ausdrücke

RLIKE „(ber|ger)$“
Fehlerhafte oder beschädigte Statistiken

MySQL interne Indexstatistiken
Zu viele passende Datensätze

Grenze 30%
07.12.2010
14 Performance und Index
58
29
Index Pflege
SHOW INDEX FROM tabelle \G
OPTIMIZE TABLE


Alle Indizes werden neu aufgebaut
Kann lange dauern und Tabelle ist locked
myisamchk

MyISAM Tabelle kann offline geprüft werden
ANALYZE TABLE für InnoDB

Daten werden neu gelesen und Statistik
verbessert
07.12.2010
14 Performance und Index
59
Konfigurationsmängel
Haben globalen Einfluss auf das System
Systemparameter
Optionen beim Start der DB
Verteilung der Datenbank Dateien
Konfiguration der SGA
Konfigurationsmängel passieren meist bei der Implementation des
DBS und können allenfalls in der Testphase noch behoben werden.
Im produktiven Betrieb sind Konfigurationsmängel oft schwer
erkennbar und lassen sich nur mit grösserem Aufwand beheben.
07.12.2010
14 Performance und Index
60
30
Hardware
Zeigt sich die gewählte Hardware als zu
leistungsschwach, muss unter Umständen ein
stärkerer Rechner gekauft und das System neu
implementiert werden.
Harmlosere Fälle sind die Erweiterung des
Hauptspeichers oder zusätzliche Festplatten.
Ist die Kombination Hardware/Software nicht für
den Einsatzzweck ausgelegt, kann dies sogar
einen Redesign des ganzen Systems bedingen!
07.12.2010
14 Performance und Index
61
Übungen

Zeichnen Sie einen Suchbaum (p=3), in den folgende Zahlen
(Reihenfolge) eingetragen werden: 1, 2, 3, 4, 5, 6, 7, 8

Wie würde der resultierende B-Tree aussehen?

In einer Tabelle gibt es in Attribut Status, welches die Werte
„offeriert, bestellt, geliefert, abgelaufen“ haben kann. Welchen
Index schlagen sie dafür vor?
07.12.2010
14 Performance und Index
62
31
07.12.2010
14 Performance und Index
63
32