Analisis SWOT untuk Neon Database: PostgreSQL dengan pemisahan lapisan Storage dan Compute

Neon adalah alternatif serverless open-source dari AWS Aurora Postgres. Di Neon, lapisan storage dan komputasi dipisahkan, serta mengganti lapisan storage PostgreSQL dengan mendistribusikan data ke PageServer. Membedah Neon secara mendalam serta mengujinya adalah sebuah topik yang besar. Pada artikel ini kita batasi hanya menganalisis SWOT (Strengths, Weaknesses, Opportunities, Threats) untuk Neon Database, dibandingkan dengan PostgreSQL.

Disclaimer: tulisan ini adalah eksplorasi yang bersifat eksperimental dan hanya hasil kreatif penulis yang tidak ada kaitannya dengan tempat bekerja sekarang dan juga sebelumnya; Anda bisa membaca halaman Disclaimer di situs ini untuk penyangkalan yang lengkap.

Motivasi Pembahasan

PostgreSQL adalah salah satu RDBMS paling populer. Bersifat open source, dengan lisensi yang mirip BSD atau MIT, tersedia banyak extension (misalkan TimescaleDB yang cukup populer) dan komunitas yang aktif. Namun PostgreSQL sendiri di-inisiasi pada tahun 1996, sehingga arsitektur dan berbagai komponennya dirancang sesuai dengan teknologi komputasi dan penyimpanan pada zaman tersebut.

Pada tahun 2023 ini, teknologi komputasi dan penyimpanan sudah berbeda signifikan dibanding tahun 1996. Terutama dengan kehadiran komputasi awan seperti AWS, Google Cloud, Microsoft Azure membuat kita bisa:

1. menyewa kapasitas CPU core dan RAM secara dinamis dan otomatis (auto-scaling)
2. menambah kapasitas penyimpanan blok, yaitu virtual hard-disk dan virtual SSD secara instan
3. menyimpan data dengan biaya relatif murah di penyimpanan objek seperti Amazon S3, Google GCS, Azure Blob

Dengan mempertanyakan kembali status quo, munculah penantang Neon Database. Seperti kata pepatah, tidak ada satu solusi yang cocok untuk semua permasalahan. Kita akan membahas di kasus-kasus apa saja Neon Database bisa berguna dengan baik, dan di area mana kelemahan Neon Database.

Arsitektur Neon Database

Instalasi Neon terdiri dari node komputasi dan node Neon storage engine. Node komputasi adalah kumpulan PostgreSQL yang stateless, didukung oleh Neon storage engine.

Neon storage engine terdiri dari dua komponen utama:

1. PageServer: storage backend yang scalable, untuk digunakan oleh node komputasi
2. SafeKeeper: membentuk layanan WAL yang redundan, menerima WAL (write-ahead log) dari node komputasi, dan menyimpannya secara durable sampai selesai diproses oleh PageServer dan di-unggah ke cloud storage (seperti Amazon S3 dan Google GCS)

Gambaran lebih lengkap dapat dilihat pada Gambar 1.

Alur Penulisan dan Baca Data

Agar mudah memahami secara keseluruhan bagaimana data ditulis dan dibaca pada Neon Database, Anda dapat melihat Gambar 1.

Kurang lebih beginilah alur penulisan dan baca data di Neon Database:

1. klien mengirimkan SQL query untuk menulis data ke Postgres Compute Write-Read (kita sebut PostgresW)
2. lalu node PostgresW akan meminta page-page yang dibutuhkan dari PageServer untuk menyelesaikan SQL query perubahan data
3. PostgresW akan melakukan tindakan yang diperlukan untuk perubahan data, lalu menulis perubahan di WAL (write-ahead log), dan mengirimkan WAL ke SafeKeeper
4. node-node SafeKeeper saling berkomunikasi dengan algoritma konsensus Paxos, menyimpan WAL dengan handal, dan mengirim-nya ke PageServer jika sudah siap
5. setelah WAL selesai di-replay oleh PageServer terhadap page-page yang terkait, maka WAL akan dikirim ke object storage sebagai cadangan
6. di sisi lain, klien bisa mengirimkan SQL query untuk membaca data dari Postgre Compute Read-Only (kita sebut PostgresR)
7. PostgresR akan meminta page-page yang dibutuhkan dari PageServer untuk menyelesaikan SQL query pengambilan data

Analisis SWOT Neon Database

Baiklah kita telah melihat arsitektur serta alur penulisan dan pengambilan data di Neon Database. Sekarang mari kita bahas analisis SWOT (strengths, weaknesses, opportunities, threats) untuk Neon Database, yang akan kita komparasikan terhadap PostgreSQL vanila dan beberapa distributed SQL

Strengths dari Neon Database

Kekuatan Neon Database dibandingkan PostgreSQL vanila antar lain:

