Ariawan Pramadi

Q: Apakah ada perbedaan dari PostgreSQL yang sekarang dengan Database Enterprise yang biasa dipakai Corporate atau perusahaan besar seperti Oracle atau MySQL ?

A: Syarat Database dapat dikatakan berkelas Enterprise adalah memenuhi ACID (Atomicity, Consistency, Isolation, and Durability) yang sudah terpenuhi oleh PostgreSQL, sedangkan MySQL tidak memenuhi ACID secara 100% sehingga belum dapat dikatakan sepenuhnya berkelas Enterprise. PostgreSQL sudah memiliki ACID dan RAS, adanya replikasi secara native, dukungan untuk terjadinya backup dengan baik, bisa dilaksanakan PITR (Point in Time Recovery) yang mana melibatkan snapshot dan environmental backup. Scalability dapat dilakukan dengan mudah di PostgreSQL dengan menambahkan partitioning, reliability, dan security sudah terbukti dapat dijalankan dengan baik, begitupun dengan performance-nya. Karena PostgreSQL bersifat Open Source maka kita memiliki source code nya sehingga kita dapat memodifikasinya selama memahami source code tersebut. Semua versi PostgreSQL sudah berkelas Enterprise dan dapat dengan mudah melakukan Scalability.

Mumbere Kayange Remacle

Q: Bagaimana tips untuk mengantisipasi bencana alam seperti gempa, banjir, kebakaran yang dapat menyebabkan kerusakan/kehilangan data pada server ?

A: Tidak perlu khawatir tentang itu, karena sudah didukung oleh PostgreSQL. Secara umum ada konsep BCP (Business Continuity Planning) bilamana kita melakukan implementasi dalam 1 Data Center. Tentunya dalam 1 Data Center implementasinya tidak hanya dilakukan di local Data Center, tetapi juga diperlukan 1 backup di tempat lain yang biasa disebut dengan DRC (Disaster Recovery Center). DRC menjadi second Data Center yang menjadi Backup Data Center utama. Bilamana terjadi force majeure, semua sistem tersebut dapat dipindahkan ke DRC. Sistem yang dipindahkan ke DRC bukan hanya Database, tetapi juga dengan aplikasi, dan infrastrukturnya. Untuk tetap dapat menjamin continuity dari bisnis tersebut, pada PostgreSQL juga di enable-kan replikasi, sehingga kita dapat membangun bukan hanya replikasi HA di sisi Data Center, tapi cascading replication dari Data Center utama ke DRC yang berjalan secara realtime.

Asromi Romi

Q: Bicara HA, DR, misal main DB PostgreSQL run di Data Center DR On Premise gedung Kantor. Apakah bisa dibuat master-master? sama-sama bisa diakses dengan tetap data sync.

A: Berbicara replikasi, pada dasarnya replikasi bukan sebagai master to master, Diperlukan persamaan persepsi master to master. Di dalam PostgreSQL terdapat istilah Hot Backup. Pada 2 Database master dan standby, Hot Backup yang dimaksud disini adalah Database Standby. Dimana sebetulnya replikasi ini bersifat sebagai backup. Disebut dengan Hot karena dapat dibaca, diakses, dan di select. Bilamana terjadi masalah di master, kita dapat menaikan Database standby ini menjadi master.
Dalam konsep HA pada dasarnya standby tidak boleh diakses. Bilamana ingin diakses kita dapat membuat suatu replikasi lagi yg disebut dengan replika, dimana Database replika dikhususkan untuk dapat diakses oleh aplikasi-aplikasi yang lain. Ketika ingin di-hit maupun di-query terus menerus, tidak akan menjadi masalah. Tetapi disini Database Replika bersifat read only.
Jadi kalau keduanya bersifat dapat diakses, tentu dapat diakses. Tapi kalau yang dimaksud master and master, hanya bersifat read-write atau read, tidak bisa keduanya. Tetap hanya 1 instance saja yang read-write.
Jika kita bicara 1 data center, kemudian bagaimana caranya membuat DRC nya ?
Kita bisa menerapkan replikasi yang sama yaitu cascading replication ke DRC. Sehingga database master masih bisa diakses oleh aplikasi secara otomatis langsung direplikasikan ke master di DRC. Bilamana Data Center utama down, kita dapat langsung mengaktifkan saja.

Megat Kurniawan

Q: Selama pengalaman Equnix menggunakan PostgreSQL. Apakah pernah terjadi inkonsistensi data antara Master dengan Standby/Replica? Jika ya, apa yg menyebabkan hal tersebut terjadi?

