stockage et indexation: plan du cours - inriapucheral/enseignements_fichiers/... · – e.g.,...
TRANSCRIPT
Modèles de stockageet d’indexation
1
By courtesy of N. Anciaux, L. Bouganim, P. Pucheral , P. Bonnet, D. Shasha, M. J. Zaki
Architecture en couche d’un SGBD
Analyseur sémantique
Interface
Opérations relationnelles
Moteur d’exécution
Optimiseur
Analyseur sémantique
2
Gestion deMémoire
Gestion deVerrous
Gestion desJournaux
Méthodes d’accès aux données
Système d’exploitation
Stockage et indexation: plan du cours
• A la base de tout, le hardware– Cache CPU, RAM, disques, …Flash
• Organisation des données• Organisation des données– Format des attributs, tuples, pages, fichiers, index
• Index hiérarchiques, hachage et autres outils
• Mises en œuvre (du Peta au Pico)– SGBDR : Oracle– Key-Value Store – NoSQL : Cassandra
3
– Key-Value Store – NoSQL : Cassandra– Column Store for Big Data : MonetDB– SGBD embarqué : PlugDB
A la base de tout, le hardware
4
Hiérarchie mémoire
10 1Cache processeur
Ratio Prix (approx) Accès (ns)
10 Go/s
Débit (Mo/s)
10
1
0.01
1
10
107
Cache processeur
RAM
Disques
10 Go/s
1 Go/s(x10-1)
100 Mo/s
5
0.01
0.001
107
10ms
1010
qq sec
Disques
Bandes / Disques optiques
100 Mo/s(x10-2)
10 Mo/s(x10-3)
Disques Magnétiques• Progression moyenne des disques
– Capacité + 60% par an– Latence stable � contraintes
mécaniques …– Débit + 40% par an
Arbre
Tête de lecturePistes
– Débit + 40% par an
tête de lecture
piste
plateau
arbre
PlateauxMouvement du bras
Secteur
6
Contrôleur
lecture
bras
levier
Interface (IDE, SCSI)
Plateaux
Bras
Optimisations logicielles– Prefetching
• Le SGBD peut anticiper les patterns d’accès aux données• Ainsi, il peut pré-charger (prefetch) des données en RAM• NB: le prefetching doit être géré au niveau du SGBD (vs. OS)
– Clustering• Regroupement physique des données fréquemment utilisées
ensemble dans les mêmes blocs/pages de données• Placement de ces blocs sur
– La même piste physique => I/O unique
7
– La même piste physique => I/O unique– Le même cylindre physique => I/O séquentielles
• Compromis entre bon placement et trop de perte de place– Allocation d’un ensemble de blocs par «granule»
• ioDrive Octal, 10,24 To – PCIe
NAND Flash: le futur des SGBD ?
• ioDrive Octal, 10,24 To – PCIe• Lecture : 1 300 000 IOPS – 6,7 Go/s• Ecriture : 1 240 000 IOPS – 3,9 Go/s• 96 « package » de Flash
• OCZ Vertex 4 - 2.5" SATA III• Capacité : 512 Go - Prix : env. 600 euros• Lecture : 35 000 IOPS - 535 Mo/s• Ecriture : 75 000 IOPS - 475 Mo/s
8
• Ecriture : 75 000 IOPS - 475 Mo/s• Compression, chiffrement, …
• Cartes Micro SD, SD et clés USB• Capacité : 1 – 32 Go (2 To annoncés en SD)• Prix : 1 à 2 euros le Go• Lecture : env. 1000 IOPS - env. 20 Mo/s• Ecriture : max. 200 IOPS - env. 10 Mo/s
Evolution des mémoires secondaires2000 2010
Capacité
IOPS
200 Go 2 To
200 200 Go/$ 0,05 30
x1x600x10
Dis
ques
m
agné
tique
s
IOPS 200 200
14 Go (2001) 256 Go
0,0003 0,5
> 1 M (PCIe)
>5000 (SATA)
1000 (SCSI)
x1
x20
x1000x1000
CapacitéIOPS > 1 M (1 chip)
200 000 cells, 4 bits/cell
Capacité
IOPSGo/$
PC
M
Fla
shD
isqu
es
mag
nétiq
ues
9
Consommation électrique• Plus faible que les disques
magnétiques• Proportionnel à l'usage !
The Good
The hardware!The hardware!• A single flash chip offers great performance
– e.g., direct read: random (25µs), sequentiel (50ns/byte)– e.g., troughput of 40 MB/s Read, 10 MB/s Program– Random access is as fast as sequential access– Low energy consumption
• A flash device contains many flash chips (e.g., 32, 64) and
10
• A flash device contains many flash chips (e.g., 32, 64) and provides inter-chips parallelism
• Flash devices may include some (power-failure resis tant) SRAM
The Bad
The severe constraints of flash chips!• C1: Program granularity: • C1: Program granularity:
– Program must be performed at flash page granularity
• C2: Must erase a block before updating a page
• C3: Pages must be programmed sequentially within a block
• C4: Limited lifetime (from 104 up to 106 erase operations)
11
Program granularity: a page (32 KB)Pages must be programmed sequentially
within the block(256 pages)
Erase granularity: a block (1 MB)
The software!, the Flash Translation Layer– emulates a classical block device and handle flash
And The FTL
– emulates a classical block device and handle flash constraints
Read sector Read page
Constraints
(C1) Program granularity
(C2) Erase before prog.
MAPPING
12SSD
Write sector
No constraint!
Flash chips
Program page
Erase block
(C2) Erase before prog.
(C3) Sequential programwithin a block
(C4) Limited lifetime
GARBAGECOLLECTION
WEARLEVELING
FTL
How do flash devices impact DBMS design? : Assumptions
• Rule 1 (?): Flash devices behave as flash chips– DBMS design coping with flash chip constraints
• Rule 2 (?): Updates and random writes are too expensive
– Buffer updates, use log-based strategies (Random IOs�Sequential IOs)
• Rule 3 (?): Reads are cheap (even random ones)– Make aggressive use of random reads, e.g., delay access to attributes
• Others rules: – Do not use all the flash logical space
13
– Do not use all the flash logical space– Use a degree of parallelism relative to the number of chips– Partition logical space– Use semi-random writes
Are these assumptions relevant?
Benchmarking methodology (example): Device state
Random Writes – Samsung SSD Random Writes – Samsung SSD
14
Random Writes – Samsung SSDOut of the box
� Enforce a well-defined device state
Random Writes – Samsung SSDAfter filling the device
Impact of write locality
Locality for the Samsung, Memoright and Mtron SSDs
Granularity for the Memoright SSD
15
Memoright and Mtron SSDsMemoright SSD
• SR, RR and SW are very efficient• RW are very expensive, unless limited to a focused area• Sequential writes should be limited to a few partit ions• Surprisingly, no device supports parallel IO submis sion
Why are FTL so unpredictable?
• Opacity: – Flash devices vendors mask design decision to protect their advantage
• Dynamicity:• Dynamicity:– The market is too dynamic to build a DBMS design on a “stable sand”
• Leading markets:– The flash internal software is tailored for mass markets (e.g., photo, file system)
• Opportunity:– Flash devices vendors include “opportunistically” some technology in the internal flash
software: e.g., deduplication
16
software: e.g., deduplication
• Complexity: – Flash devices are complex systems
How to tackle the FTL unpredictability?• Main idea: Move the complexity to the DBMS
– Provide a tunnel for IOs that respect Flash constraints � maximal performance– Manage other unconstrained IOs in best effort
Block map., Wear Leveling(C4)
DBMSunconstrained constr. patterns
patterns (C1, C2, C3)
(C1) Program granularity(C2) Erase before prog.(C3) Sequential prog.
within a block(C4) Limited lifetime
Bim
odal
flas
h de
vice Page map., Garb. Coll.
(C1, C2, C3)
17
• More research is highly required
Flash chips
(C4)
Bim
odal
flas
h de
vice
Organisation des données
(Now, back to HARD DISK DRIVES)
18
Modèles de stockage des données• Les données sont stockées sous forme de
– attributs, de taille fixe ou variable...– …stockés eux-mêmes sous forme de tuples...– …stockés dans des pages (blocs disques)...– …stockés dans des fichiers
19
• Rappel : le SGBD gère un cache de pages en RAM à la façon d’une mémoire virtuelle
attributs tuples pages fichiers∈∈∈∈ ∈∈∈∈ ∈∈∈∈
Stockage des tuples (attributs de taille fixe)
Att1 Att2 Att3 Att4
Adresse de base (B)
T1 T2 T3 T4
Adresse = B+T1+T2
20
• Les informations concernant les types/tailles d’attributs– Sont partagées par tous les tuples d’un fichier– Sont stockées dans le catalogue système
• Accéder au ième attribut ⇒ la lecture totale du tuple
Stockage des tuples (att. de taille variable)
• Deux alternatives de stockage (le nombre d’attributs est fixe):
$ $ $ $
Att1 Att2 Att3 Att4
$ $ $ $
Att1 Att2 Att3 Att4
21
• La deuxième alternative offre – Un accès direct au ième attribut – Un petit coût de stockage supplémentaire (taille de «offset» > taille «$»)
Tableau d’offsets des attributs
Pages : tuples de taille fixe
. . . . . .
Emplacement 1
Trou
Emplacement 2Emplacement 1Emplacement 2
. . . . . .
N M10. . .
M ... 3 2 1Page compacte
(pas de trou)Bitmap (0=trous)
Page éparse
Trou
11
Nombre de tuples
Nombre d’emplacements
Emplacement N
Emplacement M
Emplacement N
22
• Identifiant d’un tuple (Row id ) : Rid = < id page, emplacement #>• Remarque
– la Clé d’un tuple est un «pointeur logique», le Rid est un «pointeur physique»
Page éparse
Pages: tuples de taille variable
Page iRid = (i,N)
Rid = (i,2)
Rid = (i,1)
Pointeurvers l’espacelibreN . . . 2 1
N20 16 24
23
• Déplacement des tuples dans la page sans changer le Rid…
libre
Pointeurs d’emplacements
N . . . 2 1Nombre d’emplacements
Fichiers non ordonnés• Soit la table Doctor suivante
idnumber(4)
first_namechar(30)
genderchar(1)
specialtychar(20)
1 Maria F Pediatrics
2 Antonio M Dermatology
• Le modèle de stockage NSM (N-ary Storage Model ou Raw-based)
• Le modèle de stockage DSM (Decomposition Storage Modelou Column-based)
3 Dominique F Psychology
1 Maria F Pediatrics 2 Antonio M Dermatology
ID1 1 ID2 2 ID3 3
ID1 Maria ID2 Antonio ID3 Dominique
3 Dominique F Psychology
24
ou Column-based) – Optimisation des I/O
• Le modèle de stockage PAX (Partition Attributes Across)– Optimisation du cache
Pages disques
ID1 F ID2 M ID3 F
ID1 Pediatrics ID2 Dermatology ID3 Psychology
ID1 ID2 1 2 Maria Antonio F M Pediatrics Dermatology
ID3 3 Dominique F Psychology
Index hiérarchiques et hachage (rappel ?)
25
Indexation• Objectifs
– Offrir un accès rapide à tous les tuples d’un fichier satisfaisant un même critère
• A partir d’une clé (discriminante ou non, mono ou multi-attributs)• Sur des fichiers ordonnés sur cette clé, ou non ordonnés, ou
ordonnés sur une autre clé
• Moyen– Créer une structure de données accélératrice associant des
adresses de tuples aux valeurs de clés
26
adresses de tuples aux valeurs de clés
• Index– Table (ou hiérarchie de tables) implémentant cet
accélérateur
Catégories d’index (1)
• Index primaire ou plaçant(primary or clustered)
– Tuples du fichier organisés par rapport à l’index
Clé K
– Tuples du fichier organisés par rapport à l’index• Les tuples sont stockés «dans» l’index
– 1 seul index primaire par table…• Souvent construit par le SGBD sur la clé primaire
• Index secondaire ou non plaçant(secondary or unclustered)
…K1…
…K2……Kn…
Page 1 Page 2 Page i
Clé L
↓Tuples triés sur K
27
(secondary or unclustered)
– Tuples organisés indépendamment de l’index• Seuls les Rid des tuples sont «dans» l’index
– Plusieurs index secondaires possibles par table
…K1…
…K2……Kn…
Page 1 Page 2 Page i
Clé L
Tuples non triés sur L
Catégories d’index (2)
• Index dense (dense)– Contient toutes les clés– référence tous les tuples tuple– référence tous les tuples
• Index non dense (sparse)– Ne contient pas toutes les clés– Ne référence pas tous les tuples
(e.g., référence une seule fois chaque page)– Nécessite que le fichier soit trié sur les clés
tuple
tupletuple
Page 1 Page 2 Page i
tupletuple
28
– Nécessite que le fichier soit trié sur les clésContient alors la plus grande clé de chaque bloc + l'adresse du bloc
• NB : Densité d’un index : nb d’entrées dans l'indexnb de tuples dans la table
tupletuple
Page 1 Page 2 Page i
Catégories d’index (3)
• Mais au fait …– Peut-on créer un index non dense non plaçant ?
– Peut-on créer un index dense et plaçant ?
– Peut-on créer un index primaire (c.à.d, plaçant) sur une clé secondaire (c.à.d, non discriminante) ?
– Peut-on créer un index secondaire (c.à.d, non plaçant) sur une clé primaire (c.à.d, discriminante) ?
29
Index arborescents• Index hiérarchisés ou multi-niveaux
– Permet de gérer de gros index (i.e., très gros fichiers…)
– Principe : chaque index est indexé– Principe : chaque index est indexé
• Fonctionnement– L’index est trié
(mais trop gros � peu performant…)
– On indexe l’index
Pourquoi l’index à indexer doit-il être trié ?
30
– On indexe l’index • Par un second index non dense
(� 2ème niveau)
– On peut continuer…(jusqu’à obtenir un index non dense qui tiennent dans une seule page…)
Exemple : Arbre-B+Arbre-B (B-tree)
Un arbre-B d'ordre m est un arbre tel que:(i) chaque noeud contient k clés triées, avec m <= k <= 2m,
sauf la racine pour laquelle k vérifie 1<= k <= 2m.(ii) tout noeud non feuille possède (k+1) fils. Le ième fils contient des
1) en mettant toutes les clés des articles dans un arbre B+ et en pointant sur ces articles par des adresses relatives ==> INDEX NON PLACANT2) en rangeant les articles au plus bas niveau de l'arbre B+ ==> INDEX PLACANT
(ii) tout noeud non feuille possède (k+1) fils. Le ième fils contient desclés comprises entre la (i-1)ème et la ième clé du père.
(iii) l'arbre est équilibré.
31A faire chez soi : comprendre la mise à jour dans un arbre-B
Hauteur d'un Arbre-B
• La hauteur d'un arbre-B est déterminé par son ordre et le nombre de clés contenues. – pour stocker N clés :
log 2m (N) ≤≤≤≤ h ≤≤≤≤ log m (N)
– Soit h=3 pour N=8000 et m=10– Ou h=3 pour N=8 millions et m=100– Ou encore h=3 pour N=1 milliard et m=500
• h est très important car il détermine le nombre d’E/S nécessaire pour traverser l’arbre lors d’une sélection
32
pour traverser l’arbre lors d’une sélection
• Dans la pratique, qu’est ce qui détermine m ?• Et pourquoi est-ce important que l’arbre soit équilibré ?
Organisations par Hachage• Objectif
– Offrir un accès rapide à tous les tuples d’un fichier satisfaisant un même critère (idem orga. arborescentes)
– Eviter le coût lié à la traversée d’une arborescence
• Moyen– Calculer l’adresse du tuple à l'aide d'une fonction de
hachage appliquée à la clé de recherche
33
– La sélection se fait directement en recalculant cette même fonction
Fonction dehachage
Clé
Hachage statique
0 1 2
………… ………
i n }Paquets
• Les fonctions de hachage génèrent des collisions
34
• Les fonctions de hachage génèrent des collisions– Donc des débordements de paquets– Un fichier ayant débordé ne garantit plus de bons temps d'accès (1 + p),
avec p potentiellement grand– Il ne garantit pas non plus l’uniformité (prédictibilité) des temps d’accès
• Solution idéale: réorganisation progressive
Hachage extensible
H (KEY) Paquets
00 XXXX X X X
Paquets
000 001 010
Répertoire
00 01 10 11
Le paquet 01 éclate en deux paquets 001 et
Signature
35
Répertoire
010 011 100 101 110 111
deux paquets 001 et 101- on double la taille du répertoire- on considère un bit de plus dans chaque signature
Comparaisons B+Tree vs. Hachage• Organisations arborescentes
– Supporte les point (égalité) et range (inégalité) queries– Le nb d’E/S dépend de la hauteur de l’arbre (usuellement h – Le nb d’E/S dépend de la hauteur de l’arbre (usuellement h
reste petit)
– La taille de l’index est potentiellement importante– Le coût de mise à jour est potentiellement important
• Organisations hachées– Ne supporte que les point queries
36
– Performance optimale (resp. mauvaise) quand les données sont bien (resp. mal) distribuées
Autres outils d’indexation
37
Indexation multi-attributs• Ex: Table Médecins fréquemment interrogée sur l’attribut
Spécialité mais également sur l’attribut Adresse • Organisations arborescentes
– Tri multi-critères A1, A2, …An
– Permet de traiter les critères du type ‘(A1 θ x) AND (A2 θ y) …’
– Peut-on traiter par exemple (A2 θ y) seul ?
• Organisations hachées– Hachage multi-attributs A1, A2, …An– Certains attributs peuvent être privilégiés
h1(A1), h2(A2), … hn(An)
38
– Certains attributs peuvent être privilégiésen leur allouant plus de bits, en positionnant ces bits en début de chaîne
– Peut-on traiter par exemple (A2 = y) seul ?
001101001100100100100100011110010100
h1(A1), h2(A2), … hn(An)
001101001100100100100100011110010100
Index couvrants• Construction d’index couvrant une requête
– Accès à l’index (sans accès à la relation) permet de répondre à la requête
– Accélération drastique d’un pattern de requêtes particulier– Accélération drastique d’un pattern de requêtes particulier
• Attributs à mettre dans l’index couvrant– Tous les attributs nécessaires à la requête…
• Attributs intervenant dans les sélections• Attributs intervenant dans les projections
• Exemple
39
• Exemple– Pattern de requête
SELECT P.nomFROM Personne PWHERE P.salaire > Y;
– Index couvrant • Index sur la clé suivante : P.salaire, P.nom
Index Bitmap
– Index Bitmap = index secondaire dense non trié
– A chaque clé, on associe un bitmap • 1 entrée par tuple• 1 entrée par tuple
1/0 = contient oui/non la valeur
– Utilisé si1) clé varie sur un domaine de faible cardinalité2) requêtes multi-critères sans sélectivité dominante � Pourquoi ?
ArtBerthe
NurseZouk
100100100
001001000
000000001
010010010
↓ … … Art … …
… … Zouk … …
… … Berthe … …
… … Art … …
… … Zouk … …
… … Berthe … …
… … Art … …
… … Zouk … …
… … Nurse … …
40
– Peut être vu comme une façon de compresser les listes inversées (listes de Rid)
Bitmap Indexes and Range queries (example from Barot Rushin)
• Bitmap indexes can help answer range queries.
• Example:
No Age Salary
1 25 60
2 45 60• Example:• Given is the data of a
jewelry stores. The attributes considered are age and salary.
2 45 60
3 50 75
4 50 100
5 50 120
6 70 110
7 85 140
8 30 260
41
9 25 400
10 45 350
11 50 275
12 60 260
Bitmap Indexes and Range queries (contd…)
• bitmap index for Age
Value Vector Value Vector
• bitmap index for Salary
25 100000001000
30 000000010000
45 010000000100
50 001110000010
60 000000000001
70 000001000000
85 000000100000
60 110000000000
75 001000000000
100 000100000000
110 000001000000
120 000010000000
140 000000100000
42
85 000000100000260 000000010001
275 000000000010
350 000000000100
400 000000001000
Bitmap Indexes and Range queries (contd…)
• Suppose we want to find the jewelry buyers with an age in the range 45-55 and a salary in the range 100-200.200.
• We first find the bit-vectors for the age values in this range; in this example there are only two: 010000000100 and 001110000010, for 45 and 50, respectively. If we take their bitwise OR, we have a new bit-vector with 1 in position i if and only if the ith
43
record has an age in the desired range. • This bit-vector is 011110000110.
Bitmap Indexes and Range queries (contd…)
• Next, we find the bit-vectors for the salaries between 100 and 200 thousand.
• There are four, corresponding to salaries 100, 110, • There are four, corresponding to salaries 100, 110, 120, and 140; their bitwise OR is 000111100000.
• The last step is to take the bitwise AND of the two bit-vectors we calculated by OR:
011110000110
AND 000111100000
44
AND 000111100000-----------------------------------
000110000000
• Only the fourth and fifth records, which are (50,100) and (50,120), are in the desired range.
Index de jointure
• Join Index– Matérialisation d’une association (jointure)
• Exemple IJ
docid visitid
1 5
1 6
2 2
IJvers Doctor vers Visit
• Exemple IJDoc,Visit
• Star Join index– Pour les schémas en étoile (star schema)– Stocké sous forme de bitmap
clés = valeur d’attributs d’une dimensionbits = référencent les tuples de Fact
– Utilisé pour les requêtes en étoile
2 2
2 3
2 8
3 1
3 4
3 7
Lundi 00001↓ XL 10011↓
45
– Utilisé pour les requêtes en étoile• σσσσ : des sélections sur les dimensions• ∞ : entre les dimensions et la table de faits
– Les prédicats sont tous appliqués par AND/OR de bitmaps
id D1 D2 Desc
1 3 2 Art
2 2 1 Zouk
3 2 1 Berthe
4 3 2 Frank
5 1 2 Bif
FACT
id Jour
1 Lundi
2 mardi
3 mercredi
D1 id Taille …
1 XL …
2 XXL …
D2
mardi
mercredi
01100
10010
↓ XXL 01100↓
D3
Bloom Filters
• Introduce a trade-off between size and accuracy– Bloom Filter is a probabilistic compact data structure for
membership check.– No False Negative answers!!– There may be false positive answers, but the false positive rate f
is low.– The factor f is influenced by m and k. For example, when m=16n,
k=7, f is only 0.0007, which is very small. (n: number of elements in the set)
46
Bloom filter
A space-efficient data structure for set membership.
Example : Test the membership of 23, 46, 600 01
F ={12, 23,45, 48, 67, 88}
k independent hash functions, e.g., h1 and h2
h1(12) = 0 h2(12)=7
h1(23) = 10 h2(23)=3
h1(45) = 4 h2(45)=1
h1(23) = 10 h2(23)=3
h1(46) = 8 h2(46)=10
h1(60) = 4 h2(60)=7
23 ∈∈∈∈ F
1
2
3
4
5
6
7
0
0
0
0
0
0
0
1
0
1
1
0
1
1
47
h1(48) = 7 h2(48)=0
h1(67) = 3 h2(67)=10
h1(88) = 6 h2(88)=4
46 ∉∉∉∉ F
60 is a false positive.
7
8
9
10
11
0
0
0
0
0
1
0
0
1
0
Bloom filters: nombreuses variantes• Counting Bloom Filters
– Supporte l’opération delete d’un élément dans l’ensemble– Chaque entrée du tableau correspond à un compteur (au – Chaque entrée du tableau correspond à un compteur (au
lieu d’1 seul bit)
– Les compteurs sont incrémentés lors des insert et décrémentés lors des delete
– Oblige à connaitre le nombre approximatif de clés et augmente la taille du tableau
• Stable Bloom Filters, adaptés au streams de données
48
• Stable Bloom Filters, adaptés au streams de données• Scalable Bloom Filters, Layered Bloom Filters, …• Utilisées dans de nombreux contextes
Mise en œuvre dans les SGBDR
49
Oracle
50
Support partiellement emprunté à Pascale Borla Sala met – Oracle France
Oracle
Organisation des données sur disque
Database
PhysiqueLogique
Base de données
Tablespace
Segment
Extent
DatafilesRécipient logique pour regrouper des objets applicatifs liés et administrés ensemble
Lieu de stockage d’une structure :Table, index, partition de table …
Granule d’allocation =
51
Block Bloc OS
Granule d’allocation =Ensemble de blocs contigus
Granule d’I/OIdéalement multiple d’un Bloc OS
52
53 54
Data blocs
• Un data block est l’unité de gestion de l’espace disque• Il est la plus petite unité d’E/S• Géré indépendamment de son contenu (table, index …)• Géré indépendamment de son contenu (table, index …)
Tuples (row data)
55
Tuples (row data)
Espace libre (PCTFREE, PCTUSED)
Répertoire de tuples (row directory)
Répertoire de table (table directory)
Entête
PCTFREE et PCTUSED• Paramètre PCTFREE
– Pourcentage d’un bloc réservé aux mises à jour futures– Quand PCTFREE est atteint : le bloc est retiré de la freelist (liste des blocs dans
lesquels il est possible d’insérer de nouvelles données)
• Paramètre PCTUSED – Pourcentage d’occupation minimum d’un bloc en dessous duquel des données
peuvent à nouveau être insérées – Quand PCTUSED est atteint : le bloc est remis dans la freelist– 40%, par défaut
Pourquoi si faible ? La taille moyenne d’un tuple suffirait…
56
• Réglage– Par le DBA (paramètre du CREATE TABLE)– Par l’ASS = Automatic Segment Space Management (>Oracle 8i)
-> recommandé
Si Oracle remet les bloc dans la liste des blocs libre alors que ces blocs disposent de peu d’espace libre, le coût des insertions nombreuses (de plusieurs tuples) sera très élevé (jusqu’à 1 IO par tuple inséré)
Utilisation de PCTFREE et PCTUSEDPCTFREE=20, PCTUSED=40
INSERTION (Max 80% du bloc)INSERTION (Max 80% du bloc)
Mise à jour
57
Si PCTUSED<40, alors des insertions peuvent à nouveau être effectuées
SUPPRESSION
58
59
• Table index-organized = index plaçant• les tuples entiers sont stockés dans les feuilles plutôt que leur Rowid
60
11
61
11
1 1
62
63 64
65
Partitionnement des tables (1)• 3 méthodes de partitionnement
Exemple
CREATE TABLE sales_hash
(salesman_id NUMBER(5),
66
(salesman_id NUMBER(5),
salesman_name VARCHAR2(30),
sales_amount NUMBER(10),
week_no NUMBER(2))
PARTITION BY HASH(salesman_id)
PARTITIONS 4
STORE IN (ts1, ts2, ts3, ts4);
tablespaces
Partitionnement des tables (2)• Possibilité de combiner les modes (partitionnement
composite)
67
CREATE TABLE sales_composite(salesman_id NUMBER(5),salesman_name VARCHAR2(30),…PARTITION BY RANGE(sales_date)SUBPARTITION BY HASH(salesman_id)SUBPARTITION TEMPLATE(SUBPARTITION sp1 TABLESPACE ts1,SUBPARTITION sp2 TABLESPACE ts2, …PARTITION sales_jan2000 VALUES LESS THAN(TO_DATE('02/01/2000','DD/MM/YYYY'))PARTITION sales_feb2000 VALUES LESS THAN(TO_DATE('03/01/2000','DD/MM/YYYY'))…
Partitionnement des indexIndex partitionné local Index partitionné global
• Index global non partitionné sur une table partitionnée
68• Un index bitmap partitionné ne peut qu’être local
Mise en œuvre Mise en œuvre dans les systèmes NoSQL et application au Big Data
69
David J. [email protected]
Microsoft Jim Gray Systems LabMadison, Wisconsin
Rimma [email protected]
Amount of Stored Data By SectorIf you like analogies…If you like analogies…
Every two days we create as much data as much we did from dawn of humanity to 2003
300
400
500
600
700
800
900
1000966
848
715
619
434364
269227
Amount of Stored Data By Sector(in Petabytes, 2009)
Pet
abyt
es
35ZB = enough data to fill a stack of DVDs
reaching halfway to Mars
If you like analogies…If you like analogies…
0
100
200
300 227
1 zettabyte? = 1 million petabytes= 1 billion terabytes = 1 trillion gigabytes
71
Sources :"Big Data: The Next Frontier for Innovation, Competition and Productivity."US Bureau of Labor Statistics | McKinsley Global Institute Analysis
MarsMarsMarsMars
EarthEarthEarthEarth
Old guard
Use a parallel database systemguard
Young turks
database systemeBay – 10PB on 256 nodes
72
Use a NoSQL systemFacebook - 20PB on 2700 nodesBing – 150PB on 40K nodes
� Key/Value Stores� Examples: MongoDB, CouchBase, Cassandra,
Windows Azure, …Windows Azure, …� Flexible data model such as JSON
� Records “sharded” across nodes in a cluster by hashing on key
� Single record retrievals based on key
� Hadoop� Scalable fault tolerant framework for storing and
processing MASSIVE data sets� Typically no data model
� Records stored in distributed file system
73
Structured Unstructured&
Relational DB SystemsRelational DB Systems
Structured data w/ known schema
ACID
NoSQL SystemsNoSQL Systems
(Un)(Semi)structured data w/o schema
No ACID
74
ACID
Transactions
SQL
Rigid Consistency Model
ETL
Longer time to insight
Maturity, stability, efficiency
No ACID
No transactions
No SQL
Eventual consistency
No ETL
Faster time to insight
Flexibility
Key-Value Store: stockage & indexation• L’exemple de CASSANDRA (Facebook → Apache)• Data Store semi-structuré, hautement distribué,
‘scalable’ et disponible‘scalable’ et disponible– Développé initialement pour supporter les recherches dans
les Inbox Facebook– Milliards d’écritures par jour
• Basé sur– Principe de key-value store
75
– Principe de key-value store
– DHT (Distributed Hash Table)– Eventual consistency
Où comment construire un index supportant des milliards de modifications par jour ?
Cassandra: modèle de données• Column
– Paire (clé: name, valeur:value) associé à un timestamp utilisé pour la synchronisation
– Name, value : chaînes d’octets sans limite de taille– Name, value : chaînes d’octets sans limite de taille
• Super-column
Column family
76
• Super-column– Column dans laquelle la valeur est elle-même une liste de colonnes
• Column family– Similaire à une table (i.e., ensemble de tuples)
Exemple de Column Family
77
La structure des ‘tuples’ n’est pas obligatoirement uniforme
Exemple de Super-Column Family
78
Illustration
79
Stockage distribué par ‘consistent hashing’• Hachage sur un anneau (Distributed Hash Table)
– Par défaut MD5, mais peut être configuré– Hachage préservant l’ordre déconseillé (inéqui-distribution)
• Chaque ‘tuple’ est haché sur sa clé → k et placé sur le noeud proxy d’identifiant ≥ k • Il est répliqué sur N voisins (pas de cohérence forte sauf si exigé)
– Dont au moins un sur un data center différent du noeud proxy
80
Zone de coordinationdu noeud N21
Recherche logarihmique vs. directe• Chaque noeud possède une table de routage partielle (ex: avec p entrées)
– Découpage récursif de l’espace en 2 ⇒ recherche logarithmique
• Cassandra– 1 noeud = 1 data center– 1 noeud = 1 data center– tous les data centers ont une table de routage complète
81
Index sur chaque noeud• Primary index
– Chaque noeud maintient un index local sur la clé primaire des ‘tuples’ qu’il stocke (clé d’une (super)-column family)
• Secondary index– Sur n’importe quelle Column
• Mise à jour des index– Objectif = supporter des ‘milliards’ de modifications par jour– pas de mise à jour en place sur disque pour éviter les I/O
82
– pas de mise à jour en place sur disque pour éviter les I/O random
Mise à jour des index (1)
MemTable
83
Log
Mise à jour des index (2)
84
SSTable
Lecture dans l’index (1)
85
Optimisation• Minimiser le nombre de SSTable présentes sur disque
– Fusion d’index par Sort-merge → I/O séquentielles
86
• Minimiser le nombre de SSTable à tester lors des recherches– Ajout d’un Bloom Filter pour chaque SSTable
DB Architectures for Big Data Exploration (by Stratos Idreos - MonetDB)Où comment construire un index sur un critère inconnu au départ ?
s
87
DB Architectures for Big Data Exploration
88
DB Architectures for Big Data Exploration
89
DB Architectures for Big Data Exploration
90
DB Architectures for Big Data Exploration
91
DB Architectures for Big Data Exploration
92Indexing on-the-fly within the select-operator
DB Architectures for Big Data Exploration
93The more we crack, the more we learn
DB Architectures for Big Data Exploration
94
Mise en œuvre dans les SGBD embarqués
95
Why embedding Data Management techniques?
Secure devices on whicha GB flash chipis superposed
Personal& securedevices ④④④④①①①① ②②②② ③③③③
Personal memory devices in which a secure chip is implanted
USB MicroSD reader
Contactless + USB8GB Flash
Secure MicroSD4GB Flash
devices ④④④④①①①① ②②②② ③③③③
Sensors equipped with flash memory cards
Sim Card
96
• Common architecture▫ Microcontroller + NAND Flash▫ Low cost, low energy, dense, robust▫ Hundreds of GBs on chip !
• Microcontrollerssmall RAM ( 5KB ~ 128KB)
Hardware Constraints
small RAM ( 5KB ~ 128KB)
• NAND FlashHigh cost of Random writesLimited nb of Erase cycles NAND
FLASH
MCU
BU
S
97
Pages must be erased before being rewritten Erase by block vs. write by page
• B+ tree based indexing methods: BFTL, JFFS3, FlashDB, etc.
– To delay the index updates thanks to a log and batch them to group updates related to the same index node
Batch indexing methods
The Logical View of a B-Tree The Node Translation Table
I1 I2 I3
Index
UnitFlash Memory
Ik
A B-Tree Node
98
– To build a RAM index at boot time to speed up the lookup of a key in the log
– To commit the log updates with a given commit frequency (CF) in order to bound the log size
Batch indexing methods
• Summary of the approach– The original B-Tree on flash is updated lazily– Up-to-date index = B-Tree + Log– Up-to-date index = B-Tree + Log– RAM index speeds-up the lookups in the Log
• How to decrease the number of writes?– By decreasing the Commit Frequency CF to increase the
probability that several updates fall in the same node(s)– but the lower CF, the larger the Log …– … and then the higher the RAM consumption to index it
99
– … and then the higher the RAM consumption to index it
���� Contradictory objectives
• Let’s assume an optimal scenario for Flash and RAM usage
� To organize the complete database as a set of sequential data structures…
PBFilter Indexing Scheme
structures…
• However,•key lookup cost will be
|KA/2| + |DA| +1 Record 1
Record 2
. . .
1 page
. . .
<Key m, pt>
RAM
FlashRA KA
DA buffer
pt 2
pt t
. . .
. . .
DA
. . .
<Key 2, pt>
<Key 1, pt>
. . .
RA buffer KA buffer
100
• Question:• Can we maintain acceptable lookup performance without breaking the sequential organization?
Record m
. . .pt 1
. . .
. . .
Page k
. . .
PBFilter Principles
• Summarization:
– to condense KA � SKA
– and to produce SKA sequentially– and to produce SKA sequentially
– Requirement: Summarization must not introduce false negative
Record 1Record 2
. . .. . .
Summary 1Summary 2
. . .
RAM
Flash RA KA SKA
DA buffer
pt 2pt t
. . .
DA
<Key 2, pt><Key 1, pt>
RA buffer KA buffer SKA buffer
101
. . .
1 page
. . .
<Key m, pt>
Record m
. . .
. . .
Summary k. . .
pt 1
. . .
. . .
. . .
. . .
Page k
. . .
. . .
PBFilter Instantiation: Bloom Filter Summaries
RAM KA buffer
KA
SKA buffer
SKA
FlashKey 1, ptKey 2, pt
…Key m, pt
…
00011100010001000010001100
…0100100100010
…
.…p1.p2…p3……
(2) Scan the SKA to check each Bloom Filter at p1,p2, and p3
(3) Search in KA page
Page Pi
102
…
Lookup(ai)
h1(ai) h2(ai) h3(ai)
.…p1.p2…p3……
(1) Hash
key lookup cost becomes |SKA/2| + 1 + |DA| +1
PBFilter Principles
• Question: is it possible to reduce the cost by a bigger factor?
• Yes! If we split the bloom filters into p vertical partitions, so that only part
of the partitions need to be accessed for a lookup � SKA scan cost is
Record 1Record 2
. . .. . .
Summary 1Summary 2
. . .
RAM
Flash RA KA SKA
DA buffer
pt 2pt t
. . .
DA
<Key 2, pt><Key 1, pt>
RA buffer KA buffer SKA buffer
of the partitions need to be accessed for a lookup � SKA scan cost is decreased roughly by a factor of p/k
103
. . .
1 page
<Key m, pt>
Record m
. . .
Summary k. . .
pt 1
. . .
. . .
. . .
. . .
Page k
. . .
. . .
PBFilter Instantiation: Partitioned Summaries
1 ……… 1.......1 … .. ………………………………………… ....1 ……… 1.......1 … .. ………………………………………… ....
1 …… .1......1 ……
P 01
Status 1: bloom 1 is in SKA buffer1 st 201 st 301 st
1 st 512 nd
.…… ........... …
P 11
513 rd 1024 th
.…… ........... …
P 21
1025 th 1536 th
1 …… .1......1 …
P 31
1537 th 2048 th
2048 thBit position :
1 …… .1......1 ……
P 01
Status 1: bloom 1 is in SKA buffer1 st 201 st 301 st
1 st 512 nd
.…… ........... …
P 11
513 rd 1024 th
.…… ........... …
P 21
1025 th 1536 th
1 …… .1......1 …
P 31
1537 th 2048 th
2048 thBit position :
104
Status 2: bloom 1 is in L1 partitionsStatus 2: bloom 1 is in L1 partitions
Exemple : si 4 partitions, chaque partition contient une liste de ‘quarts’ de Bloom filters