database

DBMS – Arif Djunaidy – FTIF ITS Bab 7 - 1/32

Database Management Database Management SystemsSystems

Bab 7Bab 7Overview Overview

Storage & IndexingStorage & Indexing(Chap. 8 – Ramakrishnan)(Chap. 8 – Ramakrishnan)


Pokok Bahasan Bagaimana DBMS menyimpan dan mengakses “persistent

data” ? Mengapa biaya I/O begitu penting dalam pengoperasian

database ? Bagaimana DBMS mengorganisasi files dari data records pada

disk guna meminimumkan biaya I/O ? Apa yang dimaksud dengan index, dan mengapa diperlukan ? Apa hubungan antara sebuah file dari data records dan

berbagai indexes pada file dari records tersebut ? Apa saja pentingnya properti dari indexes ? Bgm “hash-based index” dan “tree-based index” bekerja, dan

kapan keduanya menjadi sangat efektif ? Bagaimana indexes seharusnya digunakan guna

mengoptimalkan kinerja untuk suatu beban kerja yang ditentukan ?


Data pada Storage Eksternal Disks: Dapat melakukan retrieve “random page” dengan biaya yang tetap (fixed cost) Tetapi pembacaan beberapa pages yang berurutan jauh lebih

murah dibandingkan membacanya dalam urutan yang acak (random)

Tapes: Hanya dapat membaca “pages” secara sekuensial Lebih murah dibandingkan disks, tetapi hanya untuk kerperluan

“archival storage” Organisasi File: Metode pengaturan sebuah file yang

berisikan data records pada storage eksternal Record id (rid) cukup untuk menentukan lokasi record secara fisik Indexes adalah struktur data yang memungkinkan kita untuk

memperoleh “record ids” dari records dengan menggunakan nilai-nilai yang diberikan dalam index search key fields

Arsitektur: Buffer manager mengatur penempatan pages dari storage eksternal ke dalam “main memory buffer pool”. File dan lapisan-lapisan index melakukan pemanggilan (calls) ke

buffer manager.


Pilihan Organisasi FileTerdapat banyak pilihan untuk mengorganisakan file, masing-masing ideal untuk situasi-situasi tertentu, dan mungkin tidak baik untuk situasi-situasi lainya. Tiga pilihan/alternatif utama:

Heap (random order) files: Sangat cocok bilamana akses tipikalnya berupa “file scan” yang meliputi retrieval semua records yang ada.

Sorted Files: Terbaik jika records harus di-retrieve dalam urutan tertentu, atau hanya suatu “jangkauan” (range) records tertentu yang diperlukan untuk di-retrieve.

Indexes: Struktur data untuk mengorganisasi records dengan menggunakan trees atau hashing.

• Seperti halnya sorted files, indexes mempercepat pelacakan terhadap subset dari records, berdasarkan nilai-nilai (“search key”) fields tertentu.

• Proses updates dari records jauh lebih cepat dibandingkan dalam sorted files.


Indexes Sebuah index pada sebuah file akan

mempercepat proses pemilihan pada search key fields dari index tersebut. Sembarang subset dari fields suatu relasi (tabel)

dapat digunakan sebagai search key dari index pada relasi tersebut.

Search key TIDAK SAMA DENGAN key (satu set minimal dari fields yang dapat secara unik mengidentifikasi sebuah record dalam suatu relasi).

Sebuah index berisikan sekumpulan data entries, dan memberikan dukungan untuk proses retrieval yang efisien terhadap semua data entries k* untuk sebuah nilai key k yang diberikan.


Indexes (Lanjutan)

Data entries

Data Records

Index entries(direct search utk data entries)

Index File

Data File

Index pada satu set fields yang meliputi primary key disebut primary index; sedang indexes lainnya disebut secondary indexes.

Dua buah data entries dikatakan terduplikasi jika keduanya mempunyai nilai yang sama utk search key field yang diasosiasikan dengan suatu Primary key index dijamin tidak mengandung duplikasi data entries Secara umum, secondary index dapat mengandung duplikasi data entries Index pada satu set fields yang meliputi candidate key, yang juga dijamin

tidak mengandung duplikasi data entries, disebut unique index


Alternatif-alternatif untuk Data Entry k* dalam Index

Tiga alternatif: Data record dengan nilai key k <k, rid dari data record dengan nilai search key k> <k, list rids dari data records dengan nilai search key

k>Pemilihan alternatif utk data entries bergantung

