pptx - Institut für Informationssysteme

Datenbanken
Prof. Dr. Ralf Möller
Universität zu Lübeck
Institut für Informationssysteme
Karsten Martiny (Übungen)
Architektur eines DBMS
Architecture of a DBMS / Course Outline
Applications
Anwendungen
SQL
Interface
SQL-Schnittstelle
Figure inspired by Ramakrishnan/ Gehrke: “Dat abase Management Systems”, McGraw-Hill 2003.
Webformulare
Web
Forms
Ausführer
Executor
Parser
Parser
Operator
Evaluator
Operator-Evaluierer
Optimizer
Optimierer
Transaction
Transaktions
Manager
Dateiverwaltungsund Zugriffsmethoden
Files and Access
Methods
Verwalter
Puffer-Verwalter
Buffer
Manager
Lock
SperrVerwalter
Manager
Verwalter
für Manager
externen
Disk
Space
RWiederecovery
herstellungsManager
Verwalter
dieser Teil des
thiscourse
Kurses
SQL-Kommandos
SQLCommands
Speicher
DBMS
Dateien
für Daten
und Indexe...
data
files,
indices,
Fall 2008
Datenbank
Database
Systems Group — Department of Computer Science — ETH Zürich
3
2
Danksagung
• Diese Vorlesung ist inspiriert von den Präsentationen
zu dem Kurs:
„Architecture and Implementation of Database
Systems“
von Jens Teubner an der ETH Zürich
• Graphiken wurden mit Zustimmung des Autors aus
diesem Kurs übernommen
3
Speicher: Platten und Dateien
Architecture of a DBMS / Course Outline
Applications
Anwendungen
SQL
Interface
SQL-Schnittstelle
Figure inspired by Ramakrishnan/ Gehrke: “Dat abase Management Systems”, McGraw-Hill 2003.
Webformulare
Web
Forms
Ausführer
Executor
Parser
Parser
Operator
Evaluator
Operator-Evaluierer
Optimizer
Optimierer
Transaction
Transaktions
Manager
Dateiverwaltungsund Zugriffsmethoden
Files and Access
Methods
Verwalter
Puffer-Verwalter
Buffer
Manager
Lock
SperrVerwalter
Manager
Verwalter
für Manager
externen
Disk
Space
RWiederecovery
herstellungsManager
Verwalter
dieser Teil des
thiscourse
Kurses
SQL-Kommandos
SQLCommands
Speicher
DBMS
Dateien
für Daten
und Indexe...
data
files,
indices,
Fall 2008
Datenbank
Database
Systems Group — Department of Computer Science — ETH Zürich
3
4
Speicherhierarchie
•
•
•
•
•
•
CPU (mit Registern)
Cache-Speicher
Hauptspeicher
Flash-Speicher
Festplatte
Bandautomat
Kapazität
Latenz
Bytes
Kilo-/Mega-Bytes
Giga-Bytes
Giga/Tera-Bytes
Tera-Bytes
Peta-Bytes
< 1 ns
< 10 ns
20-100 ns
30-250 ms
3-10 ms
variierend
• Zur CPU: Schnell aber klein
• Zur Peripherie: Langsam aber groß
• Cache-Speicher zur Verringerung der Latenz
5
Magnetische Platten / Festplatten
Magnetic Disks
Magnetic Disks
rotation
Rotation
Spur
track
rotation
arm
Arm
arm
track
sector
heads
Köpfe
heads
•
II
positioniert
Arme
auf
steppermotor
motor
positions
an
array
AASchrittmotor
stepper
positions
an
array
of of
bestimmte
Spur
disk
heads
the
requested
track.
disk
heads
onon
the
requested
track.
• Platters
Magnetscheiben
rotieren
ständig
(disks)
steadily
rotate.
I I Platters
(disks)
steadily
rotate.
• Disks
Organisation
in Blöcke
I I Disks
are
managed
blocks:
system
are
managed
in in
blocks:
thethe
system
• reads/
Transfer
erfolgt
blockweise
reads/
writes
data
one
block
a time.
writes
data
one
block
at (lesend
aattime.
und schreibend)
Fall
2008
Fall
2008
Systems
Group
— Department
of Computer
ScienceScience
— ETH —
Zürich
Systems
Group
— Department
of Computer
ETH Zürich
Photo: ht t p: / / www. met al l ur gy. ut ah. edu/
Sektor platter
sector
platter
Magnetscheibe
Photo: ht t p: / / www. met al l ur gy. ut ah. edu/
block
Block
block
10
10
6
Zugriffszeit
Konstruktion der Platten hat Einflüsse auf Zugriffszeit
(lesend und schreibend) auf einen Block
1. Bewegung der Arme auf die gewünschte Spur
(Suchzeit ts)
2. Wartezeit auf gewünschten Block bis er sich unter
dem Arm befindet (Rotationsverzögerung tr)
3. Lesezeit bzw. Schreibezeit (Transferzeit ttr)
Zugriffszeit: t = ts + tr + ttr
7
Hitachi Travelstar 7K200 (für Laptops)
•
•
•
•
•
4 Köpfe, 2 Magnetplatten, 512 Bytes/Sektor,
Kapazität: 200 GB
Rotationsgeschwindigkeit: 7200 rpm
Mittelere Suchzeit: 10 ms
Transferrate: ca. 50 MB/s
Wie groß ist die Zugriffszeit auf einen Block von 8 KB?
8
Sequentieller vs. Wahlfreier Zugriff
Beispiel: Lese 1000 Blöcke von je 8 KB
• Wahlfreier Zugriff:
– trnd = 1000 ∙ 14.33 ms
• Sequentieller Zugriff:
– Travelstar 7k200 hat 63 Sektoren pro Spur, mit einer
Track-to-Track-Suchzeit ts,track-to-track von 1 ms
– Ein Block mit 8 KB benötigt 16 Sektoren
– tseq = ts + tr + 1000 ∙ ttr + 1000∙16/63 ∙ ts,track-to-track
= 10 ms + 4.17 ms + 160 ms + 254 ms ≈ 428 ms
Einsicht: Sequentieller Zugriff viel schneller als wahlfreier
Zugriff: Vermeide wahlfreie I/O wenn möglich
Beobachtung: Wenn 428 ms / 14330 ms = 3% einer 8MB
Datei benötigt wird, kann man gleich die ganze Datei lesen
9
ormance Tricks
zur
Performanzsteigerung
ystemTricks
builders
play
a number of tricks to improve performance.
Spurverschiebung (track skewing)
ack skewing
Align
sector 0 of
each0track
avoid
Verschiebe
Sektor
einerto
jeden
Spur,
so dass
Rotationsverzögerung
rotational
delay
during sequential
bei sequentiellem Abgriff minimiert wird
scans.
Anfrageplanung (request scheduling)
quest scheduling
Falls mehrere
Blockanfragen
befriedigt
werden
If multiple
requests
have to be served,
choose
themüssen,
one that
wähle
diesmallest
Anfrage,arm
die die
kleineste (SPTF:
Armbewegung
requires
the
movement
shortest
bedarf
positioning
time
first).
(SPTF: shortest positioning time first)
oningEinteilung in unterschiedliche Zonen (zoning)
Outer
tracks are longer than the inner ones. Therefore,
Mehr Sektoren in den längeren äußeren Spuren
divide
outer tracks into more sectors than inners.
unterbringen
10
Verbesserung der Festplattentechnologie
Latenz der Platten über die letzten 10 Jahre
nur marginal verbessert (≈ 10% pro Jahr)
Aber:
– Durchsatz (Transferraten) um ≈ 50% pro Jahr
verbessert
– Kapazität der Festplatten um ≈ 50% pro Jahr
verbessert
Daher:
– Kosten für wahlfreien Zugriff über die Zeit hinweg
relativ gesehen immer bedeutsamer
11
Wege zur Verbesserung der I/O-Performanz
Latenzproblem kaum zu vermeiden
Aber:
– Durchsatz kann recht leicht gesteigert werden
durch Ausnutzung von Parallelität
– Idee: Verwende mehrere Platten und
greife parallel auf Daten zu
TPC-C: Ein Industrie-Laufzeittest für OLTP (V5.11)
Kennzeichen des im Jahre 2013 besten Systems (Oracle 11g auf SPARC T5-8
Server):
• Server-CPU: SPARC T5 3,6 GHz, #Prozessoren: 8, #Kerne (total): 128
• Client-CPUs: Intel Xeon E5-2690 2,9 GHz, #Clients: 8, #Proz. 32,
#Kerne: 256
• In der Summe 8,5 Mio Transaktionen pro Minute
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp
• Kosten: $4.663.073
USD, mit $0,55 USD/tpmC
12
Spiegelung von Festplatteninhalten
Disk Mirroring
I
data onto multiple
disks auf mehrere Platten
• Replicate
Replizierung
von Daten
1 2 3 4 5
6 7 8 9 ···
1 2 3 4 5
6 7 8 9 ···
1 2 3 4 5
6 7 8 9 ···
• I/O-Parallelität nur für Lesezugriffe
I I/ O parallelism only for reads.
• Erhöhte Fehlertoleranz (überlebt Plattenfehler)
I Improved failure tolerance (can survive one disk failure).
Als
RAID1
(Spiegelung
ohne Parität)
I • This
is also
knownbekannt
as RAID 1(mirroring
without parity).
(RAID:
Redundant
Array of Inexpensive
(RAID:
Redundant
Array ofDisks)
Inexpensive Disks)
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
17
13
Speicherung mit Streifenbildung
Disk Striping
• IVerteilung
der
Daten
Distribute data
over
disks auf mehrere Platten
1 2 3 4 5
6 7 8 9 ···
1 4 7 ···
2 5 8 ···
3 6 9 ···
• IVolle I/O-Parallelität
Full I/ O parallelism.
• IHohe
Fehlerrate
höheres
Ausfallrisiko)
High failure
risk (here:(hier:
3 timesdreimal
risk of single
disk failure)!
Also known
as RAID 0 bekannt
(striping without
parity).
• IAuch
als RAID-0
(Streifenbildung
ohne
Parität)
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
18
14
Streifenbildung mit Parität
Disk Striping with Parity
I Distribute
• Verteile
Daten
und
Paritätsinformation
data and
parity
information over disks. über Platten
1 2 3 4 5
6 7 8 9 ···
1 3 5/ 6 7 · · ·
2 3/ 4 5 8 · · ·
1/ 2
4 6 7/ 8 · · ·
• Hohe I/O-Parallelität
I High I/ O parallelism.
• Fehlertoleranz:
Platte
kanndata
ausfallen,
ohne
I Fault tolerance: oneEine
disk can
fail without
loss (two disks
withDaten
dual parity/
RAID 6). gehen
dass
verloren
I Also known as RAID 5 (striping with distributed parity).
• RAID-5
(Streifenbildung mit verteilter Parität)
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
19
15
Solid-State Disks als Alternative zur
Festplatte
Anpassung von Datenbanken auf
Geräteeigenschaften ist immer noch
Forschungsgegenstand
Quelle: Wikipedia Solid-State Dis
16
Netzwerk-Speicher ist kein Flaschenhals
• Durchsatz Festplatte (SSD): >500 MB/s (Serial ATA)
• SDRAM: 50 Gbit/s (Latenz: ∼ ns)
• Ethernet
– 100-Gbit/s heute (Latenz: ∼ ms)
– 400 Gbit/s erwartet in 2017
Warum also nicht Datenbank-Speicher über das
Netzwerk referenzieren?
17
Speichernetzwerk (Storage Area Network,
SAN)
• Block-basierter Netzwerkzugriff auf Speicher
– Als logische Platten betrachtet
(Suche Block 4711 von Disk 42)
– Nicht wie bei NFS (Network File System)
• SAN-Speichergeräte abstrahieren von RAID oder
physikalischen Platten und zeigen sich dem DBMS
als logische Platten
– Hardwarebeschleunigung und einfachere Verwaltung
• Üblicherweise lokale Netzwerke mit multiplen
Servern und Speicherressourcen
– Bessere Fehlertoleranz und erhöhte Flexibilität
18
Cloud-Speicher
• Cluster von vielen Standard-PCs (z.B. Google,
Amazon)
– Systemkosten vs. Zuverlässigkeit und Performanz
– Verwendung massiver Replikation von
Datenspeichern
• CPU-Zyklen und Disk-Kapazität als Service
– Amazons „Elastic Compute Cloud (EC2)“
• Kosten pro Stunde <10 Cent
– Amazons „Simple Storage System (S3)“
• „Unendlicher“ Speicher für Objekte in einer Größe
zwischen 1 Byte und 5 GB mit Key-Value-Struktur
– Latenz: 100 ms bis 1s
M. Brantner, D. Florescu, D. Graf, D. Kossmann, T. Kraska, Building a
database on S3, Proceedings of the 2008 ACM SIGMOD International
Conference on Management of Data (SIGMOD '08), S. 251-264, 2008
• Datenbank auf Basis von S3 entwickelt in 2008
19
Architektur eines DBMS
Architecture of a DBMS / Course Outline
Applications
Anwendungen
SQL
Interface
SQL-Schnittstelle
Figure inspired by Ramakrishnan/ Gehrke: “Dat abase Management Systems”, McGraw-Hill 2003.
Webformulare
Web
Forms
Ausführer
Executor
Parser
Parser
Operator
Evaluator
Operator-Evaluierer
Optimizer
Optimierer
Transaction
Transaktions
Manager
Dateiverwaltungsund Zugriffsmethoden
Files and Access
Methods
Verwalter
Puffer-Verwalter
Buffer
Manager
Lock
SperrVerwalter
Manager
Verwalter
für Manager
externen
Disk
Space
RWiederecovery
herstellungsManager
Verwalter
dieser Teil des
thiscourse
Kurses
SQL-Kommandos
SQLCommands
Speicher
DBMS
Dateien
für Daten
und Indexe...
data
files,
indices,
Fall 2008
Datenbank
Database
Systems Group — Department of Computer Science — ETH Zürich
3
20
Verwaltung des externen Speichers
• Abstraktion von technischen Details der
Speichermedien
• Konzepte der Seite (page) mit typischerweise 464KB als Speichereinheiten für die restlichen
Komponenten
• Verzeichnis für Abbildung
Seitennummer  Physikalischer Speicherort
wobei der physikalische Speicherort
– eine Betriebssystemdatei inkl. Versatz,
– eine Angabe Kopf-Sektor-Spur einer Festplatte oder
– eine Angabe für Bandgerät und -nummer inkl. Versatz
sein kann
21
Verwaltung leerer Seiten
Verwendete Techniken:
1. Liste der freien Seiten
– Hinzufügung falls Seite nicht mehr verwendet
2. Bitmap mit einem Bit für jede Seite
– Umklappen des Bits k, wenn Seite k (de-)alloziert wird
22
Aufgabe
Verwendete Techniken:
1. Liste der freien Seiten
- Hinzufügung falls Seite nicht mehr verwendet
2. Bitmap mit einem Bit für jede Seite
- Umklappen des Bits k, wenn Seite k (de-)alloziert
wird
Zur Erhöhung des sequentiellen Zugriffs sollten
hintereinanderliegende Seiten verwendet werden.
Welche Technik, 1. oder 2., würden Sie wählen, um dieses
zu unterstützen?
23
Architektur eines DBMS
Architecture of a DBMS / Course Outline
Applications
Anwendungen
SQL
Interface
SQL-Schnittstelle
Figure inspired by Ramakrishnan/ Gehrke: “Dat abase Management Systems”, McGraw-Hill 2003.
Webformulare
Web
Forms
Ausführer
Executor
Parser
Parser
Operator
Evaluator
Operator-Evaluierer
Optimizer
Optimierer
Transaction
Transaktions
Manager
Dateiverwaltungsund Zugriffsmethoden
Files and Access
Methods
Verwalter
Puffer-Verwalter
Buffer
Manager
Lock
SperrVerwalter
Manager
Verwalter
für Manager
externen
Disk
Space
RWiederecovery
herstellungsManager
Verwalter
dieser Teil des
thiscourse
Kurses
SQL-Kommandos
SQLCommands
Speicher
DBMS
Dateien
für Daten
und Indexe...
data
files,
indices,
Fall 2008
Datenbank
Database
Systems Group — Department of Computer Science — ETH Zürich
3
24
Puffer-Verwalter
Buffer
Manager
• buffer
Vermittelt
zwischen
The
manager
Seitenanforderungen
page requests
6
1
3
1 2
3 4
7 8
9 10
Fall 2008
externem
und internem
mediates between
external
Speicher
storage and(Hauptspeicher)
main memory,
4
memory
I Verwaltet
manages a designated
main
•
hierzu
einen
Seite
disk page
memory area, the
buffer pool
7
besonderen
Bereich
im
free frame
freier
for this task.
Rahmen
Hauptspeicher, den
DiskPufferbereich
pages are brought(buffer
into
memory as needed and loaded into
pool)
disk
Festplatte
memory frames.
5 6
Externe Seiten
in which
A•replacement
policy decides
11 · · ·
desthe buffer is full.
pageRahmen
to evict when
Pufferbereichs laden
• Verdrängungsstrategie
Systems Group — Department of Computer Science — ETH Zürich
28
falls Pufferbereich voll 25
Hauptspeicher
main
I
Schnittstelle zum Puffer-Verwalter
Funktion pin für Anfragen nach Seiten und
unpin für Freistellungen von Seiten nach Verwendung
• pin(pageno)
– Anfrage nach Seitennummer pageno
– Lade Seite in Hauptspeicher falls nötig
– Rückgabe einer Referenz auf pageno
• unpin(pageno, dirty)
– Freistellung einer Seite pageno zur möglichen
Auslagerung
– dirty = true bei Modifikationen der Seite
Wofür
nötig?
26
Implementation von pin()
Implementation of pi n ( )
1
Function: pi n( pageno)
2
if buffer pool already contains pageno then
pi nCount ( pageno) + 1;
pi nCount ( pageno)
return address of frame holding pageno ;
else
select a victim frame v using the replacement policy ;
if di r t y ( v) then
write v to disk ;
3
4
5
6
7
8
9
10
11
12
read page pageno from disk into frame v ;
1;
pi nCount ( pageno)
false ;
di r t y ( pageno)
return address of frame v ;
27
Implementation von unpin()
Implementation of unpi n ( )
1
Function: unpi n( pageno, dirty)
2
pi nCount ( pageno)
if dirty then
di r t y ( pageno)
3
4
pi nCount ( pageno) − 1;
dirty ;
Why don’t we write pagesback to disk during unpi n ( ) ?
Warum werden Seiten
nicht gleich beim unpin
zurückgeschrieben?
28
Verdrängungsstrategien
Die Effektivität des Puffer-Verwalters hängt von der
gewählten Verdrängungsstrategie ab, z.B.:
• Least Recently Used (LRU)
– Verdrängung der Seite mit längszurückliegendem
unpin()
• LRU-k
– Wie LRU, aber k-letztes unpin(), nicht letztes
• Most Recently Used (MRU)
– Verdrängung der Seite mit jüngstem unpin()
• Random
– Verdrängung einer
beliebigen Seite
Wann welche
Strategie einsetzen?
29
Pufferverwaltung in der Praxis
• Prefetching
– Antizipation von Anfragen, um CPU- und I/O-Aktivität
zu überlappen
• Spekulatives Prefetching: Nehme sequentiellen
Seitenzugriff an und lese im Vorwege
• Prefetch-Listen mit Instruktionen für den
Pufferverwalter für Prefetch-Seiten
• Fixierungs- oder Verdrängungsempfehlung
– Höherer Code kann Fixierung (z.B. für Indexseiten)
oder schnelle Verdrängung (bei seq. Scans)
empfehlen
• Partitionierte Pufferbereiche
– Z.B. separate Bereiche für Index und Tabellen
30
Datenbanken vs. Betriebssysteme
• Haben wir nicht gerade ein Betriebssystem
entworfen?
• Ja
– Verwaltung für externen Speicher und
Pufferverwaltung ähnlich
• Aber
– DBMS weiß mehr über Zugriffsmuster (z.B.
Prefetching)
– Limitationen von Betriebssystemen häufig zu stark für
DBMS (Obergrenzen für Dateigrößen,
Plattformunabhängigkeit nicht gegeben)
31
Datenbanken vs. Betriebssysteme
• Gegenseitige Störung möglich
– Doppelte Seitenverwaltung
– DMBS-Transaktionen vs. Transaktionen auf Dateien
organisiert vom Betriebssystem (journalling)
– DBMS Pufferbereiche durch Betriebssystem
ausgelagert
– DBMS schalten Betriebssystemdienste aus
• Direkter Zugriff auf Festplatten
• Eigene Prozessverwaltung
• ...
32
Architektur eines DBMS
Architecture of a DBMS / Course Outline
Applications
Anwendungen
SQL
Interface
SQL-Schnittstelle
Figure inspired by Ramakrishnan/ Gehrke: “Dat abase Management Systems”, McGraw-Hill 2003.
Webformulare
Web
Forms
Ausführer
Executor
Parser
Parser
Operator
Evaluator
Operator-Evaluierer
Optimizer
Optimierer
Transaction
Transaktions
Manager
Dateiverwaltungsund Zugriffsmethoden
Files and Access
Methods
Verwalter
Puffer-Verwalter
Buffer
Manager
Lock
SperrVerwalter
Manager
Verwalter
für Manager
externen
Disk
Space
RWiederecovery
herstellungsManager
Verwalter
dieser Teil des
thiscourse
Kurses
SQL-Kommandos
SQLCommands
Speicher
DBMS
Dateien
für Daten
und Indexe...
data
files,
indices,
Fall 2008
Datenbank
Database
Systems Group — Department of Computer Science — ETH Zürich
3
33
Datenbank-Dateien
abase
Files
I
I
I
2008
So far we have talked about pages. Their management is
• Seitenverwaltung
unbeeinflusst
Inhalt
oblivious
with respect to their
actual contentvom
.
• the
DBMS
verwaltet
von tablesof
Tupeln,tuples
On
conceptual
level, aTabellen
DBMSmanages
and indexes(among
others).
Indexstrukturen,
...
Such
tables are implemented
as filesof
records:
• Tabellen
sind Dateien
von Datensätzen
(records)
I
A file consists of one or more pages.
– Datei besteht aus einer oder mehrerer Seiten
I
Each page contains one or more records.
– Jede
Seite
speichert
einetuple.
oder mehrere Datensätze
I
Each
record
corresponds
to one
0
–fileJeder
Datensatz korrespondiert zu einem Tupel
free
page 0
page 1
page 2
page 3
file 1
free
page 4
page 5
page 6
Systems Group — Department of Computer Science — ETH Zürich
page 7
37
34
Heap-Dateien
Heap Files
• The
Wichtigster
Dateityp:
Speicherung
von
Datensätzen
most important
type of files
in a database is the
heap
file. It
stores
records in no particular
order (in
line with, e.g.,
mit willkürlicher
Ordnung
(konform
mitSQL).
SQL)
Linked list of pages
Verkettete
Liste von Seiten
header
page
data
page
data
page
···
data
page
pages w/
free space
data
page
data
page
···
data
page
full pages
 +Einfach
zu implementieren
easy to implement
– mostSeiten
pages will
endder
up inListe
free page
✗ Viele
auf
derlistfreie Seiten
–(haben
might have
to search
pages to place a (large) record
also
nochmany
Kapazität)
✗Fall 2008
Viele Seiten
anzufassen bis passende Seite
Systems Group — Department of Computer Science — ETH Zürich
gefunden
38
35
Heap-Dateien
Heap
Files
Directory
of pagesvon Seiten
• Verzeichnis
data
page
···
data
page
data
page
✗ Verwendung als Abbildung mit Informationen über
I use as space map with information about free page
freie
I Plätze
granularity
as trade-off
space $ accuracy
(Granularität
ist Abwägungssache)
(range
fromfreien
open/Plätzen
closed bit
to exact information)
 Suche
nach
effizient
+ ✗
free
space search more
efficient
Zusatzaufwand
für Verzeichnisspeicher
– small memory overhead to host directory
36
Freispeicher-Verzeichnis
Welche Seite soll für neuen Datensatz gewählt
werden?
• Append Only
– Immer in letzte Seite einfügen, sonst neue Seite anfordern
• Best-Fit
– Alle Seiten müssen betrachtet werden, Reduzierung der
Fragmentierung
• First-Fit
– Suche vom Anfang, nehme erste Seite mit genug Platz
– Erste Seiten füllen sich schnell, werden immer wieder
betrachtet
• Next-Fit
– Verwalte Zeiger und führe Suche fort, wo Suche beim
vorigen Male endete
37
Inhalt
einer Seite
nside
a Page
Inside a Page
I DI D
NAM
N
AME E
4711 John
John
4711
1723 Mar c
1723
Mar c
6381 Bet t y
6381 Bet t y
I
I
SEX SEX 4 7 1 1 J o4h7n 1 1 J o hM1
n723M
M1 7 2 3 M
y 3 8 1 Be t t y
M M a r c F a r c M6 3 8 1 B e t t M6
F
M
M
F
F
•I record
Datensatz-Kennung
identifier (rid):
hpageno,
slotnoi
(record
identifier,
record
identifier
(rid): rid)
I record position (within page):
hpageno, slotnoi
• Datensatz-Position
slotno ⇥ bytes per slot
(Versatz
auf(within
der Seite)
record
position
page):
I Tuple
deletion?
Slotno
Bytes
slotno
⇥xidbytes
perpro
slotSlot
record
shouldn’t
change
! slot directory (bitmap)
•Tuple
Datensatz
deletion?gelöscht?
slot
directory
I
I
–record
rid sollte
sich nicht
id shouldn’t
change
ändern
! slot
directory (bitmap)
– Slot-Verzeichnis
(Bitmap)
I
Fall 2008
Fall 2008
no. of records
in this page
slot
no. of records
1 0 1 3 Header
directory
in this page
Systems Group — Department of Computer Science — ETH Zürich
Systems Group — Department of Computer Science — ETH Zürich
42
101
3 Header
38
42
de aInhalte
Page—Variable-Sized
einer Seite: FelderFields
variabler Länge
Variable-sized fields moved to
4 7 1 1 • MJ o h n ? 1 7 2 3 • MM
• Felder variabler Länge
a r c ? 6 3 8 1 • F Be t t y ? 1 7 2
end of each record.
• • MT i mo t h y ?
3
zum Ende verschoben
I
Placeholder
points
– Platzhalter
zeigt to
auf
forward
location.
Position
Warum?
I
Why?
Slot-Verzeichnis
zeigtof
auf
Slot •directory
points to start
Start eines Feldes
each record.
• Felder
können
auf Seite
Records
can move
on page.
verschoben werden
I
E.g., if field size changes.
slot
no. of records
(z.B. wenn sich
directory
in this page
Create Feldgröße
“forward address”
if
ändert)
record
won’t fit oneiner
page.
• Einführung
I
• • • 3 Header
Future updates? wenn
Vorwärtsreferenz,
Was passiert bei
Feld nicht auf Seite passt
39
Updates?
Alternative Seiteneinteilungen
Alternative Page Layouts
Alternative
Page Layouts
We have just populated data pages in a row-wise fashion:
WeBeispiel
have just populated
pages in a row-wise
fashion:
• Im
wurdendata
Datensätzen
zeilenweise
angeordnet:
a1
b1
c1
a4
b4
a
a11
a
a22
a
a33
a
a44
b
b11
b
b22
b
b33
b
b44
c
c11
c
c22
c
c33
c
c44
d
d11
d
d22
d
d33
d
d44
c1a1 d1
c1 b2 d1
d2b2 a3
d2 c3 a3
c3
b1 a2c1
c2 a2 d2
c2 b3d2
d3 b3
d3
c4a4 d4 b4
c4
d4
page 0
page 0
c4
c4
page 1
page 1
Wecould
could as
aswell
well do
dothat
that column-wise:
column-wise:
We
• Spaltenweise Anordnung genauso möglich:
aa11
aa22
aa33
aa44
Fall 2008
2008
Fall
bb11
bb22
bb33
bb44
cc11
cc22
cc33
cc44
dd11
dd22
dd33
dd44
a1
a2
a
a
1
2
aa33
aa44
aa33
b1
b2
b
b
1
2
bb33
bb44
page 0
page 0
SystemsGroup
Group—
—Department
DepartmentofofComputer
ComputerScience
Science——ETH
ETHZürich
Zürich
Systems
bb3 3
····· ·
page 1
page 1
4444
40
Alternative Page Layouts
Alternative Seitenanordnungen
These two approaches are also known as NSM (n-ary storage
model) and DSM (decomposition storage model).1
Vorgestellte
Schemata heißen auch:
I Tuning knob for certain workload types (e.g., OLAP)
– Row-Store
– Column-Store
Different behavior with respect to compression.
I
Anwendungen
fürPAX
verschiedene
A•hybrid
approach is the
(Partition
Attributes
Accross)
layout:
Lasttypen
und
Anwendungskontexte
Divide each(z.B.
pageOLAP)
into minipages.
•I Unterschiedliche
Group attributes into them.
Kompressionsmöglichkeiten
% Ailamaki et al. Weaving Relations for Cache
• Kombination
Performance.
VLDB 2001.möglich:
minipage 3
minipage 2
I
minipage 1
minipage 0
page 0
– Unterteilung einer Seite in Miniseiten
1
Recently,
terms row-store and
column-store have become popular, too.
– mit the
entsprechender
Aufteilung
Fall 2008
Systems Group — Department of Computer Science — ETH Zürich
Ailamaki et al. Weaving Relations for Cache Performance. VLDB
2001
45
41
Zusammenfassung
• Kennzeichen von Speichermedien
– Wahlfreier Zugriff langsam (I/O-Komplexität)
• Verwalter für externen Speicher
– Abstraktion von Hardware-Details
– Seitennummer  Physikalischer Speicherort
• Puffer-Verwalter
– Seiten-Caching im Hauptspeicher
– Verdrängungsstrategie
• Dateiorganisation
– Stabile Record-Bezeichner (rids)
– Verwaltung statischer und dynamischer Felder