Prof. Dr. Jens Dittrich - Universität des Saarlandes

Über den (Un-)Sinn von 

Indexen in 

Informationssystemen 

Über mich. 

Prof. Dr. Jens Dittrich 

Lehrstuhl für Informationssysteme 

Universität des Saarlandes 

http://infosys.cs.uni-sb.de

Prof. Dr. Jens Dittrich 

! Jahrgang 1972 

! 1993 - 1999: Studium in Marburg: 

Geographische Informationssysteme, Prof. Seeger 

! 1999 - 2002: Uni Marburg 

Promotion über effiziente Datenbankalgorithmen, 

Joinverfahren, XXL 

! 2003 - 2004: SAP AG: 

Data Warehousing und OLAP: 

verteilter, Hauptspeicherbasierter column-store 

! 2004 - 09/2008: ETH Zürich, Oberassistent im Bereich 

Informationssysteme, Systems Group, Prof. Kossmann 

! Seit 1. Oktober 2008 in Saarbrücken 

Lehrstuhl für Informationssysteme 

Über den (Un-)Sinn von Indexen... Prof. Dr. Jens Dittrich / Information Systems Group / infosys.cs.uni-saarland.de 

Informationssysteme. 

3

1. April 2005 

Beispiele für Informationssysteme 

! Suchmaschinen (Google et.al.) 

! Kartendienste/Routenplaner (GIS, google maps, 2D, 3D, 4D) 

! Dateisysteme (Mac, Linux, Windows) 

! Verkehrsinformationssysteme 

(Luftraum- und Fahrzeugüberwachung) 

! PIM-Tools (Handy, iPhone, subnotebook, Musikanlage, etc.) 

! Soziale Netzwerke (Facebook, LinkedIn, Orkut, etc.) 

! Data Warehouse Systeme (Datenbank von Datenbanken) 

! Multimedia Datenbanken (Bilder, Musik, Video, Sprache) 

! Streaming Engines (Stock ticks, Satellitendaten) 

! digitale Bibliotheken 

! Datenbanksysteme (relational, OO, XML, ...) 


! 

6

“Datenbanksysteme“ (DBMS) 

! der Begriff „Datenbanksysteme“ ist sehr eng gefaßt 

! ein „Datenbanksystem“ hat folgende Eigenschaften 

! Speichern von Daten, volle Kontrolle über die Daten 

! Unterstützung der deklarativen Anfragesprache SQL 

! ein pull-basiertes Anfragemodell 

! Unterstützung von Transaktionen: ACID 

! allerdings gibt es eine Vielzahl von 

Datenmanagementanwendungen, die diese Eigenschaften 

nicht benötigen 

! für diese Anwendungen ist ein DBMS nicht die beste Lösung 

! deswegen macht es Sinn von dem weiter gefaßten Begriff 

„Informationssysteme“ zu sprechen 


Über den Sinn von Indexen. 

7

Grundproblem 

! Benutzer schickt eine Anfrage an das Informationssystem 

! Informationssystem soll Antworten möglichst schnell liefern 

! am besten im Millisekundenbereich 

! Kernproblem: Wie kann ich eine beliebige Anfrage 

beantworten auf beliebig großen Datenmengen? 

!Gigabytes (10 9 Byte)? 

Beispiel: mein Laptop, Bankanwendung, Univerwaltung 

!Terabytes (10 12 Byte)? 

Beispiel: Unternehmensdatenbank, Google Earth, Youtube 

!Petabytes (10 15 Byte)? 

Beispiel: Yahoo, Google 


Gigabyte 

Terabyte 

Petabyte 

1. April 2005 

9

Facetten des Problems 

!Gigabytes (10 9 Byte)? 

! Beispiel Laptop: 

! alle Dokumente, in denen die Phrase “windows ist doof“ 

vorkommt 

! alle Dateien, die gestern geändert wurden 

! alle pdf Dokumente über 1M die 2008 erstellt wurden 

