Skip to content

candidate db

Jump to bottom
Kim DongHyun edited this page Feb 25, 2025 · 6 revisions

후보 일정 산출용 DB 고민 과정

후보 일정 검색 과정 사용하는 데이터는 각 논의에 대한 시간 단위(30분) 블록으로 인코딩된 비트 데이터입니다. 이 데이터는 후보 일정을 산출할 때마다 사용되며, 참여자들의 개인 일정 정보가 자주 변동되는 특성 상 요청이 빈번히 발생하며, 데이터에 빠르게 접근할 수 있어야 합니다.

고려사항

  1. 데이터의 특성 및 접근 패턴

    • 일시적 데이터: 후보 일정 산출 시 생성된 인코딩 데이터는 논의 생성 시점에 생성되고, 일정 확정 시 삭제됩니다.
    • 빈번한 조회 및 갱신: 후보 일정 산출 요청이 자주 발생하며, 각 후보를 산출할 때마다 개인 일정 데이터를 빠르게 비교하여 계산해야 합니다.
    • 비트 연산 필요: 16비트 비트맵을 사용하여 각 참여자의 일정 정보를 관리하므로, 비트 단위의 연산 및 집계가 효율적으로 수행되어야 합니다.

  2. 대안 검토

    • RDBMS (MySQL, PostgreSQL):
      • 장점: 데이터의 정합성과 ACID 특성 보장, 사용의 익숙함
      • 단점: 후보 일정 산출과 같이 빈번하고 빠른 데이터 접근이 필요한 경우, 디스크 기반 저장소의 I/O 지연 문제로 성능 저하 가능성
    • NoSQL 데이터베이스 (MongoDB):
      • 장점: 스키마가 유연하고, 대량의 데이터를 분산 처리 가능
      • 단점: 비트 연산이나 캐싱에 최적화된 구조가 아니며, 데이터 갱신 주기가 빠른 경우 부적합
    • 인메모리 데이터베이스 (Redis):
      • 장점: 메모리 기반으로 매우 빠른 읽기/쓰기 성능, 비트 연산 및 비트맵 처리를 위한 다양한 명령어 지원, TTL 설정으로 캐싱 데이터 관리
      • 단점: 메모리 용량에 제한이 있음, 처음 사용해보는 기술이기에 초기 학습 곡선이 존재

최종 결정

후보 일정 산출 로직은 다음과 같은 요구 사항에 최적화되어야 합니다:

  • 빠른 접근성과 갱신: 후보 일정 산출 시 빈번한 조회 및 업데이트 필요
  • 비트 연산 지원: 30분 단위 블록 데이터를 비트맵 형태로 관리하여, OR/AND 등의 연산을 효율적으로 처리해야 함.
  • 일시적 데이터 저장: 일정 확정 후 빠르게 삭제되는 캐시 데이터 특성을 보유.

이러한 요구 사항을 종합해 볼 때, Redis는 후보 일정 산출 데이터의 저장 및 캐싱에 최적의 선택임이 확인되었습니다. Redis는 인메모리 데이터베이스로서 높은 성능과 낮은 지연시간을 제공하며, 비트 연산을 효과적으로 지원하여 후보 일정 산출 로직에 필요한 모든 기능을 충족할 수 있습니다.

RedisTemplate vs Redis Hash 및 기타 대안 비교

후보 일정 산출 로직에서는 인코딩된 비트맵 데이터를 빠르게 읽고 업데이트하는 것이 핵심입니다. 이와 같은 요구사항에 대해 Spring Data에서는 여러 Redis 접근 방법이 존재합니다. 대안을 비교하고 결정하는 과정이 필요했습니다.

1. RedisTemplate

특징

  • 다양한 데이터 타입 지원: 문자열, 리스트, 셋, 정렬된 셋, 해시, 비트맵 등 여러 Redis 데이터 구조에 대해 통합된 API를 제공합니다.
  • Spring 통합: Spring Framework와 자연스럽게 통합되어, 설정 및 사용이 간편합니다.
  • 직렬화/역직렬화 유연성: 데이터 구조에 맞는 직렬화 전략을 쉽게 구성할 수 있습니다.

장점

  • 범용성: 후보 일정 산출에 필요한 비트 연산(예: setBit, getBit)뿐만 아니라, 다양한 데이터 조작이 필요할 때 유연하게 사용할 수 있습니다.
  • 높은 제어력: 데이터 저장, 조회, 갱신, 트랜잭션 등 다양한 옵션을 세밀하게 조정할 수 있습니다.
  • 확장성: 애플리케이션의 다른 캐싱 또는 데이터 저장 요구사항에도 동일한 템플릿을 재사용할 수 있습니다.

단점

  • 설정 복잡성: 다양한 데이터 타입을 지원하다 보니, 단순한 사용 사례에도 불필요한 설정이 추가될 수 있습니다.
  • 범용성에 따른 오버헤드: 특정 데이터 구조에 최적화된 방법보다 약간의 오버헤드가 있을 수 있습니다.

2. Redis Hash (HashOperations)

특징

  • 해시 자료구조 사용: 하나의 키 아래 여러 필드를 저장할 수 있으며, 관련 데이터를 하나의 엔티티로 묶어 관리할 수 있습니다.
  • 필드 단위 접근: 각 필드에 대해 개별 조회, 수정이 가능하여, 객체의 여러 속성을 관리할 때 유리합니다.

장점

  • 메모리 효율성: 여러 관련 데이터를 하나의 Redis 키로 관리하여, 키의 수를 줄이고 메모리 오버헤드를 감소시킵니다.
  • 객체 매핑 용이: 후보 일정의 여러 속성을 하나의 엔티티로 저장할 경우, 필드 기반 접근이 용이합니다.

단점

  • 비트 연산 부적합: 후보 일정 산출 로직처럼 비트맵 데이터를 다루거나 OR/AND 연산이 필요한 경우, 해시 구조는 적합하지 않습니다.
  • 제한된 유연성: 주로 객체의 여러 속성을 저장/조회하는 데 최적화되어 있어, 단일 값 또는 비트 단위 데이터 조작에는 RedisTemplate의 직접 명령보다 불리할 수 있습니다.

최종 결론

후보 일정 산출 로직에서는 빠른 접근성과 빈번한 업데이트, 그리고 비트 단위 연산이 핵심 요구사항입니다.

  • RedisTemplate은 이러한 요구사항에 맞춰 다양한 데이터 타입과 비트 연산을 지원하며, Spring과의 통합 및 높은 유연성을 제공하기 때문에 최적의 선택입니다.
  • 반면, Redis Hash는 객체의 여러 속성을 관리하는 데 유리하지만, 비트 연산이나 단일 값의 빠른 갱신이 필요한 경우에는 적합하지 않습니다.
  • 기타 대안인 Redisson이나 Lettuce 역시 장점이 있으나, 후보 일정 산출의 단순 캐싱 및 비트 연산 요구사항에는 RedisTemplate의 통합성과 사용 편의성이 더 큰 장점으로 작용합니다.

따라서 최종적으로 후보 일정 산출 데이터의 캐싱 및 비트 연산 처리에는 RedisTemplate을 선택하게 되었습니다.

Clone this wiki locally