Yonathan Rizky

Q: Adakah teknik untuk optimasi/tuning data, ketika data suatu table sudah mencapai jutaan record?

A: Banyak caranya, dengan menggunakan partition yang kita buat menjadi partitioning. Namun dengan menggunakan partitioning tersebut, kita harus memahami kelebihan maupun kekurangannya. Dengan jutaan record yang dirasa sudah terasa panjang, kita dapat melakukan convert di partition dengan cara memotong tabel menjadi parent dan child. Kemudian kita memiliki child yang mana itu adalah tabel-tabel kecil yang merupakan pembangun dari tabel yang lebih besar.
Biasanya jika kita melakukan query dengan tabel yang cukup besar, dapat dimungkinkan karena panjang tabelnya menyebabkan indeks nya juga panjang. Dengan indeks yang besar, biasanya indeksnya tidak dapat masuk ke dalam memori sehingga tidak membantu proses query yang lebih cepat. Oleh karena itu, indeksnya dapat kita kecilkan dengan cara membangun partition tabel yang kecil-kecil. Namun jika belum terlalu besar, kita hanya perlu membesarkan workmem nya. Dengan workmem yang diperbesar, maka indeks dapat masuk kedalam memori dan dipakai untuk proses query execution. Sehingga prosesnya pun akan berjalan dengan cepat.
Jika menggunakan partition model seperti diatas. Kita harus memahami bahwa query-query yang dilaksanakan dalam tabel yang di partisi, harus mengandung where clause berupa partition key. jika kita meng-query tabel dengan partition tanpa ada key di dalam where clausenya, akan mengakibatkan tabel kecil-kecil tersebut akan di scan semuanya sehingga akan kembali melambat. Kalau kita menggunakan query yang mengandung partition key --disebut dengan pruning--, maka akan dapat berjalan sangat cepat dan jauh lebih cepat dengan tabel yang tidak menggunakan partition.

Michael Tanu – PT United Media

Q: Terkadang sudah ada beberapa user sudah memakai solusi dengan brand tertentu, karena sudah pernah menggunakan solusi sebelumnya atau sudah direkomendasikan oleh team IT mereka. Bagaimana cara kita dalam hal offering dan membawa solusi equpos ke customer dengan case tersebut?

A: Kita menawarkan fitur-fitur yang fleksibel, dan apa yang seharusnya sudah ada itu yang kita pastikan sudah berjalan di kita. Kembali lagi ke roadmap kedepanya seperti apa. Produk ini nanti akan tetap berbasis Open Source solution dimana kita juga melakukan tuning terhadap database sistem, kalkulasi dengan baik, bukan sekedar aplikasi. Tapi kita memikirkan resiko yang nantinya akan terjadi, bagaimana cara untuk bisa mendesain sistem dengan baik, mengadopsi proses daily product update yang bisa berjalan dengan cepat. Jadi bukan hanya optimisasi di level UI, namun juga micro optimization jadi bisa mengunggulkan proses update masive yang cepat, sinkronisasi yang cepat. Untuk menjawab kebutuhan dari mereka juga seperti transaksi offline, promo kombinasi, dan itulah hal yang kita sampaikan ke customer.

Hardi Agung Wibowo

Q: Apakah fitur-fitur utama dari 11DB/Postgres™ yang mungkin setara atau melebihi dari RDBMS untuk computing tinggi?

A: Kami memang merancang 11DB/Postgres™ untuk High Performance Transaction. Untuk fitur-fitur utama nya tidak jauh berbeda dengan PostgreSQL, namun kita lengkapi dengan dashboard monitoring sehingga kita dapat melakukan monitoring secara realtime, dapat memahami masalah yang terjadi secara langsung, dan memiliki kemampuan backup yang otomatis, multi-tier backup, High Availability, dan tidak kalah pentingnya dalam delivery 11DB/Postgres™ ini aladah kita juga men-deliver supportnya. Inilah yang menjadi kekuatan Equnix. Kita tidak hanya menjual license namun didalamnya kita tambahkan bonus berupa support dari mulai L.3, L.2, L.1, dari mulai Principle Level Support, Expert Level Support, dan Technical Support. Kita bisa menerima eskalasi dari tim operations dan membantu menyelesaikan masalah-masalah yang muncul. Itulah kenapa Equnix mendeliver 11DB/Postgres™ ini.

Hardi Agung Wibowo

Q: Mohon info juga terkait lisensi dari produk 11DB/Postgres™?

