Project gallendar - 조회 성능에 대한 고찰
로직
게시글을 작성하고 나의 게시글을 공유하기 위해서는 태그를 할 유저의 아이디를 검색해서 태그를 해야한다.
조회의 성능에 대한 고민을 많이하였다. 데이터베이스의 CRUD 작업 중 R이 대부분을 차지하기에, 조회에 대한 성능을 어떻게 하면 좋게 만들 수 있을까에 대한 고민을 많이 했던 것 같다. 조회의 성능을 올리기 위해서 우선적으로 검색을 해보았던게 엘라스틱 서치, 캐싱 등이 있는 것 같다.
엘라스틱 서치
엘라스틱 서치는 빠르게 검색하기 위해 NoSQL 을 많이 사용한다. 이는 오픈소스 검색엔진으로 루씬을 기반으로 만들어졌다. Full Text를 지원하여, 기존의 데이터베이스는 기본 쿼리와 색인 구조의 한계로 기본적인 텍스트 검색만 가능하지만 고차원적인 전문 검색이 가능하도록 한다. 이는 내용 전체를 색인해서 특정 단어가 포함된 문서를 검색하는 것을 의미한다.
여러모로 많은 장점들이 있고 빅데이터를 공부하는 사람들이라면 엘라스틱 서치는 많이 접해보셨을 것이다. 하지만 이 프로젝트의 특성상 단순히 쿼리문의 최적화와 데이터베이스의 설계를 통해서도 충분히 개선이 가능할 것 같아 엘라스틱 서치의 도입을 포기하였다. 또한 현재 구현하려는 로직을 엘라스틱 서치를 적용한다면, 우선 적절한 기술이 아니라고 생각하였다.
엘라스틱 서치는 SQL 데이터베이스보다 개별 레코드 검색을 수행하는 능력이 떨어지며, 특히 데이터를 업데이트 할 때는 성능이 크게 떨어진다. 만약 자주 정보를 업데이트 해야 하는 애플리케이션이라면 엘라스틱 서치는 적절한 기술이 아니라 판단(회원 가입이 계속해서 이루어질 것으로 생각하였다.)
QueryDsl
조회의 성능을 올리기 위해서, SQL문을 잘 작성하여야 했다. 직접 @Query를 이용하여 커스텀 해도 되지만, 추후에 조건에 맞는 동적인 쿼리문을 작성하기 위해서는 Querydsl을 통해서 다이나믹 쿼리로 구현할 수 있다는 것을 알게되었고, 기존 SQL문에서의 ROW의 줄과 Querydsl을 적용하여 fetch join을 한 ROW와 비교하였을 때 엄청난 개선이 된다는 점을 인지하여 적용해보려 한다.
Querydsl을 사용하면서 많은 편한점들이 있었다. 코드로 쿼리를 작성하여서 컴파일 문법 오류를 한눈에 알 수 있었고 IDE의 도움을 크게 받을 수 있었다. 또한 동적인 조건이 들어왔을 때 코드의 개선과 명확한 쿼리문이 보인다는게 큰 편리함인 것 같다.
자세한 queryDsl의 적용방법은 추후 새로운 포스팅을 통해서 안내하도록 하겠습니다.
캐싱
앞서 말했듯이 데이터베이스의 대부분이 R이 많다고 하였다. 이는 계속해서 조회 요청을 하면 트래픽이 방대해질 수 밖에 없다. 이런 트래픽이 쌓이고 쌓이면 비용적인 부분도 분명 문제가 있다. 이를 해결하기 위해 데이터베이스 클러스터로 구성하거나 캐싱 기능을 도입하여 이미 조회가된 게시글에 대해서는 캐시로 관리하여 빠른 접근이 가능하도록 하며 비용적인 부분도 해결할 수 있다.
하지만 민감한 데이터 즉 대부분의 웹페이지에서의 데이터베이스 해킹사례는 전부 캐싱에서부터 이루어진다. 따라서 민감한 데이터라고 생각되는 것들은 캐시로 관리하여서는 안된다.
아직 데이터베이스의 아키텍처 설계를 하지는 못하였지만, 트래픽에 대한 고민도 해보았고 이에대한 여러가지 기술들이 있다는거에 많은 배움을 느낀다.