Equnix Business Solutions | an Open Source and Open Mind Company
Deepgreen TDE | Equnix Business Solutions
Card image cap

The registration period ends in

Do join us, ask the Experts, and get a special Giveaway!


Data Warehouse system is increasingly being used by Enterprises in line with the large amount of data they have. The need of having a Data Storage system for decades Data up to Petabytes requires a reliable Data Warehouse system that has high reliability, availability and scalability.

If you are looking for on how to implement and increase the Data Warehouse System, and wondering with the answers of questions below:

  1. 1
    How to implement DWH with Hundreds of Terabytes of Data?
  2. 2
    Which one is better, Big Data OR Data Warehouse?
  3. 3
    Is it important to have a Data Warehouse System in our Enterprise?
  4. 4
    What should we prepare to have a Data Warehouse?

In this session, we will introduce you to the benefit of our product: Deepgreen, a Massive Parallel Processing Data Warehouse system with scale out flexibility for crunching huge transaction data. It is a one-of-a-kind solution for your needs, and this is an ultimate solution for your data lake and a guarantee for fast and responsive consolidated report for your BI system.

Agenda:

  1. Registration

    ...

  2. The Ultimate Data Warehouse System: Deepgreen

    Presentation and Live Demo


    ...

  3. Q & A

    ...

  4. Quiz and Doorprize

    ...


This webinar is one of our upcoming events that will be held in 2020, do join us to know how Open Source Technology can be a solution for the Business World.

Stay up-to-date with Equnix opportunities and events. We will have a schedule every two weeks, which is full of discussions, talks, business cases, and more over is full of fun!


Another Webinar

Webinar Material

Video title

Presentation Slides:

Frequently Asked Questions

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.
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)
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.
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
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.
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.
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.
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.
Sudah dijelaskan pada poin 1 diatas, secara umum tidak disarankan dan cukup sulit untuk maintenance kedepannya.
Berbicara keamanan dalam sistem IT, ada 2 hal yang harus kita sasar:
  1. Keamanan data
    PostgreSQL sebagai server database memiliki kemampuan menjaga data integrity yang tinggi, oleh karena itulah hanya Oracle yang dapat dibandingkan dengan PostgreSQL, dan juga inilah alasan utama PostgreSQL banyak dipergunakan di lingkungan Perbankan, Telecommunication, Retail, Fintech, dan asal diketahui most E-Commerce site banyak beralih ke PostgreSQL. Dalam Konsep RDBMS ada pillar ACID (Atomicity, Consistency, Isolation dan Durability) compliance terhadap 4 pilar tersebut adalah keharusan, hanya RDBMS tertentu saja yang mampu melaksanakan compliance nya secara maksimal, salah satunya adalah PostgreSQL. Selain masalah integritas data, juga kita memahami data yang kita letakkan di dalam storage perlu diamankan agar tidak dapat dibaca secara offline (oleh orang yang tidak bertanggung jawab) untuk itu perlu adanya enkripsi data, dalam hal ini PostgreSQL belum memilikinya secara native, namun kita sudah memiliki solusi dengan menggunakan layanan pihak ketiga yang mampu memberikan enkripsi data secara simultan, data tetap terenkripsi walau dipergunakan sebagai acuan filter.
  2. Keamanan akses
    PostgreSQL memiliki banyak fitur untuk memastikan akses tidak dilakukan oleh mereka yang tidak bertanggung jawab: SSL, Kerbero, GSS-API, dan masih banyak lagi. Postgres memiliki tingkat keamanan yang tinggi dan dapat dipertanggungjawabkan, silakan hubungi marketing kami untuk elaborasi lebih lanjut (https://equnix.asia/about/contact)
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
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.
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.
Ada beberapa langkah, semuanya lengkap dijelaskan pada website kami, silakan Pak: https://equnix.asia/solution/migration
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)
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)
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.
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.
Sangat bisa sekali untuk replikasi dari production data center ke DRC, dengan menggunakan asynchronous native streaming replication.
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.
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.
Dalam memilih teknologi kita juga harus belajar memahami apa kekurangannya, begitu pula dengan PostgreSQL ataupun Open Source Software lainnya. Untuk OSS (Open Source Software) secara umum, jawabnya adalah: tidak adanya EKOSISTEM yang mature/mapan, yang mendukung ketersediaan layanan baik dari principal support, expert support, technical support, business oriented roadmap, kematangan QC, secara umum tidak adanya tanggung jawab profesional dan tanggung jawab keberlanjutan. Untuk itulah kita harus menggunakan perusahaan yang mumpuni dan secara profesional memiliki expertise dan kompetensi untuk melayani penggunaan OSS dalam bisnis yang mission critical. Untuk PostgreSQL, ada beberapa hal, seperti:
  • Proses VACUUM,
  • Tidak user friendly,
  • Konfigurasi dan tuningnya cukup rumit, membutuhkan pengetahuan mendasar mengenai arsitektur.
  • Postgres sebagai sistem pengolah data memiliki tanggung jawab yang sangat besar, kesalahan penanganan akan berakibat hilangnya data dan berujung pada resiko bisnis, tentunya harus dilakukan dengan kecermatan dan implementasi yang kompeten.