pada teknik “indexing” yang digunakan untuk memperoleh data entries berdasarkan nilai key k. Conroh teknik indexing: B+ trees, hash-based

structures Secara tipikal, index berisikan informasi tambahan

(auxiliary information) yang mengarahkan pelacakan pada data entries yang diinginkan


Alternatif utk Data Entries (Lanjutan) Alternatif 1:

Dalam alternatif ini, struktur index adalah sebuah organisasi file dari data records (bukan berupa Heap file atau sorted file).

Paling banyak hanya satu index untuk sekumpulan data records yang diberikan yang dapat menggunakan alternatif 1.

• Jika tidak, data records akan terduplikasi, dan akan menimbulkan terjadinya redundansi storage dan inkonsistensi data.

Jika data records berukuran sangat besar, maka jumlah “pages” yang berisikan data entries akan menjadi besar. Secara tipikal hal ini juga akan menyebabkan ukuran dari informasi tambahan dalam index menjadi besar.


Alternatif utk Data Entries (Lanjutan) Alternatif 2 dan 3:

Secara tipikal, data entries jauh lebih kecil dibandingkan dengan data records. Sehingga, alternatif ini akan menjadi lebih baik untuk data records yang besar, khusunya jika search keys berukuran kecil.

• Bagian struktur index yang digunakan untuk mengarahkan pelacakan (yang bergantung pada ukuran data entries) akan menjadi jauh lebih kecil dibandingkan dengan alternatif 1.

Alternatif 3 lebih kompak (utilisasi ruang penyimpanan yang lebih baik) dari pada alternatif 2, tetapi dapat menimbulkan data entries dengan ukuran yang variabel, bergantung pada jumlah data records untuk sebuah nilai search key yang diberikan.

DBMS – Arif Djunaidy – FTIF ITSBab 7 - 10

/32

Klassifikasi Index Primary v.s. secondary: Jika search key berupa

primary key, maka disebut primary index, selebihnya disebut secondary indexes. Unique index: Search key berupa sebuah candidate key.

Clustered v.s. unclustered: Jika urutan data records sama dengan, atau `mendekati’, urutan data entries, maka disebut clustered index. Alternatif 1 mengimplikasikan clustered index. Dalam

praktek, clustered index juga mengimplikasikan Alternatif 1 (karena struktur sorted files jarang digunakan).

Sebuah file dapat mempunyai clustered index paling banyak pada satu search key.

Biaya untuk melakukan retrieving data records melalui index sangat bervariasi, bergantung pada apakah index-nya adalah clustered atau tidak !


/32

Clustered v.s. Unclustered Index

Diasumsikan menggunakan data entries alternatif 2, dan data records diasumsikan disimpan dalam Heap file. Utk membangun clustered index, pertama Heap file harus di-

sorting (dengan menyediakan beberapa ruang kosong pada setiap page untuk keperluan penyisipan yang akan datang).

Overflow pages mungkin diperlukan untuk penyisipan. Sehingga, urutan data records menjadi `mendekati ke’, bukan sama dengan, urutan terurut (sorted order).

Index entries

(direct search for data entries)

Data entries

(Index File)

(Data file)

Data Records

Data entries

Data Records

CLUSTERED UNCLUSTERED


/32

Hash-Based Indexes

Bagus untuk “equality selections”.• Index berupa sekumpulan buckets. Bucket =

primary page plus nol atau lebih overflow pages.

• Hashing function h: h(r) = bucket dimana record r berada. Untuk ini, h akan mencari search key fields dari r.

Jika Alternatif (1) digunakan, maka buckets berisikan data records; jika tidak, buckets berisikan pasangan-pasangan <key, rid> atau pasangan-pasangan <key, rid-list>.


/32

Contoh Hash-Based Indexes

Employees file hashed on age

Hash function h untuk contoh ini sangat sederhana, yaitu search key dikonversikan ke bilangan biner dan diambil dua bit terakhir

Smith, 44, 3000Jones, 40, 6003Tracy, 44, 5004

Ashby, 25, 3000Basu, 33, 4003Bristow, 29, 2007

Cass, 50, 5004Daniels, 22, 6003

3000300050045004

4003200760036003

h1age

h(age) = 00

h(age) = 01

h(age) = 10

h1sal

h(sal) = 00

h(sal) = 11

File of <sal, rid> pairs hashed on sal


/32

B+ Tree Indexes

