1. Hardisk dr IDE ke SCSI/SATA
2. Memory yg gede
On 6/6/06, mastri <[EMAIL PROTECTED]> wrote:
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
--
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