A: Ada 2 macam license yang Equnix deliver kepada client, diantaranya:

1. Subscriptions License adalah lisensi berlangganan yang mana client dapat menggunakan dan membayar lisensi nya setiap tahunnya.
2. Perpetual License adalah lisensi yang dapat dibeli 1 kali oleh client yang mana client tidak perlu membeli kembali di masa yang akan datang.

Kedua license tersebut datang dengan support. Kami percaya bahwa menggunakan 11DB/Postgres™ yang mana adalah turunan dari Open Source PostgreSQL, tidak bisa hanya dengan jual beli license saja. Karena resource expert PostgreSQL tidak bisa kita dapatkan dari luar (freelance, personal hire). Jika dimasa mendatang sudah banyak perusahaan di Indonesia menggunakan PostgreSQL di komersial, mungkin akan muncul resource tersebut. Namun saat ini belum bisa.
Pada dasarnya PostgreSQL sangat bagus dan powerful namun membutuhkan support. Karena postgreSQL adalah sebuah database yang mengolah data secara langsung dan dinamis, sehingga ada potensi-potensi permasalahan yang sangat besar di dalam pengelolaan database, dari mulai potensial sistem down karena load yang tinggi, salah setting, atau bahkan corrupt, dan sebagainya. Jadi PostgreSQL sangat membutuhkan dukungan support yang mumpuni.

Faris

Q: Apakah 11DB/Postgres™ ada solusi active-active cluster?

A: 11DB/Postgres™ memang belum memiliki konstelasi active-active. Saat ini 11DB/Postgres™ mekanismenya masih active-passive. Mekanisme ini kita gunakan untuk kebutuhan HA, yakni master dan stand by. Kalau kita membutuhkan HA, sebetulnya kita tidak membutuhkan active-active. Kita hanya butuh satu active, satu passive/standby. Kalau membutuhkan load balancing, saya kira masih bisa menggunakan cara ini [read-write dan read only]. Namun sampai dengan saat ini, dengan menggunakan resource yang cukup mumpuni seperti prosesor AMD EPYC yang sangat powerful, kita tidak membutuhkan 2 server database untuk menghandle transaksi yang besar. Jika misal ada kebutuhan tersebut, boleh datang kepada kami. Kita bisa bantu siapkan untuk scalability, supaya sistem yang dimiliki dapat berjalan dengan baik tanpa perlu membutuhkan mesin lainnya.
Memang pada dasarnya active-active disampaikan oleh produk-produk lainnya, namun ada yang mengimplementasi dengan menggunakan logical replication. Dengan menggunakan logical replication maka DDL yang ada di mesin active 1 tidak dapat di replikasikan ke mesin active 2 dan juga sequence-nya pun tidak dapat di replikasikan, begitu sebaliknya sehingga hal tersebut akan menjadi disaster, --karena seringkali developer lupa melakukan update pada production--. Kalau kita tidak memahami baik-baik tata caranya akan menjadi masalah besar. Karena begitu ada perubahan data di sisi mesin active 1, maka akan terputus replikasinya sehingga menyebabkan perbedaan dengan data di mesin active 2. Adanya ketidaksinkronan menyebabkan peer dari mesin active 2 akan tidak valid lagi menjadi backup karena sudah ada perbedaan data yang mungkin sangat jauh.

Faris

Q: Apa saja requirement yang dibutuhkan untuk mengimplementasikan PostgreSQL active-active cluster?

A: Active-active ini bisa diimplementasikan di PostgreSQL dengan menggunakan logical replication, namun ada banyak sekali hal yang harus diperhatikan dengan benar-benar ketat. Karena jika tidak, ketika sudah masuk ke production akan menjadi masalah yang cukup serius dan berakibat pada downtime yang dapat merugikan bisnis.
Mungkin di masa mendatang kita ada plan membangun active-active namun dengan model single database. Membangun clustering transaction system dengan PostgreSQL yang mungkin dapat dibandingkan dengan exadata.
Banyak produk yang mengklaim active-active, namun sebetulnya itu semua tidak bisa untuk high performance system dan ada potensi-potensi masalah yang mungkin di awal tidak diceritakan.

Mohammad Slamet Yahya

Q: Apakah penggunaan Open Source dalam bisnis menghindarkan kita dari vendor lock-in?