Kesemuanya itu tidak akan menjadi masalah, bilamana sudah menggunakan layanan mumpuni dari vendor yang memiliki kompetensi penuh, seperti yang sudah kita lakukan dengan client-client kita selama ini.
PostgreSQL memiliki tools bernama pg_upgrade, dimana dapat digunakan untuk upgrade versi yang paling lama, sampai dengan versi yang terbaru. Proses upgrade ini membutuhkan downtime dari instance, dan akan melakukan proses translasi yang dibutuhkan dari instance versi yang lama ke versi yang baru.
Equnix memberikan support Profesional untuk kebutuhan Enterprise support itu dari level Principal, Expert sampai dengan Teknis (https://equnix.asia/solution/subscription)
Secara teori: database size unlimited, jumlah table per database sekitar 1 milyar, jumlah database sekitar 4 milyar, kolom per table 1600, size dari object/table 32 TB. Secara praktis: Batasan teori diatas itu jauh diatas dari keterbatasan perangkat keras saat ini, jadi lupakan saja keterbatasan software karena keterbatasan hardware masih jauh lebih rendah dari software. Hal ini mungkin kadang kurang dipahami secara umum, PostgreSQL is not as good as Oracle in fact, it is far better than Oracle. As long as you use the right Vendor to do that. Baik PostgreSQL dan Oracle memiliki keterbatasan yang sama, yaitu keterbatasan hardware jauh lebih rendah daripada keterbatasan delivery PostgreSQL maupun Oracle.
Idealnya server nodes dan dwh manager diletakkan di 1 site, karena salah 1 faktor yang mempengaruhi performance adalah network latency. Jika diletakkan di tempat yang terpisah dan memiliki latency yang besar, maka latency itu akan terduplikasi karena komunikasi data yang bolak balik (back and forth) alhasil kinerja jauh menurun. Untuk Staging dan data source, tidak masalah jika diletakkan di lokasi terpisah, meski kami tetap suggest diletakkan pada premis yang sama.
Tidak menggunakan index
Bisa di setting dengan konfigurasi tertentu, tidak bisa dilakukan jika hanya menggunakan software Postgres apa adanya tanpa support yang profesional.
Sayangnya tidak, tapi bisa menggunakan Greenplum untuk yang versi tidak berbayar, Capacity Planning tidak bisa diukur hanya dengan menggunakan ukuran data saja, ada banyak faktor lain yang terlihat seperti:
  • Jumlah baris/row,
  • Seperti apa query report nya,
  • Apakah ada proses ETL yang kompleks?
  • Apakah Reportnya dari Data Raw atau dari Data Mart (cubes)
  • Dan masih banyak lagi.
Yang jelas database dengan data 1TB tidaklah besar. 1 mesin atau setidaknya 3 (dengan backup) sangat lebih dari cukup.
Cara mengatasi permasalahan yang muncul dari banyaknya data yang sangat besar melimpah dan tersebar adalah dengan mengintegrasikan data dari sumber yang berbeda-beda tersebut serta mengimplementasikannya ke dalam Data Warehouse seperti yang sedang kami jelaskan ini, yaitu Deepgreen yang dapat mengumpulkan, menyatukan dan mengkompilasi menjadi satu kesatuan informasi yang terpadu. Dengan demikian maka semua dapat dapat di-query dengan mudah dan dapat menghasilkan insight dengan membangun hubungan antara data yang baru.
Secara umum big data sebagai sebuah database untuk data yang tidak terstruktur (nosql atau unstructured data) seperti hadoop dan cassandra. Sedangkan untuk Data Warehouse untuk data yang terstruktur yang berisi historical data. Beberapa orang tetap menyatakan bahwa Big Data secara harfiah adalah data yang besar sehingga ketika Data Warehouse menampung data yang besar dengan metode clustering maka dapat juga dikategorikan sebagai Big Data.
Tidak menjadi ancaman karena secara umum Big Data merupakan Unstructured Database sehingga memiliki perbedaan fungsi dan konteks.
New Subsystem to Handle Spills dapat diartikan bahwa pada Deepgreen diimplementasikan sebuah subsystem baru bernama XDrive dimana subsystem ini dapat diakses oleh semua node sehingga data dari external dapat di akses dengan jauh lebih cepat, sedangkan JIT Compilation adalah Just In Time yang mana artinya logic dari suatu fungsi dapat dilakukan kompilasi pada saat runtime sehingga proses eksekusi dari fungsi dalam database tersebut dapat lebih cepat karena dieksekusi dalam bentuk binary.
Apabila satu node mati maka 2 server node lainnya akan menggantikan. Pada Replication Vector terdapat hal yang perlu diperhatikan tidak hanya tentang jumlah node tetapi juga CPU apakah bisa menangani beban yang sangat tinggi. Apabila ingin lebih tinggi dapat menaikan jumlah node pada masing-masing server.
Tidak menjadi masalah, namun kami lebih prefer menggunakan Containerization dibanding Virtualization.
Untuk Data Warehouse, tentunya data source tersebut adalah data yang terstruktur, bukan yang tidak terstruktur. Umumnya, data yang umumnya disebut di atas seperti sosial media, seperti chat log, forum/discussion tidak termasuk data terstruktur, sehingga tidak bisa diolah dalam Data Warehouse (Namun apabila hanya memasukkan saja tentunya bisa). Data yang tidak terstruktur umumnya adalah domain Database NoSQL seperti Hadoop atau Cassandra, bukan RDBMS.
Sebaliknya, terkadang ada yang menggunakan Hadoop atau Cassandra untuk menampung data yang sebetulnya asalnya terstruktur, dan kemudian menggunakan teknologi tertentu yang menginterfacekan repository (karena pada dasarnya hanya dijadikan sebagai tempat penampungan data saja) tersebut agar dapat di query dengan bahasa SQL.
Dengan memahami fitur dan purpose utama dari Deepgreen ini, semoga dapat dipahami bahwa Deepgreen adalah teknologi yang lebih sesuai dan lebih baik untuk kepentingan diatas.
Masih bisa, namun tidak disarankan karena latency network akan memperlambat proses. Sesuai dengan hukum alam, dalam serangkaian proses yang saling bergantungan, maka proses yang paling lambat adalah penentu kecepatan. Node yang paling lambat sebagai penentu kecepatan query result sehingga dapat menurunkan performance.
Apabila berbeda mesin maka akan berbeda kecepatan sehingga hasil yang paling lambat akan menentukan kecepatan keseluruhan proses.
Deepgreen lisensi per core dan tahun, sedangkan EDIM per interface.
Proses implementasi Data Warehouse baik pada DC Primary dan DRC tidak akan menjadi masalah. Data Warehouse dapat berada di main data center dan apabila ingin melakukan backup dapat dilakukan di Disaster Recovery. Umumnya data pada Data Warehouse tidak melayani pelanggan secara langsung (data untuk internal) sehingga secara severity level tidak terlalu tinggi. Data Warehouse dapat diimplementasikan baik on premise, line premise maupun cloud premise.
Jawaban umum: Server yang mampu melakukan proses scalability data secara horizontal, dalam hal ini Oracle dan PostgreSQL secara umum bisa tetap digunakan untuk Data Warehouse dengan menerapkan Tabel Partitioning, tetapi tidak akan lebih baik bilamana ada solusi melakukan horizontal Scaling dengan menerapkan Clustering Database seperti Deepgreen. Tools lainnya tentunya adalah ETL seperti EDIM, Presentation maupun BI / Report
Terdapat 3 cara untuk melakukan capacity planning. antara lain:
  1. Capacity Planning dapat dilihat melalui kecepatan perkembangan data (Growth Data) yang kemudian dapat membantu menentukan pertambahan CPU, memori dan storage sehingga tetap menjaga perkembangan data dan kecepatannya.
  2. Memindahkan beban data mart / cubes ke database lain, dan menghapus data raw yang sudah dibuat cubes, atau sudah tidak dipakai lagi.
  3. Menggunakan Strategi ballooning yaitu dengan menambahkan jumlah node sesuai dengan jumlah core. Umumnya adalah satu node dengan dua core dan bilamana dibutuhkan penambahan storage maka jumlah node tidak ditambahkan melainkan besar storage yang diperbesar.
Bisa menggunakan EXPLAIN ANALYZE, dimana fitur ini adalah internal query untuk melakukan analisa terhadap query planner sehingga bisa didapatkan informasi bagaimana Deepgreen melakukan eksekusi query, mendapatkan insight dimana kelambatan terjadi dan bisa dilakukan optimization berdasarkan hasil analyze tersebut.
Deepgreen dapat menggunakan FPGA yang mungkin secara awan dapat dianggap seperti GPU, namun penggunaan FPGA itu jauh lebih powerful daripada GPU karena FPGA adalah programmable logic yang memiliki kemampuan mengkodekan alur logika dalam sebuah hardware, sehingga proses komputasi lebih beragam dan lebih efisien.
Hampir semua ETL mendukung, sebab interface Deepgreen tidak berbeda jauh dengan Interface PostgreSQL. Lebih lanjut lagi, adalah EDIM yang dikembangkan oleh Equnix untuk melakukan proses Automation ETL dari berbagai macam sumber data secara otomatis.
EDIM merupakan aplikasi yang dibuat oleh Equnix dari scratch, sehingga dapat dicompile untuk pada Prosesor Sparc maupun Prosesor IBM tidak menjadi masalah.
Saat migrasi dari Oracle yang berada pada Sparc dan kemudian dipindahkan ke Intel dengan PostgreSQL menjadi lebih cepat dikarenakan Sparc yang digunakan clocknya jauh lebih rendah dan arsitektur Sparc tidak secanggih Intel dengan QPI nya.
  1. EDIM merupakan ETL yang berjalan di background menggunakan logic yang diperuntukan untuk kegiatan yang sudah matang dan dibangun diatas C programming language sehingga dapat dijalankan lebih cepat dan memiliki memory footprint yang kecil.
  2. Mempunyai proses transformasi yang bisa mengkombinasi berbagai data source menjadi satu destination dengan tujuan saving time di sisi Data Warehouse (Fleksibilitas di sisi ETL)
  3. Sangat cepat dalam memproses, mengkombinasi, filter dan agregasi (bila dibutuhkan) data dengan lebih efisien. Tidak membutuhkan storage sementara yang besar, semua data hanyalah passing through dari Server producer ke Server Consumer, tentunya setelah melewati semua rule dan role yang dispesifikasikan sebelumnya.

We would also like to announce that PGConf Asia is back, China will be the host!

smaple image

PostgreSQL Conference Asia 2020 will be transformed into a virtual conference and also offline event. This is going to be a different yet interesting PostgreSQL Conference for all of the business and professional community of PostgreSQL, this time would be a more fun and richer background of the audiences.

We expect this would be a great hub between technical advancement in PostgreSQL combined with Corporation Business Users. The event would be conducted in an easy talk while chilling in to get more inspirations, from the business side as well as technical perspective.

Do join us and contribute to this event as:

Attendees

Speakers

Sponsors

For more information, kindly access: https://postgresconf.org/conferences/AsiaChina2020 or https://2020.pgconf.asia/