1. 1 IT420: Database Management and Organization Storage and Indexing 14 April 2006 Adina Crăiniceanu www.cs.usna.edu/~adina

2. Ramakrishnan, Gehrke: Database Management Systems2 From Last Time: Transaction Log

3. Ramakrishnan, Gehrke: Database Management Systems3 Goals  Storage  Indexing

4. Ramakrishnan, Gehrke: Database Management Systems4 Disks and Files  Basic data abstraction - File - collection of records  Record id (rid) is sufficient to physically locate record/row in a file  DBMS store data on (“hard”) disks  Why not main memory?  Why not tapes?  Data is stored and retrieved in units called disk blocks or pages.  Unlike RAM, time to retrieve a disk page varies depending upon location on disk.  Therefore, relative placement of pages on disk has major impact on DBMS performance!

5. Ramakrishnan, Gehrke: Database Management Systems5 Components of a Disk The platters spin (say, 90rps). The arm assembly is moved in or out to position a head on a desired track. Tracks under heads make a cylinder (imaginary!). Only one head reads/writes at any one time. Block size is a multiple of sector size (which is fixed).

6. Ramakrishnan, Gehrke: Database Management Systems6 Accessing a Disk Page  Time to access (read/write) a disk block:  seek time (moving arms to position disk head on track)  rotational delay (waiting for block to rotate under head)  transfer time (actually moving data to/from disk surface)  Seek time and rotational delay dominate.  Seek time varies from about 1 to 20msec  Rotational delay varies from 0 to 10msec  Transfer rate is about 1msec per 4KB page  Key to lower I/O cost: reduce seek/rotation delays!

7. Ramakrishnan, Gehrke: Database Management Systems7 Arranging Pages on Disk  `Next’ block concept:  blocks on same track, followed by  blocks on same cylinder, followed by  blocks on adjacent cylinder  Blocks in a file should be arranged sequentially on disk (by `next’), to minimize seek and rotational delay.

8. Ramakrishnan, Gehrke: Database Management Systems8 Class Exercise  Consider a disk with:  average seek time of 15 milliseconds  average rotational delay of 6 milliseconds  transfer time of 0.5 milliseconds/page  Page size = 1024 bytes  File: 200,000 records of 100 bytes each, no record spans 2 pages  Find:  Number of pages needed to store the file  Time to read all records sequentially  Time to read all records in some random order

9. Ramakrishnan, Gehrke: Database Management Systems9 Class Exercise Solution  1 page- at most 10 records [1024/100].  200,000 records  20,000 (200,000/10) disk pages needed  20,000 * transfer time for one page = 20,000 * 0.5 = 10,000 milliseconds  for each record - bring an entire page in memory  If reading each page incurs average seek time and average rotational delay, the time to read one page at random is  tb = average seek time + average rotational delay + transfer time  tb = 15 + 6 + 0.5 = 21.5 milliseconds.  To read 200,000 records we need 200,000 * tb = 200,000 * 21.5 =  4,300,000 milliseconds = 4300s

10. Ramakrishnan, Gehrke: Database Management Systems10 Alternative File Organization  File organization: Method of arranging a file of records on external storage.  Record id (rid) is sufficient to physically locate record/row in a file  Many alternatives exist, each ideal for some situations, and not so good in others:  Heap (random order) files: Suitable when typical access is a file scan retrieving all records.  Sorted Files: Best if records must be retrieved in some order, or only a `range’ of records is needed.  Indexes: Data structures to organize records via trees or hashing.  Like sorted files, they speed up searches for a subset of records, based on values in certain (“search key”) fields  Updates are much faster than in sorted files.

11. Ramakrishnan, Gehrke: Database Management Systems11 Motivation for Indexes  Large files  Need to search efficiently for some data

12. Ramakrishnan, Gehrke: Database Management Systems12 Indexes  An index on a file speeds up selections on the search key columns  Any subset of the columns of a table can be the search key for an index on the table  Search key is not the same as key (minimal set of columns that uniquely identify a row in a table).  An index contains a collection of data entries, and supports efficient retrieval of all data entries k* with a given search key value k.

13. Ramakrishnan, Gehrke: Database Management Systems13 Alternatives for Data Entries k*  Three alternatives:  Data record with key value k   Choice of alternative for data entries is orthogonal to the indexing technique used to locate data entries with a given key value k.  Examples of indexing techniques: B+ trees, hash based structures  Typically, index contains auxiliary information that directs searches to the desired data entries

14. Ramakrishnan, Gehrke: Database Management Systems14 Index Classification  Primary vs. secondary: If search key contains  primary key, then called primary index.  Unique index: Search key contains a candidate key.  Clustered vs. unclustered: If order of data records is the same as, or `close to’, order of data entries, then called clustered index.  Alternative 1 implies clustered; in practice, clustered also implies Alternative 1 (since sorted files are rare).  A file can be clustered on at most one search key.  Cost of retrieving data records through index varies greatly based on whether index is clustered or not!

15. Ramakrishnan, Gehrke: Database Management Systems15 Clustered vs. Unclustered

16. Ramakrishnan, Gehrke: Database Management Systems16 Hash Based Indexes  Good for equality selections.  Index is a collection of buckets. Bucket = primary page plus zero or more overflow pages.  Hashing function h:  h(r) = bucket in which record r belongs.  h looks at the search key fields of r.  If Alternative (1) is used, the buckets contain the data records; otherwise, they contain or pairs.

17. Ramakrishnan, Gehrke: Database Management Systems17 Hash Index

