Tech Talk: Optimasi Query

Melanjutkan tech talk kemarin, perkenankanlah saya menyambungnya dengan membahas optimasi lebih detail lagi, yaitu ke level database dan pemrograman. Oh iya, sebagai catatan, optimasi di sini adalah berdasarkan pengalaman dan diskusi internal, mungkin belum benar-benar optimal sehingga saya harap mendapat masukan dari pembaca. Dalam kasus ini, kami menggunakan database server MySQL dan pemrograman PHP.

Oh iya, posting ini juga dimuat di studewo.com sebagai arsip.

Menggunakan mysqli

PHP telah menyediakan function untuk koneksi ke database baik secara prosedural mau pun secara obyek (class). Namun dengan berkembangnya waktu & teknologi, beberapa function telah usang dan mulai ditinggalkan karena telah ada function yang lebih baru dan lebih baik.

Kalau dahulu kita mengenal pustaka (library) mysql_xxx, maka sekarang sudah digantikan dengan mysqli_xxx (mysql improve). Jadi lebih baik mulai menggunakan library mysqli_xxx. Lebih baik lagi jika memigrasikan aplikasi yang masih menggunakan mysql_xxx ke mysqli_xxx.

Berita baiknya, cara penggunaan librari mysqli_xxx mirip dengan mysql_xxx. Dan php tetap menyediakan 2 cara penggunaan, yaitu metode prosedural mau pun obyek (class).

Iklan

Mulai Belajar Cluster MySQL

Saat ini kami sedang memulai belajar membuat cluster MySQL. Kami membuat cluster ini karena ingin meningkatkan kinerja database sekaligus meningkatkan reliabilitas-nya. Tadinya mau experimen di Pekanbaru, tapi karena terkendala waktu saat saya berkunjung ke sana, maka experimen dilakukan di Bekasi. Jika berhasil baik, maka model cluster MySQL ini akan diterapkan di semua RS.

Kami pun menyiapkan 4 buah PC untuk experimen. 4 PC ini hanya ditenagai prosesor Atom dengan RAM 2 GB dan hanya menggunakan USB sebagai media penyimpanannya. Jika dapat berjalan baik, maka kami akan menggunakan 4 buah PC dengan spesifikasi yang lebih tinggi.

Berikut ini beberapa link penting:
~ MySQL Cluster NDB 7.2
~ Download MySQL CLuster
~ MySQL Cluster Quick Start for Linux
~ MySQL Cluster and Ubuntu 12.04

Ada yang pernah punya pengalaman menggunakan cluster MySQL dengan konfigurasi standard?

Database Replication

Backup database itu penting. Tetapi membuat file backup database saja tidak cukup. Walau pun backup dibuat secara otomatis di suatu periode waktu tertentu yang mungkin dilakukan beberapa kali dalam sehari, itu tetap tidak cukup.

Mengapa tidak cukup? Karena backup hanya membuat copy atas database pada posisi tertentu. Katakanlah backup dibuat pada jam 00:00, sebenarnya data yang tersimpan hanya sampai jam 00:00. Seandainya terjadi kerusakan data pada jam 11:00, maka semua transaksi yang dilakukan antara jam 00:00 sampai jam 11:00 akan hilang. Terpaksa user harus memasukkan ulang transaksi antara jam 00:00 sampai jam 11:00 setelah backup di-restore. Bayangkan jika transaksi yang terjadi sangat banyak atau jika transaksi tidak memiliki bukti fisik seperti struk/nota transaksi. Memasukkan ulang transaksi bisa membuat user frustasi. Apalagi jika transaksi ini harus dilakukan urut lantaran sifat transaksinya panjang untuk 1 account sesuai dengan alur bisnis perusahaan. Jika ada transaksi yang tidak ter-input, maka perusahaan atau pelanggan bisa rugi.

Untuk itu perlu dibuat replikasi database. Topologinya adalah ada 1 master server dan minimal 1 slave server. Setiap kali master server melakukan transaksi, maka slave server akan melakukan transaksi yang sama. Jadi posisi database slave akan sama dengan master. Tentu ada delay beberapa waktu. Tetapi delay ini tidak terlalu membahayakan karena relatif cepat. Kalau pun slave mati, dia akan kembali melakukan sinkronisasi ke master pada posisi terakhir dia sinkronisasi. Slave akan mengejar transaksi master sehingga posisinya akan mendekati posisi transaksi di master.

Unique Key yang Tidak Unique

Ini adalah salah satu tantangan kami secara teknis berkaitan dengan database. Suatu saat kami mencatatkan header transaksi dengan autogenerated number yang merupakan fitur natif dari database. Field bertipe big integer ini menjadi Primary Key untuk relasi ke tabel detail atau tabel lain yang berelasi. Semua baik-baik saja.

Keadaan berubah saat ada beberapa divisi memerlukan penomeran yang lebih mudah dibaca (readable). Beberapa divisi ini menginginkan penggunaan prefix untuk membedakan dengan transaksi dari divisi lain. Misalnya divisi penjualan umum menggunakan prefix “FU”, penjualan rawat inap dengan prefix “FI” dan penjualan rawat jalan dengan “FJ”. Ditambahkan lagi prefix berdasarkan waktu transaksi sehingga formatnya menjadi “FJ1208xxxxx” untuk penjualan rawat jalan.

Dengan penomeran model begini user bisa dengan cepat mengidentifikasi transaksi tersebut dari divisi mana dan terjadi pada tahun dan bulan berapa.

Beberapa divisi lain juga menginginkan hal yang sama, misalnya divisi Laboratorium dan Radiologi. Sedangkan divisi lain tidak memerlukan fitur penomeran readable ini. Jadi divisi lain tetap menggunakan Primary Key. Sedangkan beberapa divisi menggunakan TrxID.