Yang harus di hindari pada saat memakai replikasi berbasis trigger dengan rubyrep

  Hallo semua, rubyrep lagi. Saya akan sharing sedikit mengenai bagaimana applikasi yang kita buat berinteraksi dengan rubyrep. Setelah sekian lama menggunakan rubyrep dan menemui beberapa kendala, crash, macet, proses yang lambat, proses yang cepat sekali, akhirnya saya dapat mengetahui beberapa karakteristik dari applikasi kita yang mempengaruhi kinerja dari rubyrep.

Didalam applikasi yang kita buat, terdapat beberapa teknik pemrograman yang membuat replikasi berbasis trigger menjadi berat kerjanya, yakni :

  1. Delete-Insert dibandingkan Update.
    • Proses ini terjadi pada saat kita update suatu Dokument, dimana dokumen ini di disimpan dalam 1 tabel master, dengan 2 atau lebih tabel detail.
    • Teknik pemrograman yang kita pakai pada saat update dokumen adalah update tabel master, delete semua tabel detail, dan insert ulang semua tabel detail.
    • Pada saat kita masih menggunakan 1 Database, teknik (delete-insert) ini adalah pilihan yang sangat tepat dibandingkan dengan teknik (update).
    • Tetapi saat ini, dengan replikasi berbasis trigger teknik tersebut sudah tidak cocok lagi, mengapa ? karena dengan melakukan proses delete dan insert maka record yang di replikasi akan 2x lebih banyak di bandingkan dengan update. Ini yang kita alami, sehingga dengan melihat lalu lintas data yang di replikasi dapat dikatakan teknik ini memakan sumber daya energi yang lebih banyak di bandingkan teknik update.
    • Solusinya adalah menghindari teknik delete-insert dan beralih ke teknik update.
  2. Hindari Variable Karakter sebagai primary key
    • Rubyrep tetap akan mengenali primary key tersebut,  tetapi karena tipe datanya adalah variable karakter maka spasi, karakter yang unik unik pun akan tersimpan.
    • Sehingga pada saat proses replikasi, karakter unik tersebut dapat mempengaruhi Rubyrep.
    • Dalam kasus kita, kita sering menemukan spasi diakhir data kita dan ini mengakibatkan Rubyrep gagal mengupdate ke server yang lain, sehingga prosesnya terhenti.
    • Solusinya adalah merubah applikasi agar spasi tersebut dapat hilang atau hindari tipe data ini sebagai primary key.
  3. Perhatikan field Auto Increment sebagai primary key
    • Field jenis ini umumnya memakai tipe data Auto Increment, Serial, Sequence, Auto numeric, dan sejenisnya.
    • Perhatikan bagaimana replikasi berbasis trigger menangani field jenis ini, karena anda melibatkan lebih dari 1 server, sehingga field auto increment harus dapat menghasilkan data yang berbeda untuk setiap servernya.
    • Jika anda memakai sequence anda bisa menambahkan suatu kode di depat nomor sequence yang di generate.
    • Kalau saya pribadi berusaha menghindari field jenis ini agar tidak ribet, lebih enak membuat data secara manual sebagai primary keynya.
  4. Besar byte per record dalam satu tabel
    • Semakin besar byte per record dalam satu tabel maka semakin berat juga kinerja replikasi dalam proses membandingkan datanya.
    • Penggunaan memori akan meningkat dan kecepatan replikasi akan menurun adalah efek samping yang timbul jika kita mengabaikan hal ini.
    • Menurut pengalaman saya 25 kolom dalam bentuk varchar(256) cukup berat untuk di proses.
    • Jika memang kita harus mereplikasi tabel jenis ini, kita harus mengatur jumlah record yang harus di baca oleh rubyrep.

Author: Nareswara

Ordinary People with eye glasses

Leave a Reply

Your email address will not be published. Required fields are marked *