Hi all, Saya saat ini sedang mengembangkan sistem informasi berbasis web. Data yg akan diolah sangat besar, sekitar 50 juta record (dan terus berkembang). Load transaksinya juga lumayan tinggi, sekitar 400-500 concurrent hits. Untuk saat ini saya menggunakan database mySQL dgn engine myISAM dgn harapan bisa melayani transaksi dan data dgn cepat. Struktur database dan aplikasi telah saya rancang sedemikian rupa untuk optimasi kecepatan. Dalam beberapa hal, terpaksa saya mengorbankan constraint database, walaupun tetap dijaga di level aplikasi. Namun demikian, saya masih merasa mySQL cukup "keteteran" juga dgn jumlah data dan load transaksi seperti di atas, terutama saat bulk data processing. Proses bulk data, krn alasan tertentu, tidak bisa dihindarkan walaupun tidak terlalu sering. Saya udah coba pindah database server ke DB2, PostgreSQL, dan Firebird, tapi ternyata hasilnya juga gak jauh berbeda. Dalam beberapa hal, mySQL masih lebih cepat. Saya mohon saran dan masukan dari rekan2 semua, yg mungkin pernah punya pengalaman dgn sistem yg serupa dgn yg saya bangun di atas. Kira2 alternatif database server apa yg mampu menangani load transaksi dan jumlah data seperti yg saya sebutkan di atas? Syukur2 kalo performance tetep bagus tanpa mengorbankan constraint database. Beberapa teman menyarankan untuk mencoba Oracle 10g. Tapi krn saya belum pernah berurusan dgn Oracle, saya juga mohon masukan juga dari rekan2 yg pernah menggunakan Oracle. Atas saran dan masukannya, sebelumnya saya ucapkan terima kasih.

wah walaupun diriku masih awam tentang ini tapi aq mo ngucapin makasih ke cyber_hecker yang dah ngasih tips2 yang sangat bermanfaat.

data 50 jt itu apanya??? transaksinya apa masternya juga??? wew kalo masternya juga perushaan apa itu 50jt record..... kalo gua saranin 2 database deh... kalo bukan ms sql server 2005 atau oracle 10 g.... gua buat program untuk toko biasa paling mentok transaksinya 1jt record... itupun udah banyak.... wew servernya harus kuat... ahahahaha..... kalo kayak saya bilang bukan sesuai dengan CH bilang masalahnya bentuk laporan biasanya di minta sama pemilik... kita harus memikirkan supaya jadi laporan itu... mau pake like pake join... itu tergantung situasi masalahnya gak ada lagi jalan ya terpaksa pake itu.... wkwkkwkwkw.... :lol: :lol: :lol: :lol: kalo data besar mikirkan data mining sama data werehouse.... kalo udah gede gini gak peduli storage besar yang penting aksesnya cepat....

nambahin ya : 1. lakukan tuning MySQL (ada di ebook diriq lupa judulnya apa xixixix) 2. gunakan index, peng-indekan akan mempercepat akses bahkan mpe > 50% 3. lakukan optimasi query (join dll) 4. Normalisasi tabel 5. Relasi dengan constraint integrity 6. klausa WHERE ... LIKE .... bisa diganti dengan MATCH(...) AGAINTS(...) gunakan FULLTEXT index dlm hal ini. 7. dll ada yg mo nambahin hehehe semoga bermanfaat, ganbate kudasai!!

Hmm.. kalo untuk DB dengan jumlah data besar, Anda perlu melakukan berbagai tuning dan optimalisasi, Indexing, bla bla bla, seperti yang sudah diungkapkan oleh beberapa rekan sebelumnya. Anda perlu menggunakan DBEngine kelas traktor, mungkin Oracle bisa jadi pilihan, atau bisa dicoba MaxDB (walaupun yg ini saya belum pernah coba) Sebenarnya DBServer tersebut untuk apa dulu, jika untuk transaksai, constraint cukup penting, walaupun tidak mutlak, tapi kalo untuk reporting, data warehouse.. segala macam constraint, relasi, trigger, normalisasi, dsb harus seminimal mungkin Anda hindari, gunakan model Flat dan DBEngine yang super kenceng. selain software, Anda perlu memperhatikan faktor hardware dan konfigurasinya. RAM nya harus besar, I/O nya juga harus cepat. Kalau perlu pake model Load-Balancing, master-slave atau clustering.