A: Sangat benar bahwa dengan kita menggunakan Open Source PostgreSQL, Open Source Linux, kita dapat menghindarkan diri dari vendor lock-in. Dan tentunya Open Source yang digunakan haruslah yang pure Open Source.
Saya berikan contoh, banyak yang mengatakan bahwa MySQL adalah Open Source, namun jawaban saya MySQL bukanlah Open Source. MySQL adalah produk komersial yang didistribusikan secara “Open Source”. Sehingga jika menggunakan produk tersebut, kita tidak menghindarkan diri dari vendor lock-in. Karena kita bergantung untuk membeli lisensi komersial-nya. Jika kita menggunakan produk tersebut untuk komersial dan tidak membeli lisensi komersialnya, artinya penggunaan ilegal. Banyak orang tidak mengetahui itu.
Kalau produk yang pure Open Source, maka pengguna terhindar dari vendor lock-in dan dapat menggunakan vendor yang lain. Sebagai contohnya, 11DB/Postgres™ yang kita pasarkan. Ini memiliki kompatibilitas yang tinggi 99,9% dengan PostgreSQL Open Source. Suatu ketika di tahun ke-2 setelah menggunakan 11DB/Postgres™ kami, kemudian ingin memaintain sendiri maka kami dapat memberikan yang bisa diubah menjadi PostgreSQL yang Open Source dan client dapat menjalankan dengan baik tanpa ada masalah. Tidak ada vendor lock-in dan itulah yang kita berikan. Produk-produk yang kita tawarkan selalu dapat digantikan oleh produk Open Source yang Open Source vanilla.

Iqbal Kurniawan

Q: Apakah ada tools monitoring terkait user management? terkait role yang sudah diberikan akses contohnya admin, dan lain-lain.

A: Kita masih menggunakan tool user management yang berasal dari distribusi Open Source seperti pgadmin dan sebagainya. Kita belum membuat sebagai suatu fitur yang khusus. Di masa mendatang memang ada plan untuk membangun sebuah management console untuk memudahkan administrasi. Namun saat ini karena yang kita deliver tidak hanya license tapi juga support. Kita akan bantu client untuk mambangun mekanisme administrasi yang baik tentang user management dan seterusnya. Kita akan berikan tata caranya sehingga client tidak perlu pusing. Untuk client kita yang membeli 11DB/Postgres™, tentunya tidak kita tinggalkan begitu saja. Setiap saat client ingin bertanya, kita selalu siap sedia untuk berkontribusi membantu. Sampai dengan masalah pada production, itu juga bagian dari tanggungjawab kami.

Mohammad Slamet Yahya

Q: Apakah di PostgreSQL bisa query join lintas database?

A: Bisa, PostgreSQL memiliki fitur foreign data wrapper. Dengan fitur tersebut PostgreSQL mampu membaca data dari database lain. Dengan demikian dengan kita membangun foreign data wrapper, semacam dblink. Kemudian data tersebut kita join kan dengan local tabel. Dan itu sangat dimungkinkan.

Michael

Q: Untuk keamanannya bagaimana? Karena kami bergerak di bidang finance dan data customer kami sangat rahasia, jadi bagaimana Equnix bisa mensupport kita tapi dengan keamanan yang maximal.

A: Saya mungkin perlu mengingatkan kepada kita semua, bahwa semua produk yang di deliver baik itu Open Source maupun bukan Open Source yang dibuat oleh manusia, walaupun dikeluarkan oleh vendor dengan kelas dunia, tidak berarti memiliki kepastian untuk sistem keamanannya.
Itu lah mengapa kita tidak menjual license saja, namun dengan supportnya. Sehingga ketika kita mengimplementasi PostgreSQL, kita memiliki tata cara dan best practice nya untuk diimplementasikan dengan aman. Itu semua sudah menjadi bagian dari implementasi dari 11DB/Postgres™. Singkatnya, untuk keamanannya sangatlah aman karena kita memitigasi semua potensi-potensi yang menyebabkan terjadinya kehilangan data. Tugas kami adalah men deliver comprehensive solution supaya client dapat menggunakan dengan baik dan nyaman tanpa perlu khawatir. Bahkan tingkat kenyamanannya dapat melebihi Oracle. Dengan best practices dan pengalaman kita bertahun-tahun, tidak perlu khawatir apapun yang dibutuhkan kita akan sediakan dan akan kita berikan mitigasinya sesuai dengan kebutuhan. Kami menjamin deliver dengan baik dan jika ada potensi yang mungkin muncul akan kita sampaikan, karena kita sudah experience dalam hal tersebut.