A: Hal-hal yang mempengaruhi adanya perbedaan data diantaranya adalah network, adanya kelambatan di sisi storage database standby, dan resource sibuk atau lebih kecil daripada master. Bisa resource memori atau resource CPU, yang paling mempengaruhi adalah storage. Replikasi akan menjalankan transaksi di master kemudian menuliskan WAL, dan WAL record inilah yang akan di replikasikan ke Database replika. Di Database replika ini baru akan melakukan replay atau recovery. Pada dasarnya replikasi adalah recovery yang berjalan tanpa berhenti. Jika instance nya mati kemudian di start, dia akan tetap melakukan recovery dengan mereply dengan WAL nya, dan akan selesai pada titik tertentu. Kemudian ketika proses replay ini ternyata storage nya lambat, artinya proses penulisan pun akan melambat. Kalau ada transaksi yang sudah berjalan, memungkinkan sisanya masih dalam perjalanan. Pada PostgreSQL memiliki 1 view untuk bisa memonitor status dari replikasi. Biasanya yang terjadi kalau ada data yang berbeda adalah karena proses replay nya yang lambat. Hal tersebut disebabkan oleh fullnya resource yang kemungkinan sedang dibaca oleh 1 aplikasi lain, ada querynya, ada lag-nya, atau adanya storage sedang tinggi penggunaanya sehingga menimbulkan inconsistency. Inconsistency sebenarnya bukan secara datanya yang berbeda, tapi secara proses replay dari transaksi tersebut yang mungkin direplikanya ini belum selesai. Namun pada akhirnya nanti, kondisi data antara Database master dan Database replikanya akan sama.

Diah Winarni

Q: Kenapa setiap beda versi PostgreSQL terkadang tipe data yang lama tidak mendukung di pakai atau berubah misal versi sebelumnya jsonb versi diatas yang mendukung nya json yang sehingga mempengaruhi stored procedure ya?

A: Bicara mengenai forward compatibility dan backward compatibility. Untuk data jsonb untuk PostgreSQL versi sebelum 9.4 memang belum mendukung. Tetapi PostgreSQL selalu menjaga tipe-tipe data yang sudah ada, storage from 9.4 sudah ada json dan 9.5 ada jsonb, kedepannya tetap akan ada jsonb. Mungkin bila boleh dielaborasikan lebih lanjut, tipe data apa yang mungkin berbeda? Contohnya PostgreSQL 14 dihapus tipe datanya, dan tetap forward compatible.

Megat Kurniawan

Q: Jika dipertimbangkan dari faktor cost dan performance. Apakah OS untuk server yang disarankan Equnix Linux atau Windows?

A: Tentu saja Linux, Karena kita bicara cost dan performance. Saat ini hampir semua bidang seperti telekomunikasi, bank, dan lainnya sudah menggunakan Linux. Adapun jika dilihat dari segi performance dan ability untuk tuning maka lebih baik menggunakan Open Source.

Mashum Abdul Jabbar

Q: Seberapa penting Indexing dalam Database, kapan butuh dan tidaknya kita menyiapkan Indexing. Bagaimana implementasinya di PostgreSQL?

A: ndexing merupakan salah satu bagian yang dapat kita lakukan untuk meraih performance dengan baik. Karena indexing adalah salah satu bagian dari tuning. Indexing penting sekali. Indexing sangat membantu untuk data yang cukup besar, bervariasi, dan memiliki query yang kompleks. Dalam PostgreSQL terdapat sekuensial scan dan index scan. Sekuensial scan adalah pencarian data paling awal hingga pencarian data yang ingin dicari, sedangkan index scan adalah pencarian berdasarkan acuan yang ada di dalam Database. Index ini dapat dianggap sebagai object dalam Database. Ketika membuat atau mengakses index, tetap membutuhkan memori dan kalkulasi. Index di PostgreSQL disebut dengan BTree (Balance Tree). Dimana ketika melakukan proses index scan, pada tree juga di load ke memori dan akan diproses. Index sangat berguna dalam melaksanakan tuning dan performance, tetapi pembuatannya pun harus disesuaikan dengan query-query yang sedang berjalan. Ketika membuat index akhirnya tidak terpakai, akan membuat boros resource. Karena index tidak akan disimpan kedalam file. Index dalam Database replikasi akan tetap direplikasikan, sehingga tidak perlu membuat index lagi.

Denny Rizky

Q: Terkait proses indexing Database apakah support untuk dilakukan di semua tipe Database? serta jika dilihat dari sisi security sendiri adakah efek secara langsung yg dapat ditimbulkan dari proses indexing ini?