@deLogic: Betul. Saya dan tim udah profiling, gonta-ganti setting/konfigurasi, optimasi, dlsb... tapi kayaknya memang harus upgrade hardware, terutama memory. Tapi, solusi sementara udah ada. Duh, harus berurusan ama duit (lagi) deh, males banget sebenarnya. :( Anyway, thanks atas masukan dan saran dari semua rekan.

bro simba udah gunakan RAM berapa besar? ini basic & harus terpenuhi terlebih dahulu. jenis RAM juga harus se-level utk RAM kelas cluster server. (10x lipat lebih mahal) data yang 50 jt record tersebut benar seperti om deLogic bilang apakah bersifat static (master) atau transaksi? kebanyakan di perusahaan2 besar DB di partisi menjadi beberapa cluster (misal operator's customers data). misal 50jt record tsb adalah bersifat master maka data dipartisi menjadi minimal 2 buah computer (atau idealnya adalah sebanyak uniqe search index). haha... agak ekstrim memang, tapi mau ngga' mau seperti itu. cluster computers total at least "A .. Z / 2" :mrgreen: Oracle versi 10g sudah built-in support clustering, tapi konfigurasinya lumayan ribet...

waduh...waduh gak mudeng saya soal pembahasan sampe sejauh ini, emang benar kata orang ilmu di luar itu lebih banyak daripada ruang lingkup kampus, tapi dengan ini akan menjadikan modalku untuk besok...Thread ini berguna banget untukku.

he he... mumpung lagi pada mbahas ini, nitip masalah juga pada case gw, dikarenakan kondisi sedemikian rupa DB server dialihkan ke Oracle 9i sehingga opsi untuk fine tuning bisa lebih banyak : - menghilangkan constraint secara DDL (FK, UNIQUE) setuju, akan mempercepat DML secara bulk asal terdapat garansi bahwa constraint tetap bisa dijaga, baik dari modul program maupun konsistensi data itu sendiri. pertimbangan : meskipun klaim dari banyak DB Engine bahwa proses pengecekan constraint hanya memerlukan sedikit resource (memory, CPU Time), tapi tetap merupakan hal yang perlu dipertimbangkan untuk manipuasi data secara bulk - index dan reindex meskipun memakan waktu yang lama, hal ini sangat vital untuk tuning performa query select, lebih bagus kalo ditempatkan di schedule tengah malam, biar ga kelamaan nunggu - kalo bukan transaksional, jangan sungkan pake materialized view yang sudah di-denormalisasi untuk kepentingan searching n viewing, bisa dikombinasikan dengan cut-off data secara periodik (misalnya, data 1 minggu terakhir) - gunakan hint, semacam /+ PARALLEL / atau /+ USE_HASH / akan lebih optimal untuk lingkungan multiprosesor semacam server Sun Fire - fungsi/procedure yang berkaitan dengan bisnis proses jangan dibebankan ke PL-SQL DB server, mendingan di layer atasnya (java / php framework) - menggunakan Grid Computing, yang ini gw belon jelas, bisikan dari temen sebelah - jangan pake RAID, idem dg yang diatas - 1 keping memory 1 GB =kurang lebih 1 jt, kalo 10 GB ya 10 jt-an, bandingkan dengan manggil OCA / OCP yang 2.000 dollar sekali visit + konsulting + problem solving naaaah, masalahnya gw juga punya kasus yang sama... jumlah data, ya segituan lah... pertumbuhan 17 jt record per hari ketika user pengen bisa nampilkan grafik dari data tsb kurang dari 30 detik, point2 diatas ternyata belon memecahkan masalah juga :P ada yang punya saran lagi?