Michael

Q: Untuk supportnya jika ada case severity level 1 itu masa penanganan berapa lama?

A: Di dalam tabel severity level yang kita miliki. Untuk penanganan respon adalah 15 menit. Untuk quick fix nya adalah 1 hari dan resolve nya adalah 5 hari. Jadi tidak perlu khawatir, dengan severity level 1 itu artinya kita melaksanakan fungsi principal.
Jika ada yang ingin melihat dapat langsung mengunjungi website Equnix pada bagian SLA Plan.

Michael

Q: Apakah PostgreSQL bisa dijadikan sebagai active 2 database (2 DC)?
seperti kita tahu sekarang sudah mulai banyak distributed database seperti Cockroachdb, Yugabite dll yang mana protokolnya based on PostgreSQL

A: PostgreSQL dan 11DB/Postgres™ pada dasarnya tidak bisa active-active di 2 data center, dalam arti active-active yang ada di satu kesatuan sistem. Karena jika ingin active-active, keduanya harus memiliki sinkronisasi data dan karena berada di tempat yang jauh antara 2 data center, tentunya latency akan membuat masalah di transaction yang akan mengakibatkan kelambatan. Untuk Cockroachdb saya belum tau secara langsung, tapi yang jelas ada beberapa partner yang pernah mengalami kejadian tersebut. Kalau untuk Yugabyte, saya juga kurang mengetahui bagaimana mereka implementasinya. Kemungkinan besar mereka menggunakan logical replication dan ada beberapa kondisi yang sebelumnya disebutkan, diantaranya: DDL dan sequence. Saran saya jangan terlalu percaya dengan produk yang dijual. Kita siap untuk di challenge dan melakukan POC.
Jika antar data center bersifat active-active, ini akan sedikit menjadi problem. Karena kita menginginkan untuk saling update. Kalau ternyata active-active ini tidak membutuhkan hal yang update, sebetulnya itu merupakan 2 database yang terpisah. Jadi ada istilah geographical load balancing, geographical load balancing adalah load balancing yang berdasarkan pada geografis. Ketika domain user berbeda dan berjalan dengan baik, itu tidak menjadi masalah. Tinggal kita tarik datanya ke suatu tempat untuk konsolidasi, untuk reporting, which is fine. Namun sebetulnya itu bukanlah active-active karena posisi di geografis tersebut (geografis A dan B) menangani domain yang berbeda/ dua aplikasi yang berbeda, hanya kembar modelnya.

Koko Bachrudin

Q: Apakah ada perbedaan performance deploy PostgreSQL on the top GNU/linux dan FreeBSD?

A: Sekedar informasi GNU/linux ini adalah sebuah OS. setiap linux yang kita pakai itu kategorinya ada GNU/linux kecuali menggunakan linux yang berbeda seperti Alphine LInux. FreeBSD adalah distribusi OS BSD, xBSD.
Saya kira ada perbedaan, diantaranya:

1. Penggunaan library C nya.
2. Linux dan BSD nya

Saya tidak bisa memastikan mana yang lebih baik. Tapi selama ini kita sudah well tested dengan GNU/linux, dengan performance yang cukup baik. Kemungkinan FreeBSD tidak sebaik di linux. Tapi saya tidak bisa menyampaikan sebagai yang pasti karena kita belum melakukan tes secara go though. Untuk perbedaan, saya kira ada. Karena perbedaan OS nya akan menyebabkan performance diatasnya yang mana PostgreSQL nya, call to kernel, memory management nya, dan seterusnya pasti akan terpengaruh.

Michael

Q: Apakah PostgreSQL bisa replace MySQL atau database yang sudah existing, atau kita bisa kombinasikan dengan yang sudah ada?

A: PostgreSQL bisa replace any kind of RDBMS, namun kalau me-replace sebuah database yang tidak sama dengan PostgreSQL maka akan ada effort konversi yang lebih besar. PostgreSQL sangat sering dipakai untuk me-replace Oracle. Kalau untuk MySQL, tidak masalah, juga bisa kita laksanakan, microsoft juga bisa, yang lain pun tidak masalah.
Karena sama-sama RDBMS, secara konstruksi delivery dari sebuah RDBMS itu kurang lebih sama, sehingga replacement nya tidak terlalu besar. Bahkan jika ada sebuah fungsi-fungsi khusus yang digunakan oleh existing database, kita bisa lakukan konversi, customization untuk menyesuaikan PostgreSQL kita agar memiliki delivery fitur yang sama dengan existing database. Dan itu yang kita lakukan di client. Ada Oracle yang memiliki fungsi-fungsi khusus yang tidak ada secara umum di database, maka kita customization function yang di deliver sebagai jawaban dari konversinya sistem Oracle supaya dapat berpindah ke PostgreSQL 100% dan digunakan dengan baik.

