Aditya Indra Pramana - PENS

Q: Bilamana database Server ada di Kota Jakarta dan di Kota Surabaya, dan user yang berlokasi di Surabaya dan ingin mengakses server di Surabaya, namun tidak dapat diakses melainkan harus mengakses Database yang di Jakarta, pertanyaannya adalah bagaimana cara mengoptimasi database server di Jakarta agar user yang di Surabaya dapat mendapat respon dengan cepat dan server yang di Jakarta dapat memproses request dari user yang di Surabaya?

A:

1. Geographical load balancing kita tidak dapat memperbolehkan user dari kota A mengakses kota B secara langsung, namun bilamana kasusnya emergency maka dapat dilakukan setup tertentu. Contoh kasus Emergency adalah ketika Server di Kota B mati, sehingga harus di-route semuanya ke kota A yang membackup layanan dari Kota B.
2. Yang harus dihindarkan jika menggunakan automatic route, adalah: Bila Server di Kota B tidak jalan/mati namun ternyata sebenarnya tidak benar mati, hanya karena masalah jaringan yang intermitten saja, Maka user akan mengakses data Kota B yang ada di Server Kota A mengakibatkan adanya potensi deadlock. Karena Data Kota B tersebut diakses dari 2 sumber (dari replikasi kota B, dan user Kota B).
3. Proses update tidak perlu realtime, karena kebutuhan report dimasing-masing server bersifat lokal sesuai dengan domain usernya. Sementara Report yang bersifat menyeluruh umumnya dilaksanakan pada saat setelah End of Day, atau setelah dilakukan konsolidasi.

Ruben - FIF

Q: Apa fungsi load balancing jika ada data master di masing masing kota berbeda?

A:

1. Load balancing yang dimaksud disini adalah Load Balancing berdasarkan geografis, umumnya disebut GLB (Geographically Load Balancing), dapat di-enable dengan menggunakan DNS, Manual atau mekanisme lainnya, dan database harus mendukung Multi-master atau Active-active replication.
2. Data dimasing-masing Kota sama, tidak berbeda. Namun user yang mengakses data tersebut berbeda-beda setiap kota. Data pada masing-masing kota memang pada waktu yang sama dapat berbeda, karena ada update di masing-masing kota yang belum tersinkronisasi ke kota lainnya. Namun hal tersebut tidak menjadi masalah sebab data yang di update dari satu kota ke kota lainnya tidak dipergunakan secara realtime.
3. Pemecahan beban menjadi 3 kota ini ditujukan agar sistem berjalan dengan baik dan investasi perangkat tidak mahal (membeli 3 server lebih murah daripada membeli 1 server dengan spek 3x lipat lebih tinggi). Dengan adanya Multi-master / Active-active Server tersebut maka data dapat saling terupdate sehingga proses konsolidasi lebih mudah dan cepat. Termasuk Management Executive Report.

Ruben - FIF

Q: Kalau kita menggunakan data master yang berbeda bagaimana caranya load balancing membagi session sesuai dengan kebutuhan user?

A: Tidak perlu ada load balancing yang membagi session, load balancing dalam hal ini berdasarkan geografis yaitu biasanya menggunakan DNS. secara aplikasi tidak terjadi load balancing, load balancing ini berdasarkan sudut pandang management.

Andi Abdul

Q: Apakah datawarehouse bisa menjadi solusi dapat menjadi solusi agar menyatukan database agar dapat diakses seluruh region?

A: Datawarehouse adalah repository yang besar dan dapat menampung data dengan waktu yang lama. Datawarehouse baik bila digunakan untuk reporting namun tidak dapat digunakan untuk OLTP/ transactional, Penjelasan diatas (sebelumnya) memang diarahkan untuk kebutuhan transaksi / Data Warehouse/OLAP, sehingga tidak dapat menggunakan Data Warehouse.

Pak Hero - PENS

Q: Untuk melakukan mendesain desain server maka ada fungsi CDN untuk membantu mempercepat prosesnya apa nama fungsi yang sama untuk mendesain database server?

A:

1. CDN (Content Delivery Network) yang dimaksud dapat disebut juga dengan Reverse Proxy atau Front-end Cache, dimana ada penyimpanan data statis didepan Server yang diharapkan dapat mempercepat proses pengambilan data. Hal ini melanggar prinsip C (Consistency) dalam ACID, dimana data yang seharusnya dinamis menjadi statis.
2. Database Server tidak cocok menggunakan Front-end Caching seperti itu, karena ada potensi pelanggaran prinsip C (Consistency) dalam ACID, data yang seharusnya dinamis dan konsisten sesuai dengan perubahan yang terjadi menjadi tidak konsisten karena adanya independent data caching yang tidak sinkron dengan perubahan atau dinamisasi data pada database server.
3. Database Server (dalam hal ini PostgreSQL) memiliki kemampuan caching data secara internal, secara umum, penggunaan Database Server PostgreSQL untuk Transactional berjalan cukup cepat karena pada dasarnya hampir semua data yang dibutuhkan sudah ada didalam memori sehingga dapat juga disebut bekerja In-Memory.
4. Jadi tanpa harus dilakukan Front-end Caching pun data yang dinamis itu sudah dapat diambil dengan cepat, saran kami gunakan Clustering Report untuk proses pengambilan data yang massif.
5. Aplikasi dapat melakukan data caching secara internal dan ini baik sebab Aplikasi memiliki kewenangan dalam memanipulasi data dan tahu kapan harus melakukan update data tersebut.