! Beispiel Bankanwendung: 

! aktueller Kontostand 

! Überweisung, Abbuchung 

! Zinsgutschrift 

! Entdeckung „auffälliger“ Konten (Kreditkartenmißbrauch, etc.) 

! Beispiel Univerwaltung: 

! Eintrag eines neuen Studierenden 

! Anzahl der Studierenden an der Universität des Saarlandes 



!Terabytes (10 12 Byte)? 

! Beispiel Unternehmensdatenbank: 

! Umsatz des letzten Quartals 

! alle Aufträge für Kunde Müller 

! Bestand des Warenlagers XY 

! Durchschnittsgehalt aller Mitarbeiter 

! Beispiel Google Earth: 

! Wo befindet sich Saarbrücken? 

! Welche Städte befinden sich in der Nähe von Saarbrücken? 

! Wie fahre ich von Saarbrücken nach Metz? 

! Beispiel: Youtube 

! welche Videos gibt es zu „Led Zeppelin“? 


11 

12


!Petabytes (10 15 Byte)? 

! Beispiel Yahoo und Google: 

! gib mir die wichtigsten Webseiten zu „Saarbrücken Informatik“ 

! zeig mir alle Bilder zum Thema „Sonnenblume“ 

! zeig mir die neusten Nachrichten zum Thema “Barack Obama“ 


Facetten der Lösungen 

! Ziel: effiziente Suche in beliebig großen Datenmengen 

! zur Lösung all dieser Probleme spielen Indexe eine 

herausragende Rolle 

! Index = Datenbanklingo für Datenstruktur/Indexstruktur 


13 

14

Über den Sinn von Indexen. 

Was ist ein Index? 

Grundidee eines Index 

! Abbildung: Schlüssel Menge von Einträgen 

! Beispiel: 

ein Index materialisiert diese Abbildung! 

! Immatrikulationsnummer -> persönliche Daten des Studierenden 

! Städtename -> geographische Region, in der sich diese Stadt 

befindet 

! Stichwort -> alle Webseiten, die dieses Stichwort enthalten 


16

Indexierung in Google Maps 

! Index: 

... 

uni saarbrücken -> 

! sll=49.239793,7.000179 

! ll=49.254921,7.040198 

uni whatever -> ... 

Über den (Un-)Sinn von Indexen... Prof. Dr. Jens Dittrich / Information Systems Group / infosys.cs.uni-saarland.de 17 

Indexierung in (ohne Ranking) 

document IDs 

! Invertierte Liste: 

... 

jens -> (42,{3,500,900,1000}), 

(88,{3,300}), 

(4025,{1,20,5000}), 

dittrich -> (12,{2,450,600}), 

(78,{1,4300,7000}), 

(2123,{30}), 

uni -> (15,{2,450,600}), 

(19,{11,100,2000}), 

(77,{16,1200,2000}), 

(345,{17,300,5000}), 

(2123,{30}), 

... 


Vorkommnisse 

Stichwort “uni“ ist 

vorhanden in Dokument 

15 an den Positionen 2, 

450 und 600 

18

Wie implementiert man binäre Suche? 

! sortiertes array, dann binär suchen 

! O(N log N) Kosten fürs Sortieren 

! was passiert, wenn ich einen neuen Datensatz einfüge? 

! binärer Suchbaum, am besten balanciert (AVL oder rotschwarz 

Baum) 

! binäre Suchbäume sind für DBMS ungeeignet 

! zu hoher Speicherverbrauch 

! schwer abzubilden auf Externspeicher (Flash, Festplatten) 

! zuviele Cache Misses 

! zu langsam 


Wie implementiert man binäre Suche? 

! B + -Baum: 

! wichtigste Indexstruktur im Bereich Informationssysteme 

! extrem vielseitig 

! balanciert 

! selbst im Hauptspeicher um Faktor 5 schneller als rot-schwarz 

Baum von Java 6!!! 

! cache-optimierter B + -Baum um weiteren Faktor 2 und mehr 

