42P by neo 15일전 | favorite | 댓글 2개
  • PostgreSQL을 각 분야에 사용하는 방법에 대한 링크를 정리한 페이지
    • 백그라운드잡, 메시지 큐, GIS, Audit Log, 접근 제어, 권한 관리, 검색, 시계열, 그래프 데이터, 외부 데이터, HTTP, API, 이벤트/복제/CDC, 유닛 테스트, 마이그레이션, 대시보드/UI, 데이터 시각화, HTML과 어플리케이션, LSP(랭귀지 서버)

PostgreSQL is Enough

배경 작업

  • pg_cron을 통해 PostgreSQL에서 스케줄링된 작업을 관리할 수 있음.

메시지 큐

  • PostgreSQL을 메시지 큐 기술로 선택하는 방법에 대한 정보 제공.
  • pgmq는 PostgreSQL을 기반으로 한 메시지 큐 시스템임.

GIS/지도

  • PostGIS는 PostgreSQL에 지리공간 데이터베이스 기능을 추가함.

감사 로그

  • pgMementopgaudit는 PostgreSQL에서 변경 사항을 추적하고 감사 로그를 관리함.

접근 제어

  • acl은 PostgreSQL에서 접근 제어 리스트를 관리하는 데 사용됨.

인증

  • PostgreSQL의 pgcrypto 모듈과 pgjwt는 데이터베이스 내에서 인증을 처리함.

검색

  • PostgreSQL의 전문 검색 기능과 관련된 유용한 링크들 제공.
  • paradedb, pg_embedding, pgvector는 PostgreSQL에서 검색 기능을 향상시킴.

시계열 데이터

  • timescaledb는 PostgreSQL을 확장하여 시계열 데이터를 관리함.

그래프 데이터

  • Apache AGE는 PostgreSQL을 확장하여 그래프 데이터베이스 기능을 제공함.

외부 데이터

  • wrappers는 PostgreSQL에서 외부 데이터 소스를 통합함.

HTTP

  • pgsql-httppg_net은 PostgreSQL에서 HTTP 요청을 처리함.

API

  • PostgREST, graphql-engine, postgraphile, pg_graphql은 PostgreSQL을 기반으로 한 API 서버를 구축함.

이벤트, 복제, CDC

  • PostgreSQL의 NOTIFY 명령어와 walex, peerdb, debezium, pglogical은 데이터 변경을 추적하고 복제 기능을 제공함.

단위 테스트

  • pgtap은 PostgreSQL 데이터베이스의 단위 테스트를 위한 도구임.

마이그레이션

  • postgresql-migrationsbytebase는 PostgreSQL 데이터베이스 마이그레이션을 관리함.

대시보드 / UI

  • Baserow, NocoDB, AppSmith는 사용자 인터페이스와 대시보드를 제공함.

데이터 시각화

  • EvidenceMetabase는 데이터 시각화 도구임.

HTML과 애플리케이션

  • SQLpage, Omnigres, pg_render, plmustache는 PostgreSQL 데이터를 웹 애플리케이션에 통합함.

언어 서버

  • postgres_lsp는 PostgreSQL을 위한 언어 서버 프로토콜 지원을 제공함.

무엇이 빠졌나요?

  • 댓글을 통해 누락된 내용을 공유 바람

GN⁺의 의견

  • PostgreSQL은 다양한 확장 기능과 도구를 통해 단순한 데이터베이스 관리 시스템을 넘어서는 다재다능한 플랫폼임을 보여줌.
  • 이 글은 PostgreSQL을 사용하여 다양한 애플리케이션 요구 사항을 충족시킬 수 있는 방법을 제시함으로써, 개발자들에게 유용한 자원을 제공함.
  • 특히, 데이터베이스 내에서 직접 처리할 수 있는 기능들을 통해 시스템 아키텍처를 단순화하고 성능을 최적화할 수 있는 잠재력을 강조함.

이 중에 postgREST 개인적으로 사용중인데, 만족스럽습니다.

