카운팅 조회 시 질문

안녕하세요 질문있습니다.

만약 게시글 전체 조회할 때 게시글 마다 좋아요 수도 함께 기재하려고 하면 게시글 조회 할 때 마다 articleId에 맞는 좋아요 수 정보도 함께 필요하잖아요?

현재 게시글 서버와 좋아요 서버가 다른 환경을 고려할 때 그러면 게시글 조회할 때 마다 좋아요 서버로의 api요청이 불가피할 거 같은데 이 경우 조회 성능이 당연히 안좋게 나올 수 밖에 없다고 생각합니다.

비정규화로 좋아요수를 게시글 테이블에 붙여서 단일 서버로의 요청을 만들어줄려고 해도 말씀하신 한계 때문에 안될 거 같구요.

만약 게시글 전체 조회 시에 게시글과 게시글의 좋아요수가 반드시 제공되어야 한다면 제가 생각한 성능 저하 포인트가 타당한가요? 만약 타당하다면 어떻게 개선할 수 있을까요? 인기게시글만 따로 추려서 레디스로 메모리를 활용해야할까요?

안녕하세요, 인프런 AI 인턴입니다. leettletree님.

질문 주신 내용은 게시글 조회 시, 각 게시글의 좋아요 수를 함께 제공하는 것과 관련된 성능 문제입니다. 이와 관련하여 몇 가지 해결책을 제안드리겠습니다.

문제점 및 성능 저하의 원인

현재 게시글 서버와 좋아요 서버가 분리되어 있고, 각 게시글에 대해 좋아요 수를 함께 조회해야 한다면, 게시글 조회 시마다 좋아요 서버로 API 호출이 필요해집니다. 이런 방식은 여러 개의 네트워크 호출을 초래하게 되어 성능 저하의 원인이 될 수 있습니다.

성능 개선 방안

비정규화:
- 말씀하신 대로 비정규화를 통해 게시글과 좋아요 수를 단일 서버에서 관리하는 방식은 데이터 일관성을 유지하는 데 있어서 어려움이 있을 수 있습니다. 하지만, 적절한 시점에 데이터 동기화를 수행하면 비정규화를 통한 성능 개선이 가능합니다.
캐싱 사용:
- Redis와 같은 캐시 솔루션을 이용하여 자주 조회되는 데이터(인기 게시글 등)를 메모리에 저장함으로써 DB에 대한 부하를 줄일 수 있습니다. Redis를 활용해 자주 조회되는 게시글과 그에 대한 좋아요 수를 캐싱하면 응답 시간을 크게 줄일 수 있습니다.
데이터 동기화 주기 조정:
- 좋아요 수와 같은 비즈니스 데이터는 실시간 일관성을 요구하지 않는다면, 일정 주기로 동기화하거나 늦게 반영될 수 있도록 유도하는 방식이 가능합니다. 조회 빈도가 높은 데이터를 중심으로 캐싱하고, 배치 작업을 통해 DB에 동기화하는 방식을 취할 수 있습니다.
결합 데이터 모델:
- 조회 시점에 대한 응답 성능이 중요하다면, 좋아요 수를 포함한 특정 데이터셋을 결합하여 미리 구성해 놓고 조회하는 방법도 고려 가능합니다. 이는 LikeCount를 게시글 데이터에 주기적으로 합산하여 미리 계산된 데이터셋을 준비해 놓는 방식입니다.

위의 방법들을 참고하여 구현하시면 좋겠습니다. 추가적으로 멀티 서버 환경에서의 데이터 동기화 및 캐싱 전략에 관한 질문을 확인해보시면 도움이 될 것입니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

인프런 커뮤니티 질문&답변

문제점 및 성능 저하의 원인

성능 개선 방안