schneller 

! invertierte Listen 

! wichtigste Indexstruktur im Bereich Text- und Graphdatenbanken 

! viele Indexprobleme hierauf abbildbar 

! viele weitere Indexstrukturen für Spezialfälle 


21 

22

Trade-offs von Indexen 

! Vorteile 

! Performancegewinn für Anfragen 

! höherer Durchsatz 

! weniger Hardware notwendig 

! Nachteile 

! Implementierungsaufwand 

(eventuell Einbau in bestehendes System) 

! Einpflegen von Datenänderungen 

! mehr Aufwand bei Anfrageoptimierung 


Quintessenz: Der Sinn von Indexen 

! super: 

wir brauchen also für ein gegebenes 

Datenmanagementproblem nur den passenden Index 

finden!!! 

! oder? 

! Nein, das ist leider völlig falsch. 


23 

24

Über den Unsinn von Indexen. 

Einleitung 

! es gibt Szenarien, für die es keine geeigneten Indexe gibt 

! bzw. gibt es Indexe, aber diese Indexe sind langsamer als 

eine lineare Suche... 

! Beispiele 

! Sequentieller vs. Zufälliger Zugriff 

! Relationales Data Warehousing 

! Multi-dimensionales Data Warehousing 

! Ähnlichkeitssuche auf Bildern 

! Trade-offs von Indexen 

! KISS und KIWI 


26

Festplatten 

Virtuelle Spuren 

Platten 

Sektor 

Achse 

Festplattenkopf 


Sequentieller vs. Zufälliger Zugriff 

! Experiment 

Lese 1000 Blöcke der Größe 8 KB 


Arm 

(u: Transferrate in MB, k: Anzahl der überquerten Spuren) 

! sequentielles Lesen: 

tseq = avg(ts) + tr/2 + k*min(ts) + 1000 * 8 KB/u 

! zufälliges Lesen: 

trandom = 1000 * (avg(ts) + tr/2 + ttr) 

27 

28

Sequentieller vs. Zufälliger Zugriff 

! Experiment 

Lese 1000 Blöcke der Größe 8 KB 

zufällig 

sequentiell 

Faktor 

Konsequenzen: 

1970 2007 Verbesserung 

48 275 ms 6 000 ms 8,0 

10 315 ms 70 ms 147,4 

4,7 85,7 

! Werden mehr als 1/85,7= 1,1% der Blöcke gelesen, 

lohnt es sich die gesamte Datei zu lesen!!! 

! 1970 war dieser Faktor wesentlich größer: 21.3%. 

Wichtiges Design-Kriterium für Indexstrukturen! 


Data Warehousing 

! Beispiel Unternehmensdatenbank: 

! Umsatz des letzten Quartals 

! alle Aufträge für Kunde Müller 

! Bestand des Warenlagers XY 

! Durchschnittsgehalt aller Mitarbeiter 

! Dies sind Anfragen mit geringer Selektivität 

! => eine große Zahl von Datensätzen muss berücksichtigt 

werden 

! => Indexierung lohnt nicht (immer) 


29 

30

Data Warehousing 

! Lösung: nahezu vollständiger Verzicht auf Indexe 

! Anfragebearbeitung: alle Einträge werden linear gelesen 

! Aber es werden zahlreiche Tricks benutzt: 

! Vertikale Partitionierung/column stores 

- es wird versucht, nur diejenigen Attribute zu lesen die relevant sind 

- dafür werden die Tabellen in Spalten aufgeteilt 

! Komprimierung 

- Daten werden komprimiert gehalten, um die Lesekosten zu verringern 

! Parallelität 

- die Anwendung wird auf Dutzende bis Hunderte Cores verteilt 

! Hauptspeicher 

- wenn möglich werden alle Daten im Hauptspeicher gehalten 

! Das ist immer noch “lineare Suche“ mit O(N) Komplexität. 

! Aber: die Konstante für die einzelne Operation ist extrem gering. 


