PostgreSQL là đủ

 (gist.github.com/cpursley)
44 điểm bởi GN⁺ 2024-02-07 | 2 bình luận | Chia sẻ qua WhatsApp
  • Trang tổng hợp các liên kết về cách sử dụng PostgreSQL trong nhiều lĩnh vực khác nhau
    • tác vụ nền, hàng đợi tin nhắn, GIS, nhật ký kiểm toán, kiểm soát truy cập, quản lý quyền, tìm kiếm, chuỗi thời gian, dữ liệu đồ thị, dữ liệu bên ngoài, HTTP, API, sự kiện/nhân bản/CDC, kiểm thử đơn vị, migration, bảng điều khiển/UI, trực quan hóa dữ liệu, HTML và ứng dụng, LSP (Language Server)

PostgreSQL is Enough

Tác vụ nền

  • Có thể quản lý các tác vụ được lên lịch trong PostgreSQL thông qua pg_cron.

Hàng đợi tin nhắn

  • Cung cấp thông tin về cách chọn PostgreSQL làm công nghệ hàng đợi tin nhắn.
  • pgmq là một hệ thống hàng đợi tin nhắn dựa trên PostgreSQL.

GIS/Bản đồ

  • PostGIS bổ sung khả năng cơ sở dữ liệu không gian địa lý cho PostgreSQL.

Nhật ký kiểm toán

  • pgMemento và pgaudit theo dõi thay đổi và quản lý nhật ký kiểm toán trong PostgreSQL.

Kiểm soát truy cập

  • acl được dùng để quản lý danh sách kiểm soát truy cập trong PostgreSQL.

Xác thực

  • Mô-đun pgcrypto và pgjwt của PostgreSQL xử lý xác thực ngay trong cơ sở dữ liệu.

Tìm kiếm

  • Cung cấp các liên kết hữu ích liên quan đến tính năng tìm kiếm toàn văn của PostgreSQL.
  • paradedb, pg_embedding, pgvector giúp tăng cường khả năng tìm kiếm trong PostgreSQL.

Dữ liệu chuỗi thời gian

  • timescaledb mở rộng PostgreSQL để quản lý dữ liệu chuỗi thời gian.

Dữ liệu đồ thị

  • Apache AGE mở rộng PostgreSQL để cung cấp tính năng cơ sở dữ liệu đồ thị.

Dữ liệu bên ngoài

  • wrappers tích hợp các nguồn dữ liệu bên ngoài vào PostgreSQL.

HTTP

  • pgsql-http và pg_net xử lý các yêu cầu HTTP trong PostgreSQL.

API

  • PostgREST, graphql-engine, postgraphile, pg_graphql xây dựng máy chủ API dựa trên PostgreSQL.

Sự kiện, nhân bản, CDC

  • Lệnh NOTIFY của PostgreSQL cùng với walex, peerdb, debezium, pglogical theo dõi thay đổi dữ liệu và cung cấp khả năng nhân bản.

Kiểm thử đơn vị

  • pgtap là công cụ để kiểm thử đơn vị cho cơ sở dữ liệu PostgreSQL.

Migration

  • postgresql-migrations và bytebase quản lý migration cho cơ sở dữ liệu PostgreSQL.

Bảng điều khiển / UI

  • Baserow, NocoDB, AppSmith cung cấp giao diện người dùng và bảng điều khiển.

Trực quan hóa dữ liệu

  • Evidence và Metabase là các công cụ trực quan hóa dữ liệu.

HTML và ứng dụng

  • SQLpage, Omnigres, pg_render, plmustache tích hợp dữ liệu PostgreSQL vào các ứng dụng web.

Language Server

  • postgres_lsp cung cấp hỗ trợ giao thức Language Server cho PostgreSQL.

Còn thiếu gì?

  • Hãy chia sẻ những nội dung còn thiếu qua phần bình luận

