Project/Bidderown

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

결과 비교 이번 테스트에서는 데이터 건수를 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행까지의 레코드를 건너 뛰는 방식으로 동작하기 때문입니다. 건너 뛰어야 ..