PostgreSQL Sudah Cukup

 (gist.github.com/cpursley)
44 poin oleh GN⁺ 2024-02-07 | 2 komentar | Bagikan ke WhatsApp
  • Halaman yang merangkum tautan tentang cara menggunakan PostgreSQL di berbagai bidang
    • background job, message queue, GIS, audit log, kontrol akses, manajemen izin, pencarian, time-series, data graf, data eksternal, HTTP, API, event/replikasi/CDC, unit test, migrasi, dashboard/UI, visualisasi data, HTML dan aplikasi, LSP (language server)

PostgreSQL is Enough

Pekerjaan latar belakang

  • Dengan pg_cron, pekerjaan terjadwal dapat dikelola di PostgreSQL.

Message queue

  • Menyediakan informasi tentang cara memilih PostgreSQL sebagai teknologi message queue.
  • pgmq adalah sistem message queue berbasis PostgreSQL.

GIS/Peta

  • PostGIS menambahkan kemampuan database geospasial ke PostgreSQL.

Audit log

  • pgMemento dan pgaudit melacak perubahan dan mengelola audit log di PostgreSQL.

Kontrol akses

  • acl digunakan untuk mengelola access control list di PostgreSQL.

Autentikasi

  • Modul pgcrypto dan pgjwt di PostgreSQL menangani autentikasi di dalam database.

Pencarian

  • Menyediakan tautan-tautan berguna terkait fitur full-text search PostgreSQL.
  • paradedb, pg_embedding, pgvector meningkatkan kemampuan pencarian di PostgreSQL.

Data time-series

  • timescaledb memperluas PostgreSQL untuk mengelola data time-series.

Data graf

  • Apache AGE memperluas PostgreSQL untuk menyediakan kemampuan database graf.

Data eksternal

  • wrappers mengintegrasikan sumber data eksternal ke PostgreSQL.

HTTP

  • pgsql-http dan pg_net menangani permintaan HTTP di PostgreSQL.

API

  • PostgREST, graphql-engine, postgraphile, pg_graphql membangun server API berbasis PostgreSQL.

Event, replikasi, CDC

  • Perintah NOTIFY PostgreSQL serta walex, peerdb, debezium, pglogical melacak perubahan data dan menyediakan kemampuan replikasi.

Unit test

  • pgtap adalah alat untuk unit test database PostgreSQL.

Migrasi

  • postgresql-migrations dan bytebase mengelola migrasi database PostgreSQL.

Dashboard / UI

  • Baserow, NocoDB, AppSmith menyediakan antarmuka pengguna dan dashboard.

Visualisasi data

  • Evidence dan Metabase adalah alat visualisasi data.

HTML dan aplikasi

  • SQLpage, Omnigres, pg_render, plmustache mengintegrasikan data PostgreSQL ke aplikasi web.

Language server

  • postgres_lsp menyediakan dukungan Language Server Protocol untuk PostgreSQL.

Apa yang terlewat?

  • Silakan bagikan hal-hal yang belum tercantum melalui komentar

Pendapat GN⁺

  • PostgreSQL menunjukkan bahwa melalui beragam ekstensi dan alat, ia adalah platform serbaguna yang melampaui sekadar sistem manajemen database.
  • Tulisan ini memberi sumber daya yang berguna bagi para pengembang dengan menunjukkan cara memenuhi berbagai kebutuhan aplikasi menggunakan PostgreSQL.
  • Secara khusus, tulisan ini menekankan potensi untuk menyederhanakan arsitektur sistem dan mengoptimalkan performa melalui fungsi-fungsi yang dapat diproses langsung di dalam database.

Bacaan terkait

2 komentar

 
eususu 2024-02-07

Dari semua ini, saya pribadi sedang menggunakan postgREST, dan saya puas.
 
