스프링 JPA vs 다 불러와서 Collections.sort 뭐가 더 선호되나요? + pageable의 동작 방식?

Question

지나가면서 본 거 같기로는 findBy뭐뭐Sort어쩌고 하는거랑, findAll 해서 sort하는 거랑 큰 시간 차이가 없다고 하는데그래도 JPA 혹은 쿼리로 조건 걸고 불러 오는 게 더 선호 되는 것 같더라구요이유는 무엇인가요? 속도 차이가 난다거나, 혹은 DB단에서 처리하는 게 어떤 이점이 있나요?마찬가지로 pagable을 JPA에 넣는 방식은findAll 해서 자르는 거 (PageImpl한다던지..) 랑 속도라든가에서 큰 차이가 없나요?pagable 방식도 쿼리대로 조건 맞는 거 다 찾은 다음에 개수대로 잘라서 보내주는 거면 서비스단에서 로직으로 처리하는 거랑 큰 차이가 없어 보이기는 하는데.. 어떤가요?

olivahn · Answer

DB의 메모리에서 처리하느냐, 애플리케이션의 메모리에서 처리하느냐의 차이인데 상황에따라 굉장한 차이가 될 수 있죠.애플리케이션의 메모리에서 처리한다는 것은, DB에서 읽은 데이터가 천만개라면 천만개의 데이터를 네트워크를 통해 애플리케이션의 메모리에 복사하고 정렬을 수행한다는것과 같습니다.페이지네이션을 하는데 위의 상황이 된다고 가정하면 10개의 데이터를 읽기위해 천만개의 데이터를 복사해와야 할수도 있다는 얘기겠죠.N이 작다면 대체로 비효율적인지언정 문제가 있지는 않을것이므로 정답은 없습니다. 상황에맞는 도구를 고르면 됩니다.

심심하다능! · Answer

제가 알기로는 페이징을 구현하는 순간은 DB의 모든 데이터를 검색하는 것은 아닙니다. 하지만 결국 모든 데이터를 검색한다고 봐야 합니다. 이유는 대부분 어떤 정렬 기준으로 검색을 해서 페이징 처리를 하기 때문이죠. Order By 같은 것이 들어가는 순간 DB에서는 모든 데이터를 읽습니다. 하지만 DB에서 검색하는 것이 월등히 더 빠릅니다. 왜냐면 애시당초 MySql같은 DB들은 옛날부터 그런 것에 최적화가 되어 있기 때문이죠. 그게 곧 DB의 성능이잖아요. 프론트쪽 사람들이 백엔드가 쉽다고 우기는 것도 백엔드가 제대로 쿼리하지 않고 findAll 형식으로 대충 구현해서 프론트에 던져 주기 때문이죠 ㅋㅋㅋ. 어떤 백엔드 사람들을 만나는가에 따라 고달픈 프론트의 운명이 정해지죠...

스프링 JPA vs 다 불러와서 Collections.sort 뭐가 더 선호되나요? + pageable의 동작 방식?

2개의 답변

기술 목록