티스토리 뷰
카페를 추천해주는 멀티 에이전트를 구현했는데, 자료를 검색하고 선택을 하는 과정이 많지만, 마지막에 추천해주는 결과만 저장하기가 아까웠다. 그래서 에이전트를 중간에 나눠서 그동안 찾은 자료들을 redis에 저장하기로 했다.
Redis는 Set & Tag 구조를 사용할 수 있어서 다중 키워드 검색이 용이하다.
1. Redis의 Set이 SQL보다 빠른 이유
1) MySQL과 같은 관계형 데이터베이스에서는 WHERE 조건을 만족하는 행을 찾기 위해 테이블을 조회해야 한다.
조건이 여러개(OR)일 경우, 테이블 전체를 스캔할 수 도 있어, 데이터가 많아질수록 성능 저하가 일어날 수 있다.O(n)이상
2) Set은 해시 테이블을 기반으로 동작하기 때문에, 특정 키를 검색할 때 O(n) 이하의 속도를 가진다.
2. MySQL이 유리한 상황(Redis tag 검색의 한계)
1) 복잡한 조건(숫자, 정렬 등) 포함된 경우
- Redis의 Set은 정확히 일치하는 값을 검색하는데 최적화되어있어, "후기 평점이 4.5이상"과 같은 범위 검색은 Set에서 직접 지원되지 않는다.
- Redis의 set은 검색된 데이터를 정렬할 수 없어, "서울 + 빈티지" 태그를 가진 카페를 찾은 뒤, "후기 개수가 많은 순"으로 정렬해야할 수 있다.
- Redis에도 ZSET(Sorted Set)은 자동 정렬 기능이 있어 평점, 리뷰개수로 해결할 수 있지만, ZSET은 한 번에 하나의 기준(평점 또는 리뷰 개수)만으로 정렬할 수 있다.
- "평점 높은 순"으로 정렬한 ZSET과 "리뷰 개수 많은 순"으로 정렬한 ZSET을 따로 저장해야하고, 교집합(SINTER)을 ZSET에 직접 사용할 수 없어 어렵다.
- 따라서 태그 기반 검색(Set)과 정렬 기능(ZSET)을 함께 적용하는 것이 어렵다.
'AI > AI 서비스 개발' 카테고리의 다른 글
[AI 서비스 개발] FastAPI 쿼리 파라미터 (0) | 2025.02.20 |
---|---|
[AI 서비스 개발] Redis 기초 문법(with python) (0) | 2025.02.18 |
[AI 서비스 개발] Windows Redis 설치 및 실행(WSL) (0) | 2025.02.16 |
[AI 서비스 개발] Redis key-value (0) | 2025.02.15 |
[AI 서비스 개발] Redis, 디스크, 메모리, I/O 비용 (0) | 2025.02.14 |
- Total
- Today
- Yesterday
- SQL
- 미라클모닝
- 프로그래머스
- 실기
- ChatGPT
- 고득점 Kit
- 줄넘기
- 스크랩
- Ai
- 다이어트
- 갓생
- Python
- 기초
- 루틴
- 아침
- 뉴스
- 티스토리챌린지
- 습관
- 경제
- 운동
- 아침운동
- C언어
- 영어회화
- opic
- llm
- 오픽
- 30분
- IH
- 빅데이터 분석기사
- 오블완
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |