Can Enterprise use PostgreSQL?

PostgreSQL tidak sama dengan MySQL, MySQL secara kaidah sederhana mungkin bisa dianggap Open Source, tetapi dengan adanya restriksi lisensi dan pengembangannya yang dikendalikan dari satu Institusi saja, maka menjadikan MySQL memiliki risiko operasional yang berbeda dibandingkan dengan PostgreSQL. Saat ini sudah menjadi aturan yang tidak tertulis, PostgreSQL akan dipilih dibandingkan MySQL bilamana aplikasi tersebut terkait pada transaksi finansial. Disini dapat dipahami aturan ACID yang diimplementasi dengan baik menjadikan PostgreSQL sebagai database yang memiliki integritas yang baik dan memiliki tingkat kepercayaan yang tinggi dari para System Analyst maupun developer.

Saya kira pertanyaan terkait size provisioning SSD tidak berhubungan dengan HA atau Non-HA, panjang record tergantung pada struktur data yang dirancang, capacity planning didasarkan pada perhitungan kondisi stress test dan melakukan ekstrapolasi, atau dapat menggunakan cara lainnya selama memiliki justifikasi mengapa cara tersebut sesuai untuk digunakan. Setiap metode tentunya memiliki pertimbangannya masing-masing dan memiliki ranah penggunaan terbaiknya. Jumlah data yang berkembang dalam database tentunya tidak selalu ditentukan oleh desain aplikasi saja, tetapi juga kebiasaan pengguna (User behavior) yang perlu dicermati dan menjadi faktor penentu.

Betul, bisa dilaksanakan menggunakan Point-in-Time Recovery, di mana kita bisa melakukan replay terhadap snapshot backup yang di-replay dengan menggunakan Archived WAL, serta ketika melakukan recovery, dapat menentukan sampai tanggal dan jam berapa transaction perlu di-replay.

Sangat memungkinkan, dan Equnix sendiri sudah memiliki beberapa pengalaman dalam melakukan migrasi dari Oracle ke PostgreSQL dan berjalan dengan baik sampai saat ini. Salah satunya adalah Success Story di INSW, dimana sebelumnya menggunakan 4 Server Oracle yang dikonfigurasi menggunakan RAC, dan kemudian dimigrasikan ke single instance PostgreSQL dan dirasakan percepatan 3x lipat. Dari 4 server ke 1 server saja sebetulnya sudah bisa dibilang 4x percepatan, sehingga secara keseluruhan setelah dipindahkan ke Oracle, maka mendapatkan 12x percepatan.
Tentunya ketika mau melakukan migrasi, perlu dilakukan assessment terlebih dahulu, untuk menentukan tingkat compatibilitynya. Sebetulnya karena baik PostgreSQL maupun Oracle itu berasal dari akar yang sama, yaitu mereferensi paper yang dibuat oleh IBM Scientist Edgar F Codd dan Pat Selinger, maka secara konsep utamanya mirip, dan juga karena mengikuti standarisasi SQL ANSI, sehingga tingkat kompatibilitasnya cukup tinggi jika menggunakan query-query standard.

Singkatnya, ada reaksi tentunya muncul sebagai respon dari sebuah aksi. Bilamana tidak ada kebutuhan maka tidak ada solusi yang perlu dibuat untuk memenuhi kebutuhan tersebut. Ada beberapa aspek yang dapat diangkat sebagai referensi mengapa saat ini ada banyak sekali perusahaan menengah ke atas memindahkan databasenya dari Oracle maupun lainnya ke PostgreSQL. Beberapa di antaranya adalah: (a) Perubahan lisensi Oracle, sehingga akuisisi nya menjadi mahal, (b) Dukungan support expert yang cukup mahal, (c) Kebutuhan agar terlepas dari Vendor Lock-In, (d) Adanya concern untuk menggunakan software legal (masih banyak kalangan bisnis yang menggunakan software tidak legal hanya karena terlalu mahal membayar lisensinya) dan masih banyak sebab lainnya.

Saya kira, Database Open Source secara umum ada banyak, untuk RDBMS, sejauh kami memahami masih belum ada yang lebih baik dari PostgreSQL dilihat dari sisi kinerja, akuisisi penggunaan, keamanan, dll. Untuk yang NOSQL mungkin bisa mencoba menggunakan Apache Hadoop atau Cassandra.

Keamanan data dari sebuah database tidak hanya ditentukan oleh Database Server, dalam ruang lingkup Database, PostgreSQL memiliki fitur dan kemampuan yang sangat baik dalam menjaga integritas data seperti WAL, mengenai menjaga keamanan data terhadap unauthorize access, Postgres memiliki beberapa fitur seperti GSS-API, LDAP, dll. Singkat nya karena Open Source tidak berarti tidak aman, banyak sekali software yang berbayar (proprietary) yang justru lebih tidak aman dibandingkan PostgreSQL. Silahkan pelajari lebih lanjut.

