Urun rembug ya, dah lama gak nulis di milsi ini. (ehm, semoga gak dianggap memperpanjang topik OOT :)
Mungkin bisa juga di identifikasi dari perilaku databasenya, misal: 1. apakah traffic yang rame itu traffic WRITE apa READ ? tipikal database system tidak berimbang, kebanyakan sih READ nya lebih banyak daripada WRITE nya. Kalau polanya begini, clustering mungkin agak overkill, buat aja master-slave replication. WRITE ke master, READ nya di sebar ke semua slave. Yang perlu identifikasi lagi, seberapa REAL TIME kebutuhan informasi nya ? kalau harus real time ya berarti update di master harus 'transactional' di replicate ke slave, load traffic antara master ama slave agak berat, tapi kan bisa di buat dedicated. Pasang gigabit khusus antara master ama slave tidak boleh ada yang lain. Kalau nggak terlalu perlu real time, boleh ada delay, bisa di synchronize pas traffic agak longgar, misal jam 3 pagi. Asumsi nya, traffic yang super super banyak itu tidak terjadi 24 jam sehari 7 hari seminggu dan 365 hari setahun (atau 366 kalau tahun kabisat :). Intinya, kenali perilaku database kita, sesuaikan solusinya. Mungkin, untuk aplikasi seperti banking asumsi WRITE less than READ tidak berlaku ya. Pendekatan selanjut nya lebih feasible. 2. kalau system nya sedemikian besar, tapi ini pendekatan dari software yang menyimpan ke database, bukan databasenya an sich, system nya di partisi! Maksud nya, kalau memang terlalu besar untuk menyimpan data HR dan finance di satu tempat, kenapa tidak dipisah jadi 2 database, beda physical system dan jaringan, dan bikin bridge aplikasi untuk menjembatani kebutuhan referensi data. Day to day transaksi kan HR dan Finance misal nya tidak terlalu sering saling tergantung. Kalau HR kantor pusat dan cabang terlalu besar, kenapa tidak di pisah saja ? kalau sudah longgar, di merge. Orangkan tidak selalu ngolah data HR kantor pusat dan cabang *berbarengan*. Partisi, delegasikan load! Intinya, kenali perilaku system / software kita, delegasikan load nya. Pendekatan ini agak sudah kalau system nya sudah jadi, dan posisi kita 'cuma' DBA, tidak dalam kewenangan menentukan software development policy 3. tentu saja, tool bawaan DBMS nya untuk meng identifikasi bottleneck nya dimana fardhu atau wajib hukumnya untuk di gunakan dulu untuk tune up. Oracle kayak nya ngasih info lengkap banget dimana saja bottle neck dari database kita. Gak tahu yang lain . 4. hardware nya super super high end ? ;) kecuali kita kerja di NSA nya amrik (no cush agency :), pokok nya tempat nongkronya dedengkot IT negeri paman sam), asal ada dana, percaya deh, kita masih bisa upgrade hardware kita ke level *higher* end! Salam, Tri -----Original Message----- From: diditdr [mailto:[EMAIL PROTECTED] Sent: 06 Juni 2006 11:08 To: tanya-jawab@linux.or.id Subject: Re: [tanya-jawab] sorry oot soal DB nih Mirza Khadnezar wrote: > ada cara ? > seperti clustering DB ? > atau sejenisnya ? > > On 6/5/06, Mirza Khadnezar <[EMAIL PROTECTED]> wrote: >> udah dari segi H/W dah super high end server deh >> >> >> On 6/5/06, m Ilhami <[EMAIL PROTECTED]> wrote: >> > On 6/5/06, Mirza Khadnezar <[EMAIL PROTECTED]> wrote: >> > > gini ada 3 server >> > > dengan traffic super super super banyak >> > > ada yang bisa bantuin selain clustering DB ? >> > > -- FAQ milis di http://wiki.linux.or.id/FAQ_milis_tanya-jawab Unsubscribe: kirim email ke [EMAIL PROTECTED] Arsip dan info milis selengkapnya di http://linux.or.id/milis