Leaf pages terdiri dari data entries, dan dihubungkan oleh (prev & next) pointers

Non-leaf pages terdiri dari index entries dan pelacakan langsung:

P0 K 1 P 1 K 2 P 2 K m P m

index entry

Non-leaf

Pages

Pages

Leaf


/32

Contoh B+ Tree

Cari data 28*? 29*? All > 15* and < 30* Insert/delete: Cari data entry dalam leaf, kemudian

lakukan perubahan. Kadang-kadang, diperlukan untuk mengatur simpul induk (parent) dari tree. Perubahan dapat menyebabkan “bubbles up the tree”

2* 3*

Root

17

30

14* 16* 33* 34* 38* 39*

135

7*5* 8* 22* 24*

27

27* 29*

Entries <= 17 Entries > 17


/32

Cost ModelMengabaikan CPU costs (untuk penyederhanaan):

B: Jumlah data pages R: jumlah records per page D: Rerata waktu utk membaca atau menulis disk page Pengukuran jumlah page I/O’s mengabaikan

peningkatan akibat pre-fetching dari satu urutan pages; sehingga, I/O cost hanya merupakan aproksimasi.

Analisis didasarkan pada “average-case analysis” berdasarkan beberapa “simplistic assumptions”.

Cost model di atas cukup baik untuk menunjukkan trend secara menyeluruh


/32

Perbandingan Organisasi File Heap files (tersusun secara random;

penyisipan pada End Of File) Sorted files, diurut berdasarkan <age,

sal> Clustered B+ tree file, Alternatif (1),

search key <age, sal> Heap file dengan unclustered B + tree

index on search key <age, sal> Heap file dengan unclustered hash index

on search key <age, sal>


/32

Operasi-operasi yang Dibandingkan

Scan Mengambil (Fetch) semua records dari disk

Equality search Fetch semua records yang memenuhi “equality selection” dari disk. Misal” ‘Cari

employee records utk employees dengan age = 25 dan sal = 100” Range selection

Fetch semua records yang memenuhi “range selection” dari disk. Misal” ‘Cari semua employee records dengan nilai age > 40”

Insert a record Menyisipkan sebuah record ke dalam file. Hrs mengidentifikasi page dlm file dimana record baru akan disisipkan. Fetch

page tsb dari disk, lakukan perubahan utk memasukkan record baru, dan tulis kembali page yang telah diubah ke disk. Bergantung pada organisasi dari file, operasi fetch, ubah, dan tulis kembali dari pages lainnya mungkin harus juga dilakukan

Delete a record Menghapus sebuah record dengan mengunakan “rid” dari record tsb. Hrs mengidentifikasi page yang berisikan record yang akan dihapus. Fetch record

tsb dari disk, lakukan perubahan, dan tulis kembali ke disk. Bergantung pada organisasi dari file, operasi fetch, ubah, dan tulis kembali dari pages lainnya mungkin harus juga dilakukan.


/32

Asumsi yang digunakan dlm Analisis Heap Files:

Equality selection pada key; tepat utk sekali match.

Sorted Files: Files dibandingkan setelah penghapusan.

Indexes: Alternatif (2), (3): ukuran data entry = 10%

ukuran record Hash: Tidak ada overflow buckets.

• 80% page occupancy => Ukuran file = 1.25 ukuran data Tree: 67% occupancy (asumsi yang tipikal).

• Mengimplikasikan ukuran file = 1.5 ukuran data


/32

Perbandingan I/O Costs

(a) Scan (b) Equality (c ) Range (d) Insert (e) Delete

(1) Heap BD 0.5BD BD 2D Search +D

(2) Sorted BD Dlog 2 B Dlog 2 B + # matches

Search + BD

Search +BD

(3) Clustered 1.5BD Dlog F 1.5B Dlog F 1.5B + # matches

Search + D

Search +D

(4) Unclustered Tree index

BD(R+0.15) D(1 + log F 0.15B)

Dlog F 0.15B + # matches

D(3 + log F 0.15B)

Search + 2D

(5) Unclustered Hash index

BD(R+ 0.125)

2D BD 4D Search + 2D

Beberapa asumsi diberlakukan guna memperoleh esitimasi (kasar) dari I/O Costs di atas


/32

Memahami Beban Kerja (Workload) Utk setiap query dalam workload:

Relasi-relasi apa saja yang diakses ? Attribute-attribut apa saja yang di-retrieve ? Attribute-attribut apa saja yang dilibatkan dalam

