Project

개요 - 프로젝트를 진행하며 각 게시물 별로 조회수를 관리하기로 결정했습니다. - 문제점은 같은 사용자에 의해 조회수가 중복으로 증가하는 상황이었습니다. - 여러 검증 방식을 고민하다가 정확한 측정에 중점을 두고 IP를 이용하기로 결정했습니다. 검증 방식 세션 검증 장점 서버에서 관리하고 값을 직접 세션 저장소에 저장하면서 검증을 할 수 있으므로 다루기 편하고 보안성이 높습니다. 사용자의 세션 정보를 바탕으로 중복 조회를 정확하게 파악할 수 있습니다. 단점 서버에 데이터를 저장하므로 서버의 리소스를 사용하기 때문에 세션 양이 많아진다면 서버에 부하가 커집니다. -> 비용, 성능과 직결될 수 있는 문제가 발생할 수 있습니다. 세션은 휘발성이라 만료되거나 사용자가 다른 컴퓨터로 사용하면 중복 체크하기가 까다..

개요 실시간 알림을 구현하는 과정에서 페이지 이동시 소켓 연결이 끊기는 이슈가 발생했습니다. - 소켓 연결을 새로고침을 하거나 다른 페이지로 이동을 하면 끊기게 되있습니다. - 이를 막기 위한 방법으로 새로고침 시 경고 창을 띄어주거나 방지하는 방법이 있지만 - 저희 서비스에서는 단순히 새로고침 뿐 아니라 페이지 전역에서 소켓 연결을 유지할 방법이 필요했습니다. 소켓 정보 DB저장 - 우선 저희 서비스에서 알림은 상품에 대한 구독으로부터 시작됩니다. - 판매자는 상품을 등록했을 때, 소비자는 상품에 입찰을 걸었을 때 해당 상품에 구독하면서 알림 서비스를 지원합니다. - 사용자는 소켓에 구독할 때마다 DB에 자신의 소켓 목록을 저장합니다. - 모든 페이지에 접근할 때마다 자신의 소켓 연결 정보를 불러오며 ..

전체 구조 Custom Exception 처리 방식 비슷한 역할이나 동일한 예외에 대해서 공통 예외로 추상화 합니다. NotFound ProgramNotFound BoothNotFound Forbidden ForbiddenUpdate ForbiddenDelete ErrorCode(Enum Type)를 통해 구분하며 에러 코드는 에러 메시지와 HTTP 상태 값을 가집니다. 처리 방법이 나뉘지 않는다면 모두 CustomException으로 묶어 처리하게 됩니다. @ExceptionHandler(CustomException.class) public ResponseEntity handleCustomException(final Custom e) { log.warn(e.ErrorCode.getMessage(), e..

결과 비교 이번 테스트에서는 데이터 건수를 500만건으로 줄여 테스트 했습니다. index적용(X) index적용(O) Covering Index적용 3.8sec 1.8sec 0.36sec 기존 코드(인덱스 적용 전,후) service @Transactional(readOnly = true) public List getItems(ItemsRequest itemsRequest, Pageable pageable) { List items = itemCustomRepository.findItems( itemsRequest.getId(), itemsRequest.getS(), itemsRequest.getQ(), itemsRequest.isFilter(), pageable ); return items; } rep..

학습 목적 이전에 적용했던 noOffset방식은 성능 자체는 가장 좋지만 더보기 버튼을 눌렀을 때 동작하는 무한 스크롤 방식이 아니거나 group by등으로 기준을 잡을 key가 중복이 되는 경우에는 사용할 수가 없습니다. 따라서 이번에는 noOffset을 이용하지 못하는 경우에 대비하기 위해 커버링 인덱스를 사용하여 성능 개선을 확인 해보고자 합니다! DB에는 item이 2000만개 존재합니다. 커버링 인덱스란 쿼리를 충족시키는 데 필요한 모든 데이터를 갖고 있는 인덱스 를 이야기합니다. 즉, select, where, order by, limit, group by 등에서 사용되는 모든 컬럼이 Index 컬럼 안에 다 포함된 경우입니다. 인덱스 vs 커버링 인덱스 인덱스를 탔음에도 느리다면 select..

적용에 대한 고민 우선 적용 이유는 데이터가 많아질수록 뒤에 있는 데이터에 접근하는 시간이 길어지는데 이를 줄이고자 했습니다. * 데이터가 적어도 100만건 이상은 돼야 차이가 유의미 해지는데 이 정도로 뒤에 있는 데이터를 조회할 일이 있는가? -> 조회하는 경우가 거의 없다가 현실적이지만 누군가는 정말 끝까지 탐색할 수도 있는것이고 누군가는 악의적으로 접근하여 DB connection을 점유해버릴 수도 있기 때문입니다. on offset 성능 비교(데이터 2000만건) offset을 활용해 페이징 처리를 했을 때는 끝에있는 데이터 999990 ~ 999999를 가져오는데 0.35초가 걸렸습니다. 이는, offset방식이 999990행까지의 레코드를 건너 뛰는 방식으로 동작하기 때문입니다. 건너 뛰어야 ..