Tidak semua, kita melakukan seleksi, kita memiliki kriteria Open Source yang kita support adalah software Open Source yang Pure, tidak semua Open Source itu Pure. Umumnya adalah software pendukung infrastruktur seperti OS Linux, PostgreSQL, Apache, GNU, dll.

Tantangan terbesarnya bilamana ingin lakukan migrasi sendiri adalah dikonversi stored procedurenya, secara umum migrasi dari database satu ke lainnya mostly di codenya, yaitu stored procedure, trigger, maupun sql statement, biasanya yang dipakai untuk query

Jaminan tentunya tidak diberikan dari Open Sourcenya, oleh karena itulah siapapun yang membutuhkan jaminan untuk penggunaan Open Source harus membeli jaminan tersebut dalam bentuk Layanan Premium, atau bentuk lainnya. Equnix sebagai perusahaan penyedia solusi IT memberikan layanan premium untuk PostgreSQL dan menjamin sampai dengan level Principal (https://equnix.asia/solution/subscription)

Dalam Deepgreen, penentuan distribution key adalah hal yang sangat penting juga dalam mendistribusikan data ke multiple data node. Hal ini juga merupakan salah satu bentuk optimisasi yang dilakukan, agar ketika data menyebar secara merata dan juga complex query yang dipanggil nantinya juga menjadi lebih cepat. Distribution key akan menentukan dimana data akan diletakkan berdasarkan kategori key tersebut, dan bilamana sudah didistribusikan secara merata, maka semua node akan dapat bekerja secara paralel dan mengembalikan hasil dengan lebih cepat.

Untuk struktur dari table tentunya sama, begitu juga jumlah data yang dilakukan pengujian. Yang berbeda sebetulnya adalah karena pada Deepgreen ini menggunakan topology Massive Parallel Processing, dimana terdiri dari beberapa node yang bekerja secara paralel, sehingga dengan demikian dapat dilakukan complex query secara bersamaan dengan tempo waktu yang lebih singkat, karena secara data juga didistribusikan ke masing-masing data node.

Di dalam PostgreSQL sebetulnya stored procedure dianggap sebagai function, dan semua function ini bisa dipanggil dengan SELECT dan dapat mengembalikan record set. Mulai dari PostgreSQL v 11, sudah didukung syntax CREATE PROCEDURE. Ketika dilakukan SELECT dari stored procedure tersebut, dapat juga dipilih kolom dari return set nya, dimana tentunya di dalam stored procedure tersebut, kita perlu lakukan definisi kolom-kolomnya terlebih dulu dari untuk dikembalikan dalam record set.

Sebetulnya sudah disebutkan:

1. Truly ACID Compliance
2. Hanya PostgreSQL yang mampu dibandingkan dengan Oracle sebagai Mission Critical Financial related Transaction System.
3. Native Streaming Replication (tanpa membutuhkan tools tambahan)
4. Logical Replication (replikasi secara selektif, tidak 1 instance)
5. Dukungan HA yang mumpuni (dengan dukungan hot standby)
6. Ekstensibilitas yang tinggi
7. Performa yang tinggi
8. Open Source, sehingga mudah untuk dilakukan modifikasi dan patching secara mandiri.
9. FDW (bisa mengakses data source external yang lain)
10. Dukungan RAS yang tinggi

Salah 1 alasanya adalah karena yang sudah disebutkan di point 1, khususnya untuk Big Data yang bersifat structured data, PostgreSQL as RDBMS sangat cocok dan memiliki performance yang baik. Lebih baik lagi menggunakan yang sudah didesain untuk itu seperti Deepgreen

1. Ada beberapa langkah, semuanya lengkap dijelaskan pada website kami, silakan Pak: https://equnix.asia/solution/migration
2. Charge migration kita per mandays dari mulai Comprehensive Assessment sampai dengan semua stages Migration Effortnya, silahkan kontak Marketing kami untuk lebih lanjut (https://equnix.asia/about/contact)
3. Bergantung kepada query seperti apa, dan berapa jumlah node yang dikonfigurasi, karena semakin banyak jumlah node dan juga clock dari processor yang digunakan, maka akan bisa semakin cepat. 100 juta itu jumlah yang tidak besar dewasa ini, dengan test kami data dengan 1 milyar bisa di query dalam beberapa detik (slide no 28)

Referred kepada general topology yang kami sampaikan tadi, ada 4 site yang perlu kita konfigurasi. Pertama adalah di sisi Main Data Center, dimana perlu dibuat terlebih dahulu konfigurasi HA serta untuk kebutuhan Reporting dan Historical, kemudian juga perlu dilakukan konfigurasi untuk DRC. Dari Main Data Center, kemudian diimplementasikan juga Multi-Tier Backup mechanism yang baik, baru kemudian mengimplementasikan Data Warehouse configuration untuk kebutuhan Analytics dan BI.

Secara rule of thumbs-nya, shared_buffers adalah sekitar 25-30% dari total physical memory, tetapi tentunya untuk performance, parameter memory lain seperti work_mem, effective_cache_size, wal_buffer, dll, itu juga bergantung kepada behaviour application/query yg masuk. Tentunya juga perlu diperhitungkan memory yang dipakai oleh OS.

Untuk yang saya jelaskan di slide itu adalah membandingkan query-query reporting antara Oracle dengan di Deepgreen, jadi bukan menggunakan metode benchmark standard seperti TPC-C atau yang lainnya. Benchmark Database Standard dilakukan dengan menggunakan TPC-C yang merupakan standard benchmark Database, silakan pelajari TPC-C pada https://www.tpc.org. Parameter metode dan mekanismenya dijelaskan semuanya pada website tersebut, itu adalah standard dunia benchmark untuk RDBMS.

1. Tentunya bisa untuk me-replace MySQL dan sangat kita endorse untuk hal tersebut, mengingat MySQL sebetulnya juga tidak cocok untuk production database yang mission critical, karena sering sekali ditemukan adanya data corruption dan secara performance pun tidak secepat PostgreSQL setelah di tuning.
2. Sangat bisa sekali untuk replikasi dari production data center ke DRC, dengan menggunakan asynchronous native streaming replication.

Security compliance pada dasarnya memiliki standarisasi, ada ISO 27001, PCI-DSS, NSI-CSS, ataupun standard security compliance lainnya nantinya yang mungkin akan ada. Tidak ada masalah dengan semua compliance yang dimaksud di atas, selama memiliki Vendor yang mumpuni dan kompeten. Vendor lah yang akan melakukan mitigasi, adjustment, tuning maupun refactor source code untuk menyesuaikan dengan kebutuhan yang ada. Kami memiliki pengalaman yang sesuai dengan kebutuhan ini, salah satu client kami sebuah Bank Nasional menggunakan jasa Konsultan Security, dan mereka comes up dengan 6 point of concern, kami hanya butuh waktu kurang dari 1 hari untuk melakukan customization agar kita bisa compliance dengan point tersebut.

Ada beberapa monitoring views yang bisa dianalisa untuk semua usage PostgreSQL instance, seperti jumlah data yang di-fetch, read, inserted, updated, deleted, dan dapat dikalkulasikan untuk mendapatkan insight mengenai besarnya load yang diterima oleh PostgreSQL. Untuk resource usage, tentunya ini adalah bagian dari OS monitoring, dimana perlu juga adanya tambahan statistic usage specific untuk PostgreSQL process. Untuk versioning pada PostgreSQL, sebetulnya hanya perlu untuk mengupdate saja driver yang digunakan. PostgreSQL sendiri bersifat backward compatible, sehingga jika ada upgrade version, aplikasi sangat less likely sekali untuk perlu di-update juga dari sisi logic. Seperti contohnya PostgreSQL sebelum version 10 dan semenjak version 10, yang berbeda hanyalah fungsi-fungsi yang berkaitan dengan operasional dan administratif, sementara query-query yang dipanggil oleh aplikasi tidak ada perubahan yang signifikan.

1. Pengertian Big Data itu sendiri masih perlu diperjelas, secara umum pengertian Big Data diaplikasikan untuk data yang tidak terstruktur, dan contohnya seperti penggunaan Hadoop, Cassandra, dll. Sebaiknya bilamana ingin membangun Big Data maupun Datalake (database RDBMS atau just bunch of storages) sebaiknya menggunakan teknologi yang sama agar efisien, namun bilamana menggunakan PostgreSQL sebagai pusat query data dalam islands of databases (ada MySQL, ada Oracle, ada MSSQL) maka sangat menarik, karena PostgreSQL memiliki FDW (Foreign Data Wrapper) yang mampu menarik data dari berbagai jenis database tersebut.
2. Sudah dijelaskan pada poin 1 diatas, secara umum tidak disarankan dan cukup sulit untuk maintenance kedepannya.

PostgreSQL memiliki banyak fork, salah satunya adalah yang mendukung replikasi dua arah (Bi-Directional Replication). Hal ini bisa dicapai dengan PostgreSQL versi khusus, dimana replikasi dua arah ini memanfaatkan logical decoding dari transaction log yang dituliskan, sehingga kedua instance bisa dibuat menjadi mode Master dan Master. Namun demikian, perlu dicermati bahwa mekanisme BDR ini tidak disarankan untuk model OLTP untuk melakukan load-balancing, karena ada potensi jika melakukan update pada 1 row yang sama secara bersamaan di kedua Master instance, maka dapat terjadi conflict terhadap data. BDR ini diperuntukan kepada topologi yang terpisah secara geografis, misalnya instance A ditulis oleh application A dan instance B ditulis oleh application B, yang mengakses 2 data yang berbeda. Tujuan utama dari BDR ini adalah untuk mereplikasikan 2 data dari 2 sumber yang berbeda, dimana masing-masing instance tersebut butuh untuk mengakses data dari sumber dari peer-nya.