Kerahasiaan data sebetulnya bukan domain database, lebih kepada domain dari aplikasi yang menggunakan database. Bilamana diinginkan menggunakan In Store Encryption dapat menggunakan beberapa pendekatan seperti TDE, CubeOne (Webinar ke 4 nanti akan dijelaskan) Storage based Encryption yang kesemuanya berada di luar domain tanggung jawab database. Tingkat securitynya tentunya tergantung pada tingkat security dari implementasi software tambahan tersebut. Topik security adalah topik yang kompleks meliputi beberapa aspek dari mulai legalitas, support, operational dan masih banyak lagi. Intinya untuk mendapatkan layanan database yang baik dan berkualitas harus memiliki vendor yang memiliki kompetensi yang cukup untuk hal tersebut.

HA tidak membutuhkan Replikasi Master-Master. Replikasi Master-Master umumnya digunakan untuk Geographical based Load Balancing. Support Replikasi Master-Master, didukung dengan beberapa teknologi, yang kesemuanya memiliki downside. Sama sekali tidak disarankan untuk mendukung HA. Ada Produk turunan PostgreSQL memiliki MMR (Multimaster Replication) yang menggunakan Logical reps atau Trigger, ada juga yang menggunakan cara lain. Secara native tidak ada dukungan Replikasi Master-Master pada PostgreSQL.