kondisi-kondisi seleksi/join ? Seberapa selektif pengaruh dari kondisi-kondisi tersebut ?

Utk setiap update dalam workload: Jenis update (INSERT/DELETE/UPDATE) apa yang

dilakukan, dan attribut-attribut apa saja yang dipengaruhinya


/32

Pilihan-pilihan Index Indexes apa saja yang seharusnya dibuat ?

Relasi-relasi yang mana yang seharusnya memiliki indexes ?

Field(s) yang mana yang seharusnya dijadikan search key?

Haruskah beberapa indexes harus dibangun ? Utk setiap index, jenis index apa yang

seharusnya diberlakukan ? Clustered ? Hash/tree ?


/32

Salah satu pendekatan: Perhatikan queries yang paling penting satu per satu. Perhatikan rencana terbaik penggunaan indexes terkini, dan pikirkan jika suatu rencana yang lebih baik dengan penambahan sebuah index dimungkinkan. Jika ya, buat index tambahan tsb. Sudah tentu, hal ini mengimplikasikan bahwa kita harus mengerti

bagaimana DBMS mengevaluasi queries dan menciptakan rencana evaluasi query !

Utk kuliah ini, pembahasan dibatasi hanya utk queries pada 1-tabel sederhana saja.

Sebelum pembuatan sebuah index, hrs juga diperhati-kan pengaruh pada updates dalam workload! Trade-off: Indexes dapat menjadikan queries berjalan lebih cepat,

tetapi updates dapat menjadi lebih lambat. Selain itu juga memerlukan tambahan ruang penyimpanan (disk storage).

Pilihan-pilihan Index (lanjutan)


/32

Petunjuk Pemilihan Index Attributes dlm WHERE clause adalah kandidat utk index

keys. Kondisi “exact match” hash index. “Range query” tree index.

• Clustering khusunya bermanfaat utk “range queries”; dapat juga bermanfaat utk “equality queries” jika terdapat banyak duplikasi.

“Multi-attribute search keys” perlu dipertimbangkan bilamana WHERE clause berisikan beberapa kondisi. Urutan attributes menjadi penting untuk range queries. Strategi pembuatan index-only dapat digunakan untuk indexing

terhadap queries yang penting.• Utk strategi “index-only”, clustering menjadi tidak penting !

Upayakan untuk memilih indexes yang dapat memberikan manfaat sebanyak mungkin queries. Oleh karena hanya sebuah index yang dapat di-clustered per

relasi, maka pemilihan index sebaiknya didasarkan pada queries yang penting yang akan memperoleh manfaat sebesar-sebesarnya dari clustering.


/32

Contoh Pentingnya Clustered Indexes

B+ tree index pada E.age dpt digunakan utk memperoleh tuples yang memenuhi kondisi. Seberapa selektif kondisi yang ada ? Apakah index perlu di-clustered?

Perhatikan GROUP BY query. Jika banyak tuples memp E.age > 10,

penggunaan E.age index yang diikutidengan sorting tuples yang di-retrieve dapat memiliki biaya yang tinggi.

Clustered E.dno index mungkin lebih baik!

Equality queries dan duplikasi: Clustering pada E.hobby merupakan

pilihan yang baik !

SELECT E.dnoFROM Emp EWHERE E.age > 40

SELECT E.dno, COUNT (*)FROM Emp EWHERE E.age > 10GROUP BY E.dno

SELECT E.dnoFROM Emp EWHERE E.hobby=Stamps


/32

Indexes dengan Composite Search Keys

Composite Search Keys: Pelacakan pada suatu kombinasi beberapa fields. Equality query: Setiap nilai field

sama dg sebuah nilai konstan. Contoh, <sal,age> index:

• age=20 and sal =75 Range query: Beberapa nilai

field tidak berupa konstanta. Contoh:

• age =20; atau age=20 and sal > 10

Data entries dalam index diurut berdasarkan search key guna mendukung range queries. Lexicographic order, atau Spatial order.

sue 13 75

bob

cal

joe 12

10

20

80 11

12

name age sal

<sal, age>

<age, sal> <age>

<sal>

12,20

12,10

11,80

13,75

20,12

10,12

75,13

80,11

11

12

12

13

10

20

75

80

Data recordssorted by name

Data entries in indexsorted by <sal,age>

Data entriessorted by <sal>