Ý kiến của GN⁺

  • PostgreSQL cho thấy đây là một nền tảng đa năng, vượt xa một hệ quản trị cơ sở dữ liệu đơn thuần, nhờ vào nhiều phần mở rộng và công cụ đa dạng.
  • Bài viết này cung cấp tài nguyên hữu ích cho các nhà phát triển bằng cách gợi ý những cách dùng PostgreSQL để đáp ứng nhiều nhu cầu ứng dụng khác nhau.
  • Đặc biệt, bài viết nhấn mạnh tiềm năng đơn giản hóa kiến trúc hệ thống và tối ưu hiệu năng thông qua các chức năng có thể được xử lý trực tiếp trong cơ sở dữ liệu.

Bài viết liên quan

2 bình luận

 
eususu 2024-02-07

Trong số này, cá nhân tôi đang dùng postgREST và khá hài lòng.
 
GN⁺ 2024-02-07
Ý kiến Hacker News

  • Chia sẻ kinh nghiệm về việc cố gắng đơn giản hóa stack ứng dụng

    Một người dùng chia sẻ rằng họ thường cố gắng đơn giản hóa stack ứng dụng, nhưng khi độ phức tạp của ứng dụng tăng lên thì lại nhận ra sự cần thiết của nhiều stack công nghệ khác nhau. Nếu cố gắng hợp nhất mọi thứ vào một công nghệ duy nhất như Postgres, bạn có thể cảm thấy bất tiện. Dù vậy, mở rộng công nghệ hiện có vẫn có thể tốt hơn việc thêm một lớp mới. Ví dụ, dùng Postgres làm hàng đợi thông điệp dễ hơn rất nhiều so với việc duy trì một message queue riêng. Ngay trong các cơ sở dữ liệu, Postgres cũng rất linh hoạt để mở rộng, và việc xây dựng công nghệ dựa trên nó rất thú vị.

  • Ý kiến của một nhà sáng lập ParadeDB về khả năng mở rộng của Postgres

    Là một trong những người tạo ra ParadeDB, người này cho biết họ cung cấp khả năng tìm kiếm và phân tích nhanh thông qua các extension của Postgres. Với các workload nhỏ như ở startup, việc ở lại trong Postgres càng lâu càng hợp lý. Tuy nhiên, khi quy mô tăng lên thì không thể giải quyết mọi thứ chỉ với Postgres. Để xử lý nhiều loại workload khác nhau trong Postgres, cần tách hệ thống theo từng yêu cầu cụ thể và bảo đảm khả năng mở rộng cũng như khả năng phục hồi độc lập. Ở giai đoạn đó, cần một stack giải pháp chuyên biệt cho từng nhu cầu. Dù đang có xu hướng xây dựng các thành phần stack theo phiên bản Postgres, nhưng mỗi giải pháp rồi cũng sẽ vượt ra ngoài Postgres, và người này không cho rằng sẽ có lời giải dựa trên Postgres cho mọi thành phần của stack.

  • Ý kiến về quyết định dùng sqlite khi bắt đầu dự án mới

    Một người dùng nói rằng mỗi khi bắt đầu dự án mới, họ sẽ bắt đầu với sqlite và chỉ chuyển đi khi thực sự cần thiết. Nếu Postgres phù hợp trong 90% trường hợp thì sqlite cũng phù hợp trong 80% trường hợp, lại dễ bắt đầu và hiệu năng tốt. Khi mở rộng theo chiều dọc không còn hiệu quả, ít nhất bạn cũng sẽ hài lòng với những gì mình đã xây dựng.

  • Thắc mắc của một chuyên gia C++ về cơ sở dữ liệu

    Một chuyên gia C++ không quen với cơ sở dữ liệu đặt câu hỏi về sự cần thiết của chúng. Người này đến từ một ngành dùng rất nhiều định dạng tệp nhị phân tùy chỉnh, và cảm thấy cơ sở dữ liệu thoạt nhìn có vẻ giải quyết được nhiều vấn đề nhưng thực tế lại không hẳn như vậy. Các ràng buộc về kiểu dữ liệu, vấn đề cập nhật và khác biệt tương thích giữa các SQL engine khiến việc dùng cơ sở dữ liệu có vẻ là một ý tưởng tồi. Họ hiểu lợi ích về khả năng tương tác ở quy mô dữ liệu lớn, nhưng ngoài ra vẫn nghiêm túc đặt câu hỏi liệu cơ sở dữ liệu có thực sự cần thiết hay không.

  • Ý kiến về các tính năng bổ sung của PostgreSQL

    Một người chỉ ra rằng phần lớn các tính năng bổ sung đó đã được tích hợp sẵn trong MariaDB, đồng thời trích dẫn một phần động cơ đằng sau HTTP client của PostgreSQL. Trước ý tưởng rằng sẽ rất hay nếu có thể viết trigger để gọi web service, người này bày tỏ quan điểm rằng họ muốn để người khác làm việc đó thay mình.

  • Vấn đề kết hợp với trải nghiệm quản lý mã khi dùng tính năng nâng cao

    Có người dùng Postgres rất rộng rãi, nhưng mỗi khi dùng các tính năng nâng cao thì lại gặp vấn đề trong việc kết hợp với mọi mặt tốt đẹp của lập trình như quản lý phiên bản, code review, type, test và phân tích tĩnh. Họ đặt câu hỏi về migration.

  • Ưu điểm của việc tạo prototype tính năng mới bằng stack hiện có

    Một người chia sẻ kinh nghiệm rằng trước tiên nên làm prototype cho tính năng mới bằng stack hiện có thay vì đưa thứ mới vào ngay. Nếu chọn lọc cẩn thận, prototype ban đầu có thể được chuyển thành mã production trên cùng stack. Nhưng khi hệ thống chạm trần, bạn có thể cảm thấy cần Redis hoặc một công cụ chuyên dụng khác. Điều quan trọng là viết API wrapper, rồi khi cần chỉ thay đổi phần triển khai bên trong và kiểm thử migration thật kỹ. Họ nói rằng mọi người sẽ ngạc nhiên khi thấy có thể trì hoãn các quyết định công nghệ lâu đến mức nào.

  • Chia sẻ kinh nghiệm của người dùng dùng Postgres, Redis và S3

    Một người dùng cho biết họ sử dụng kết hợp Postgres, Redis và S3, và cho đến nay bộ ba này chưa từng khiến họ thất vọng. Thỉnh thoảng họ muốn thử Pub/Sub bằng Postgres, nhưng vì Redis đã cần cho caching và sidekiq, mà Redis cũng rất xuất sắc, nên họ không thấy cần phải thử.

  • Giới hạn của Postgres với phân tích dữ liệu quy mô lớn

    Có người chia sẻ rằng họ rất thích Postgres, nhưng khi quy mô dữ liệu trở nên rất lớn thì Postgres không còn đủ nữa. Postgres hoàn hảo để xử lý các workload kiểu OLTP, nhưng nếu cần hỗ trợ OLAP nhiều hơn thì họ khuyên dùng StarRocks. Trải nghiệm đưa dữ liệu từ Postgres sang StarRocks để phân tích rất tuyệt, và StarRocks cũng hỗ trợ truy vấn trực tiếp trên data lake.

  • Nhu cầu về tính năng nén jsonb của Postgres

    Một người dùng cả Mongo lẫn PG, nhưng cảm thấy PG đơn giản hơn nhiều nên muốn bỏ Mongo để đơn giản hóa hệ thống. Điều họ cần chỉ là một cột jsonb được nén, chỉ cần hỗ trợ insert, select và delete mà không cần update hay query phức tạp. Họ muốn giữ được tỷ lệ nén 80-90% cho các khóa JSON lặp lại giống như trong Mongo mà không cần công sức bảo trì.