Produktbeispiele 

! Sybase IQ (seit frühen 90ern) 

! Applix 

! Monet DB (Hauptspeicher) 

! SAP BI Accelerator (Hauptspeicher) 

! Vertica (Hauptspeicher) 

! ParAccel Analytic 

! Exasol 

! ... 

! Effekt: Schranken für maximale Laufzeit einer Anfrage 

werden möglich. 

! Milliarden-Euro Markt... 


31 

32

Multi-Dimensionales Data Warehousing 

! anderer Lösungsansatz: 

vielleicht gibt es doch geeignete Indexe 

! wir dürfen halt kein relationales DBMS nehmen!! 

! sonder ein multi-dimensionales! 

! => MOLAP (multi-dimensionales OLAP) 

! einige Industrieprodukte 

! z.b. Microsoft Analysis Services 

! sehr viele Vorschläge in der Literatur 

! z.B. Dwarf Index 


A Glimpse on a Dwarf 

! Problem: D-dimensional fact table F 

Example 

Fact Table F 

! Required: Efficient aggregate query processing on F 

- Example queries: (Store,* , *), (*, *, Product), etc. 

! Core idea of a Dwarf: 

! materialize all possible aggregates of F at index time 

! Effect: at query time only need to look-up precalculated results in the Dwarf 

Example 

Dwarf 

Store 

Customer 

Product 

Price 

2 * 

70 70 

1 2 * 

2 3 * (6) 1 * (8) 1 2 3 * 

1 * 

40 40 

1 2 * 

40 70 110 

1 2 * 

90 50 140 

1 2 * 

130 120 250 

VLDB 2008, August 26 Jens Dittrich / ETH Zurich -> Saarland University Dwarfs in the Rearview Mirror 

Store 

Customer 

(2) 

(3) (4) (5) 

1 2 

2 3 1 

(1) 

(7) 

3 dimensions: Store, Customer, 

Product 

1 measure: Price 

(9) 

L=1 

L=2 

L=3 

33 

34

Index Storage Size [MB] 

Comparing with SIGMOD‘02 (3/3) 

! Experiment: 

! 250,000 tuples in fact table 

! however: scale up to 20 dimensions and not only 10 as in SIGMOD‘02 

! Results: 

9000 

8000 

7000 

6000 

5000 

4000 

3000 

2000 

1000 

Dwarf Uniform 

Dwarf 80-20 

Dwarf Zipf 

Fact Table 

0 

4 6 8 10 12 14 16 18 20 

#Dimensions 

Index Construction Time Time [sec] [sec] 

! Dwarf works well for less than 10 dimensions 

! above 10 dimensions and skewed data 

Dwarf index becomes hard to control 

0 

4 6 8 10 12 14 16 18 20 

VLDB 2008, August 26 Jens Dittrich / ETH Zurich -> Saarland University Dwarfs in the Rearview Mirror 

1600 

1400 

1200 

1000 

800 

600 

400 

200 

Dwarf Uniform 

Dwarf 80-20 

Dwarf Zipf 

Ähnlichkeitssuche auf Bildern 


#Dimensions 

confirms results 

additional results 

! hoch-dimensionale Daten treten auch auf bei der 

Ähnlichkeitssuche auf Bildern 

! was ist der geeignete Index? 

35 

36

VLDB 2008 – What’s Wrong with High-Dimensional Similarity Search? 2 of 62 

The Similarity Search Paradigm – 1 

1. April 2005 

1. April 2005 

? 

locate similar images in 

large image collection 

... ... 

Stephen Blott and Roger Weber 



image space 

18 

24 

87 

129 

43 

8 

212 

85 

199 

76 

83 

21 

210 

87 

9 

45 

72 

14 

9 

153 

78 

42 

90 

91 

139 

8 

4 

120 

121 

85 

67 

10 

9 

15 

89 

100 

feature space 

77 

52 

14 

13 

139 

14 

87 

90 

