안녕하세요! devNine입니다.
devNine
devNine에서 메일링 서비스를 오픈한지 2주 가량이 지났습니다!
극초기 몇 번의 오류를 겪고 현재는 안정적인 상태로 메일이 잘 전송되고 있습니다!
하지만, 여러 블로그 또는 유튜브에서 컨텐츠들을 가져오다보니 역시 여러 이슈들을 겪기 마련이었습니다.
이번 DB편이 마무리되면 이런 이슈들 또한 공유할 예정입니다!
시작
사실, 이 글을 쓰게된 계기였던 select count(*) from table은 해결했습니다.
기존 Page를 활용해 페이지네이션을 진행했을 때는 전체 컨텐츠 즉, total을 제공하기 위해 전체 카운트 쿼리가 필요했는데, devNine처럼 무한스크롤로 컨텐츠를 제공할 경우 Slice를 사용해 총 개수를 알지 않아도 first, last, empty 등의 signal을 통해 마지막 페이지인지, 비어있는지를 체크해 기능을 구현할 수 있습니다.
그래도 혹시나 후에 게시판 기능이 추가되어 활발한 커뮤니티사이트처럼 아주 많은 컨텐츠를 가지면서도, CRUD가 활발하고, 페이지네이션을 제공해야할 때를 대비해 알아봤습니다.
Query Caching
SELECT 명령문 텍스트를 클라이언트에 보내는 결과와 함께 저장한다.
https://dataonair.or.kr/db-tech-reference/d-guide/dbms-2/?mod=document&uid=62466
거두절미 하고 쿼리 캐싱이 켜져있고, SELECT를 요청했다면 해당 결과는 SELECT 명령문과 함께 저장됩니다. 정확히 동일한(대소문자도 동일, 바이트 비교) SELECT 명령문이 요청된다면, 저장되었던 결과가 반환됩니다.
그런데, 해당 SELECT 명령문과 관련된 테이블에 단 하나라도 변경이 발생한다면 모든 캐시가 지워집니다.
사라져가는(사라진) Query Caching
https://dev.mysql.com/doc/refman/5.7/en/query-cache.html
쿼리 캐싱을 사용하지 않았던 가장 큰 이유가 이것이다. 5.7부터 deprecated되었고, 8.0에서는 아예 제거되었다니.. 사실상 쓰지 말라는 의미로 이해했습니다.
왜?
http://www.tocker.ca/2013/09/27/how-do-you-use-the-query-cache.html
https://dba.stackexchange.com/questions/23699/is-the-overhead-of-frequent-query-cache-invalidation-ever-worth-it/23727#23727
https://dba.stackexchange.com/questions/217577/why-did-mysql-remove-the-query-cache-feature-after-version-8-0
https://mysqldba.tistory.com/356
이 외 관련 글들을 읽어보고 정리해보자면,
-
MySQL 엔진인 InnoDB와 쿼리 캐시 무효화 사이의 오버헤드가 너무 크다.
결정적으로 테이블에 단 한번의 DML에도 참조된 모든 영역에 무효화가 일어나는데, 이 때 모든 캐시에서 참조를 찾는다. 이 부분에서 Redis와 같은 Key-Value형태는 어플리케이션에서 Key로 데이터가 관리되면서 비교적 적은 영역의 참조가 일어날 것이라고 합니다. -
여러 ORM에서 준수한 성능의 쿼리를 제공한다.
물론 각각 차이는 있겠지만, 사용되고 있는 ORM들에서 쿼리에 대한 캐싱을 제공하고 캐싱에 대한 관리 또한 DB보단 부담이 덜하다는 의견입니다. 또한 별도의 캐싱을 위한 DB들(Redis 등) 또한 제공되고 있기 때문에 쿼리 캐시를 개선하기보다 MySQL 자체의 성능 향상에 집중하겠다는 MySQL 서버 팀의 글이 있었습니다.
결론
결론적으로 DB에서의 쿼리 캐싱은 다른 DB는 더 알아봐야겠지만, 최소한 MySQL에서는 지양하고 있으며 어플리케이션 레이어 이상에서의 캐싱을 권하는 것으로 보여집니다.
devNine에서도 현재 WAS(Spring Boot)와 Client(React의 Recoil)에서 캐싱을 사용하고 있습니다.
