Architecture en couche d un SGBD Interface Modèles de stockage et d indexation Analyseur sémantique Optimiseur Moteur d exécution Opérations relationnelles Méthodes d accès aux données By courtesy of N. Anciaux, L. Bouganim, P. Pucheral, P. Bonnet, D. Shasha, M. J. Zaki Gestion de Mémoire Gestion de Verrous Gestion des Journaux Système d exploitation 1 2 Modèle de stockage: plan du cours Hiérarchie mémoire Introduction à la hiérarchie mémoire Cache CPU, RAM, disques, Flash Ratio Prix (approx) Accès (ns) Débit (Mo/s) Organisation des données Format des attributs, tuples, pages, fichiers, index Modèle de stockage Organisation des index Type d index Modèle d indexation Deux exemples concrets Oracle Key-Value Store: Cassandra 10 1 0.01 0.001 Cache processeur RAM Disques Bandes / Disques optiques 1 10 10 7 10ms 10 10 qq sec 10 Go/s 1 Go/s (x10-1 ) 100 Mo/s (x10-2 ) 10 Mo/s (x10-3 ) 3 4
Disques Magnétiques Optimisations logicielles Progression moyenne des disques Capacité + 60% par an Latence stable contraintes mécaniques Débit + 40% par an Tête de lecture Arbre Pistes 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) piste plateau levier Contrôleur arbre tête de lecture bras Mouvement du bras Bras Plateaux Secteur 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 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» Interface (IDE, SCSI) 5 6 NAND Flash: le futur des SGBD? Evolution des mémoires secondaires 2000 2010 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 Flash Disques magnétiques Capacité 200 Go x10 2 To Go/$ 0,05 x600 30 IOPS 200 x1 200 Capacité Go/$ IOPS 14 Go (2001) x20 256 Go 0,0003 x1000 0,5 1000 (SCSI) x1000 > 1 M (PCIe) >5000 (SATA) 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 Compression, chiffrement, PCM Capacité IOPS 200 000 cells, 4 bits/cell > 1 M (1 chip) 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 Consommation électrique Plus faible que les disques magnétiques Proportionnel à l'usage! 7 8
The Good The Bad 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 provides inter-chips parallelism Flash devices may include some (power-failure resistant) SRAM The severe constraints of flash chips! 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 10 4 up to 10 6 erase operations) Pages must be programmed sequentially within the block (256 pages) Program granularity: a page (32 KB) Erase granularity: a block (1 MB) 9 10 And The FTL The software!, the Flash Translation Layer emulates a classical block device and handle flash constraints Read sector Write sector No constraint! GARBAGE COLLECTION MAPPING WEAR LEVELING Read page (C2) Erase before prog. Program page Erase block Constraints (C1) Program granularity (C3) Sequential program within a block (C4) Limited lifetime 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 IOsSequential 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 Use a degree of parallelism relative to the number of chips Partition logical space Use semi-random writes Are these assumptions relevant? SSD FTL Flash chips 11 12
Benchmarking methodology (example): Device state Impact of write locality Random Writes Samsung SSD Out of the box Random Writes Samsung SSD After filling the device Granularity for the Memoright SSD Locality for the Samsung, Memoright and Mtron SSDs Enforce a well-defined device state 13 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 partitions Surprisingly, no device supports parallel IO submission 14 Opacity: Why are FTL so unpredictable? Flash devices vendors mask design decision to protect their advantage 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 Complexity: Flash devices are complex systems 15 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 Bimodal flash device DBMS unconstrained constr. patterns patterns (C1, C2, C3) Page map., Garb. Coll. (C1, C2, C3) Block map., Wear Leveling (C4) Flash chips (C1) Program granularity (C2) Erase before prog. (C3) Sequential prog. within a block (C4) Limited lifetime But this strategy does not cope with highly parallel devices More research is highly required 16
Now, Back to HARD DISK DRIVES 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 attributs tuples pages fichiers Rappel : le SGBD gère un cache de pages en RAM à la façon d une mémoire virtuelle 17 18 Stockage des tuples (attributs de taille fixe) Stockage des tuples (att. de taille variable) Deux alternatives de stockage (le nombre d attributs est fixe): Att1 Att2 Att3 Att4 T1 T2 T3 T4 Att1 Att2 Att3 Att4 $ $ $ $ Adresse de base (B) Adresse = B+T1+T2 Att1 Att2 Att3 Att4 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 Tableau d offsets des attributs 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 «$») 19 20
Pages : tuples de taille fixe Pages: tuples de taille variable Emplacement 1 Emplacement 2 Emplacement 1 Emplacement 2 Rid = (i,n) Page i Emplacement N...... Trou Emplacement N Rid = (i,2) Rid = (i,1) Emplacement M N Page compacte (pas de trou) Nombre de tuples 1... 0 1 1M M... 3 2 1 Bitmap (0=trous) Page éparse Nombre d emplacements 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» 20 16 24 N... 2 1 Pointeurs d emplacements Pointeur N vers l espace libre Nombre d emplacements Déplacement des tuples dans la page sans changer le Rid 21 22 Fichiers non ordonnés Soit la table Doctor suivante id number(4) Le modèle de stockage NSM (N-ary Storage Model ou Raw-based) Le modèle de stockage DSM (Decomposition Storage Model ou Column-based) Optimisation des I/O Le modèle de stockage PAX (Partition Attributes Across) Optimisation du cache first_name char(30) gender char(1) specialty char(20) 1 Maria F Pediatrics 2 Antonio M Dermatology 3 Dominique F Psychology 1 Maria F Pediatrics 2 Antonio M Dermatology 3 Dominique F Psychology Pages disques ID1 1 ID2 2 ID3 3 ID1 Maria ID2 Antonio ID3 Dominique 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 23 Objectifs Indexation 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 Index Table (ou hiérarchie de tables) implémentant cet accélérateur 24
Catégories d index (1) Catégories d index (2) Index primaire ou plaçant (primary or clustered) 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) Tuples organisés indépendamment de l index Seuls les Rid des tuples sont «dans» l index Plusieurs index secondaires possibles par table Clé K K1 K2 Kn Page 1 Page 2 Page i Tuples triés sur K Clé L K1 K2 Kn Page 1 Page 2 Page i Tuples non triés sur L 25 Index dense (dense) Contient toutes les clés 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 Contient alors la plus grande clé de chaque bloc + l'adresse du bloc NB : Densité d un index : tuple tuple tuple Page 1 Page 2 Page i nb d entrées dans l'index nb de tuples dans la table tuple tuple tuple Page 1 Page 2 Page i 26 Mais au fait Catégories d index (3) 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)? 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é Fonctionnement L index est trié (mais trop gros peu performant ) Pourquoi l index à indexer doit-il être trié? 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 ) 27 28
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 clés comprises entre la (i-1)ème et la ième clé du père. (iii) l'arbre est équilibré. 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 PLACANT 2) en rangeant les articles au plus bas niveau de l'arbre B+ ==> INDEX PLACANT 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 Dans la pratique, qu est ce qui détermine m? Et pourquoi est-ce important que l arbre soit équilibré? A faire chez soi : comprendre la mise à jour dans un arbre-b 29 30 Objectif Organisations par Hachage 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 La sélection se fait directement en recalculant cette même fonction 31 Hachage statique Clé 0 1 2 Fonction de hachage i n } Paquets 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 32
Hachage extensible Et la gestion multi-attributs? H (KEY) XXXX X X X Signature Le paquet 01 éclate en deux paquets 001 et 101 - on double la taille du répertoire - on considère un bit de plus dans chaque signature 00 01 10 11 000 001 010 011 100 101 110 111 Répertoire Paquets Paquets 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 en leur allouant plus de bits, en positionnant ces bits en début de chaîne Peut-on traiter par exemple (A2 = y) seul? h1(a1), h2(a2), hn(an) 001101001100100100100100011110010100 001101001100100100100100011110010100 Répertoire 33 h1(a1), h2(a2), hn(an) 34 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 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 Performance optimale (resp. mauvaise) quand les données sont bien (resp. mal) distribuées 35 Utilisation d index multicritères cas part. 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 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 Pattern de requête SELECT P.nom FROM Personne P WHERE P.salaire > Y; Index couvrant Index sur la clé suivante : P.salaire, P.nom 36
Index Bitmap Index de jointure Index Bitmap = index secondaire dense non trié A chaque clé, on associe un bitmap 1 entrée par tuple 1/0 = contient oui/non la valeur Utilisé si Art Berthe Nurse Zouk 1) clé varie sur un domaine de faible cardinalité 2) requêtes multi-critères sans sélectivité dominante Pourquoi? 100100100 001001000 000000001 010010010 Art Zouk Berthe Art Zouk Berthe Art Zouk Nurse Peut être vu comme une façon de compresser les listes inversées (listes de Rid) 37 vers Doctor Join Index Matérialisation d une association (jointure) Exemple IJ Doc,Visit Star Join index Pour les schémas en étoile (star schema) Stocké sous forme de bitmap clés = valeur d attributs d une dimension bits = référencent les tuples de Fact Utilisé pour les requêtes en étoile σ : des sélections sur les dimensions : entre les dimensions et la table de faits id Les prédicats sont tous appliqués par AND/OR de bitmaps Lundi mardi mercredi D1 Jour 1 Lundi 2 mardi 3 mercredi 00001 01100 IJ vers Visit docid visitid 1 5 1 6 2 2 2 3 2 8 3 1 3 4 3 7 XL XXL 10010 FACT D1 D2 id Desc 1 3 2 Art 2 2 1 Zouk 3 2 1 Berthe 4 3 2 Frank 5 1 2 Bif 10011 01100 D2 id Taille 1 XL 2 XXL D3 38 Organisation des données sur disque Logique Physique Base de données Database Récipient logique pour regrouper des objets applicatifs liés et administrés ensemble Tablespace Datafiles Oracle Lieu de stockage d une structure : Table, index, partition de table Granule d allocation = Ensemble de blocs contigus Granule d I/O Idéalement multiple d un Bloc OS Segment Extent Block Bloc OS Support partiellement emprunté à Pascale Borla Salamet Oracle France 39 40
41 42 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 ) Tuples (row data) Entête Espace libre (PCTFREE, PCTUSED) Répertoire de tuples (row directory) Répertoire de table (table directory) 43 44
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 Utilisation de PCTFREE et PCTUSED PCTFREE=20, PCTUSED=40 INSERTION (Max 80% du bloc) Mise à jour 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é) Réglage Par le DBA (paramètre du CREATE TABLE) Par l ASS = Automatic Segment Space Management (>Oracle 8i) -> recommandé 45 SUPPRESSION Si PCTUSED<40, alors des insertions peuvent à nouveau être effectuées 46 Table index-organized = index plaçant les tuples entiers sont stockés dans les feuilles plutôt que leur Rowid 47 48
1 1 1 1 49 50 51 52
53 54 Partitionnement des tables (1) 3 méthodes de partitionnement Partitionnement des tables (2) Possibilité de combiner les modes (partitionnement composite) Exemple CREATE TABLE sales_hash (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 55 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')) 56
Partitionnement des index Index partitionné local Index partitionné global Index global non partitionné sur une table partitionnée Key-Value Store: stockage & indexation L exemple de CASSANDRA (Facebook Apache) Data Store structuré, hautement distribué, 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 DHT (Distributed Hash Table) Eventual consistency Un index bitmap partitionné ne peut qu être local 57 58 Amount of Stored Data By Sector (in Petabytes, 2009) If you like analogies David J. DeWitt dewitt@microsoft.com Rimma Nehme rimman@microsoft.com Microsoft Jim Gray Systems Lab Madison, Wisconsin Petabytes 1000 900 966 848 35ZB = enough data to fill a stack of DVDs 619 reaching halfway to Mars 800 715 700 600 500 434 364 400 300 200 100 0 Earth Sources: "Big Data: The Next Frontier for Innovation, Competition and Productivity." US Bureau of Labor Statistics McKinsley Global Institute Analysis 269 227 Mars 1 zettabyte? = 1 million petabytes = 1 billion terabytes = 1 trillion gigabytes 60
Key/Value Stores Old guard Use a parallel database system Examples: MongoDB, CouchBase, Cassandra, 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 ebay 10PB on 256 nodes Young turks Hadoop Use a NoSQL system Scalable fault tolerant framework for storing and processing MASSIVE data sets Typically no data model Records stored in distributed file system Facebook - 20PB on 2700 nodes Bing 150PB on 40K nodes 61 Structured & 62 Unstructured Retour à nos moutons Stockage et indexation dans Cassandra Relational DB Systems Structured data w/ known schema ACID Transactions SQL Rigid Consistency Model ETL Longer time to insight Maturity, stability, efficiency NoSQL Systems (Un)(Semi)structured data w/o schema No ACID No transactions No SQL Eventual consistency No ETL Faster time to insight Flexibility 63 64
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 Exemple de Column Family Column family 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) La structure des tuples n est pas obligatoirement uniforme 65 66 Exemple de Super-Column Family Illustration 67 68
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 Recherche logarihmique vs. directe Chaque noeud possède une table de routage partielle (ex: avec p entrées) Décdoupage récursif de l espace en 2 recherche logarithmique Cassandra 1 noeud = 1 data center tous les data centers ont une table de routage complète Zone de coordination du noeud N21 69 70 Primary index Index sur chaque noeud 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 random Log Mise à jour des index (1) MemTable 71 72
Mise à jour des index (2) Lecture dans l index (1) SSTable 73 74 Optimisation Minimiser le nombre de SSTable présentes sur disque Fusion d index par Sort-merge I/O séquentielles Bloom Filter : principe Bloom filter Structure probabiliste compacte pour réaliser des tests d appartenance d un élément à un ensemble Pas de faux négatifs Possibilités de faux positifs, mais avec un ratio f très faible f est influencé par m et k. Par exemple, avec m=16n, k=7, f = 0.0007 (n: nb d éléments dans l ensemble) Minimiser le nombre de SSTable à tester lors des recherches Ajout d un Bloom Filter pour chaque SSTable 75 76
Bloom Filter : exemple Bibliographie (1) Site de vulgarisation Disques durs http://www.pcguide.com/ref/hdd/ Example : 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(48) = 7 h2(48)=0 h1(67) = 3 h2(67)=10 h1(88) = 6 h2(88)=4 0 1 2 3 4 5 6 7 8 9 10 11 01 01 0 01 10 0 01 01 0 0 10 0 Test the membership of 23, 46, 60 h1(23) = 10 h2(23)=3 h1(46) = 8 h2(46)=10 h1(60) = 4 h2(60)=7 23 F 46 F 60 is a false positive. Jim gray Evolution du matériel pour le stockage persistent des données Présentation : «the five minutes rule» Lien : http://research.microsoft.com/~gray/talks/fiveminuterule.ppt Présentation de Bernard Ourghanlian (Microsoft France) Lien : http://projets.etudes.ecp.fr/2003-2004/intranetit/nvsite/bibi/folder.2003-06-27.5856/folder.2003-03- 30.0033/Innovation%20-%20Centrale.pdf/download Cours BD INSA Rouen Stockage http://asi.insa-rouen.fr/enseignement/siteuv/bd/cours/supports/bd1/5-stockage Dennis Shasha, Philippe Bonnet Storage Tuning Livre : Database Tuning Lien : http://www.distlab.dk/dbtune/slides/storagetuning.ppt Site industriels Prix du matériel (nouvelles technologies de stockage) Sur : http://www.tpc.org/results/individual_results/ Compléments du lien : Sun/sunfire.x4100.3.0_tpch.sybaseIQ.100gb.es.pdf IBM/IBM_595_64_20041118_ESv2.pdf Sun/sunfire.x4100.3.0_tpch.sybaseIQ.100gb.es.pdf 77 78 Bibliographie (2) Mohammed J. Zaki Modèle de stockage et d indexation des données Présentations (voir en particulier les lectures 7 et 8) Lien : http://www.cs.rpi.edu/~zaki/cs4380/ J. L. Griffin et al. Stockage persistent basé sur la technologie MEMS Article de recherche : Modeling and Performance of MEMS-Based Storage Devices (Sigmetrics 2000) Lien : http://www.pdl.cmu.edu/pdl-ftp/storage/sigmetrics2000.pdf Sites industriels Stockage persistent basé sur la technologie FLASH Flash disk 3,5 : http://www.bitmicro.com/public_docs/products_edide_ datasheet.3.5.pdf Flash disk 2.5 : http://www.bitmicro.com/public_docs/products_edide_ datasheet.2.5.pdf Etude de 2005 : http://www.storagesearch.com/semico-art1.html Latence et débit : http://www.bitmicro.com/products_edisk_35_scsiw.php 79