Contoh composite key indexes berdasarkan urutan

lexicographic


/32

Composite Search Keys Utk me-retrieve Emp records dg age=30 AND

sal=4000, index pada <age,sal> akan lebih baik dari pada index pada age atau index pada sal saja. Pemilihan index key dipengaruhi oleh clustering, dll.

Jika kondisi: 20<age<30 AND 3000<sal<5000: Clustered tree index pada <age,sal> atau <sal,age>

merupakan pilihan terbaik. Jika kondisi: age=30 AND 3000<sal<5000:

Clustered <age,sal> index jauh lebih baik dari pada <sal,age> index !

Composite indexes lebih besar dibandingkan single index, dan biasanya lebih sering diupdate.


/32

Rencana Index-Only

Sejumlah queries dapat dijawab tanpa hrs melaku-kan proses retriev-ing tuples pada satu atau lebih relasi yang dili-batkan, jika terse-dia index yang sesuai.

SELECT D.mgrFROM Dept D, Emp EWHERE D.dno=E.dno

SELECT D.mgr, E.eidFROM Dept D, Emp EWHERE D.dno=E.dno

SELECT E.dno, COUNT(*)FROM Emp EGROUP BY E.dno

SELECT E.dno, MIN(E.sal)FROM Emp EGROUP BY E.dno

SELECT AVG(E.sal)FROM Emp EWHERE E.age=25 AND E.sal BETWEEN 3000 AND 5000

<E.dno>

<E.dno,E.eid>Tree index!

<E.dno>

<E.dno,E.sal>Tree index!

<E. age,E.sal> or<E.sal, E.age>

Tree index!


/32

Rencana Index-Only (Lanjutan)

Dalam contoh berikut, rencana Index-only dimungkinkan jika search key berupa <dno,age> atau kita mempunyai tree index dengan search key <age,dno> Mana yang lebih baik? Bagaimana untuk

query yang kedua ?

SELECT E.dno, COUNT (*)FROM Emp EWHERE E.age=30GROUP BY E.dno

SELECT E.dno, COUNT (*)FROM Emp EWHERE E.age>30GROUP BY E.dno


/32

Rangkuman Terdapat banyak altrenatif untuk

mengorganisasikan file, masing-masing sesuai untuk situasi-situasi tertentu

Index adalah sekumpulan data entries plus suatu cara untuk secara cepat mencari entries untuk nilai-nilai search key yang diberikan.

Jika selection queries sering terjadi, maka pembuatan sorted file atau index menjadi penting. Hash-based indexes hanya baik untuk equality search. Sorted files dan tree-based indexes merupakan pilihan

terbaik untuk range search; dan juga bagus untuk equality search. (Dalam praktek, files jarang disimpan dalam keadaan ter-sorted; pilihan struktur B+ tree index lebih baik.)


/32

Data entries dapat berupa data records yang sebenarnya, pasangan-pasangan <key, rid>, atau pasangan-pasangan <key, rid-list>. Kriteria pemilihannya bergantung pada teknik

indexing yang digunakan untuk memperoleh data entries dengan suatu nilai search key yang diberikan.

Berbagai indexes dapat diberlakukan pada suatu file atau data records, masing-masing dengan search key yang berbeda.

Indexes dpt diklassifikasikan menjadi clustered v.s. unclustered, primary v.s. secondary, dan unique index. Perbedaan yang timbul mempunyai konsekuensi penting terhadap kinerja dari transaksi.

Rangkuman (Lanjutan)


/32

Pemahaman terhadap workload dari aplikasi, dan kinerja yang diinginkan, merupakan faktor yang essensial untuk memperoleh desain database yang baik. Perlu identifikasi queries dan updates yang penting. Perlu identifikasi attributes/relations yang harus dilibatkan

Indexes harus dipilih untuk mempercepat queries yang penting (dan mungkin juga beberapa operasi updates !) Pikirkan overhead pemeliharaan index pada operasi updates

terhadap key fields. Pilih indexes yang dapat meningkatkan kinerja banyak

queries, jika memungkinkan. Buat indexes utk mendukung strategi “index-only plans”. Clustering merupakan keputusan penting; hanya satu index

pada satu relasi yang dapat di-clustered ! Pengurutan fields dalam composite index key dapat menjadi

penting untuk dipertimbangkan.

Rangkuman (Lanjutan)

database

Documents

composite

data records

index file

index entries

data entries

data file

leaf pages

jika tidak