개발

[미해결] 다른 서비스의 DB 데이터를 통합 조회할 수 있을까?

brobro332 2025. 4. 2. 01:23
반응형
💡 문제 상황
서로 다른 두 서비스 A, B의 데이터베이스에는 유사한 메타를 가진 테이블이 있음.

사용자에게 통합검색 서비스를 제공하는 목적으로 두 테이블의 데이터를 합쳐 보여 달라는 요구사항이 발생함. 

조건
데이터량이 방대하여 페이징이 필요함. 또한 사용자가 검색 조건을 입력하거나, 정렬 기준을 선택할 수 있음.

사용자의 화면에서 특정 버튼을 누르면 A 테이블엔 B 테이블의 ID, DB 구분(A/B)을 포함한 행 데이터가 추가됨.
단 ID 외의 다른 정보는 B 테이블에만 존재함

 

 시도 - 애플리케이션 차원 데이터 병합

  1. 서버단에서 A 테이블의 ID, DB 구분을 전체 조회
  2. DB 구분별로 ID를 나눠 구분별 리스트 변수에 저장
  3. 구분별 리스트 변수를 인자로 하여 각 DB에 IN 조회 수행 및 조회 조건 포함
  4. 조회된 데이터들을 맵을 사용하여 합침
  5. Comparator를 통해 정렬 처리
  6. for문을 통해 페이징 처리
  7. 반환

 

뭐가 문제일까?

  • 1번에서 데이터가 방대하기 때문에 페이징 처리가 필요하다.
  • 그러나 페이징 처리를 할 수 없다. 데이터 정합성을 지키려면 검색조건과 정렬 처리가 페이징에 선행되어야 함
  • 오라클에서는 IN 조건에 1_000개 이상의 ID가 포함될 경우 예외가 터진다.
    • 이 문제는 쿼리를 개선하여 해결 가능할 것으로 보인다.
  • 개인적으로는 페이징을 포기하지 않는 한 애플리케이션 차원에서 데이터를 병합할 수 있는 방법은 없다고 결론 내림

 

예상 대안

Redis 도입

  • 키워드는 캐싱, 메시징 큐, Pub/Sub, STOMP 등이 있다.
  • 시나리오
    • 사용자가 조회 버튼 누를 경우 각 서비스의 데이터 Redis로 전송
    • 검색조건 → 정렬 → 페이징 처리 → 반환

 
Elastic Search 도입

  • 챗지피티피셜 Redis보다 훨씬 빠름
  • 시나리오
    • 사용자가 조회 버튼 누를 경우 Elastic Search 인덱스에 저장하고 필터링 
    • 검색조건 → 정렬 → 페이징 처리 → 반환

 
UI 개선

  • UI를 분리하여 각 서비스의 데이터를 따로 조회
  • 비용을 고려하면 가장 현실적인 대안이다. 

 

엘라스틱 서치는 챗지피티피셜이라 반만 믿어야 한다.

문제가 된 당시 엘라스틱 서치는 아니지만 팀에서 검색엔진을 사용했는데도, 검색엔진에 대한 이해가 없어서 이런 생각도 못 했고 그래서 시도할 기회조차 놓쳤다는 점이 아쉽다. 물론 위의 대안이 안 될 수도 있기 때문에 아직 해결법을 찾은 것은 아니다. 

현재 진행 중인 개인 프로젝트에서는 사용자 정보를 중앙에서 관리할 필요성이 있는데, 한 번 도입해보려고 한다.

 

이미지 출처

 

생각하는 사람 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전.

ko.wikipedia.org