1. Neon Database kompatibel dengan PostgreSQL v14, v15, v16
2. Neon hanya melakukan patch minor terhadap kode-sumber PostgreSQL (sekitar 2000 baris kode) untuk menjadikannya sebagai stateless Postgres Compute node, sehingga Anda bisa berekspektasi tinggi bahwa SQL query, berbagai extension PostgreSQL dan aplikasi Anda akan kompatibel dengan Neon Database
3. spesifikasi CPU dan RAM untuk Compute Node dapat diubah secara fleksibel
4. jumlah Compute Node dapat diubah secara fleksibel, bahkan sampai satu atau nol, sedangkan data tetap persisten di PageServer
5. hanya ada satu salinan page data di block storage HDD/SSD sehingga biaya menjadi lebih murah

Weaknesses dari Neon Database

Kelemahan dari Neon Database dibandingkan dengan PostgreSQL vanila antara lain:

1. per 19 November 2023, tidak ada replika untuk PageServer, sehingga jika ada masalah di VM PageServer termasuk di hardware disk yang bermasalah, perlu waktu (dan mungkin downtime?) yang cukup lama untuk restore data dari object storage S3
   (referensi: github.com/neondatabase/neon/docs/pageserver.md, namun sudah ada dalam roadmap pengembangan tim Neon: referensi GitHub issue)
2. per 19 November 2023, karena tidak ada replika untuk PageServer, ini bisa menjadi bottleneck saat banyak PostgreSQL Compute Node melayani banyak request, entah terkena limit kapasitas CPU atau Disk I/O (pembuatan replika sudah ada dalam roadmap tim Neon: referensi GitHub issue)
3. per 19 November 2023, sebuah database PostgreSQL di Neon hanya bisa dilayani oleh sebuah PageServer, alias tidak ada sharding; sehingga sebuah database PostgreSQL ukurannya tidak boleh melebihi daya tampung sebuah PageServer

Opportunities dari Neon Database

Peluang untuk Neon Database antara lain:

1. distributed SQL seperti Yugabyte dan CockroachDB ada banyak perbedaan dibandingkan PostgreSQL, sehingga ada peluang besar masalah kompatibilitas SQL query dan kebiasaan saat migrasi dari PostgreSQL ke distributed SQL; sedangkan dengan Neon Database hampir bisa dipastikan akan kompatibel berbagai SQL query, extension PostgreSQL dan aplikasi yang digunakan

Threats dari Neon Database

Ancaman dari penggunaan Neon Database:

1. dengan desain PageServer yang tanpa ada replika, akan menjadi potensi bottleneck untuk melayani trafik baca-tulis data yang tinggi; berbeda dengan distributed SQL seperti Yugabyte dan CockroachDB yang sudah mendukung replikasi data untuk durability
2. dengan desain PageServer yang belum mendukung sharding, akan sulit untuk hosting sebuah database besar di Neon; berbeda dengan distributed SQL seperti Yugabyte dan CockroachDB yang sudah memiliki fitur sharding
3. perangkat keras server, hard-disk, SSD, dan network termasuk di Public Cloud bisa error dan offline kapan saja sehingga menjadi potensi masalah besar untuk PageServer

Simpulan Analisis SWOT untuk Neon Database

Sebenarnya Neon Database adalah penantang baru terhadap status-quo PostgreSQL yang membawa ide yang sangat bagus. Hanya mengubah sekitar ~2000 baris kode PostgreSQL untuk menjadikannya sebagai stateless Postgres Compute Node di sistem Neon Database, sehingga kita bisa berekspektasi semua SQL query dan aplikasi yang kita punya akan kompatibel dengan Neon Database. Kita juga bisa menaikkan dan menurunkan kapasitas CPU dan RAM komputasi secara dinamis.

Namun sayang ada pekerjaan rumah yang cukup besar di sisi PageServer untuk tim Neon. Tidak bisa dipungkiri untuk workload yang besar di production, memerlukan dua fitur berikut:

1. replikasi di block-storage diperlukan untuk redudansi agar trafik read-only bisa didistribusikan; selain itu untuk memastikan agar recovery dapat cepat diselesaikan saat terjadi masalah di lapisan perangkat keras seperti server dan SSD
2. sharding, agar database PostgreSQL yang berukuran besar bisa dibagi-bagi ke banyak node PageServer (dibandingkan hanya menggunakan satu node PageServer dan hanya menambah kapasitas SSD terus menerus)

Dari analisis ini, saya bisa menyimpulkan bahwa Neon Database cocok untuk kasus-kasus penggunaan berikut:

1. jika Anda memiliki banyak database PostgreSQL yang berukuran kecil yang dijalankan di banyak PostgreSQL server kecil, dan ingin menggabungkannya ke sebuah sistem untuk menekan biaya
2. jika Anda memiliki workload OLTP yang kapasitas CPU dan RAM untuk komputasi-nya bisa dimatikan di hampir semua waktu, dan hanya dinyalakan di waktu tertentu
3. Anda ingin migrasi ke sistem database yang hampir pasti kompatibel untuk semua SQL query dan aplikasi yang dimiliki, dan ingin menggunakan extension PostgreSQL

Demikian analisis dan opini saya. Tulisan ini tidak dibayar dan disponsori oleh siapa pun, termasuk dari nama-nama pihak yang disebutkan dalam tulisan ini.