Cách tận dụng Postgres
(github.com/Olshansk)- Kho lưu trữ này tập hợp và giới thiệu các công cụ cũng như ví dụ sử dụng Postgres cho nhiều mục đích khác nhau, theo định hướng “Keep It Simple Stupid, just use postgres”
- Danh sách được lấy cảm hứng từ bài viết Postgres for Everything của Amazing CTO và GitHub gist của @cpursley, và được duy trì vì các công cụ mới hoặc cách tận dụng mới trên nền Postgres liên tục xuất hiện
- Phạm vi rất rộng, bao gồm tác vụ cron, Postgres nhúng, hàng đợi thông điệp, phân tích, GIS, nhật ký kiểm toán, kiểm soát truy cập, tìm kiếm, chuỗi thời gian, NoSQL, đồ thị, HTTP, API, CDC, caching, kiểm thử, migration, tinh chỉnh hiệu năng, giám sát, mở rộng, UI, CLI, trực quan hóa, quản lý gói, bảo mật, cho đến sổ cái tài chính
- Mỗi mục sắp xếp các phần mở rộng Postgres, thư viện, nền tảng API, bài viết và công cụ chủ yếu dưới dạng liên kết; một số mục được liên hệ với các công nghệ cụ thể như DuckDB, pgvector, PostGIS, PgBouncer, GraphQL, CDC
- Người dùng muốn bổ sung ví dụ về đoạn mã, công cụ hoặc dự án cụ thể cần mở PR kèm liên kết và sử dụng pull request template mới
Mục đích và cách duy trì kho lưu trữ
- Mục tiêu của kho lưu trữ Postgres for Everything là cho thấy các cách dùng Postgres cho nhiều mục đích khác nhau
- Kho lưu trữ được lấy cảm hứng từ các tài liệu sau
- Vì các công cụ mới xuất hiện trên nền Postgres hoặc các cách tận dụng mới liên tục được tạo ra, kho này được duy trì như một nơi để theo dõi chúng
- Nếu có ví dụ khác, có thể gửi PR
- Để giới thiệu đoạn mã, công cụ hoặc dự án, cần mở PR kèm liên kết và sử dụng pull request template
Bài đọc và bài viết ví dụ
- Bao gồm các bài viết về khả năng mở rộng của Postgres, pattern, cách dùng hàm trong cơ sở dữ liệu, tối ưu hóa và tính năng của PostgreSQL
Chạy tác vụ, nhúng, hàng đợi
-
Cron Jobs
-
Embeddable Postgres
-
Message Queues
- tembo-io/pgmq
- SKIP LOCKED
- sequinstream/sequin: công cụ CDC gửi các hàng và thay đổi của Postgres tới các nền tảng streaming và hàng đợi như Kafka, SQS
- janbjorge/pgqueuer: thư viện hàng đợi tác vụ Python tận dụng PostgreSQL
- smartpricing/queen: hàng đợi thông điệp dựa trên PostgreSQL, cung cấp phân vùng FIFO độc lập, consumer group kiểu Kafka và exactly-once delivery
Phân tích, bản đồ, kiểm toán, quyền hạn
-
Analytics
- paradedb/pg_analytics: cung cấp phân tích data lake dựa trên DuckDB trong Postgres
- duckdb/pg_duckdb: phần mở rộng Postgres chính thức cho DuckDB
- BemiHQ/BemiDB: bản sao đọc Postgres được tối ưu cho phân tích
- Mooncake-Labs/pg_mooncake: phần mở rộng bổ sung lưu trữ dạng cột và thực thi vector hóa DuckDB bên trong Postgres
- ClickHouse/pg_clickhouse: chạy các truy vấn phân tích ClickHouse từ PostgreSQL mà không cần viết lại SQL
-
GIS & Mapping
-
Audit Logs
- supabase/supa_audit
- pgMemento/pgMemento
- pgaudit/pgaudit
- BemiHQ/Bemi: tự động theo dõi thay đổi dữ liệu PostgreSQL
-
Access Control & Authorization
Tìm kiếm, chuỗi thời gian, dạng cột, NoSQL, đồ thị
-
Full Text Search
- Postgres Full Text Search: tập hợp các liên kết liên quan
- pg_search: tìm kiếm toàn văn trên Postgres sử dụng BM25
- plpgsql_bm25: tìm kiếm BM25 được triển khai bằng PL/pgSQL
-
Vector Search
- pgvector/pgvector
- tensorchord/VectorChord: phần mở rộng tìm kiếm độ tương đồng vector cho PostgreSQL, hướng tới khả năng mở rộng, hiệu năng cao và hiệu quả về đĩa
- timescale/pgai: phần mở rộng dựa trên pgvector hỗ trợ phát triển RAG, tìm kiếm ngữ nghĩa và ứng dụng AI ngay trong Postgres
- timescale/pgvectorscale: triển khai chỉ mục vector DiskANN bổ sung cho pgvector
-
Hybrid Search
- plpgsql_bm25rrf.sql: tìm kiếm lai kết hợp BM25 và pgvector bằng Reciprocal Rank Fusion
-
Time Series
- timescale/timescaledb: PostgreSQL++ cho chuỗi thời gian và sự kiện
- tembo-io/pg_timeseries: phần mở rộng chuỗi thời gian mã nguồn mở cho PostgreSQL
-
Column Oriented
- paradedb/paradedb: Postgres cho tìm kiếm và phân tích
- pg_duckdb: lưu trữ dạng cột DuckDB trong Postgres
-
NoSQL
- JSON Types: hỗ trợ JSON native của PostgreSQL
- Using JSONB in PostgreSQL: cách lưu trữ và lập chỉ mục dữ liệu JSON trong PostgreSQL
-
Graph Data
- Apache Age: cơ sở dữ liệu đồ thị cho PostgreSQL, cung cấp khả năng xử lý và phân tích dữ liệu đồ thị trong cơ sở dữ liệu quan hệ
Dữ liệu bên ngoài, HTTP, API, GraphQL, CDC
-
Foreign Data
-
HTTP
-
API Platforms
- PostgREST: tạo RESTful API từ cơ sở dữ liệu PostgreSQL hiện có
- Hasura GraphQL Engine: nền tảng API dựa trên metadata
-
GraphQL and Alternative Query Languages
- PostGraphile: GraphQL API tự động cho PostgreSQL
- supabase/pg_graphql: phần mở rộng PostgreSQL cho phép truy vấn GraphQL bằng một hàm SQL duy nhất
- dosco/graphjin: tự động chuyển đổi GraphQL thành truy vấn SQL
- kaspermarstal/plprql: phần mở rộng PostgreSQL để viết hàm bằng PRQL
-
Events, Replication, CDC
- aws/pgactive: phần mở rộng sao chép của AWS để tạo cơ sở dữ liệu active-active
- xataio/pgstream: CLI và thư viện CDC gửi sao chép Postgres, bao gồm cả thay đổi DDL, tới đích xuất
- electric-sql/electric: HTTP API đồng bộ hóa Shapes của cơ sở dữ liệu Postgres
- SQL Notify
- debezium/debezium
- 2ndQuadrant/pglogical
Bộ nhớ đệm, kiểm thử, ứng dụng, migration
-
Caching
- tidwall/pogocache: lớp caching tập trung vào độ trễ và hiệu quả CPU
- readysettech/readyset
-
Unit Tests
-
HTML & Applications
-
Migrations
- purcell/postgresql-migrations
- Bytebase
- xataio/pgroll
- stripe/pg-schema-diff
- pgschema/pgschema: CLI mang đến quy trình migration schema khai báo kiểu Terraform cho Postgres
Hiệu năng, giám sát, mở rộng, UI
-
Performance Tuning
- Supabase Index Advisor
- Dexter
- HypoPG
- pg_hint_plan
- PGHero
- pg_incremental: phần mở rộng để xử lý batch tăng dần nhanh và đáng tin cậy
- pgassistant: trợ lý dành cho nhà phát triển, giúp hiểu và tối ưu hiệu năng PostgreSQL
-
Monitoring
-
Testing
- regresql: công cụ kiểm thử hồi quy truy vấn SQL hỗ trợ PostgreSQL
-
Scaling & Storage
- Snowflake-Labs/pg_lake: tận dụng Postgres như một hệ thống lakehouse độc lập, hỗ trợ giao dịch và truy vấn trên các bảng Iceberg trong object storage như S3
- pgdogdev/pgdog: transaction pooler và trình quản lý logical replication có khả năng sharding PostgreSQL
- pgbouncer/pgbouncer: connection pooler gọn nhẹ cho PostgreSQL
- orioledb.com: phần mở rộng PostgreSQL kết hợp ưu điểm của engine on-disk và in-memory
-
User Interfaces & Dashboards
- Baserow
- NocoDB
- AppSmith
- mathesar-foundation/mathesar: giao diện kiểu bảng tính cho phép người dùng ở nhiều trình độ kỹ thuật khác nhau xem, chỉnh sửa, truy vấn và cộng tác trên dữ liệu Postgres
Công cụ cho nhà phát triển, trực quan hóa, gói, bảo mật, tài chính
-
CLIs
- dbcli/pgcli: client Postgres cung cấp tự động hoàn thành và tô sáng cú pháp
- sosedoff/pgweb: trình khám phá cơ sở dữ liệu PostgreSQL đa nền tảng dựa trên web
- Maxteabag/sqlit: TUI cho cơ sở dữ liệu SQL, bao gồm PostgreSQL
-
Visualization
- dr-jts/pg_svg: tập hợp hàm PostgreSQL chuyển đổi PostGIS geometry thành tài liệu SVG có áp dụng style
- Evidence
- Metabase
- Hopara: nền tảng trực quan hóa dữ liệu thời gian thực cho sản xuất, IoT, khoa học sự sống và data lake
- posit-dev/ggsql: phần mở rộng SQL trực quan hóa dữ liệu khai báo dựa trên Grammar of Graphics
-
Package Management
-
Language Servers
- supabase/postgres-language-server: bộ công cụ ngôn ngữ và triển khai LSP cho Postgres
-
Data Privacy & Security
- neondatabase/postgresql_anonymizer: phần mở rộng PostgreSQL trực tiếp masking hoặc thay thế PII hay dữ liệu nhạy cảm về mặt thương mại
-
Financial Ledgers
- pgledger: sổ cái kế toán kép được triển khai bằng PostgreSQL
-
Miscellaneous
- Very comprehensive list of Postgres tooling
- Unsupported PostgreSQL features in Aurora DSQL: danh sách các tính năng PostgreSQL không được hỗ trợ trong AWS Aurora DSQL
1 bình luận
Ý kiến trên Hacker News
Khi quy mô tăng lên đến hơn 100 kỹ sư, không nên dùng một DB Postgres cho mọi thứ
Cuối cùng rất khó tránh tình huống database trở thành API
Nếu có năng lực lãnh đạo kỹ thuật để phân chia tốt ranh giới logic/vật lý và mở rộng sao cho mỗi đơn vị có Postgres riêng, thì “Postgres for everything” cũng là một lựa chọn vững chắc
Tuy nhiên, các CTO làm được việc khó như vậy hiếm hơn tưởng tượng
Phần lớn công ty sẽ không đạt tới hơn 100 kỹ sư, nên cứ ra mắt trước rồi lo những chuyện này muộn hơn nhiều cũng được
Khi thấy những công ty thậm chí chưa có 2 người dùng thực tế, chỉ có 1 kỹ sư quá tải, nhưng lại có 40 máy chủ và kiến trúc giả định một triệu kỹ sư cùng hàng chục tỷ lượt truy cập, ta cảm nhận được rằng overengineering khiến cuộc sống khó khăn hơn
Những người này thực sự đã ra mắt sản phẩm
Việc migrate sang nhiều database và đồng bộ thông tin người dùng là các cột mốc theo giai đoạn, không phải điều kiện tiên quyết cần có ở mọi thời điểm
Đặc biệt nếu bán shard single-tenant cho từng khách hàng, và kết quả là mỗi khách hàng có database riêng thì càng đúng
Việc vạch ranh giới phần mềm logic trước khi sản phẩm còn chưa biết domain và những tính năng có thể bán được là khá rủi ro
Thậm chí có thể ít mong manh hơn nhiều so với 100 service được expose qua GraphQL
Tôi thật sự thích Postgres, nhưng nên tránh expose nguyên xi API được tạo từ database cho người ngoài team
Làm vậy sẽ hạn chế rất nhiều khả năng thay đổi cách lưu trữ dữ liệu
Trước đây tôi từng viết về chủ đề này, và đến giờ suy nghĩ cũng không thay đổi nhiều
Bạn có lẽ sẽ không muốn kiểu liên kết chặt như thế này: https://wundergraph.com/blog/six-year-graphql-recap#generate...
Có phải ý là sau này dù đổi tên cột trong database cũng không muốn đổi API, nên sẽ thêm hẳn một lớp nữa để dịch định dạng A sang định dạng B không
Gần đây tôi thấy bực khi biết index của Postgres không hỗ trợ skip scan
Cũng không thể đưa ký tự null
\u0000vào chuỗiĐây là một DB tuyệt vời, nhưng vẫn có những khoảng trống kỳ lạ ở nhiều chỗ
https://wiki.postgresql.org/wiki/Loose_indexscan
https://stackoverflow.com/questions/28813409/are-null-bytes-...
Suy nghĩ đầu tiên của tôi là chuỗi có null thì đương nhiên nên bị từ chối
Việc những thứ kiểu cache cũng không phải tính năng hạng nhất cũng hơi đáng tiếc
Unlogged table khá dùng được và temporary table cũng tốt, nhưng nhìn chung vẫn phiền phức, gượng gạo và có cảm giác khác với thứ thực sự cần
PGQueuer là một hàng đợi tác vụ nhẹ cho Python, được xây dựng chỉ bằng PostgreSQL
Nó dùng
SKIP LOCKEDđể xử lý tác vụ hiệu quả và an toàn, đồng thời chọn thiết kế tối giản để giữ sự đơn giản mà vẫn đảm bảo hiệu năngNếu bạn đã dùng Postgres và muốn quản lý tác vụ nền theo cách thân thiện với Python mà không cần thêm hạ tầng, đây là thứ đáng xem: GitHub - https://github.com/janbjorge/pgqueuer
Dự án này thì ngược lại, đi theo hướng đưa vào các tính năng như dashboard, workflow, worker chế độ hỗn hợp
Nếu xem phần các dự án tương tự trong tài liệu, sẽ thấy nhiều hàng đợi tác vụ dựa trên Postgres
SKIP LOCKEDthực sự hiệu quả đến vậyNếu có cả tác vụ rất ngắn lẫn tác vụ chạy lâu, trong lúc một tác vụ dài kết thúc thì hàng trăm, hàng nghìn tác vụ ngắn có thể đã chạy xong
Khi đó các hàng của tác vụ dài vẫn bị khóa, nên chúng bị bỏ qua hàng trăm lần trong bảng tác vụ
Càng có nhiều tác vụ chạy lâu đồng thời, lãng phí do liên tục bỏ qua các hàng bị khóa càng lớn; vì vậy khi tải thấp thì ổn, nhưng một cấu trúc chuyển chúng sang bảng “đang chạy” riêng có thể hiệu quả hơn
Vì ở một số dự án tôi bị ràng buộc với MariaDB/MySQL nên gần đây đã so sánh với PostgreSQL, và thấy bên đó cũng có khá nhiều tính năng mở rộng như JSON, bảng tạm có system-versioning, lưu trữ dạng cột và vector store
Các tính năng như
LISTEN/NOTIFYthì có vẻ còn thiếu, nhưng nhìn chung tôi ngạc nhiên vì họ đã bắt kịp khá nhiềuTuy nhiên, trong nhiều ứng dụng legacy, có lẽ những tính năng này hầu như sẽ không được dùng
Sẽ rất tốt nếu thêm cả phần quảng bá này: https://github.com/jankovicsandras/plpgsql_bm25
Đây là tìm kiếm BM25 mã nguồn mở dựa trên PL/pgSQL dành cho những môi trường không thể dùng extension Rust, v.v.; cũng hỗ trợ tìm kiếm hybrid bằng pgvector và Reciprocal Rank Fusion
Trên Supabase cũng từng thảo luận đúng chủ đề này
https://github.com/orgs/supabase/discussions/18061#discussio...
Sáng nay thấy câu “lấy cảm hứng từ bài viết này của Amazing CTO”, rồi phát hiện bài của mình được tham chiếu, cảm giác thật tuyệt
https://www.amazingcto.com/postgres-for-everything/
Full-text search của Postgres rất hạn chế và không thân thiện với người dùng
Có một API duy nhất để truy cập nhiều tính năng có vẻ mang lại nhiều lợi ích
Ví dụ, thay vì tích hợp với message queue, chỉ cần
INSERTlà giảm đáng kể ma sátVector search thì đương nhiên là dễ hiểu
Đã có thể làm tất cả bằng một thứ thì không có lý do gì phải dùng hai cơ sở dữ liệu
Tuy nhiên việc tạo HTML bằng Postgres thì tôi thấy đáng ngờ
Chưa tự thử, nhưng khó tưởng tượng đó là một cách thực tế để xây dựng giao diện người dùng
Mình muốn biết có tài liệu hay nào về tự host cơ sở dữ liệu Postgres không
Mình định tự vận hành DB server cho nhiều dự án cá nhân, nên muốn biết rõ các mẹo và best practice về backup, tối ưu, có nên dùng Docker hay không, v.v.
Dễ hơn tưởng tượng
https://youtube.com/playlist?list=PLBrWqg4Ny6vVwwrxjgEtJgdre...
Dễ nâng cấp tại chỗ, backup đơn giản qua Litestream, v.v.
Nâng cấp major version của Postgres là lý do chính khiến mình không tự host, nhưng có lẽ cần nghĩ lại
pg_dumplà lựa chọn tốt và đơn giảnĐể tuning thì postgresqlco.nf rất tuyệt
https://postgresqlco.nf/tuning-guide
Mình muốn liên tục deploy các dự án MVP nhỏ, nhưng không muốn trả tiền một dịch vụ DB riêng cho từng dự án trên Render
https://www.thenile.dev/pricing có vẻ hỗ trợ số lượng database không giới hạn
Trên cloud hoặc Kubernetes thì tốt hơn là dùng DB được quản lý; theo mình biết, tự thiết lập DB trên Kubernetes khó vì vấn đề filesystem
Tôi đã mất gần 2 tuần để tích hợp Apache Age cho dữ liệu đồ thị, rồi nhận ra dự án đang đình trệ và khá lộn xộn
Không nên tin nguyên xi những danh sách kiểu này
Giờ tôi đang kỳ vọng kết quả tốt hơn với DGraph, nhưng các graph database có vẻ nằm trên một hệ sinh thái thiếu ổn định
Chắc là có vài trường hợp, nhưng tôi không nghĩ ra ngay; ngược lại thì từng thấy graph DB được dùng ở những nơi không phù hợp
Lý do gì để không chọn nó thay Neo4j?
Tất cả dự án graph DB tôi từng tham gia đều dùng Neo4j, nên nếu có lựa chọn thay thế tốt thì tôi muốn biết
Nếu có thể chia sẻ chi tiết hơn một chút thì tốt
Lần cuối kiểm tra, Apache Age kém Neo4j khá xa
Về mặt kỹ thuật thì nó tồn tại và cũng có quyền được đưa vào danh sách, nhưng tôi không khuyến nghị cho workload nghiêm túc