50P by xguru 2022-12-13 | favorite | 댓글 13개
  • Postgres는 (수백만명의 사용자까지) 수많은 백엔드 기술을 대체 가능
    → Kafka, RabbitMQ, Mongo, Redis,..
  • 캐시에 Redis 대신 UNLOGGED 테이블에 TEXT 를 JSON 형으로 사용
    • 스토어드 프로시저로 데이터에 대한 만료기간을 설정
  • 메시지큐(Kafka) : SKIP LOCKED
  • 데이터 웨어하우스는 Postgres+TimescaleDB
  • Mongo 대신 JSONB를 저장하고 검색 및 인덱싱
  • pg_cron 으로 메일 전송 같은 CRON 데몬으로 사용
  • Geospacial 쿼리에 사용
  • Elastic 대신 Fulltext 검색에 사용
  • DB내에서 JSON을 생성해서 서버사이드 코드 없이 API에 바로 전달하기
  • GraphQL 어댑터로 GraphQL도 지원

음.. 각 앱에서 지원하는 더 많은 기능이 필요하지 않다면 기본적인 컨셉은 postgres 로 충분하다 정도인 듯 하네요.
각 앱들은 위에서 대체하고있는 플로우 보다 더 많은 기능을 사용할 수 있으니까요.

인터페이스만 잘 잡고 쓰면 터무니없는 이야기는 아니라고 봅니다. 다만 캐시/메시지큐 정도는 레디스한테 맡겨도 괜찮다고 봐요

저도 최근 위 글과 같은 비슷한 생각을 하고 있습니다. 물론 대규모 서비스에는 최대한 분산해서 리스크를 분산하는게 좋겠지만, 종종 소규모 외주할 때 별도 nosql 안쓰고 postgres jsonb 타입 활용하면 훨씬 활용도가 좋았습니다. RDB + NoSQL 을 복합적으로 쓰는 듯한 사용성과 소형프로젝트 내에선 충분한 성능이였습니다.

하나로 모든걸 다 하는만큼 모든 리스크 포인트가 한곳에..!

몇몇은 대체할 제품이 없던 시절에 실제로 RDB로 하던 일이지만, Redis, Kafka, Cron 같은 것들은 주요한 이점을 대체하지 못하는 것처럼 보이네요. 재미로 보고 넘어가는 정도의 아이디어인 것 같습니다.

뭔가 하나로 다하는걸 좋아하시는 분들에겐 딱 좋겠네요

저는 Geospacial때문에 postgres를 썼었는데요.
다른 DB대비 10~100배정도 빨랐습니다.. geo쪽은 압도적이더라고요.

단 다들 아시는것처럼 데이터가 많아져서 vacuum 잘못 돌아가면 지옥을 경험을 합니다..

오 여러트릭들이 있네요

다만 첫번째 UNLOGGED 와 스토어드 프로시저 조합은 차라리 레디스 쓰는게 훨씬 깔끔할 것 같긴 합니다 ㅎㅎ

몇년 전이지만 JSONB 쓰다가 부하가 심해지면 kv 패턴에 맞는거 골라서 redis로 빼는 식으로 작업한 적이 있었는데, 쾌적한 경험이었습니다.

흥미로운 의견이네요.

어그로성 제목이지만, 나름 생각해 볼만한 주제라 그대로 옮겨 봤습니다.
초기 MVP를 하는데 너무 많은 컴포넌트들을 도입하는 것도 문제긴 하니까요.

좋은컨셉같아보입니다