12 

Stephen Blott and Roger Weber



1. April 2005 

1. April 2005 

query object 

d!dimensional feature space 

NN 

NN! 

dist 

Locate closest point to query object, i.e. its nearest neighbour (NN) 




This search paradigm is not restricted to images 

Other examples include: 

• music databases, video databases 

• medical information systems, genomic databases 

• 3D object recognition 

• . . . 



So many methods . . . it has to be difficult! 

1. April 2005 

1. April 2005 

Quad trees [Finkel:1974] 

R-tree [Guttman:1984] 

R + -tree [Sellis 1987] 

R ∗ -tree [Beckmann:1990] 

Vp-tree [Chiueh:1994] 

UB-tree [Evangelidis:1995] 

SS-tree [White:1996] 

M-tree [Ciaccia:1996] 

Pyramid [Berchtold:1998] 

DABS-tree [Böhm:1999] 

Slim-tree [Faloutsos:2000] 

P-Sphere-tree [Goldstein:2000] 

K-d-b-tree [Robinson:1981] 

Gridfile [Nievergelt:1984] 

LSD-tree [Henrich:1989] 

hB-tree [Lomet:1990] 

TV-tree [Lin:1994] 

hB-Pi-tree [Bayer:1996] 

X-tree [Berchtold:1996] 

SR-tree [Katayama:1997] 

Hybrid-tree [Chakrabarti:1999] 

IQ-tree [Böhm:2000] 

landmark file [Böhm:2000] 

A-Tree [Sakurai:2000] 

Unfortunately, 

as dimensionality increases, these methods become ineffective: 

• the so-called curse of dimensionality . . . why? 



Oddity 1 

A simple clustering scheme: 

cluster into regions created by partitioning all dimensions 

This seems reasonable with two or three dimensions 

But with d = 100 there are 2 100 ≈ 10 30 regions: 

even with billions of points, almost all of the regions are empty 



Oddity 2 

1. April 2005 

1. April 2005 

Consider a really big square search region of size s, say s =0.95: 

data space 

target region 

0.95 

But with d = 100: 

probability of a point being in this region is 0.95 100 ≈ 0.0059 

1.0 



Analysis – Probability of Visiting a Region – Hyper-Rectangles 

Prob. of visiting a block 

1 

0.9 

0.8 

0.7 

0.6 

0.5 

0.4 

0.3 

0.2 

0.1 

0 ←− number of dimensions −→ 60 

0 

0 10 20 30 

Number of dimensions (d) 

40 50 60 


KISS und KIWI 

! KISS: “keep it simple and stupid“ 

! falls Performance der linearen Suche ausreicht 

=> warum einen Index bauen? 

! lineare Suche extrem leicht zu warten 

! zum Vergleich: Aufwand zum Warten von Indexen => Manpower 

=> Kosten? 

! KIWI: “kill it with iron“ 

! falls Performance nicht OK => mehr CPUs/Hauptspeicher/ 

Festplatten kaufen 

! die Kosten für zusätzliche Hardware sind oft vernachlässigbar 

gegenüber den Kosten für Manpower 

! allerdings ein Nachteil: Kosten für Strom und Kühlung 


! Intel Core 2 Duo, 2.53 GHz 

! nur ein Core genutzt 

! Java 6 

! selbst 100 M brauchen weniger als 0.12 Sekunden 

1. April 2005 

45

Forschungsthemen. 

Information Systems Group. 

MOVIES.

Moving objects (Autos, Flugzeuge, Schiffe) 

! erinnern Sie sich an den Film “The Fifth Element“? 

! Sicherheitsüberwachung (Distanz zu anderen Fahrzeugen) 

! Unfallvermeidung (virtuelle und dynamische Straßen) 

! Maut 

! Geschwindigkeitskontrolle 

! wie macht man das mit 58 Millionen Fahrzeugen in D? 


Anwendungen 

! car tracking 

! airplane surveillance (3D, 4D) 