Michael

Q: Bagaimana untuk PostgreSQL bisakah untuk mirroring dan replikasi dari production kita ke DR?

A: Production PostgreSQL atau bukan PostgreSQL?
Kalau production PostgreSQL tentunya bisa, karena itu fitur standarnya PostgreSQL untuk mirroring dari database utama ke database yang lainnya, entah itu dari production ke DR atau production ke yang production lainnya yang berada di beberapa data center. Selama itu sama-sama PostgreSQL, everything is ok, consider done, karena bisa di mirror dengan baik. Namun kalau dari production Oracle, saya kira ada solusi untuk melakukan mirroring dengan membeli produk lain yang dapat membaca CDC Oracle dan kemudian menuliskannya ke PostgreSQL. Kebetulan kami pun memiliki produk tersebut. Ini adalah software lain yang berpartner dengan Equnix. Software tersebut mampu membaca CDC-nya seperti Golden Gate, tetapi Golden Gate nya dari Oracle ke PostgreSQL.

Tedy Handoko

Q: Bagaimana strategi meyakinkan bagian IT dalam menggunakan produk ini dibandingkan kita memakai produk kompetitor dari segi biaya dan reliability?

A: Kalau yang disebut dengan kompetitor ini adalah produk proprietary, saya kira sangat mudah. Karena memiliki masalah di sisi pekerjaan maintenance. Ketika menggunakan produk kami, maka akan memiliki delivery layanan support. Kita akan me-maintain dan memberikan konsultasi kepada client kita terkait pekerjaan apa saja yang harus dilakukan supaya layanan dapat berjalan dengan baik. Untuk produk PostgreSQL komersial yang lain, sebetulnya sama saja. Biasanya mereka hanya datang dalam bentuk license tanpa ada supportnya. Biasanya client tidak mengetahui tentang PostgreSQL dan belum ada kecakapan maupun pengalamannya. Itulah kenapa kami berani memberikan diri untuk memberikan support yang mumpuni, karena kami tahu PostgreSQL tidak dapat hanya digunakan dengan license nya saja. Namun license dan supportnya.
Sederhananya, kami datang dengan support sehingga tidak perlu khawatir segala permasalahan akan kita bantu dan selesaikan berdasarkan pengalaman dan best practice yang kita miliki.

Tedy Handoko

Q: Bagaimana lisensi produk 11DB/Postgres™ ini utk dipakai di beberapa perangkat & sistem yang ada di kantor pusat dan kantor cabang? Adakah batasannya dalam melakukan proses upgrading?

A: License 11DB/Postgres™ ini dihitung dari penggunaan core nya. Ketika nantinya digunakan sebagai bagian DR, nanti akan ada perhitungan khusus, harga khusus untuk penggunaan di DR. Sama juga hal nya jika kita menggunakan di kantor cabang dan kantor pusat, kemudian ada data yang di mirror. Jadi jangan khawatir. Semakin banyak core yang digunakan, maka harganya semakin turun.
Dan untuk upgrading akan menjadi tanggungjawab kami, client tidak perlu memusingkan upgrading seperti hal nya policy upgrade yang disampaikan oleh proprietary software, yang mana client harus upgrade ketika ada patch. Itu hanya karena proprietary software khawatir adanya potensi trojan, back door, dan seterusnya. Jika client tidak upgrade maka akan menjadi tanggungjawab client jika ada permasalahan karena tidak melakukan patch. Dan kita tidak seperti itu. Menurut kami itu adalah tindakan yang tidak bertanggungjawab. Memang ada perbedaan, kalau untuk proprietary dengan jumlah deploy sampai jutaan di seluruh dunia.
Sedangkan kita belum sampai sebesar itu. Jadi care kita akan lebih dekat dengan client. Kita tidak mengharuskan client untuk upgrade, karena kita yang akan selidiki. Karena patch-patch yang muncul jika menggunakan patch dari komunitas Open Source, tidak serta merta security patch. Semua potensial vulnerability yang ada, akan kita assessment dan kalau memang dibutuhkan akan kita upgrade. Baik kita upgrade secara langsung atau dari sisi client dengan kita berikan tata cara upgrade nya. Jadi policy upgrade nya kembali kepada kami sebagai provider, kita akan maintain dan akan kita komunikasikan kepada para pengguna yang mana yang perlu di upgrade yang mana tidak perlu di upgrade. Kalau ada permintaan upgrade versi keatas, dapat kita diskusikan. Kalau secara umum, jika hanya patching dan bug fixing itu menjadi domain kita untuk memutuskan perlu atau tidaknya.

