Readings. Important Decisions on DB Tuning. Index File. ICOM 5016 Introduction to Database Systems

Transcription

1 Readings ICOM 5016 Introduction to Database Systems Read New Book: Chapter 12 Indexing Most slides designed by Dr. Manuel Rodríguez-Martínez Electrical and Computer Engineering Department 2 Important Decisions on DB Tuning Index File Choice of indices to create on which relations and attributes? what kind of index? Conceptual schema tuning Alternative normalized schemas Denormalization Vertical partitioning Horizontal partitioning Views Query tuning Often focuses on selection and join operations Index entry 121 Jil NY $ Bob NY $ Pat WI $ Bill LA $ Al SF $ Ned SJ $ Ned NY $ Tim MIA $4000 Data entries 3 4 1

2 Index files structure Index entries Store search keys Search key a set of attributes in a tuple can be used to guide a search Ex. Student id Search key do not necessarily have to be candidate keys For example: gpa can be a search key on relation: Students(sid, name, login, age, gpa) Data entries Store the data records in the index file Data record can have Actual tuples for the table on which index is defined Record identifier for tuples that match a given search key Issues with Index files Index files for a relation R can occur in three forms: 1. Data entries store the actual data for relation R. Index file provides both indexing and storage. 2. Data entries store pairs <k, rid>: k value for a search key. rid rid of record having search key value k. Actual data record is stored somewhere else, perhaps on a heap file or another index file. 3. Data entries store pairs <k, rid-list> K value for a search key Rid-list list of rid for all records having search key value k Actual data record is stored somewhere else, perhaps on a heap file or another index file. 5 6 Example FROM food WHERE cuisine=`greek`; Q1 Update SET WHERE food cuisine= Greek` name=`shish-kobab`; Q2 If no index is defined, For executing Q1 (or Q2): DBMS must search all blocks of the file, representing the food relation, to find the matching tuples Index on cuisine For executing Q1: DBMS needs to search substantially less blocks For executing Q2: DBMS needs to search all blocks, and may also need to update the cuisine index file. Creating an Index CREATE INDEX indcuisine ON food (cuisine); Defining the above index: Increases the amount of space needed to store the food relation Substantially speeds up the queries in which a specific cuisine is involved in the WHERE clause May substantially speeds up the queries in which a range of cuisines is involved in the WHERE clause Slows down insert operations May slow down delete and update operations 7 8 2

3 Structure of Index FROM provides WHERE price<=7 and price>=5; Defining a hash index on price may not help the above query; but a B + Tree index on price can improve the performance: use the B + tree index to find a tuple matching price=5, and then visit the leaf nodes until you reach price=7 Note that this index structure needs more space Multi-Attribute Indices CREATE INDEX indfs ON branch (name, b#); Defines an index on attribute name of relation branch Then, defines an index on attribute b# for those tuples that have the same value for attribute name The order of indexing attributes is important The above index speeds up queries in which the WHERE clause refers to a specific foodservice name (and b#) The above index substantially speeds up queries in which the WHERE clause refers to a specific foodservice name (and b#) and the SELECT clause contains only foodservice name and/or foodservice branch# 9 10 Example: Multi-Attribute Search Keys Clustered and Unclustered Indices indfs would be useful for the following two queries. WHERE name=`sodexo`; WHERE name=`sodexo` AND b#=3; indfs would be very useful for the following two queries. SELECT b#, name WHERE name=`sodexo`; SELECT b# WHERE name=`sodexo`; indfs would not be useful for the following two queries. WHERE b#=3; UPDATE branch SET name=`b3`+name WHERE b#=3; could be harmful here 11 Definition: When the physical order of tuples, w.r.t. a set of attributes, is the same as (or close to) the ordering of data entries in an index file, the index in called a Clustered Index. Other indices are called unclustered indices. A relation can have at most one clustered index and as many as required unclustered indices at a time. 12 3

4 Example: Clustered Index Example: Unclustered Index Index entries based on foodservice name Index entries based on foodservice name Tuples sorted based on foodservice name, in the physical storage. Tuples sorted based on branch number, in the physical storage Some terminology Primary index Index defined on the primary key of a relation Secondary index Index defined on one or more attributes that are not a key Other nomenclature Primary access method access data as stored Primary index Index based on Index organization option (1) of slide 5 Secondary access method alternative access to data independent from native storage organization Secondary index Other methods such as sorting or hashing data into a temporary file 15 Hash-Based Indexing Hash the records on some attribute(s) Accumulate records with same hash into value into same bucket Bucket has a primary page and additional pages are linked in a list Hash function maps each record to a bucket Ex. int Hash(char *str, int len) { int res = 0; for (int j =0; j < len; ++j){ res+=str[i]; } return res % NUMBER_BUCKETS; } 16 4

5 Hash Index (clustered) Hash Index (Unclustered) Account attribute H() 121 Jil NY $ Bob NY $ Pat WI $ Bill LA $ Ned SJ $ Al SF $ Ned NY $ Tim MIA $ Jil NY $ Bob NY $ Pat WI $ Bill LA $ Ned SJ $ Al SF $ Ned NY $ Tim MIA $4000 LA NY NY NY MIA SJ SF WI H() city Tree-Structured Index 122, Jil, NY, $ , Pat, WI, $30 123, Bob, NY,$ Data Entries , Bill, LA, $ , Ned, SJ, $ , Al, SF, $52303 Index on account id , Ned,NY,$ , Tim, MI, $ Some issues Data entries are maintained at the leaf level Each index entries are stored in disk pages We want to keep root page of index in the buffer pool while we are scanning the index In practice, finding data with an index will costs N I/Os to read the index entries in the path of the tree. K I/Os to read all the index entries Total N + K I/O operations Most DBMS system manage to keep path between 2 and 3! B+ tree Fan-out - number of children in index nodes Bigger means smaller tree height (smaller path to leaves!) 20 5

6 Guidelines for Index Selection 1. Whether to Index? 2. Choice of Search Key? An exact-match selection condition suggests an index on the attribute; ideally, a hash index A range selection condition suggests a B+tree index (or an ISAM index) 3. When Multi-Attributes Search Keys? A WHERE clause includes conditions on 1+ attributes, or They enable index-only evaluation strategies 4. Whether to Cluster? (Co)clustering affects performance greatly: use it wisely if you have range queries. Use co-clustering when there are several 1:N joins 5. Hash vs. Tree Index? Hash Index, if intend to support nested loops joins, or if there is very important equality query (and no range queries) 6. Cost of Index Maintenance? After drawing the wishlist of indexes, drop those that slow down frequent update operations 21 6