기능 설명
카테고리가 고정된 것인데 매번 다 조회하는게 조금 비효율적인 것 같아요 추후 캐싱하는거 제안해봅니다.(by. @JiwonLee42 )
도메인 조회 또한 자주 방문하는 도메인 명을 캐싱하는 것도 좋은 생각입니다. 현재 중요 도메인들은 db에 저장중입니다.
목적
-
카테고리 조회 최적화 제안: 현재 시스템에서 카테고리는 데이터가 고정된 정적 데이터(Static Data)에 가깝습니다. 링크 생성 등 빈번한 비즈니스 로직마다 카테고리 전체 테이블을 매번 데이터베이스에서 전체 조회(categoryRepository.findAll())하는 것은 비효율적입니다. 성능 최적화를 위해 추후 캐싱(Caching) 도입을 제안합니다
-
도메인 조회 최적화 제안: 현재 중요 타겟 도메인들은 DB(domains 테이블)에 저장하여 관리 중입니다. 사용자가 자주 방문하고 등록하는 주요 도메인 명들 또한 데이터베이스 조회를 최소화할 수 있도록 글로벌 캐시 또는 로컬 캐싱을 적용하는 것이 효율적일 것으로 보입니다.
-
DB 부하 감소 및 응답 속도 향상: 고정된 메타데이터(카테고리, 도메인)를 조회하기 위해 매번 디스크 I/O나 네트워크 비용을 발생시키는 쿼리를 제거하여 API의 전반적인 Latency를 개선합니다.
-
시스템 확장성 확보: 사용자 수가 늘어남에 따라 동시다발적인 링크 생성 요청이 들어올 때, 정적 데이터 조회로 인한 DB 커넥션 풀 고갈 리스크를 사전에 예방합니다.
요구사항
DB 변경 사항
X
Additional Context
관련 이슈
기능 설명
카테고리가 고정된 것인데 매번 다 조회하는게 조금 비효율적인 것 같아요 추후 캐싱하는거 제안해봅니다.(by. @JiwonLee42 )
도메인 조회 또한 자주 방문하는 도메인 명을 캐싱하는 것도 좋은 생각입니다. 현재 중요 도메인들은 db에 저장중입니다.
목적
카테고리 조회 최적화 제안: 현재 시스템에서 카테고리는 데이터가 고정된 정적 데이터(Static Data)에 가깝습니다. 링크 생성 등 빈번한 비즈니스 로직마다 카테고리 전체 테이블을 매번 데이터베이스에서 전체 조회(categoryRepository.findAll())하는 것은 비효율적입니다. 성능 최적화를 위해 추후 캐싱(Caching) 도입을 제안합니다
도메인 조회 최적화 제안: 현재 중요 타겟 도메인들은 DB(domains 테이블)에 저장하여 관리 중입니다. 사용자가 자주 방문하고 등록하는 주요 도메인 명들 또한 데이터베이스 조회를 최소화할 수 있도록 글로벌 캐시 또는 로컬 캐싱을 적용하는 것이 효율적일 것으로 보입니다.
DB 부하 감소 및 응답 속도 향상: 고정된 메타데이터(카테고리, 도메인)를 조회하기 위해 매번 디스크 I/O나 네트워크 비용을 발생시키는 쿼리를 제거하여 API의 전반적인 Latency를 개선합니다.
시스템 확장성 확보: 사용자 수가 늘어남에 따라 동시다발적인 링크 생성 요청이 들어올 때, 정적 데이터 조회로 인한 DB 커넥션 풀 고갈 리스크를 사전에 예방합니다.
요구사항
DB 변경 사항
X
Additional Context
관련 이슈