Iqbal Kurniawan

Q: Untuk proses migrasi dari MySQL ke PostgreSQL apakah membutuhkan downtime/bisa dilakukan secara live?

A: Kita harus melihat pada kondisinya. Kalaupun diperlukan downtime, kita bisa meminimalisir downtime. Saya kira aplikasi pun harus di convert dan harus ada testing replikasi. Jadi ketika data dipindahkan dari MySQL ke PostgreSQL menggunakan cara apapun FDW, dumping atau copy data dengan EDIM ETL, pasti harus ada downtime. Ketika data dipindahkan tidak boleh ada aplikasi yang mengakses ke MySQL sampai selesai dipindahkan. Kalau datanya masih menyala dan terus berjalan, akibatnya migrasi tidak akan pernah selesai. Ada downtime, tapi kita dapat meminimalkan downtime tersebut.

Iqbal Kurniawan

Q: Fitur-fitur unggulan apa yang ada di PostgreSQL jika dibandingkan dengan database MySQL atau lainnya?

A: Tentunya PostgreSQL jauh lebih baik karena PostgreSQL dirancang untuk transactional sedangkan MySQL tidak dirancang untuk transactional. PostgreSQL tidak setara dengan MySQL. MySQL dapat berjalan cepat dengan menggunakan MyISAM dan MyISAM bukan untuk transactional karena MyISAM tidak mampu melaksanakan isolation dengan baik. Karena tidak mampu maka tidak mendukung transactional. Katanya juga bisa menggunakan innodb, bisa menggunakan innodb namun semakin lambat dan jauh lebih lambat dari MyISAM.
MySQL bukan par nya PostgreSQL, jauh lebih unggul PostgreSQL dibandingkan MySQL. PostgreSQL par dengan Oracle. Secara delivery Oracle, kita harus akui bagus dan PostgreSQL tidak kalah baiknya dengan Oracle. Saat ini kekurangan Oracle adalah dari sisi bisnisnya adalah mahal, vendor lock-in, dan seterusnya. PostgreSQL mengantisipasi hal tersebut. Dengan fitur yang tidak kalah baiknya dan performance yang kalau dengan kami, kami selalu surpassing dengan Oracle. Misal client kita menggunakan 100 tps, dengan kami client bisa menggunakan 200-300 tps. Dengan kita memahami arsitektur PostgreSQL dengan baik, kita dapat membuat implementasi PostgreSQL yang sangat cepat. Kita me-riset PostgreSQL, mempelajari arsitekturnya, mengetahui kelemahan dan kelebihannya, dan dengan melakukan SWOT analisis kita melakukan mitigasi.
Karena kita memahami PostgreSQL jauh lebih dalam dan lebih baik, sementara Oracle biasa diinstall dengan cara yang mungkin tidak terlalu maksimal, otomatis kita mampu surpassing secara umum penggunaan PostgreSQL diatas Oracle dengan lebih cepat dengan yang kita deliver.

Iqbal Kurniawan

Q: Apa persiapan/best practise bagi perusahaan jika ingin mengimplementasikan database PostgreSQL?

A: Perlu mempersiapkan support nya. Harus memiliki support yang mumpuni, jangan asal-asalan. Karena jika PostgreSQL diinstall dengan cara yang tidak baik dan bukan dari expertnya, maka akan menimbulkan masalah dan nantinya akan memiliki anggapan bahwa penggunaannya tidak memuaskan. Perlu adanya support yang mumpuni karena tidak ada satupun developer PostgreSQL yang memiliki kepentingan terhadap implementasi PostgreSQL dengan baik. Dan kita mampu mensupport dengan tata cara implementasi yang baik. Karena kita memiliki Assessment, Provisioning, and Implementation metodologi-nya.

Kurnia Awal Ramadhan

Q: Apakah PostgreSQL sangat cocok untuk genre aplikasi HTAP (Hybrid Transaction Analytical Processing) ?