Untuk meng handle large data volume dengan yang lebih tepat menggunakan Deepgreen yang memiliki mekanisme Massive Parallel Processing, sehingga dapat menyimpan dan memproses data dengan lebih cepat dan dilakukan secara paralel. Silakan cek pada catatan Webinar kami yang pertama (https://equnix.asia/webinar)

Replication PostgreSQL, natively adalah bersifat active - passive, dimana Master akan mereplikasikan ke Standby yang tidak bisa di-write, tetapi bersifat read-only saja. Tentunya sangat mudah untuk dilakukan failover, karena cukup melakukan promote saja di sisi Standby, dan kemudian Standby akan dipromosikan menjadi Master.

Tentunya Equnix selalu melaksanakan QC terlebih dahulu untuk me-maintain dan menentukan apakah version yang terbaru ini perlu di-endorse atau tidak ke client agar dilakukan upgrade.

Bisa dan sudah terbukti, 2ndQuadrant dalam publikasinya menyatakan sudah pernah menjalankan PostgreSQL di atas Mainframe Z, dengan menggunakan sistem operasi LinuxOne (sistem operasi linux untuk Mainframe Z IBM). Bilamana Pak Ramadani tertarik, kita bisa PoC nya menjalankan PostgreSQL di atas Mainframe tersebut.

Jika dibanding dengan VM, maka akan lebih maksimal jika menggunakan Container, karena pada dasarnya di dalam Container tidak dilakukan virtualisasi, sehingga resource yang digunakan oleh PostgreSQL instance, sama seperti jika tanpa menggunakan Container. Seperti yang umumnya kita pahami Virtualisasi menyebabkan penurunan IO (slightly) sementara PostgreSQL adalah aplikasi yang sangat bergantung pada akses I/O sehingga penambahan latency di sisi tersebut akan teramplifikasi sehingga penurunan performanya cukup signifikan dibandingkan dengan menggunakan Container

Tuning bisa dilaksanakan di 3 level, yaitu hardware, server parameter, dan juga client-side. Tentunya harus dilakukan tuning di postgresql.conf, seperti contohnya yang berkaitan dengan memory yaitu shared_buffers, work_mem, effective_cache_size, dll. Dan tentunya juga dalam kondisi production, penggunaan query juga harus diperhatikan agar lebih efektif, seperti contohnya menghindari penggunaan OR, memanfaatkan JOIN dengan lebih baik, dll.

EDW yang dimaksud adalah Enterprise Data Warehouse dalam konteks OLAP, dan tentunya berbeda kepentingan antara OLTP dan OLAP, dimana pada OLTP yang diprioritaskan adalah writing transactions, sementara untuk OLAP yang diprioritaskan adalah untuk complex select, sehingga secara tuning behaviour pun berbeda, maka tidak bisa menggunakan 1 instance yang sama.
Secara umum bisa dilakukan, tetapi menjadi tidak maksimal untuk keduanya. Ada beberapa cara agar PostgreSQL dapat dijalankan pada beberapa Server sehingga dapat menampung data yang besar sekaligus tetap sebagai Database Transaksional, seperti menggunakan FDW, ataupun plugin pg_shard, tetapi sekali lagi pendekatan tersebut harus kita assess dan evaluasi baik-baik, agar sesuai dengan kebutuhan saat ini maupun dimasa mendatang.

Seperti yang sudah dijelaskan secara lisan oleh Pak Chris Travers, umumnya Global Tech Company memaintain source code nya sendiri yang juga disesuaikan dengan source code dari Open Sourcenya, dengan tujuan memiliki kontrol, dan memastikan implementasinya terjaga dengan baik, tentunya selain QC juga memiliki adanya custom extension yang disesuaikan dengan kebutuhan perusahaan tersebut.

Apakah dimungkinkan? Saya kira dimungkinkan kalau ada kerjasama atau memang menggunakan jasa perusahaan tersebut dalam implementasi dan penggunaannya. Perlu kita sadari, tidak ada yang benar-benar gratis di dunia ini, Open Source menawarkan kebebasan dalam pengembangan bukan penggunaan gratis. Bilamana ada perusahaan Global yang sudah menggunakan PostgreSQL dengan kustomisasinya sendiri dan kemudian mendistribusi ulang, tentu saja akan menjadi bumerang pada perusahaan tersebut, bilamana software yang didistribusikan tersebut ternyata membuat kerugian pada penggunanya, kecuali dinyatakan sebagai Open Source sehingga dengan sendirinya terhindar dari tanggung jawab.

Yes of course it is possible to create such function, and yet you have to call the function every time/every row, or you might want to use trigger with for each row execute procedure clause, so everytime insert is executed, before the data is inserted to the table, the procedure should be executed first.

Bergantung dari behaviour sistem itu sendiri, apakah melakukan intensive Read atau Write (Insert/Update)? Biasanya jika sifat dari aplikasi adalah intensive Write, karena transaction log yang dituliskan juga semakin banyak, maka bisa ditingkatkan terlebih dahulu IOPS dari storage yang digunakan untuk menyimpan WAL, seperti contohnya menggunakan NVME. Jika beban lebih banyak Complex Query, maka dapat dinaikkan terlebih dahulu CPU Clock kemudian RAM. Sebagai rule of thumb, CPU Clock yang tinggi adalah opsi utama yang harus dipilih bilamana kita ingin mendapatkan performa yang baik untuk sistem database yang memiliki update yang massive.

Tentunya indexing adalah satu hal yang perlu dilaksanakan, khususnya disesuaikan dengan where clause yang sering digunakan untuk melakukan query ke dalam data tersebut. Penggunaan index juga harus tepat, agar tidak banyak index yang unused.

Banyaknya Query tidak menyebabkan data hilang (lost), setiap transaksi yang sudah commit, akan tercatat dengan baik pada storage sehingga tidak akan hilang begitu saja, ada beberapa faktor data tidak dapat di query kembali, dan 90% permasalahan tersebut dari storage/ fisiknya bukan dari PostgreSQL, 9% dari setting parameter yang tidak benar atau tidak sesuai sehingga mendukung pelanggaran Durability (D pada ACID), seperti fsync off, dll.

Di dalam PostgreSQL tidak mengenal istilah atau konsep database suspect

Yaitu dengan memperhatikan terjadinya slow query. Slow query ini adalah sesuatu yang bisa menjadi indikasi awal terjadinya kelambatan dalam instance, sehingga sedapat mungkin perlu dilakukan optimasi baik dari sisi indexing, optimization query, maupun server side tuning.

Jika memang tidak ada low transaction time, tentunya autovacuum dapat membantu dan tentunya juga dengan melakukan tuning pada threshold untuk autovacuum, seperti jumlah dead tuples dalam persentase ataupun number. Jika memungkinkan adanya low transaction time, misalnya di malam hari atau setiap weekend, bisa saja kita gunakan scheduler untuk melaksanakan VACUUM.
Opsi selanjutnya adalah bisa saja memanfaatkan table partition, misalnya monthly partitioning, sehingga jika mau dilakukan housekeeping, tinggal melakukan truncate/drop saja ke table yang sudah dianggap obsolete untuk menghindari menumpuknya dead tuples.

Low bug rates is not downside, and in the Open Source community, since the people are working together to do QC and testing, then the advancement of the features and core functionalities are better. Indeed, when using an Open Source solution requires expertise, that is why Equnix is striving to become the expert to help you maintain a solution with PostgreSQL.

PostgreSQL memiliki extension Foreign Data Wrapper yang dapat dimanfaatkan untuk melakukan penarikan data dari data source lain, tentunya bisa juga untuk menarik dari Oracle (oracle_fdw). Untuk SP sendiri, karena hal tersebut berhubungan dengan logic, maka perlu dilakukan inspeksi dan konversi secara manual, khususnya jika menggunakan fungsi-fungsi spesifik dari Oracle.

Ora2PG tetap belum bisa melakukan migration dari semua logic di dalam SP, oleh karenanya harus dilakukan inspeksi dan konversi secara manual, untuk melaksanakan data migration pada sistem yang sangat mission critical dapat menghubungi kami (https://equnix.asia/solution/migration)

Dalam PostgreSQL tidak ada synonym, tetapi karena PostgreSQL dapat mengakses secara cross schema, maka bisa saja dibuat 1 view di 1 schema yang melakukan select dari schema lainnya.

Oleh karena PostgreSQL memungkinkan akses cross-schema, maka sebaiknya tidak perlu menggunakan synonym, melainkan melakukan akses langsung saja ke schema yang dimaksud, tentunya dengan privilege management yang sesuai untuk masing-masing user.

Our Premium Maintenance Support is a professional service that helps you to maintain the PostgreSQL implementation on your production system. On Maintenance Services, Equnix acts as your Maintainer and support you reactively, so when you experience problems on the PostgreSQL installation we maintain, you can get our support 24/7. We cover from installation, configuration, tuning, replication, multi-tier backup/restore, slow query analysis, and performance check. There are 2 services, Corrective Maintenance and Preventive Maintenance.
Corrective Maintenance follows our SLA Plan (https://equnix.asia/sla) and Preventive Maintenance will be done every 3 months, to check the instance health and give advice for optimization. Please open https://equnix.asia/solution/subscription for more information.

Pertanyaan yang cukup menarik, sebuah permasalahan umum yang sering dihadapi oleh Arsitek Aplikasi. Ada beberapa pendekatan yang bisa dilaksanakan:

1. Melakukan enkripsi data untuk data-data yang sangat confidential seperti data catatan medis, atau sejenisnya. Enkripsi disini dapat menggunakan software-based dengan melibatkan HSM (Hardware Security Module) atau dapat juga menggunakan semacam TDE (Transparent Data Encryption) atau yang sejenisnya, salah satu produk pihak ketiga yang dapat digunakan adalah CubeOne (Equnix adalah partner CubeOne https://equnix.asia/product/cubeone)
2. Menggunakan User Management yang sama dengan User yang mengakses database, dan melakukan pengaturan akses user secara ketat di level database. Dengan cara ini maka User Aplikasi adalah user dari PostgreSQL itu sendiri.
3. Cara lainnya dapat kita diskusikan kemudian dalam sesi konsultansi bilamana diinginkan.

Apa yang dimaksud dengan kemudahan? Bilamana yang dimaksud adalah kemudahan dalam pengembangan ke depan atau kemudahan dalam memaintain database, seperti data management, scalability, high availability, backup/restore, tentunya menang benar, ada banyak sekali kemudahan yang kita dapatkan dengan menggunakan PostgreSQL.

Tunggu tanggal mainnya, nanti kita akan buat program khusus untuk mahasiswa, dari mulai kurikulum, materi pengajaran, training profesional sampai dengan sertifikasi.

There are some options to have multi-tenancy in PostgreSQL, we can use a single logical Database for every tenant application, or share a single Database across multiple application forks partitioned by schema. Or using a single database instance per application, implemented on Docker/Container. Which one is preferred? It depends, we have experienced one of our clients having very dense multi-tenancy PostgreSQL, host more than 10 thousands logical databases in a single database instance, and it works well after we do some little patch on the source code. The first thing that we should consider is, having multiple database instances for every single database logic is not a good choice, it would end up having memory exhausted. While having too many logical databases in a single instance is also not a good choice, let assume for rule of thumb 10 thousand is already considered as big.
Having docker or any other containerization technology is a good approach if we wanted to re-sale the services per container. Container technology has the ability to partition the core usage strictly (while VM is not) and that would be a great advantage for selling the service in a fair manner. Using a multi schema, compared to the multi database logic is a good point when the application access comes from a single domain or organization. While separating parallel access from users (from the same institution/domain) into logical databases will reduce database flexibility in doing reports, while still that can be approached using FDW anyway. Well, what is the best option? That depends on the situation and business process that is already done and will be implemented in the future.
There are more factors which we didn’t count in this discussion yet, I am open for any other thought. Thanks for asking.

Benar sekali Pak, dengan menggunakan PostgreSQL kita memiliki kebebasan untuk menggunakan tanpa harus terikat dengan lisensi tertentu dari Vendor, kita mendapatkan kebebasan dan tetap memiliki dukungan yang mumpuni sampai dengan level Principal dengan membeli pada Vendor yang sesuai dan memiliki kompetensi dalam hal tersebut.

Equnix memberikan layanan terhadap implementasi PostgreSQL pada sistem Produksi yang mission critical, dengan dukungan yang mumpuni dan memiliki kompetensi yang cukup untuk melaksanakan tugas principal (root cause analysis, bug fixing, security analysis and recommendation, performance patch, etc), expert support dan sampai dengan operational support bilamana diinginkan. Untuk lebih lanjut dapat dipelajari https://equnix.asia/solution/subscription.