반응형
💡 문제 상황
서로 다른 두 서비스 A, B의 데이터베이스에는 유사한 메타를 가진 테이블이 있음.
사용자에게 통합검색 서비스를 제공하는 목적으로 두 테이블의 데이터를 합쳐 보여 달라는 요구사항이 발생함.
✅ 조건
데이터량이 방대하여 페이징이 필요함. 또한 사용자가 검색 조건을 입력하거나, 정렬 기준을 선택할 수 있음.
사용자의 화면에서 특정 버튼을 누르면 A 테이블엔 B 테이블의 ID, DB 구분(A/B)을 포함한 행 데이터가 추가됨.
단 ID 외의 다른 정보는 B 테이블에만 존재함
시도 - 애플리케이션 차원 데이터 병합
- 서버단에서 A 테이블의 ID, DB 구분을 전체 조회
- DB 구분별로 ID를 나눠 구분별 리스트 변수에 저장
- 구분별 리스트 변수를 인자로 하여 각 DB에 IN 조회 수행 및 조회 조건 포함
- 조회된 데이터들을 맵을 사용하여 합침
- Comparator를 통해 정렬 처리
- for문을 통해 페이징 처리
- 반환
뭐가 문제일까?
- 1번에서 데이터가 방대하기 때문에 페이징 처리가 필요하다.
- 그러나 페이징 처리를 할 수 없다. 데이터 정합성을 지키려면 검색조건과 정렬 처리가 페이징에 선행되어야 함
- 오라클에서는 IN 조건에 1_000개 이상의 ID가 포함될 경우 예외가 터진다.
- 이 문제는 쿼리를 개선하여 해결 가능할 것으로 보인다.
- 개인적으로는 페이징을 포기하지 않는 한 애플리케이션 차원에서 데이터를 병합할 수 있는 방법은 없다고 결론 내림
예상 대안
✅ Redis 도입
- 키워드는 캐싱, 메시징 큐, Pub/Sub, STOMP 등이 있다.
- 시나리오
- 사용자가 조회 버튼 누를 경우 각 서비스의 데이터 Redis로 전송
- 검색조건 → 정렬 → 페이징 처리 → 반환
✅ Elastic Search 도입
- 챗지피티피셜 Redis보다 훨씬 빠름
- 시나리오
- 사용자가 조회 버튼 누를 경우 Elastic Search 인덱스에 저장하고 필터링
- 검색조건 → 정렬 → 페이징 처리 → 반환
✅ UI 개선
- UI를 분리하여 각 서비스의 데이터를 따로 조회
- 비용을 고려하면 가장 현실적인 대안이다.
엘라스틱 서치는 챗지피티피셜이라 반만 믿어야 한다.
문제가 된 당시 엘라스틱 서치는 아니지만 팀에서 검색엔진을 사용했는데도, 검색엔진에 대한 이해가 없어서 이런 생각도 못 했고 그래서 시도할 기회조차 놓쳤다는 점이 아쉽다. 물론 위의 대안이 안 될 수도 있기 때문에 아직 해결법을 찾은 것은 아니다.
현재 진행 중인 개인 프로젝트에서는 사용자 정보를 중앙에서 관리할 필요성이 있는데, 한 번 도입해보려고 한다.
이미지 출처
생각하는 사람 - 위키백과, 우리 모두의 백과사전
위키백과, 우리 모두의 백과사전.
ko.wikipedia.org
'개발' 카테고리의 다른 글
멋쟁이사자처럼부트캠프 백엔드 부트캠프 플러스 (5) | 2025.04.08 |
---|---|
라즈베리파이 서버에 도커 컨테이너 환경으로 프로젝트를 배포하자 (6) | 2025.04.06 |
이미저를 통해 라즈베리파이5에 우분투를 설치해보자 (2) | 2025.03.14 |
라즈베리파이5 언박싱 및 케이스 조립 (1) | 2025.03.14 |
젠킨스로 CI/CD 파이프라인을 구축해보며 남은 것들 (6) | 2025.01.19 |