A: HTAP (Hybrid Transaction Analytical Processing) memang sebuah challenge untuk sebuah RDBMS. Sebetulnya jika ada aplikasi seperti itu, kita akan tetap suggest untuk dipecah ke dalam 2 database, yaitu OLTP dan OLAP. Semua transaksi yang sudah selesai di OLTP akan dikirim ke OLAP dan OLAP dapat kita pecah menjadi beberapa server sehingga load balancing, karena datanya sudah statis. Untuk data yang sangat dinamis ada di OLTP nya. Dengan cara tersebut kita dapat overcome problem data yang besar, panjang, dan transactional. Kalau kasusnya lebih kecil, kita hanya perlu membagi beban dalam bentuk partition, tabel partition dan seterusnya, tergantung dengan kondisinya. Dalam kondisi yang sangat besar, maka solusi kita adalah off loading ke dalam server-server yang lain, yang kita sebut server OLAP yang mana digunakan untuk menangani reporting, analytical, dan sebagainya akan transaction di OLTP. Dengan demikian PostgreSQL mampu dengan mitigasi tertentu.

Kurnia Awal Ramadhan

Q: Apakah mampu menandingi MySQL dan Oracle?

A: Jelas sangat mampu. Dalam beberapa implementasi di client, kita even better dengan Oracle yang dipakai oleh client. Dalam test kami di tahun 2015 kita melakukan test antara Oracle dengan PostgreSQL dimana Oracle di tuning oleh Oracle Gold Partner, dan hasilnya kita 7x lebih cepat daripada Oracle. Team Oracle Gold partner tersebut sudah mengambil nilai AWR nya dan tidak ada sanggahan apapun terkait hasil test tersebut.

Kurnia Awal Ramadhan

Q: Bagaimana dengan perform read and write-nya?

A: PostgreSQL kita tes di atas server prosesor IBM (paling kiri), Intel, Xeon, sampai dengan AMD Epyc (paling kanan) Zen 2 dengan 1 prosesor. Terlihat even better, PostgreSQL mampu memanfaatkan seluruh kinerja dari prosesor hingga mencapai 151,684 transaction per second. Hal tersebut tidak bisa dicapai oleh yang lain.
Untuk MySQL (saat itu) dipastikan tidak mampu, karena kita sudah melakukan tes. Jadi posisi PostgreSQL dalam hal performance dengan implementasi yang tepat dan tuning yang baik, PostgreSQL dapat menjadi nomor 1. Kalau ada rekan-rekan yang ingin mencoba, silahkan saja. Kita bisa melakukan POC, karena bukti dapat berbicara ribuan kata. Riset ini menggunakan pgbench dan TPC-B. Dari hasil tes ini, kita semua dapat melihat bahwa PostgreSQL mampu menekan dan mengolah resource CPU dengan sangat maksimal. Hal ini tentu tidak mudah. Karena tidak semua aplikasi/software yang di develop siapapun mampu memanfaatkan resources yang ada didalam sistem. Untuk testing Oracle biasanya akan menggunakan metode TPC-C menggunakan hammerdb, Selama kita dapat men-tuning dengan baik dan benar tentunya dengan strategi yang tepat. Kita bisa memaksimalkan database setinggi kemampuan hardware dibawahnya. Kalau kita ingin membandingkan 2 software, maka harus diatas hardware yang sama persis, baik waktunya, tahunnya, maupun jumlahnya. Karena dengan perbedaan tahun akan menyebabkan perbedaan performancenya.

Michael

Q: Apakah sampai sekarang PostgreSQL masih belum mendukung selectable stored procedure?

A: PostgreSQL mendukung selectable stored procedure.

Michael

Q: Pak untuk solusi kedua "menggunakan vendor untuk melaksanakan mitigasi". Bila menggunakan beberapa Open Source, seperti PostgreSQL, Redhat, dll. Bagaimana best practice nya bila terjadi troubleshoot agar kedua vendor ini tidak saling lempar untuk mendapatkan tanggung jawab?

