GN⁺: Redis가 필요할까? PostgreSQL이 큐잉, 락킹, 그리고 pub/sub 기능을 제공하는데 (2021)

• 사용 사례 1: 작업 큐잉

  • Redis는 웹 서비스에서 백그라운드 작업을 조정하는 데 자주 사용됨.
  • PostgreSQL 9.5 버전 이후 SKIP LOCKED 옵션을 사용하여 작업 큐잉을 구현할 수 있음.
  • 이 옵션은 잠금 대기 없이 작업을 선택할 수 있게 하여 여러 작업자가 동일한 작업을 동시에 처리하지 않도록 보장함.

• 사용 사례 2: 애플리케이션 잠금

  • Redis는 분산 잠금에 자주 사용됨.
  • PostgreSQL의 조언적 잠금을 사용하여 동일한 기능을 구현할 수 있음.
  • 조언적 잠금은 PostgreSQL의 내부 잠금 엔진을 애플리케이션 정의 목적으로 활용할 수 있게 함.

• 사용 사례 3: Pub/Sub

  • Redis는 이벤트를 활성 클라이언트에 푸시하는 데 사용됨.
  • PostgreSQL 9 버전 이후 LISTEN과 NOTIFY 문을 사용하여 Pub/Sub 기능을 제공함.
  • PostgreSQL 클라이언트는 특정 메시지 채널에 구독할 수 있으며, 다른 클라이언트가 해당 채널에 메시지를 보내면 모든 구독자가 알림을 받음.

• PostgreSQL의 완전한 활용

  • Redis는 PostgreSQL과 다른 용도로 사용되며, TTL을 가진 데이터 캐싱 및 일시적인 데이터 저장에 뛰어남.
  • PostgreSQL은 SQL 데이터베이스 이상의 기능을 제공하며, Redis를 사용하는 작업을 PostgreSQL로 대체할 수 있는 가능성이 있음.
  • 여러 데이터 서비스를 사용하는 복잡성을 줄이고 운영 비용을 절감할 수 있는 가치 있는 선택이 될 수 있음.

[neo]

Hacker News 의견

• Redis는 애플리케이션과 같은 기기에서 실행될 때 매우 빠른 응답 속도를 제공함. 이는 Postgres와는 다른 작업을 가능하게 함

  • 인메모리 키-값 저장소는 RAM의 성능 특성을 필요로 하는 작업에 적합함
  • 네트워크 연결을 통해 RAM의 성능을 얻을 수 없다는 것은 자명한 사실임

• PostgreSQL은 단순한 SQL 데이터베이스 이상의 기능을 제공함

  • ORM 뒤에서만 데이터베이스를 사용하면 기능을 놓칠 수 있음
  • Redis 같은 서비스를 추가하기보다는 이미 설정된 데이터베이스를 활용하는 것이 나을 수 있음

• PGQueuer는 PostgreSQL을 사용하여 작업 큐, 잠금, 실시간 알림을 제공하는 최소한의 대안임

  • Redis의 필요성을 줄여줌

• Postgres는 강력한 데이터베이스임

  • Redis는 사용 장벽이 낮고 높은 성능을 제공하며, 기본 데이터베이스의 부하를 줄여줌
  • API 응답 캐싱은 Postgres에서도 가능하지만, Redis를 사용하는 것이 더 간단함
  • 별도의 시스템을 사용하는 것은 단점이 있지만, Redis의 경우 그 단점이 크지 않음

• 대부분의 프로젝트는 간단한 작업 큐만 필요로 하며, 복잡한 스택을 단순화하는 것이 중요함

  • 여러 상업적 관심이 있는 다양한 대안들이 존재함

• Postgres는 몇 가지 제한 사항이 있음

  • KVstore, 큐, pubsub, 잠금 등의 기능은 해결할 수 있지만 간단하지 않음

• PostgreSQL로 시작하고 필요할 때 Redis로 전환하는 것이 좋음

  • 움직이는 부품의 수를 최소화하는 것이 중요함

• Postgres pub/sub의 큰 단점은 메시지 크기가 8000바이트로 제한된다는 것임

  • 데이터베이스에 데이터를 저장하고 ID를 보내는 방법이 있지만, 이는 추가 작업을 요구함

• Redis의 가장 중요한 응용 중 하나인 캐싱은 Postgres에서 더 복잡함

  • Postgres의 업데이트는 삽입보다 비용이 많이 들고, 내구성 보장은 캐싱에 중요하지 않음

• Postgres에서 이러한 기능을 사용할 때 업데이트와 복제가 더 어려워짐

  • 가능하지만, Postgres의 더 널리 사용되는 기능에 집중하는 것을 선호함