Cách tận dụng Postgres

 (github.com/Olshansk)
8 điểm bởi GN⁺ 2024-12-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • 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ụ

Chạy tác vụ, nhúng, hàng đợi

  • Cron Jobs

  • Embeddable Postgres

    • PGLite: đóng gói bản build WASM Postgres dưới 10MB có thể chạy trong trình duyệt, Node.js, Bun và Deno dưới dạng thư viện TypeScript
    • pgmicro: bản tái triển khai PostgreSQL in-process dựa trên engine lưu trữ tương thích SQLite

  • 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

Tìm kiếm, chuỗi thời gian, dạng cột, NoSQL, đồ thị

  • Full Text Search

  • 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

  • Column Oriented

  • NoSQL

  • 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

Bộ nhớ đệm, kiểm thử, ứng dụng, migration

Hiệu năng, giám sát, mở rộng, UI

  • Performance Tuning

  • Monitoring

    • StatsMgr: hỗ trợ quản lý thống kê như WAL, SLRU, checkpointing, v.v.
    • pgMonitor: giải pháp giám sát trực quan hóa metric bằng Prometheus, Grafana, SQL Exporter và phần mở rộng pgMonitor

  • 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

Công cụ cho nhà phát triển, trực quan hóa, gói, bảo mật, tài chính

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-09
Ý 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

    • Không cần lập kế hoạch quá sớm
      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
    • Không cần đặt “thành công” trong ngoặc kép
      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
    • Tôi nghĩ “database trở thành API” chẳng phải lại chính là ý chính của Postgres for everything sao
    • Database-as-the-API cũng có thể mở rộng được khá xa
      Đặ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
    • Nếu trừu tượng hóa đúng cách bằng stored procedure và view, cách dùng database làm API cũng hoạt động tốt
      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...

    • Tôi thắc mắc liên kết chặt rốt cuộc có vấn đề gì
      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
    • Dùng view làm lớp trung gian chẳng phải được sao

  • 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 \u0000 và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-...

    • Tôi tự hỏi có trường hợp sử dụng hợp lý nào cho việc đưa ký tự null vào trong chuỗi không
      Suy nghĩ đầu tiên của tôi là chuỗi có null thì đương nhiên nên bị từ chối
    • Nếu cần ký tự null, tôi muốn giới thiệu blob
    • Đúng vậy, hiện tại skip index scan cần SQL tự định nghĩa
      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ăng
    Nế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

    • Một lựa chọn Python giai đoạn đầu khác là https://github.com/TkTech/chancy
      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
    • Tôi luôn nghi ngờ tuyên bố rằng SKIP LOCKED thực sự hiệu quả đến vậy
      Nế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
    • Tôi tò mò lợi thế so với hệ thống hàng đợi tác vụ chuyên dụng là gì

  • 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/NOTIFY thì 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ều
    Tuy 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

  • 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/

    • Đề xuất “dùng Postgres cho full-text search thay vì Elastic” thì không ổn lắm
      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 INSERT là giảm đáng kể ma sát
    Vector 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.

    • Kênh YouTube này có nhiều video giải thích cách cài đặt, cấu hình Postgres trên một máy Linux thông thường và làm cho nó chạy với high availability
      Dễ hơn tưởng tượng
      https://youtube.com/playlist?list=PLBrWqg4Ny6vVwwrxjgEtJgdre...
    • Khi tự host, vì sự đơn giản nên mình nghiêng về SQLite hơn
      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
    • Với backup, nếu mới bắt đầu thì pg_dump là lựa chọn tốt và đơn giản
      Để tuning thì postgresqlco.nf rất tuyệt
      https://postgresqlco.nf/tuning-guide
    • Có thể không phải câu trả lời bạn đang tìm, nhưng vì lý do tương tự gần đây mình đã tìm hiểu các dịch vụ
      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
    • Nếu on-premises thì nên dùng container, nhưng để thư mục dữ liệu là volume được mount
      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

    • Tôi tò mò graph database phù hợp với những use case nào
      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
    • Tôi muốn biết Dgraph có những cạm bẫy nào
      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
    • Apache Age cũng ở tình trạng tương tự
      Nếu có thể chia sẻ chi tiết hơn một chút thì tốt
    • Tôi cũng đến để nói điều này
      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