A: Itu salah satu yang kita mitigasi. Kalau boleh menggunakan solusi yang total. Dan itu lah mengapa kita perlu menggunakan Equnix Appliance. Hal tersebut tidak terjadi di penggunaan Open Source, namun terjadi di penggunaan yang non Open Source.
Kalau di kami tidak pernah terjadi hal yang saling salah menyalahkan. Kita akan bantu client untuk mengurangi dispute. Karena kita menguasai PostgreSQL, OS nya, Hardware nya, dan kita mengetahui bagaimana networknya bekerja. Kalau end user bersikap open, meskipun masalah bukan dari sisi database, kita dapat membantu jika dipersilahkan memberikan pemaparan yang logis dan rasional. Selama client dan vendor open mind dan mau berdiskusi, pasti akan menemukan solusi. Karena kita akan bantu resolve problem tersebut dan kita juga menguasai teknologi yang dimiliki oleh vendor tersebut dari mulai: containerization, operating system, networking, dan hardware nya sekali pun. Memang tidak mudah, namun tidak masalah. Karena Equnix berorientasi pada pelanggan.

Rangga Adjie Sumantri

Q: Adakah parameter parameter di dalam settingan PostgreSQL-nya yang dapat mempengaruhi naik/turunnya tps ini Pak?

A: Ada banyak yang dapat mempengaruhi, tidak bisa disebutkan satu persatu. Tentunya setiap parameter yang ada dalam PostgreSQL memiliki fungsi dan impact sendiri-sendiri. Jadi jawabannya sangat bisa dan sangatlah penting, serta perlu dicek parameternya. Tuning ada 3 jenis:

1. Hardware tuning
2. Server tuning
3. Query tuning

Dan ketiga hal tersebut harus dilaksanakan dengan baik.

Budi Hertanto

Q: Equnix kan memang punya team yang mumpuni untuk PostgreSQL ini, ketika test comparison dengan database lain, apakah team tetangga juga sudah melakukan tuning di databasenya, kalau salah tuning tentu hasilnya akan tidak optimal?

A: Benar sekali, jika kita mau compare database 1 dengan lainya kita harus fair. Sehingga database lain juga harus di tuning oleh vendor yang bersangkutan. Kita pernah lakukan test di 2015, Equnix tuning PostgreSQL, dan ada gold partner dari Oracle. Kita tuning masing-masing secara maksimal dan hasilnya PostgreSQL 7x lebih cepat dari Oracle.

Nanang - Adyagraha

Q: Apakah Equnix Appliance ada support pada Enterprise PostgreSQL bila customer menemui kendala atau masalah? Untuk mekanisme pelaporan dan handling problemnya seperti apa?

Equnix Appliance kita deliver memang untuk PostgreSQL 11DB/Postgres™, bukan yang lain. Intinya Equnix Appliance adalah RDBMS PostgreSQL berkelas Enterprise yang berlisensi 11 DB/Postgres™. Jika Enterprise PostgreSQL lainnya kita tidak dukung, namun Equnix Appliance bisa dipakai di aplikasi.

Nanang - Adyagraha

Q: Apakah Equnix Appliance ada keterbatasan Enterprise PostgreSQL dari sisi size database, jumlah tabel, row, dan column?

A: Terkait Keterbatasan physical, memang Equnix datang dengan spek yang hanya 1 macam. Tapi jika klien membutuhkan lebih besar tentu bisa kita penuhi. Saya kira hampir tidak pernah ada kebutuhan user saat ini yang melebihi kemampuan theoretical Postgres dalam men-deliver layanannya (jumlah tabel, dan sebagainya). Equnix Appliance pada dasarnya dirancang untuk OLTP, jika ada yang OLAP mungkin bisa kami sesuaikan. Equnix Appliance datang dengan 64 core, zen 3 dan hasilnya sudah sangat tinggi, seperti yang ada di grafik dibawah ini:

Nanang - Adyagraha

Q: Apakah Equnix Appliance dapat berjalan optimal bila baik data source, staging maupun server node berada terpencar di lokasi terpisah, baik di cloud maupun on premise?

Jika server node-nya terpencar, mungkin ada potensi latency yang mengurangi performance. Maka dari itu Equnix Appliance dapat dibeli tanpa database, jika sudah membeli databasenya. Jadi klien harus menggunakan 11DB/Postgres™ tidak bisa yang lain. Jika sudah memakai 11DB/Postgres™, mau menambah server node pun tidak masalah. Equnix mendeliver Equnix Appliance supaya client tidak perlu menggunakan cloud. Layanan Equnix Appliance mulai dari L3, L2, L1, L0 comprehensive support, 24/7, dan masih banyak lainnya sehingga client tidak perlu pusing, jika mau tambah resource bisa langsung telepon kita. Untuk informasi lebih lanjut dapat dilihat pada: https://equnix.asia/product/appliance