A: Indexing merupakan bagian dari SQL ANSI dan ini juga merupakan conformance, dimana RDBMS harus bisa diindex. Proses indexing tidak berpengaruh ke security tapi lebih ke arah performance. Proses indexing ketika dia harus membuat BTree tersebut apalagi dengan jumlah data jutaan, tentunya di akan take-up resources. Dan bilamana ada transaksi yang sedang berjalan bisa sedikit mempengaruhi transaksi tersebut. Transaksi-transaksi yang masuk dapat diabaikan dahulu karena sedang ada indexing. Proses indexing jika bisa dilakukan production sebaiknya ketika low peak hours. Karena akan mempengaruhi transaction performance. PostgreSQL memiliki concurrent index, proses ini akan mengalah daripada transaksi-transaksi yang sedang berjalan. Transaksi akan diprioritaskan dahulu, sehingga proses creation index nya akan menjadi lebih lama.

Asromi Romi

Q: Berapa IOPS yang ideal untuk running PostgreSQL Production untuk transaksi yg tinggi ?

A: Secepat mungkin. Mengapa demikian? Karena kita memiliki transaction journal/ WAL, dan yang utama dalam PostgreSQL untuk menjalankan atau menerima beban yang tinggi adalah WAL. WAL adalah notes yang berisi jurnal-jurnal dan semua transaksi yang masuk tentunya akan diletakkan dahulu di dalam memori (Buffer). Buffer ini juga secara langsung akan dituliskan didalam WAL file nya. Jadi ada 2 komponen utama yaitu WAL sebagai transaction lock, dan base data directory nya. Ketika transaksi sudah diteruskan ke dalam WAL tidak langsung dituliskan ke base, sehingga yang perlu dipentingkan adalah storage untuk WAL. Jika ternyata memiliki IOPS yang terlalu kecil, maka akan mempengaruhi performance dengan sangat signifikan. Maka dari itu Equnix rekomendasikan menggunakan NVMe yang terbukti memiliki storage tercepat. IOPS untuk NVMe ini yang akan digunakan untuk WAL tersebut. NVMe juga sejauh yang saat ini bisa mencapai 7 GBps. Hal ini dapat memboosting performancenya PostgreSQL dengan sangat baik

Aji Prakorso

Q: Bagaimana cara delete pg_wal yang tepat apabila kita punya slave?

A: Idealnya WAL itu jangan di delete secara manual. Karena PostgreSQL memiliki 1 checkpoint. Setiap transaksi akan dituliskan dalam WAL File. PostgreSQL memiliki catatan terakhir kali WAL mana yang sudah di flush ke basedir? artinya checkpoint yang paling konsisten. Misal dia ada di WAL AF maka WAL-WAL yang belakangnya sebetulnya sudah obsolete atau tidak dipakai lagi. Jika mau di restart, dia akan selalu me-replace AF. PostgreSQL memiliki housekeeper dimana WAL-WAL yang sudah tidak relevan lagi, dapat di rotate atau di rename ke WAL baru lainya. Ada 1 tool PostgreSQL yaitu pg_control_data dimana kita dapat mengetahui titik PostgreSQL, dimana checkpoint nya paling konsisten. Ada pula WAL archiving yang dapat memberitahukan pada PostgreSQL WAL mana yang sudah committed, aman, sudah di replay oleh Database direktori dan di backup ke tempat lain.

Gadael Sedubun

Q: Apakah PostgreSQL bisa digunakan untuk menyimpan BLOB (Binary Large Object) file seperti JPEG?

A: Blobfile bisa disimpan dalam Database, namun tidak direkomendasikan. PostgreSQL memiliki 1 tipe data yang mendukung yaitu bytea. Lalu jika kita bicara performance, blob file sebaiknya tidak disimpan dalam DB, karena kita bicara tentang storage penyimpanannya seperti apa, dan ketika kita select dari tabel tersebut dan ternyata tabel tersebut punya data yang besar sekali, maka table tersebut akan toasted (terbelah/terkompres). Pada skema toast ini nanti akan dipecah pecah lagi menjadi beberapa tabel berikutnya untuk menyimpan data yang terlalu besar, sehingga jika kita select dia akan join terus ke table-table toastnya yang lain. Jika kita menyimpan data berformat JPEG simpan saja path nya di dalam DB, dan file tetap disimpan diluar DB.

Ade Sapto Saputro

Q: Untuk replikasi, apakah di PostgreSQL bisa clustering (Rewrite-Rewrite) atau lebih baik master - slave?

A: Untuk read-write and read-write sebenarnya tidak bisa. Untuk replikasi tidak bisa master-master juga karena master-master memiliki banyak constraint- nya.