GN⁺ 2024-02-07
Opini Hacker News

  • Berbagi pengalaman dalam upaya menyederhanakan application stack

    Seorang pengguna mengatakan bahwa ia sering mencoba menyederhanakan application stack, tetapi seiring meningkatnya kompleksitas aplikasi, ia menyadari perlunya berbagai tech stack. Jika mencoba menyatukan semuanya ke dalam satu teknologi seperti Postgres, hal itu bisa terasa tidak nyaman. Meski begitu, memperluas teknologi yang sudah ada bisa lebih baik daripada menambahkan lapisan baru. Misalnya, menggunakan Postgres sebagai message queue jauh lebih mudah daripada memelihara message queue terpisah. Postgres juga sangat mudah diperluas di antara database, dan membangun teknologi di atasnya sangat menyenangkan.

  • Pendapat pembuat ParadeDB tentang ekstensibilitas Postgres

    Sebagai salah satu pembuat ParadeDB, ia menjelaskan bahwa mereka menyediakan fitur pencarian cepat dan analitik melalui ekstensi Postgres. Untuk workload kecil seperti di startup, masuk akal untuk tetap bekerja di dalam Postgres selama mungkin. Namun, ketika skala membesar, tidak semua hal bisa diselesaikan hanya dengan Postgres. Untuk menangani berbagai workload di dalam Postgres, sistem perlu dipisahkan sesuai kebutuhan tertentu agar mendapatkan skalabilitas dan ketahanan yang independen. Pada titik itu, diperlukan stack solusi yang terspesialisasi untuk tiap kebutuhan. Memang ada gerakan membangun komponen stack versi Postgres, tetapi tiap solusi pada akhirnya melampaui Postgres, dan ia tidak yakin akan ada solusi berbasis Postgres untuk semua komponen stack.

  • Pendapat tentang keputusan memakai sqlite saat memulai proyek baru

    Seorang pengguna memutuskan untuk selalu memulai proyek baru dengan sqlite, dan tidak akan berpindah sampai benar-benar diperlukan. Jika Postgres cocok untuk 90% kasus, maka sqlite cocok untuk 80% kasus, mudah untuk mulai digunakan, dan performanya juga baik. Saat vertical scaling gagal, kemungkinan besar Anda sudah puas dengan apa yang telah dibangun.

  • Keraguan seorang ahli C++ terhadap database

    Seorang ahli C++ yang tidak terlalu akrab dengan database mempertanyakan perlunya database. Ia berasal dari industri yang banyak menggunakan format file biner kustom, dan merasa database tampak menyelesaikan banyak masalah di permukaan, tetapi kenyataannya tidak demikian. Keterbatasan pada tipe data, masalah pembaruan, serta kompatibilitas antar SQL engine yang berbeda membuat penggunaan database tampak seperti ide buruk. Ia memahami manfaat interoperabilitas pada volume data besar, tetapi selain itu benar-benar mempertanyakan kebutuhan akan database.

  • Pendapat tentang fitur tambahan PostgreSQL

    Ia menunjukkan bahwa sebagian besar fitur tambahan tersebut sudah terintegrasi di MariaDB, sambil mengutip sebagian motivasi di balik klien HTTP PostgreSQL. Menanggapi gagasan bahwa akan bagus jika bisa menulis trigger yang memanggil layanan web, pengguna itu mengatakan bahwa pekerjaan seperti itu lebih baik diserahkan kepada orang lain, bukan dirinya.

  • Masalah penggabungan dengan pengalaman pengelolaan kode saat memakai fitur lanjutan

    Ia banyak menggunakan Postgres, tetapi setiap kali memakai fitur lanjutan, muncul masalah dalam menggabungkannya dengan semua hal baik dari dunia coding seperti version control, code review, tipe, testing, dan static analysis. Ia juga mengajukan pertanyaan tentang migration.

  • Keuntungan membuat prototipe fitur baru dengan stack yang ada

    Ia berbagi pengalaman bahwa membuat prototipe fitur baru terlebih dahulu lebih baik daripada langsung memperkenalkan sesuatu yang baru. Dengan kurasi yang hati-hati, prototipe awal dapat diubah menjadi kode produksi dengan stack yang sama. Namun, ketika sistem mulai mencapai batasnya, Anda mungkin merasa perlu Redis atau alat khusus lainnya. Yang penting adalah menulis API wrapper, lalu hanya mengubah implementasi internal saat diperlukan, serta menguji migration dengan baik. Ia menambahkan bahwa orang-orang akan terkejut melihat betapa lamanya keputusan teknis sebenarnya bisa ditunda.

  • Berbagi pengalaman pengguna yang memakai Postgres, Redis, dan S3

    Ia menggunakan kombinasi Postgres, Redis, dan S3, dan kombinasi itu sejauh ini tidak pernah salah. Kadang ia ingin mencoba Pub/Sub dengan Postgres, tetapi karena Redis tetap dibutuhkan untuk caching dan sidekiq, dan Redis juga sangat bagus, ia jadi tidak merasa perlu mencobanya.

  • Batasan Postgres untuk analisis data berskala besar

    Ia sangat menyukai Postgres, tetapi berbagi pengalaman bahwa saat skala data menjadi sangat besar, Postgres terasa tidak lagi cukup. Postgres sempurna untuk menangani workload tipe OLTP, tetapi jika membutuhkan dukungan OLAP yang lebih kuat, ia menyarankan menggunakan StarRocks. Pengalaman memindahkan data dari Postgres ke StarRocks untuk analisis sangat baik, dan StarRocks juga mendukung query langsung pada data lake.

  • Kebutuhan akan fitur kompresi jsonb di Postgres

    Ia menggunakan Mongo dan PG sekaligus, tetapi merasa PG jauh lebih sederhana sehingga ingin meninggalkan Mongo demi penyederhanaan. Yang ia butuhkan hanyalah kolom jsonb terkompresi, cukup bisa insert, select, dan delete tanpa update atau query. Ia ingin tetap mendapatkan rasio kompresi 80-90% untuk key JSON yang berulang seperti di Mongo, tanpa perlu perawatan tambahan.