18. Ramakrishnan, Gehrke: Database Management Systems18 B+ Tree Indexes Leaf pages contain data entries, and are chained (prev & next) Non-leaf pages contain index entries and direct searches:

19. Ramakrishnan, Gehrke: Database Management Systems19 Example B+ Tree  Find 28*? 29*? All > 15* and < 30*  Insert/delete: Find data entry in leaf, then change it. Need to adjust parent sometimes.  Change sometimes bubbles up the tree

20. Ramakrishnan, Gehrke: Database Management Systems20 SQL to Create Index  CREATE [UNIQUE] INDEX index_name [USING index_type] ON tbl_name (col_name,...) Example: CREATE INDEX I_ItemPrice USING BTREE ON Items (Price) SELECT * FROM Items WHERE Price between 5 and 10 SELECT * FROM Items WHERE ItemID = 100111

21. Ramakrishnan, Gehrke: Database Management Systems21 Understanding the Workload  For each query in the workload:  Which tables does it access?  Which columns are retrieved?  Which columns are involved in selection/join conditions? How selective are these conditions likely to be?  For each update in the workload:  Which columns are involved in selection/join conditions? How selective are these conditions likely to be?  The type of update (INSERT/DELETE/UPDATE), and the columns that are affected.

22. Ramakrishnan, Gehrke: Database Management Systems22 Choice of Indexes  What indexes should we create?  Which tables should have indexes? What column(s) should be the search key? Should we build several indexes?  For each index, what kind of an index should it be?  Clustered? Hash/tree?

23. Ramakrishnan, Gehrke: Database Management Systems23 Choice of Indexes (Cont.)  One approach: Consider the most important queries in turn. Consider the best plan using the current indexes, and see if a better plan is possible with an additional index. If so, create it.  Obviously, this implies that we must understand how a DBMS evaluates queries and creates query evaluation plans!  For now, we discuss simple 1-table queries.  Before creating an index, must also consider the impact on updates in the workload!  Trade-off: Indexes can make queries go faster, updates slower. Require disk space, too.

24. Ramakrishnan, Gehrke: Database Management Systems24 Index Selection Guidelines  Columns in WHERE clause are candidates for index keys.  Exact match condition suggests hash index.  Range query suggests tree index.  Clustering is especially useful for range queries; can also help on equality queries if there are many duplicates.  Try to choose indexes that benefit as many queries as possible.  Since only one index can be clustered per relation, choose it based on important queries that would benefit the most from clustering.

25. Ramakrishnan, Gehrke: Database Management Systems25 Examples  B+ tree index on E.age can be used to get qualifying tuples.  How selective is the condition?  Is the index clustered?  Consider the GROUP BY query.  If many tuples have E.age > 10, using E.age index and sorting the retrieved tuples may be costly.  Clustered E.dno index may be better!  Equality queries and duplicates:  Clustering on E.hobby helps!

26. Ramakrishnan, Gehrke: Database Management Systems26 Indexes with Composite Search Keys  Composite Search Keys: Search on a combination of fields.  Equality query: Every field value is equal to a constant value. E.g.:  age=20 and sal =75  Range query: Some field value is not a constant. E.g.:  age =20; or age=20 and sal > 10  Data entries in index sorted by search key to support range queries.

27. Ramakrishnan, Gehrke: Database Management Systems27 Composite Search Keys  To retrieve Emp records with age=30 AND sal=4000, an index on would be better than an index on age or an index on sal.  If condition is: 20<age<30 AND 3000<sal<5000:  Clustered tree index on or is best.  If condition is: age=30 AND 3000<sal<5000:  Clustered index much better than index!  Composite indexes are larger, updated more often.

28. Ramakrishnan, Gehrke: Database Management Systems28 Index Selection Guidelines (Cont.)  Multi-attribute search keys should be considered when a WHERE clause contains several conditions.  Order of attributes is important for range queries.  Such indexes can sometimes enable index- only strategies for important queries.  For index-only strategies, clustering is not important!

29. Ramakrishnan, Gehrke: Database Management Systems29 Class Exercise What index would you construct? 1. SELECT * FROM Mids WHERE Company=02 2. SELECT CourseID, Count(*) FROM StudentsEnroll WHERE Company = 02 GROUP BY CourseID

30. Ramakrishnan, Gehrke: Database Management Systems30 Summary  Many alternative file organizations exist, each appropriate in some situation.  If selection queries are frequent, sorting the file or building an index is important.  Hash-based indexes only good for equality search.  Sorted files and tree-based indexes best for range search; also good for equality search. (Files rarely kept sorted in practice; B+ tree index is better.)  Index is a collection of data entries plus a way to quickly find entries with given key values.

31. Ramakrishnan, Gehrke: Database Management Systems31 Summary (Cont.)  Data entries can be actual data records, pairs, or pairs.  Choice orthogonal to indexing technique used to locate data entries with a given key value.  Can have several indexes on a given file of data records, each with a different search key.  Indexes can be classified as clustered vs. unclustered, primary vs. secondary. Differences have important consequences for utility/performance.

32. Ramakrishnan, Gehrke: Database Management Systems32 Database Tuning with Indexes  Understanding the nature of the workload for the application, and the performance goals, is essential to developing a good design.  What are the important queries and updates? What attributes/tables are involved?  Indexes must be chosen to speed up important queries (and perhaps some updates!).  Index maintenance overhead on updates to key columns.  Choose indexes that can help many queries, if possible.  Build indexes to support index-only strategies.  Clustering is an important decision; only one index on a given relation can be clustered!  Order of columns in composite index key - important