! mobile phone tracking 

! emergency services (e.g., enhanced 911) 

! social networking (e.g. Loopt) 

! gaming engines/virtual worlds 

(in three dimensions) 

! etc. 


49 

50

Indexierung eines „Bienenschwarms“ 

! Wie verhalten sich Indexe 

bei einer großen Anzahl von 

Änderungsoperationen? 

! Beispiel: ca. 55 Millionen 

Fahrzeuge in Deutschland 

! Ziel: indiziere aktuelle 

Position aller Fahrzeuge 

! Anfragen: Welche 

Fahrzeuge befinden sich in 

einer bestimmten Region in 

5 Minuten? 


MOVIES 

! MOVIES: MOVing Object Indexing using frEquent Snapshots 

! Kernidee: Filmkamera-Analogie 

! es ist unmöglich kontinuierliche Bewegung mit einer Kamera zu 

erfassen 

! deswegen schießen Filmkameras eine Serie statischer Bilder 

! 24 oder 25 Bilder pro Sekunde (Bildwiederholrate) 

! Anzahl der Bilder überschreitet Trägheit des menschlichen Auges 

! deshalb: Illusion einer kontinuierlichen Bewegung entsteht 

! wir wenden dieselbe Idee auf Indexe an 

! wir versuchen so viele statische Indexe wie möglich zu erzeugen 

! solange die Indexwiederholrate hoch ist, entsteht die Illusion 

eines aktuellen Index 


51 

52

MOVIES 

F45 

F46 

F458 


F459 

I44 

I46 

Experiments 

max update rate [# up./sec., log scale] 

1e+07 

U44 optional input 

U46 

build index 

optional input 

build index 

I45 

I45 

U45 

U45 

1e+06 

100000 

transfer limit 

binary search tree 

B+-tree 

Bx-tree 

MOVIES Aggregated NPI 

MOVIES Logged NPI 

100000 1e+06 1e+07 

index size [# elements, log scale] 


queries 

updates 

queries 

updates 

53 

54

Flash. 

Flash Chips 

! market driven by cell phones, digital cameras, iPods, ... 

! persistent storage 

! yet no mechanical (moving) parts 

! small form factor 

! also replacement for floppy and tape 

! USB drives 


56

Flash Chips 

! cost of a GB of flash versus DRAM 


Example: SSD - Solid State Disks 

! MTRON MSD-P Series with ATA 7 Standard Interface 

! Burst Read/Write: ! 133 MB/sec 

! Sustained Read: ! 100 MB/sec 

! Sustained Write: ! 80 MB/sec 

! IOPS: 

- (Sequential/Random): 76,000/16,000 

- Access Time: less than 0.1 msec 

! Drawback: expensive 

! about X times more expensive than hard disks 

! But: price is expected to drop due to mass-market 

(factor 10 in 2012?) 


Source: http://www.mtron.net/eng/sub_eb11.asp 

(extended) 

approx. by a factor 100 (!) 

better than hard disks 

57 

58

Solution: Hybrid Approach 

! combination of hard disk and SSD 

! flash used as a disk cache 

! in contrast to volatile disk cache flash is persistent 

! Hybrid Storage Alliance 

! Fujitsu 

! Samsung 

! Seagate 

! Toshiba 

! Western Digital 

! Hitachi 

! see http://www.hybridstorage.org 


Flash as DRAM Replacement 

! problem: access to flash still limited by maximal disk interface 

bandwidth 

! how to fix this? 

! idea: 

! replace one of the CPUs by an additional memory controller 

! use one of the DRAM banks to put in flash banks (sic!) 

! effect: 

! reads as fast as DRAM 

! writes as slow as flash 

! persistent 

! much bigger readable memory available 

! hundreds of Gigabytes DRAM-fast memory on a single node!!! 

! good for read-intensive work-loads 

! a startup company in the US is doing this 


59 

60

Parallelität. 

Motivation 

! why use only one CPU if we can use many? 

! goals: 

! improve throughput (number of queries/updates) handled 

! improve individual queries (time to compute a single query) 

! improve system availability 

! improvement linear to the number of CPUs 

! current trends: 

! hardware is getting cheaper 

! example: for a study 18 months ago we used 

- 2*Dual Core AMD Opteron 280 

(= 4 CPU cores on each machine running each at 2.4 GHz) 

- 6 GB of main memory on each machine 

- about 2K Euros per computing node 


62

Motivation: Multi-Core Systems 

! CPU manufactors hit physical barriers: 

! clock rates may not be increased much further (heat problem) 

! chip structures hard to make smaller (physical barriers) 

! solution: improve performance by packing multiple CPUs on 

the same chip 

! current mainstream are dual-cores: 

! Intel Core 2 Duo (e.g., MacBook) 

! AMD Dual-Core Opteron 

! high-end server market already 

sees quad-cores: 

! Intel Xeon (since end of 2006) 

! AMD Quad-Core (September 2007) 

L1 cache 

L2 cache 

shared 

L3 

cache 


Motivation: Multi-Node Systems 

! used large number of independent 

machines 

! either 

! standard (desktop) hardware (Google did this) 

! blade servers, i.e, 

- complete computer on a small blade 

- multiple blades in a rack 

! relatively cheap 

! if used well, may provide tremendous 

performance boosts 

! For instance, assume 

! 16GB of main memory on each blade 

! each blade using at least a Quadcore CPU 

! =96 cores and 384 GB main memory 

24 blades 


AMD Quad-core 

blade rack 

63 

64

Motivation: GPU Data Processing 

! example: NVIDIA GeForce 9800 GTX 

! 128 cores on a single card!! 

! cores optimized for graphcs 

processing 

! however useful for other 

applications as well 

! price: 190 Euros 

(as of Jan 1, 2009) 

! so why not run the information system on the graphics card? 

! several ongoing research projects 

! programmable through CUDA: 

! http://en.wikipedia.org/wiki/CUDA 

! http://www.nvidia.com/object/cuda_sdks.html 


Motivation: GPU Data Processing 

! graphic vendors have also started selling general purpose 

high performance computing chips 

! not calling it GPUs anymore 

! recent example: NVIDIA Tesla 

! 240 cores per processor 

! up to 4 processors in a PC-sized system => 960 cores 

! 3.732 Teraflops 

! compare: my MacBook Pro, Intel Core 2 Duo, 2.53 GHz, 

is at 20 Gigaflops: this is by a factor 187 slower!! 

! under 10,000 $ 

! see video at http://www.youtube.com/nvidiatesla 

! how to implement an information system on a 960 core 

machine? 


65 

66

Fazit. 

! Indexstrukturen sind entscheidend, um ein 

Informationssystem performant zu machen. 

! es gibt allerdings zahlreiche Szenarien, in denen Indexe 

keinen Sinn machen 

! die gegenwärtige Hardwareentwicklung hat 

! Vorteile für Indexe: 

- Flash => zufälliger Zugriff um Faktor 100 schneller 

! Nachteile: 

- simples Scannen wird viel schneller besser als zufäliger Zugriff 

- dies gilt sowohl für Festplatten als auch für Hauptspeicher 

! Um ein Informationssystem effizient zu machen, ist es 

wichtig, die verschiedenen Trade-Offs zu verstehen. 


Information Systems Group 

! Campus E1 1, Räume 220-223 

! http://infosys.cs.uni-sb.de 

! Stammvorlesung “Database Systems“: 

! besserer Name: “Fundamentals of Data Management“ 

! mindestens jedes zweite Wintersemester auf Englisch 

! Einführende Vorlesung “Informationssysteme“ 

! jedes Sommersemester auf Deutsch 

! Interesse and einer Bachelor- oder Masterarbeit? 

! Sprechen Sie mich an! 


67 

68

Prof. Dr. Jens Dittrich - Universität des Saarlandes

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?