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

철현님, 안녕하세요!

궁금하신 부분들 답변 드립니다!

페이징 쿼리 설명하는 과정에서 offset의 증가로 인해 결국 뒷페이지로 갈수록 느려지는 문제는 불가피하다는 점을 언급하는데요,

그에 대한 해결책으로 무한 스크롤 방식의 쿼리를 사용할 수 있습니다.

애초에 페이지 번호 방식과 무한 스크롤 방식은 사용성부터가 완전히 다릅니다.

무한 스크롤 사용성에 페이지 번호 방식의 쿼리를 사용하면, 사용자에게 데이터를 온전하게 보여줄 수 없습니다.

그래서 무한 스크롤의 사용성에서 페이지 번호 방식의 쿼리를 사용했을 때의 중복 또는 누락되는 상황에 대해서 설명을 하는 것이고요.

각 사용성에 적절한 쿼리를 제시해드린 것이고,

무한 스크롤 쿼리는 페이지 번호 쿼리의 문제점을 해결하면서도, 무한 스크롤 사용성에 적합하기 때문에 별도의 쿼리로 구현됩니다.

페이지 번호 방식 쿼리의 한계를 알아본 뒤에 무한 스크롤을 진행하는거라, 강의 자료로 전반적인 흐름을 다시 살펴보시는 것도 추천드립니다!

게시글 챕터는, 인덱스 알고리즘에 대한 이해와 최적화된 인덱스 활용법을 알려드리기 위한 과정입니다.

분산 환경과는 완전히 무관합니다! (분산에 대해서는 언급하지 않는 것 같은데, 오해될 만한 부분이 있었을까요?!)

JPA는 논외로 생각하시는게 좋을 것 같습니다.

JPA의 자동 완성되는 페이징 쿼리를 살펴보시면 아시겠지만, 커버링 인덱스를 활용하여 데이터베이스에 최적화된 쿼리를 만들어주지 않습니다.

Slice는 무한 스크롤 쿼리와 유사하게 만들어주긴 하지만, 

데이터베이스에서 어떻게 실행되는지 직관적으로 보여주기 위해 native query로 만들었습니다.

주변에서 데이터베이스를 학습하지 않고 JPA만 학습하여 페이징 쿼리 만드는 분들을 봤을 때에는, 

내부적으로 어떤 SQL 구문과 어떤 원리로 돌아가는지 제대로 인지하지 못하는 경우가 많더라고요.

이러한 부분도 일부러 native query를 사용하게 된 이유이기도 합니다.

원리만 알고 있으면 어떤 방법으로 구현하든 아무 상관 없습니다!

그리고 사실 JPA도 복잡한 시스템을 만들다보면 최선의 선택이 아닐 때가 많습니다. (JPA의 장점만 전파가 너무 잘된 느낌이..!?)

데이터베이스를 잘 알아야 JPA도 제대로 쓸 수 있는거라,

JPA에 종속된 사고보단, 데이터베이스 관점에서 생각하시는게 이해가 편할 것 같습니다.

https://www.inflearn.com/community/questions/1504157

JPA 실무 활용 관련하여 다른 분이 질문 주신 것도 있어서, 위처럼 답변 드린 적이 있습니다.

참고 차 같이 남겨둡니다!

혹시 더 궁금한 점은 편히 문의주세요!