109
BAB IV ANALISIS DAN EVALUASI 4.1. Analisis dan Evaluasi Pada bab ini akan dijabarkan secara rinci bagaimana langkah – langkah yang dilakukan untuk melakukan analisis dan evaluasi dari pengujian sistem. Dalam melakukan pengujian dan evaluasi, terdapat tujuh langkah utama yaitu :
Gambar 4.1. Langkah analisis dan evaluasi 1. Pengujian performansi sistem sebelum melakukan implementasi MV. 2. Simulasi proses seleksi MV dengan menggunakan aplikasi prototipe. 3. Pengujian performansi sistem setelah melakukan implementasi MV. 4. Melakukan
estimasi
analisis
biaya
yang
dikeluarkan
untuk
implementasi MV pada sistem. 5. Melakukan analisis manfaat yang didapatkan setelah implementasi MV dengan menggunakan metode gap analysis.
110
6. Melakukan evaluasi
perbandingan
biaya
dan
manfaat
untuk
mendapatkan hasil evaluasi dari solusi yang ditawarkan. 7. Melakukan evaluasi prototype aplikasi seleksi MV Dalam melakukan pengujian, peneliti menggunakan dua buah data sampel pada tabel fact dengan ukuran sebesar 1.25G dan 11.05G, hal ini dikarenakan adanya limitasi untuk mendapatkan data tepat sebesar 1G dan 10G sesuai dengan rekomendasi dari TPC-H (TPC, 2011). Untuk melakukan simulasi proses seleksi MV pada aplikasi prototype diperlukan query workload sebagai data sampel dengan beberapa pertimbangan dalam melakukan pemilihan sampel, yaitu : 1. Query untuk mendapatkan laporan pendapatan berdasarkan jenis trafik dan jenis charging adalah paling sering digunakan. Parameter query yang sering digunakan sebagai predicate adalah jenis charging yang berelasi dengan akses ke facebook (Q3 dan Q4) dan jenis trafik yang berelasi dengan akses data GPRS (Q7 dan Q8). 2. Laporan pendapatan harian adalah laporan yang paling penting karena untuk melihat performa jaringan dan pendapatan setiap harinya (Q1Q8). 3. Sistem DWS yang digunakan dalam penelitian hanya mencakup area region Jawa Timur dan sekitarnya, sehingga parameter yang pilih adalah area Surabaya (Q2 dan Q4) dan Malang (Q6 dan Q8) karena area ini mempunyai jumlah pelanggan dan jumlah trafik paling tinggi diantara kota lainnya.
111
Berikut ini adalah data sampel yang digunakan yang terdiri dari delapan jenis query. Tabel 4.1 Query Workload untuk Uji Coba ID Q1
Q2
Q3
Q4
Teks Query select wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME ,sum(sdtf.DURATION), sum(sdtf.FREE_DURATION), sum(sdtf.NUMBER_OF_TRANSACTIONS),sum(sdtf.TOTAL_COST), sum(sdtf.VOLUME) from sdm_daily_traffic_facts sdtf, wh_charging_categories_dim wccd, wh_financials_time_dim wftd where sdtf.CH_CATEGORY_ID = wccd.CH_CATEGORY_ID and sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY and wftd.FINANCIAL_DATE_KEY = 20111220000 group by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME order by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME select wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME ,sum(sdtf.DURATION), sum(sdtf.FREE_DURATION), sum(sdtf.NUMBER_OF_TRANSACTIONS),sum(sdtf.TOTAL_COST), sum(sdtf.VOLUME) from sdm_daily_traffic_facts sdtf, wh_charging_categories_dim wccd, wh_financials_time_dim wftd where sdtf.CH_CATEGORY_ID = wccd.CH_CATEGORY_ID and sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY and wftd.FINANCIAL_DATE_KEY = 20111220000 and sdtf.branch = 'Surabaya' group by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME order by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME select wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME ,sum(sdtf.DURATION), sum(sdtf.FREE_DURATION), sum(sdtf.NUMBER_OF_TRANSACTIONS),sum(sdtf.TOTAL_COST), sum(sdtf.VOLUME) from sdm_daily_traffic_facts sdtf, wh_charging_categories_dim wccd, wh_financials_time_dim wftd where sdtf.CH_CATEGORY_ID = wccd.CH_CATEGORY_ID and sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY and wftd.FINANCIAL_DATE_KEY = 20111220000 and wccd.ch_category_name LIKE 'Facebook%' group by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME order by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME select wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME ,sum(sdtf.DURATION), sum(sdtf.FREE_DURATION), sum(sdtf.NUMBER_OF_TRANSACTIONS),sum(sdtf.TOTAL_COST), sum(sdtf.VOLUME) from sdm_daily_traffic_facts sdtf,
Frek 2
1
2
1
112
Q5
Q6
Q7
Q8
wh_charging_categories_dim wccd, wh_financials_time_dim wftd where sdtf.CH_CATEGORY_ID = wccd.CH_CATEGORY_ID and sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY and wftd.FINANCIAL_DATE_KEY = 20111220000 and sdtf.branch = 'Surabaya' and wccd.ch_category_name LIKE 'Facebook%' group by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME order by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wccd.CH_CATEGORY_NAME select wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME ,sum(sdtf.DURATION), sum(sdtf.FREE_DURATION), sum(sdtf.NUMBER_OF_TRANSACTIONS),sum(sdtf.TOTAL_COST), sum(sdtf.VOLUME) from sdm_daily_traffic_facts sdtf, wh_traffic_types_dim wttd, wh_financials_time_dim wftd where sdtf.TRAFFIC_TYPE_ID = wttd.TRAFFIC_TYPE_ID and sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY and wftd.FINANCIAL_DATE_KEY = 20111220000 group by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME order by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME select wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME ,sum(sdtf.DURATION), sum(sdtf.FREE_DURATION), sum(sdtf.NUMBER_OF_TRANSACTIONS),sum(sdtf.TOTAL_COST), sum(sdtf.VOLUME) from sdm_daily_traffic_facts sdtf, wh_traffic_types_dim wttd, wh_financials_time_dim wftd where sdtf.TRAFFIC_TYPE_ID = wttd.TRAFFIC_TYPE_ID and sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY and wftd.FINANCIAL_DATE_KEY = 20111220000 and sdtf.branch = 'Malang' group by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME order by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME select wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME ,sum(sdtf.DURATION), sum(sdtf.FREE_DURATION), sum(sdtf.NUMBER_OF_TRANSACTIONS),sum(sdtf.TOTAL_COST), sum(sdtf.VOLUME) from sdm_daily_traffic_facts sdtf, wh_traffic_types_dim wttd, wh_financials_time_dim wftd where sdtf.TRAFFIC_TYPE_ID = wttd.TRAFFIC_TYPE_ID and sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY and wftd.FINANCIAL_DATE_KEY = 20111220000 and wttd.TELE_SERVICE_NAME = 'GPRS' group by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME order by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME select wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME ,sum(sdtf.DURATION), sum(sdtf.FREE_DURATION),
1
2
1
2
113
sum(sdtf.NUMBER_OF_TRANSACTIONS),sum(sdtf.TOTAL_COST), sum(sdtf.VOLUME) from sdm_daily_traffic_facts sdtf, wh_traffic_types_dim wttd, wh_financials_time_dim wftd where sdtf.TRAFFIC_TYPE_ID = wttd.TRAFFIC_TYPE_ID and sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY and wftd.FINANCIAL_DATE_KEY = 20111220000 and sdtf.branch = 'Malang' and wttd.TELE_SERVICE_NAME = 'GPRS' group by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME order by wftd.FINANCIAL_DATE_KEY, sdtf.branch, wttd.TELE_SERVICE_NAME
4.2. Performansi Sistem tanpa MV Melakukan pengujian performansi pada sistem sebelum diimplementasi MV merupakan langkah pertama dalam langkah – langkah uji coba. Masing – masing data sampel dari query workload dijalankan sebanyak empat kali untuk mendapatkan hasil yang lebih akurat, kemudian hasil akhirnya diambil dari nilai rata – ratanya. Terdapat dua parameter indikator yang akan diukur dalam pengujian ini yaitu nilai waktu respon dan nilai estimasi biaya dalam satuan blok. Hasil dari pengujian ini nantinya akan dibandingkan dengan sistem setelah diimplementasi MV. Berikut ini adalah hasil rata – rata dari pengujian data sampel : Tabel 4.2. Hasil Pengujian Sistem tanpa MV ID Q1 Q2 Q3 Q4 Q5
Ukuran 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G
Waktu Respon (s) 28.7175 296.5385 28.0765 285.9955 0.51375 2.8255 0.161 0.26575 28.38025 294.05975
Query Cost (block) 35838 328704 36697 336896 10213 77369 10207 77320 35838 328704
114
Q6 Q7 Q8
1.25G 11.05G 1.25G 11.05G 1.25G 11.05G
28.49275 281.7285 28.41225 287.07575 28.20775 275.28575
37292 336896 35836 328704 36689 336896
Berdasarkan hasil pengujian diatas terlihat bahwa kenaikan waktu respon query dan biaya query processing secara umum adalah linier karena hasil query plan yang didapatkan adalah full table scan. Namun meskipun terdapat kenaikan linier, hasil akhirnya tidak selalu merupakan nilai kelipatan dari hasil sebelumnya. Sebagai contoh rasio perbandingan ukuran antara sampel data pertama dan kedua adalah 8.9, namun rasio perbandingan waktu respon query secara umum antara sampel data pertama dan kedua berada pada kisaran 9.7 hingga 10.3 kali. Begitu juga dengan rasio perbandingan biaya query processing ada pada kisaran 9 – 9.2 kali. Rasio hasil pada Q3 dan Q4 relatif kecil karena pada kedua query tersebut query plan yang digunakan adalah menggunakan index dan tidak full table scan, sehingga perbandingan hanya sebesar 1-5 kali. Hal tersebut juga dibuktikan dengan biaya query processing yang lebil kecil dibandingkan query yang lain. Jadi kesimpulannya adalah tanpa menggunakan MV maka performansi akan turun secara linier dan penggunaan index bisa memperkecil rasio penurunan performansi. Tabel 4.3. Rasio Perbandingan 2 Ukuran Sampel ID Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8
Waktu Respon 10.32605554 10.18629459 5.499756691 1.650621118 10.36142212 9.887725825 10.10394284 9.759223972
Query Cost 9.171940398 9.180477968 7.575540977 7.575193495 9.171940398 9.034001931 9.172452283 9.182479762
115
4.3. Simulasi Prototype Seleksi MV Pada bagian ini akan digambarkan bagaimana proses seleksi MV berdasarkan input query workload. Berikut adalah gambar aplikasi prototype seleksi MV dan informasi penggunaannya :
Gambar 4.2. Prototype Seleksi MV Dari gambar di atas, berikut adalah penjelasan dari masing – masing widget : 1. Workload Input Type digunakan untuk memilih apakah pengguna ingin menggunakan input dari file teks atau langsung mengambil informasi dari database. 2. Sample Size adalah pilihan besaran tabel fact yang digunakan dalam proses seleksi.
116
3. Query Filter digunakan untuk memilih input query yang masuk dalam kriteria. Pilihan ada dua yaitu berdasarkan nilai threshold atau Top-N. Nilai masing – masing parameter bisa dikonfigurasi pada bagian value. 4. MV Selection digunakan untuk memilih kandidat MV yang masuk dalam kriteria. Pilihan ada dua yaitu berdasarkan nilai threshold atau Top-N. Nilai masing – masing parameter bisa dikonfigurasi pada bagian value. 5. Save digunakan untuk menyimpan perubahan konfigurasi 6. View Selection digunakan untuk melakukan proses seleksi MV berdasarkan konfigurasi yang telah ditetapkan. 7. Preview digunakan untuk melihat hasil proses seleksi MV secara langkah per langkah. 8. Maintanance MV digunakan untuk memberikan laporan penggunaan MV kepada pengguna berdasarkan tingkat penggunaan dan kapasitas storage
Dengan konfigurasi seperti pada gambar di atas dan ketika proses dijalankan maka pada langkah pertama adalah melakukan seleksi query – query mana yang terseleksi dan tidak. Dengan menggunakan asumsi nilai threshold (Φ) = 11, maka dari input yang ada berikut adalah hasil dari proses seleksi query : Tabel 4.4. Hasil Proses Seleksi Query ID Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8
Frekuensi 2 1 2 1 1 2 1 2
Ukuran (byte) 206016 206016 1554 1554 13542 8631804 888 4350090
Bobot 10.849 12.235 5.962 7.348 9.513 14.585 6.789 13.899
117
Selanjutnya dari query yang terseleksi (bobot < 11), masing – masing akan diekstrak atribut yang terdapat pada conditional clause (CC). Pada masing – masing CC akan dicari attribut yang benar – benar unik atau disebut Distinc CC. Di bawah ini adalah tabel representasi CC pada query – query yang telah terseleksi. Tabel 4.5. Representasi CC ID Q1
Q3
Q4
Q5
Q7
CC CC1 CC2 CC3 CC1 CC2 CC3 CC4 CC1 CC2 CC3 CC4 CC5 CC1 CC2 CC3 CC1 CC2 CC3 CC4
CC Text sdtf.CH_CATEGORY_ID = wccd.CH_CATEGORY_ID sdtf.FINANCIAL_DATE_KEY= wftd.FINANCIAL_DATE_KEY wftd.FINANCIAL_DATE_KEY = 20111220000 sdtf.CH_CATEGORY_ID = wccd.CH_CATEGORY_ID sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY wftd.FINANCIAL_DATE_KEY = 20111220000 Wccd.CH_CATEGORY_NAME LIKE 'Facebook%' sdtf.CH_CATEGORY_ID = wccd.CH_CATEGORY_ID sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY wftd.FINANCIAL_DATE_KEY = 20111220000 sdtf.BRANCH = 'Surabaya' Wccd. CH_CATEGORY_NAME LIKE 'Facebook%' sdtf.TRAFFIC_TYPE_ID = wttd.TRAFFIC_TYPE_ID sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY wftd.FINANCIAL_DATE_KEY = 20111220000 sdtf.TRAFFIC_TYPE_ID = wttd.TRAFFIC_TYPE_ID sdtf.FINANCIAL_DATE_KEY = wftd.FINANCIAL_DATE_KEY wftd.FINANCIAL_DATE_KEY = 20111220000 wttd.TELE_SERVICE_NAME = 'GPRS'
DCC DCC7 DCC5 DCC4 DCC7 DCC5 DCC4 DCC1 DCC7 DCC5 DCC4 DCC2 DCC1 DCC3 DCC5 DCC4 DCC3 DCC5 DCC4 DCC6
Langkah selanjutnya untuk mendapatkan kandidat MV adalah dengan cara menghitung bobot masing – masing DCC. Jika nilai bobot tidak melebihi nilai threshold, dalam hal ini diasumsikan threshold < 4.48, maka berikut ini hasil dari proses seleksi DCC. Tabel 4.6. Hasil Seleksi DCC ID DCC1 DCC2 DCC3 DCC4
Frekuensi 2 1 2 5
Ukuran (byte) 3892548 300665256 38921484 645132
Bobot 4.499 5.618 4.471 2.669
118
DCC5 DCC6 DCC7
5 1 5
19965792 973248 901995768
2.654 5.888 2.447
Setelah semua DCC terpilih maka selanjutnya atribut – atribut tersebut disusun kembali menjadi query semula. Hasil inilah nantinya yang akan digunakan untuk implementasi MV pada sistem. Dari hasil DCC yang terpilih, berikut ini adalah MV yang akan diimplementasi.
4.4. Performansi Sistem dengan MV Setelah MV hasil dari proses seleksi telah diimplementasi di dalam sistem, maka langkah selanjutnya adalah melakukan pengujian performansi sistem setelah implementasi MV. Skenario dan parameter indikator yang digunakan adalah sama dengan pengujian pada sistem tanpa MV. Berikut ini adalah hasil dari waktu respon dan biaya query : Tabel 4.7. Hasil Pengujian dengan MV ID Q1 Q2 Q3
Ukuran 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G
Waktu Respon (s) 0.19575 0.189 0.1475 0.2115 0.22075 0.19125
Query Cost (block) 4 4 4 4 4 3
119
Q4 Q5 Q6 Q7 Q8
1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G
0.1535 0.185 0.14775 0.2205 0.14575 0.17325 0.21125 0.1815 0.1495 0.14975
4 3 4 4 4 4 2 4 1 3
Berdasarkan hasil pengujian diatas terlihat bahwa kenaikan waktu respon query dan biaya query processing adalah tidak linier meskipun hasil query plan yang didapatkan adalah full table scan. Sebagai contoh rasio perbandingan ukuran antara sampel data pertama dan kedua adalah 8.9, namun rasio perbandingan waktu respon query secara umum antara sampel data pertama dan kedua berada pada kisaran 0.8 hingga 1.4 kali. Begitu juga dengan rasio perbandingan biaya query processing ada pada kisaran 1 – 3 kali. Rasio hasil pada Q3 dan Q4 juga tidak selalu linier meskipun kedua query tersebut query plan yang digunakan adalah menggunakan index dan tidak full table scan. Bahkan biaya query processing pada data 11.05G lebih kecil daripada data 1.25G. Jadi kesimpulan yang bisa didapatkan adalah pada MV tidak terdapat efek penurunan performansi yang cukup signifikan antara jumlah data yang lebih besar dan penggunaan index atau tidak. Tabel 4.9. Rasio Perbandingan 2 Ukuran Sampel ID Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8
Waktu Respon 0.965517241 1.433898305 0.866364666 1.205211726 1.492385787 1.188679245 0.859171598 1.001672241
Query Cost 1 1 0.75 0.75 1 1 2 3
120
4.5. Analysis Biaya Dalam melakukan investasi pengembangan sebuah sistem, biaya merupakan faktor penting yang harus diperhatikan. Begitu juga ketika perusahaan akan melakukan implementasi aplikasi pemilihan MV. Perhitungan biaya investasi yang harus dikeluarkan untuk biaya hardware, software dan biaya lain seperti biaya pengembangan, biaya operasional dll. Berikut ini adalah biaya – biaya yang diperlukan untuk pengembangan, implementasi dan operasional. 1. Biaya Pengembangan Dalam perhitungan biaya akan digunakan model COCOMO II dengan sub model level prototype. Karena dalam pengembangan hanya dihasilkan output berupa prototype yang sudah bisa diujikan dan hanya dibutuhkan tim yang kecil dan tentunya masing – masing anggota memiliki kompenten yang sangat baik tentang database dan programming. Berikut ini adalah koefisien daripada prototype yang akan dibangun. •
Terdapat 1 tampilan GUI dengan tingkat kerumitan simpel
•
Report yang digunakan hanya 2 yaitu 1 report hasil seleksi MV dan 1 report untuk hasil maintenance MV. Tingkat kerumitan dari masing – masing report adalah simpel.
•
Modul yang digunakan ada 6 modul yaitu modul input query set, query selection, MV selection, QP and MV cost calculation, final recommendation and MV maintenance.
•
Asumsi tingkat produktivitas dari developer menggunakan nilai nominal yaitu 13.
121
Sehingga dengan input koefisien diatas maka akan didapatkan jumlah object-points dari prototype dibawah ini : •
1 GUI simpel
x1
=
1
•
2 Report simple
x1
=
2
•
6 modul
x 10
=
60
Total
63
Hasil perhitungan estimasi usaha yang diperlukan adalah sebagai berikut : PM
=
NOP
/
PROD
=
63
/
13
=
5 PM
Dengan asumsi gaji seorang programmer adalah 7.000.000 (Kelly, 2011), maka total estimasi biaya pengembangan yang diperlukan adalah 7 jt x 5 bulan = 35 jt. 2. Biaya Operasional Biaya operasional adalah biaya yang dihitung setelah aplikasi tersebut sudah dipakai termasuk biaya untuk melakukan monitor aplikasi. Diasumsikan untuk melakukan aktivitas operasional dan maintenance adalah personel yang sama dengan tim OAM aplikasi DWS, maka biaya ini bisa dihilangkan. 3. Biaya Hardware Karena implementasi MV membutuhkan disk untuk meyimpan data hasil aggregasi, maka perlu diperhitungkan biaya yang harus dikeluarkan untuk setiap byte yang digunakan. Diasumsikan besarnya
122
kapasitas yang dibutuhkan untuk menyimpan data MV adalah sebesar kapasitas yang dibutuhkan oleh tabel – tabel fact maka total kapasitas MV adalah : 12 tabel fact x 24Gb = 288 Gb. Dengan asumsi bahwa pada sistem DWH kebutuhan hardware media penyimpanan masih mencukupi, maka biaya ini bisa dihilangkan.
4.6. Analisis Manfaat Sebuah perbaikan yang dilakukan pasti akan menghasilkan manfaat terhadap perusahaan baik yang dapat diukur secara langsung ataupun tidak. Sehingga perlu dilakukan analisis manfaat terhadap implementasi MV dengan apa yang telah dihasilkan dalam pengujian. Analisis manfaat ini akan digunakan untuk melakukan analisa terhadap sistem yang belum mengimplementasikan MV dan sistem yang telah mengimplementasikan MV, di mana metode akan yang digunakan adalah metode gap analysis. Terdapat dua buah parameter indikator yang akan digunakan dalam melakukan perbandingan yaitu : 1. Biaya Query Processing Berdasarkan hasil pengujian pada sistem sebelum dan sesudah diimplementasi MV, tabel berikut akan menggambarkan perbandingan hasil keduanya. Tabel 4.7. Perbandingan Biaya Query Processing ID Q1 Q2 Q3
Ukuran 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G
Tanpa MV 35838 328704 36697 336896 10213 77369
Dengan MV 4 4 4 4 4 3
123
Q4 Q5 Q6 Q7 Q8
1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G
10207 77320 35838 328704 37292 336896 35836 328704 36689 336896
4 3 4 4 4 4 2 4 1 3
Dapat dianalisis dari tabel diatas bahwa dengan menggunakan MV maka biaya query processing dapat diturunkan hingga skala faktor ribuan. Selain itu pada sistem dengan menggunakan MV, biaya query processing relatif sama artinya tidak terlalu terpengaruh oleh besaran data yang dibaca. Sedangkan pada sistem tanpa MV terlihat bahwa kenaikan linier terjadi. Dari hasil analisis tersebut dapat disimpulkan bahwa implementasi MV memberikan manfaat : a. Menghasilkan biaya query processing yang lebih rendah hingga ribuan kali lipat b. Biaya query processing tidak terpengaruh oleh besaran data, sehingga sangat cocok dengan sistem DWH yang memiliki data sangat besar c. Memberikan efisiensi penggunaan processor ketika melakukan proses komputasi data seperti query , aggregation dll d. Dapat menggunakan utilisasi processor untuk proses aplikasi yang lain dalam 1 sistem.
Berikut ditampilkan grafik perbandingan biaya query processing antara sebelum dan sesudah implementasi MV. Terlihat bahwa
124
terjadi gap yang sangat besar dalam artian efek implementasi MV memberikan peningkatan performansi yang sangat signifikan. Biaya Query Processing - 1.25G 100000 10000 1000 Biaya (blok) 100 10 1 Q1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Query ID Tanpa MV
Dengan MV
Biaya Query Processing - 11.05G 1000000 100000 10000 Biaya (blok)
1000 100 10 1 Q1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Query ID Tanpa MV
Dengan MV
Grafik 4.1. Perbandingan Biaya Query Processing 2. Waktu Respon Query Berdasarkan hasil pengujian pada sistem sebelum dan sesudah diimplementasi MV, tabel berikut akan menggambarkan perbandingan
125
hasil keduanya dalam hal waktu respon query dalam satuan detik (second).
Tabel 4.8. Perbandingan Waktu Respon Query ID Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8
Ukuran 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G 1.25G 11.05G
Tanpa MV 28.7175 296.5385 28.0765 285.9955 0.51375 2.8255 0.161 0.26575 28.38025 294.05975 28.49275 281.7285 28.41225 287.07575 28.20775 275.28575
Dengan MV 0.19575 0.189 0.1475 0.2115 0.22075 0.19125 0.1535 0.185 0.14775 0.2205 0.14575 0.17325 0.21125 0.1815 0.1495 0.14975
Dapat dianalisis dari tabel diatas bahwa dengan menggunakan MV maka waktu respon query meningkat sangat signifikan hingga rata – rata dengan skala faktor 150 keatas. Selain itu pada sistem dengan menggunakan MV, waktu respon query relatif sama artinya tidak terlalu terpengaruh oleh besaran data yang dibaca. Sedangkan pada sistem tanpa MV terlihat bahwa kenaikan linier terjadi. Dari hasil analisis tersebut dapat disimpulkan bahwa implementasi MV memberikan manfaat : a. Meningkatkan waktu respon query sebesar 150 – 190 kali lipat.
126
b. Waktu respon query relatif sama untuk ukuran data yang lebih besar, hanya memberikan kenaikan sebesar 1-1.5 kali untuk data 1.25G dengan 11.05G. c. Hasil report dapat disediakan lebih cepat dari sebelumnya. d. Membantu meningkatkan efisiensi operasional karyawan dalam perusahaan, sehingga waktu kerja dapat digunakan untuk aktivitas operasional yang lain. Berikut ditampilkan grafik perbandingan waktu respon query antara sebelum dan sesudah implementasi MV. Terlihat bahwa terjadi gap yang sangat besar dalam artian efek implementasi MV memberikan peningkatan performansi yang sangat signifikan. Dapat dilihat bahwa rata – rata kecepatan waktu respon query dari sampel data di bawah 1 detik. Hal ini akan memberikan pengalaman baru kepada user ketika sedang melakukan proses retrieval data. Waktu Respon Query - 1.25G 100
10 Waktu (detik) 1
0.1 Q1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Query ID Tanpa MV
Dengan MV
127
Waktu Respon Query - 11.05G 1000
100
Waktu (detik)
10
1
0.1 Q1
Q2
Q3
Q4
Q5
Q6
Q7
Q8
Query ID Tanpa MV
Dengan MV
Grafik 4.2. Perbandingan Waktu Respon Query
4.7. Analysis Biaya dan Manfaat Berdasarkan hasil analisis biaya dan manfaat di atas, maka dapat digambarkan metrik perbandingan antara sistem sebelum dan sesudah menggunakan MV dalam dua bagian yaitu analisis perbandingan biaya dan analisis perbandingan manfaat.
4.7.1. Analisis Perbandingan Biaya Berikut adalah tabel metrik perbandingan biaya antara aplikasi DWS tanpa dan dengan menggunakan MV. Tabel 4.9. Metrik Biaya No 1 2 3
Indikator Biaya Pengembangan (rupiah) Biaya Operasional tambahan per tahun (rupiah) Biaya Hardware tambahan (rupiah)
Tanpa MV 0 0 0
Dengan MV 35.000.000 0 0
128
Terlihat bahwa dalam implementasi MV hanya dibutuhkan biaya pengembangan prototype senilai 35 juta rupiah. Sedangkan untuk tambahan biaya operasional tidak perlu biaya karena dapat menggunakan resource yang ada yaitu staf operation and maintenance dan para DBA perusahaan. Karena implementasi MV bisa menggunakan sisa kapasitas storage yang masih ada maka tidak diperlukan biaya tambahan untuk meningkatkan kapasitas storage.
4.7.2. Analisis Perbandingan Manfaat Berikut adalah tabel metrik perbandingan manfaat antara aplikasi DWS tanpa dan dengan menggunakan MV. Tabel 4.10. Metrik Manfaat No 1 2
Indikator Biaya per Query Processing (blok) Waktu Respon per Query (detik)
Tanpa MV 29826.25 21.37
Dengan MV 3.375 0.17
Terlihat bahwa secara tangible, manfaat yang diperoleh jauh lebih besar karena memberikan biaya query processing per query yang jauh lebih rendah dan juga meningkatkan waktu respon per query. Impak dari manfaat tangible tersebut akan memberikan banyak mafaat intangble yaitu : 1. Memberikan efisiensi penggunaan processor ketika melakukan proses komputasi data seperti query , aggregation dll, sehingga utilitasi sistem bisa digunakan untuk proses – proses lain. 2. Dengan waktu respon query yang lebih cepat maka secara langsung akan memberikan manfaat yaitu report akan dihasilkan lebih cepat dan lebih tepat waktu. Sehingga akan membantu tim assurance untuk menganalisis dan memberikan rekomendasi berdasarkan hasil report lebih cepat.
129
3. Jika waktu respon query lebih cepat maka akan meningkatkan efisiensi jam kerja pegawai, sehingga waktu yang ada bisa diutilisasi untuk pekerjaan yang lain. 4. Operational efficient akan terwujud dengan sistem yang bekerja lebih optimal dan jam kerja yang lebih efisien.
