Π notsp,tgl_lhr(peserta)
HASIL DAN PEMBAHASAN
4.2.4. Analisis Optimisasi query optimizer DBMS MySQL
DBMS MySQL Oprimizer dapat memberikan perkiraan unjuk kerja pecarian dari disk. Untuk tabel-tabel yang kecil dapat mencari baris dalam satu disk secara berurutan. Jika tabel-tabel cukup besar, dapat diperkirakan dengan menggunakan B++ tree index, akan diperlukan langkah pencarian sebanyak i : log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1 seeks to find a row ... (4.3) dan memerlukan buffer sebanyak :
row_count * (index_length + data_pointer_length)*3/2 ... (4.4) Dalam MySQL banyak indek dalam block adalah 1024 bytes dan panjang data pointer 4 bytes dan panjang indek 3 bytes. Jika diaplikasikan pada tabel
pst_ke1 yang mempunyai record sebanyak 3.873.324, maka dalam tabel pst_ke1 dengan mempunyai panjang data pointer 4 bytes dan panjang indek 3 bytes, berdasarkan persamaan (4.3) akan didapat nilai pencarian sebesar :
log(3.873.324 )/log(1024/3*2/(3+4)) + 1 = (6.58880 / 0.07167 ) + 1 = 93 kali pencarian.
dan berdasarkan persamaan (4.4), memerlukan buffer sebanyak 3.873.324 * 7 * 3/2 = 40,6 MB
Untuk tabel pstaktif mempunyai jumlah record sebesar 3.619.423, akan mempunyai nilai pencarian sebesar :
log(3.619.423 )/log(1024/3*2/(3+4)) + 1 = (6.55863 / 0.07167 ) + 1 = 92 kali pencarian dan memerlukan buffer sebanyak
3.619.423 * 7 * 3/2 = 38 MB
Proses pencarian satu indek dalam tabel pst_ke1 diperlukan 93 langkah dan memerlukan memori sebanyak 40,6 MB, sedangkan untuk tabel pstaktif pencarian indek diperlukan 92 langkah dengan memerlukan memori sebanyak 38MB. Diasumsikan buffer index digunakan sebanyak 2/3, normalnya proses pencarian dilakukan 2 kali, yaitu untuk update indek dan menulis baris.
i
Proses selanjutnya melakukan join setelah record mempunyai indek yang sesuai, dan kemudian dilakukan equality join.
Untuk menghitung biaya join diperlukan ii : a. Jumlah blok sebesar :
bP =r / bfr ... (4.5) dimana : r = jumlah record
bfr = blocking factor (jumlah record per blok) b. Selection cardinality, yaitu :
Satribut = rP / datribut ... (4.6) dimana : rP = jumlah record dalam tabel pertama
datribut = distinct value tabel kedua c. Biaya algoritma nested loop :
Cost = bP + ( bP * bF) + [ ( js * rP * rF) / bfrF ] ... (4.7) dimana : bp = jumlah blok dalam tabel pertama
bF = jumlah blok tabel kedua
js = join selectivity sebesar (1/jumlah record tabel kedua) rP = jumlah record dalam tabel pertama
rF = jumlah record dalam tabel kedua bfrF = blocking factor dari tabel kedua d. Biaya algoritma B++ tree indek structure :
Cost = bP + (rP * ( XatributF + SatributP))+[ (js*rP * rF) / bfrF ] ... (4.8) dimana : bp = jumlah blok dalam tabel pertama
rP = jumlah record dalam tabel pertama XatributF = primary index tabel kedua
SatributP = Selection cardinality tabel pertama
js = join selectivity sebesar (1/jumlah record tabel kedua) rF = jumlah record dalam tabel kedua
bfrF = blocking factor dari tabel kedua
ii
Contoh kasus sebelumnya perintah join query yaitu:
SELECT *
FROM pst_ke1 P, pstaktif F
WHERP P. no_tsp = F. no_tsp
Tabel pst_ke1 P mempunyai 3.873.324 record. Jadi rp = 3.873.324 ( rP adalah record dalam P ). Diasumsikan jumlah record pst_ke1 per-halaman dalam satu disk blok adalah 100. Jadi bfrP = 100. Jika b adalah jumlah blok yang diperlukan untuk menyimpan tabel, maka jumlah blok dalam tabel P adalah bP, berdasarkan persamaan (4.5) blocking factor dari tabel P adalah :
bP =rP / bfrP
= 3.873.324 / 100 = 38.733
Untuk membedakan nilai indek diperlukan sebuah secondary index pada no_tsp dengan Xno_tsp = 2. Jangkauan atribut no_tsp terhadap nippa dari tabel pstaktif diperlukan 3.619.423 distinct value untuk no_tsp. Jadi dno_tsp = 3.619.423
Berdasarkan persamaan (4.6), nilai selection cardinality tabel P dari no_tsp adalah:
Sno_tsp = rP / dno_tsp
= 3.873.324 / 3.619.423 = 1,07
Tabel pstaktif mempunyai 3.619.423 record. Jadi rF = 3.619.423 dengan Blocking factor dari pstaktif adalah bfrF= 80, maka nilai blok untuk pstaktif F adalah bF = 45242. Primary index pada nippa adalah tunggal, maka Xnippa = 1 Berdasarkan asumsi-asumsi di atas, Join Selectivity (js) adalah 1 / 3.619.423. dan untuk mendapatkan harga yang minimum, dapat dilakukan perhitungan berdasarkan persamaan (4.7) untuk nested loop, dan persamaan (4.8) untuk index structure yaitu :
1. Menggunakan nested loop dengan pst_ke1 pada bagian luar : Cost = bP + ( bP * bF ) + [ ( js * rP * rF) / bfrF ]
= 38733 + ( 38733 * 45242 ) + [ (1 / 3.619.423 * 3.873.324 * 3.619.423 ) / 80 ] = 38733 + 1752358386 + 48416,55
= 1752445536 blok
Apabila kecepatan I/O komputer mencapai 10ms, maka biaya di atas menjadi : = 1752445536 * 0,0000028, hasilnya setara dengan
= 4906,85 jam = 204,5 hari
2. Menggunakan nested loop dengan pstaktif pada bagian luar : Cost = bF + ( bF * bP ) + [ ( js * rP * rF) / bfrF ]
= 45242 + (45242 * 38733 ) + [ ( 1 / 3.619.423 * 3.873.324 * 3.619.423 ) / 80 ] = 45242 + 1752358386 + 48416,55
= 1752452027,55 blok , jika kecepatan I/O komputer mencapai 10ms, maka, = 1752452027,55 * 0,0000028, hasilnya setara dengan
= 4906,86 jam = 204 hari
3. Menggunakan index structure pada nippa dengan pst_ke1 pada bagian luar. Cost = bP + ( rP * ( Xnippa + Sno_tsp ) ) + [ ( js * rP * rF) / bfrF ]
= 38733 + ( 3.873.324*(1 + 1)) + [(1/3.619.423 * 3.873.324 * 3.619.423) / 80 ] = 38733 + 7746648 + 48416,55
= 7833797,55 blok, jika kecepatan I/O komputer mencapai 10ms, maka, = 7833797,55 * 0,0000028, hasilnya setara dengan
= 21,935 jam = 0,91395 hari
4. Menggunakan index structure pada nippa dengan pstaktif pada bagian luar. Cost = bF + ( rF * ( Xno_tsp + Sno_tsp ) ) + [ ( js * rP * rF) / bfrF ]
= 45242+ (3.619.423*(2+1,07 ))+ [(1/3.619.423 * 3.873.324 * 3.619.423) /80] = 45242 + 11111628,61 + 48416,55
= 11205287,16 blok , jika kecepatan I/O komputer mencapai 10ms, maka, = 11205287,16 * 0,0000028, hasilnya setara dengan
= 31,3748 jam = 1,37 hari
Dari hasil perhitungan menunjukkan bahwa persamaan ketiga mempunyai biaya 21,935 jam adalah nilai yang paling rendah, sehingga optimizer akan memilih eksekusi menggunakan persamaan yang ketiga. Biaya keempat proses di atas tidak termasuk proses pencarian yang dilakukan sebelum operasi join, untuk proses pencarian biaya dapat diabaikan karena proses pencarian dilakukan didalam buffer.
Fasilitas optimizer dari DBMS MySQL, menggunakan index structure biaya query lebih rendah dibandingkan dengan biaya menggunakan nested loops, MySQL optimizer akan memilih dan menggunakan index structure, dengan persyaratan spesifikasi minimum untuk tabel yang besar harus dipenuhi , sebagai berikut iii :
Processor Intel Pentium IV Set Up Buffer : Key_buffer = 384 M max_allowed_packet = 1 M table_cache = 512 M Sort_buffer_size = 2 M read_buffer_size = 2 M MyISAM_sort_buffer_size = 64 M thread_cache_size = 32 M iii
4.3. Percobaan
Penulis melaksanakan percobaan menggunakan fasilitas jaringan komputer yang berada di Kampus FMIPA UNPAD Jatinangor (” sebagian peta network dapat dilihat pada Gambar 23 ”), fasilitas tersebut menggunakan arsitektur client-server dengan spesifikasi antara lain :
- Client : Processor Intel Pentium IV Core Duo 2,66 GHZ Memory 512 MB, Harddisk 60 GB
Processor Intel Pentium IV 1,7 GHZ Memory 256 MB, Harddisk 40 GB Sistem Operasi Windows XP
- Server : Processor Intel Pentium IV Core Duo 2,66 GHZ Memory 2 GB, Harddisk 80 GB
Sistem Operasi Linux Redhat - Software DBMS: Mysql 4.0.3 win
My ODBC 3.51.06 My SQL-Front_2.5
My-SQL Administrator 1.0.5
Dalam melakukan perintah-perintah query terdapat karakteristik dari DBMS dan arsitektur client server antara lain :
1. Client dan server dapat melakukan komputasi, client dapat menerima bagian dari jawaban query.
2. Server melakukan replikasi kepada client secara real time dimana server sebagai server master dan client sebagai server slave.
3. Client akan merubah data transaksi pada server sebelum koneksi ke server di tutup.
Dalam skenario yang memiliki 3 karakteristik ini minimasi waktu akses dan transfer data menjadi sangat penting, sehingga masalah minimasi ongkos yang dikeluarkan dalam transfer hasil query dapat menjadi lebih murah.
Ada beberapa cara yang mungkin untuk mendekomposisi query kedalam hasil views, rencana terbaik yaitu mempunyai ukuran minimum dan pada basis data di server.
Sebuah keuntungan dari pendekatan ini adalah bahwa menggunakan metoda formal, untuk memilih optimisasi secara global yang terdapat dalam DBMS dapat diperhitungkan dan dapat dibuktikan pada saat yang sama efisiensi metoda-metoda yang men-dekomposisi query kedalam views, dengan kata lain untuk sebuah query yang diberikan dari sebuah client ke server. Dalam percobaan dengan ketiga skenario di atas ongkos komunikasi tidak dapat diabaikan dan akan berpengaruh pada total perhitungan waktu, kemudian hasilnya dapat dievaluasi dalam berbagai kasus query tersebut.
Dalam percobaan ini data relasi disimpan pada client (server slave) dan server (server master), situasinya dapat dilihat pada Gambar 23, masing-masing
pst_ke1 dan pstaktif disimpan dalam client (server slave), sedangkan, pmk_ke1,
pmk_fd1 dan pstpens disimpan dalam server (server master).
Dalam DBMS yang penulis gunakan client terkoneksi dengan database server, dan server melakukan replikasi pada client. Replikasi yang dijalankan yaitu dari server master ke server slave, transfer data (selama replikasi) antar server apabila query menggunakan MySQL kecepatannya mencapai 0,0002 detik dalam keadaan kondisi jaringan normal.
Untuk percobaan yang dilakukan tabel-tabel yang diuji masih berupa tabel dengan tipe file masih ber-ekstensi .dbf, tabel tersebut dikonversi kedalam tabel Microsoft Access, setelah menjadi file Microsoft Access kemudian dikonversi lagi kedalam database MySQL, hal ini dilakukan karena karakteristik database tersebut banyak mengandung duplikasi dan banyak kesalahan dari tipe data yang tidak sesuai dengan isi data, begitu pula untuk field yang tidak null banyak yang tidak dipenuhi, sehingga apabila data berupa file .dbf tersebut langsung di konversi kedalam database MySQL sulit dapat diterima.
Dari hasil pengamatan dalam proses query yang dilakukan terdapat hasil analisis dari beberapa output runtime antara lain :
1. Perintah-perintah query yang tidak melakukan join tidak terdapat masalah walaupun jumlah record cukup besar dengan rata-rata lebih dari satu juta record dengan kapasitas memori tabel di atas 100 MB.
2. Perintah-perintah query dengan menggunakan proses optimisasi menggunakan kriteria tertentu baik dalam satu relasi atau lebih dari satu
relasi, perbedaan kecepatan join query sangat signifikan, walaupun dalam DBMS sendiri sudah mempunyai fasilitas optimizer.
3. Proses optimisasi dengan mendahulukan proses seleksi sebelum melakukan join, proses eksekusi waktunya lebih cepat dari pada melakukan join lebih dahulu kemudian melakukan seleksi.
4. Perubahan-perubahan hasil proses optimisasi sangat terlihat dalam jumlah record diatas 100.000, demikian juga untuk spesifikasi komputer yang berbeda, perbedaan runtime terlihat pada record diatas 100.000.
5. Fragmentasi sangat diperlukan dalam jumlah record lebih dari satu juta, karena proses join tersebut dapat memakan waktu lebih dari satu hari. Perintah-perintah query yang dilaksanakan dalam kasus ini pertama kali adalah perintah query yang dilakukan untuk menguji bahwa tabel betul-betul layak uji dan tidak terdapat error data dalam field sehingga tidak perlu melakukan join terlebih dahulu, kemudian perintah query selanjutnya dilakukan seleksi dan join, perintah-perintah query tersebut adalah :
Q1. Perintah-perintah query tanpa optimisasi pada satu tabel relasi, hal ini untuk melihat seluruh isi tabel layak uji dan melihat unjuk kerja I/O komputer, yaitu : 1 SELECT * FROM pst_ke1; 2 SELECT * FROM pstaktif; 3 SELECT * FROM pmk_ke1; 4 SELECT * FROM pmk_fd1; 5 SELECT * FROM pstpens;
Q2 Perintah-perintah query dengan optimisasi seleksi satu kriteria dari atribut tertentu pada tabel satu relasi, yaitu :
1 SELECT * FROM pst_ke1 WHERE no_tsp = 131653793; 2 SELECT * FROM pstaktif WHERE nippa = 131653793; 3 SELECT * FROM pmk_ke1 WHERE tmt_pst = “1970/01/01”; 4 SELECT * FROM pmk_fd1 WHERE tmt_pst = “1970/01/01”; 5 SELECT * FROM pstpens WHERE kp180=”1997/11/01”;
Tabel 11 . Running time query tabel satu relasi tanpa join, Q1 tanpa optimisasi Q2
dengan optimisasi satu kriteria. TABEL/QUERY
P IV Core Duo 512 MB
pmk_ke1 pstpens pmk_fd1 pst_ke1 pstaktif
58 MB 1,4 juta record 70 MB 1,26 juta record 107 MB 1,26 juta record 132 MB 3,87 juta record 165 MB 3,62 juta record Q1 10,84 14,69 19,26 22,75 29,66 Q2 0,8 2,81 3,05 7,49 7,73