Hacker News 의견
  • 응용 프로그램 스택 간소화 시도에 대한 경험 공유

    한 사용자는 응용 프로그램 스택을 간소화하려는 시도를 자주 하지만, 응용 프로그램의 복잡성이 증가함에 따라 다양한 기술 스택의 필요성을 깨닫게 됨. 모든 것을 Postgres와 같은 단일 기술에 통합하려고 하면 불편함을 느낄 수 있음. 그럼에도 불구하고, 기존 기술을 확장하는 것이 새로운 계층을 추가하는 것보다 나을 수 있음. 예를 들어, Postgres를 메시지 큐로 사용하는 것이 별도의 메시지 큐를 유지하는 것보다 훨씬 쉬움. Postgres는 데이터베이스 중에서도 확장성이 뛰어나며, 이를 기반으로 기술을 구축하는 것이 매우 재미있음.

  • ParadeDB 제작자의 Postgres 확장성에 대한 의견

    ParadeDB의 제작자 중 한 명으로, Postgres 확장을 통해 빠른 검색과 분석 기능을 제공함. 스타트업과 같이 작은 워크로드의 경우 가능한 한 오래 Postgres 내에서 작업하는 것이 합리적임. 그러나 규모가 커지면 Postgres만으로는 모든 것을 해결할 수 없음. Postgres 내에서 다양한 워크로드를 처리하려면 특정 요구 사항에 맞게 시스템을 분리하고 독립적인 확장성과 복원력을 확보해야 함. 이 시점에서 각 요구 사항에 맞는 전문화된 솔루션 스택이 필요함. Postgres 버전의 스택 구성 요소를 구축하는 움직임이 있지만, 각 솔루션은 Postgres를 넘어서며, 모든 스택 구성 요소에 대한 Postgres 기반 솔루션이 있을 것이라고는 생각하지 않음.

  • 새 프로젝트 시작 시 sqlite 사용 결정에 대한 의견

    한 사용자는 새 프로젝트를 시작할 때마다 sqlite로 시작하고, 반드시 필요할 때까지 전환하지 않기로 결정함. Postgres가 90%의 경우에 적합하다면, sqlite는 80%의 경우에 적합하며, 시작하기 쉽고 성능도 좋음. 수직 확장이 실패할 때, 이미 구축한 것에 만족할 것임.

  • 데이터베이스에 대한 C++ 전문가의 의문

    데이터베이스에 익숙하지 않은 C++ 전문가가 데이터베이스의 필요성에 대해 의문을 제기함. 사용자는 맞춤형 바이너리 파일 형식을 많이 사용하는 산업에서 왔으며, 데이터베이스가 표면적으로 많은 문제를 해결하는 것처럼 보이지만 실제로는 그렇지 않다고 느낌. 데이터 유형에 대한 제한, 업데이트 문제, 다른 SQL 엔진 간의 호환성 문제 등이 데이터베이스 사용을 나쁜 아이디어로 보이게 함. 대규모 데이터 볼륨에서의 상호 운용성 이점을 이해하지만, 그 외의 경우 데이터베이스의 필요성을 진지하게 묻고 있음.

  • PostgreSQL 추가 기능에 대한 의견

    대부분의 추가 기능이 MariaDB에 이미 내장되어 있음을 지적하며, PostgreSQL HTTP 클라이언트의 동기 부여 중 일부를 인용함. 웹 서비스를 호출하는 트리거를 작성할 수 있다면 좋을 것이라는 아이디어에 대해, 사용자는 그런 작업을 자신보다는 다른 사람에게 맡기겠다는 의견을 표함.

  • 고급 기능 사용 시 코드 관리 경험과의 결합 문제

    Postgres를 광범위하게 사용하지만, 고급 기능을 사용할 때마다 버전 관리, 코드 리뷰, 타입, 테스트, 정적 분석 등 코딩의 모든 좋은 점과 결합하는 문제가 발생함. 마이그레이션에 대한 질문을 함.

  • 기존 스택으로 새 기능 프로토타입 제작의 장점

    새 기능을 프로토타입으로 먼저 제작하는 것이 새로운 것을 도입하는 것보다 낫다고 경험을 공유함. 신중한 큐레이션을 통해 초기 프로토타입을 동일한 스택으로 생산 코드로 전환할 수 있음. 하지만 시스템이 한계에 부딪히면 Redis나 다른 전문 도구가 필요하다고 느낄 수 있음. 중요한 것은 API 래퍼를 작성하고, 필요할 때 내부 구현만 변경하고 마이그레이션을 잘 테스트하는 것임. 기술 결정을 얼마나 오래 미룰 수 있는지 사람들이 놀랄 정도라고 언급함.

  • Postgres, Redis, S3를 사용하는 사용자의 경험 공유

    Postgres, Redis, S3의 조합을 사용하며, 이 조합이 아직까지 잘못된 적이 없음을 밝힘. 가끔 Postgres로 Pub/Sub을 시도하고 싶지만, 어차피 캐싱과 sidekiq에 Redis가 필요하고, Redis도 뛰어나기 때문에 굳이 시도하지 않음.

  • 대규모 데이터 분석에 대한 Postgres의 한계

    Postgres를 매우 좋아하지만, 데이터 규모가 매우 클 때 Postgres가 충분하지 않다고 느낀 경험을 공유함. OLTP 유형의 워크로드를 처리하는 데는 Postgres가 완벽하지만, OLAP 지원이 더 필요한 경우 StarRocks를 사용할 것을 권장함. 데이터 분석을 위해 Postgres에서 StarRocks로 데이터를 가져오는 경험이 훌륭하며, StarRocks는 데이터 레이크에서의 직접 쿼리도 지원함.

  • Postgres의 jsonb 압축 기능에 대한 요구

    Mongo와 PG를 모두 사용하지만, PG가 훨씬 간단하여 Mongo를 단순화를 위해 포기하고 싶음을 표현함. 필요한 것은 단순히 압축된 jsonb 컬럼으로, 업데이트나 쿼리 없이 삽입, 선택, 삭제만 가능하면 됨. Mongo에서와 같이 반복적인 json 키에 대해 80-90% 압축률을 유지하면서 유지 관리가 필요 없음.