Real MySQL 8.0 을 읽었습니다.

---

 전에 db의 query plan명령어를 활용해서 db가 어떻게 정보들을 가져오는지 파악하고, 몇몇 인덱스의 원리와 쿼리들의 작동방식(?) 등을 공부하고 결과적으로 covering index를 통한시간단축을 경험해본 적이 있다. 당연히 모든부분을 공부해본것도 아니였고 한번 더 제대로 공부할 필요성이 느끼고 있던 찰라, 인프런의 유료강의를 들어보려던 순간에 책으로 대체하게 되었다.

 

 얼마전에 인프런에서 처음으로 멘토링을 받아봤다. 유망한 회사들로부터 다양한면접경험을 받아보고 이제막 1년차가 된 분이셨다. 인터넷을 통해서 너무 방대한 정보를 노력만 한다면 얻어갈 수 있기에, 뭘 준비해야할지, 어떻게 준비해야할지 파악하고 나만의 기준을 세워 묵묵하게 걸어가고 있던도중, 당연히 쓸데없이 나만의 방식을 고수할 필요 없이 취업 선배님의 멘토링과 시야를 통한 중간점검을 분명히 받아볼 필요가 있다고 생각했기에 받에보게 되었다.

 

 결과적으론 대 성공(?) 이었다. 생각보다 칭찬을 잘 해주셨고 준비하려는 방향성 등에 대해서 이야기를 해보았을때 내심 '음 역시 내가 알아보고 가는 방향이 맞군' 하고 뿌듯(?)해 할 수 있었다. 알면서도 cs에 대한 대비를 심도깊게 하고 있진 못했는데 해당 부분에 대해서도 평소에도 계속해서 준비해야 겠구나 하고 알 수 있는 기회가 되기도 하였다.

 그렇게 멘토링 과정중에 멘토님이 특히 강력추천해주신 책이 바로 위의 책이다. 나 또한 책을 읽다가 재밌으면 몰입해서 적당한 수백페이지 짜리라도 하루만에 주파가 가능하기 때문에 멘토님또한 읽다가 재밌어서 단기간에 주파했다는 이야기를 듣고 그 얘기에 마음이 움직여 유료 강의 대신 db에 대해서 위 책으로 공부를 하고자 선택하고 읽게 되었다. 인터넷을 검색해보니, 2까지 있던데 확실히 어마어마한 분량이긴 하다...  1은 약 500페이지 정도 된다. 2는 읽게될지 말게될지는 아직은 잘 모르겠다.

 

 우선 이책은 읽는데 좀 힘들(?)었던 책이다. 분량이 많기도 하고, 다행히 앞페이지는 설치 관련 이야기로 50페이지 정도가 나와 어느정도 읽다보니 당장필요한 내용은 아니라 바로 넘겨 50페이지를 줄여주는 마법이 발동하게 되는데, 이후 중요한 내용들에 대해서는 하나하나 꼼꼼히 되짚어읽어가며 머리속에서 이해를 하면서 읽다 보니 읽는 시간이 훨씬 많이 들어가는 책이였던듯 하다. 또 정말 폭넓게 다루다 보니 당장 필요하지 않아보이는 내용들도 가끔 섞여있어서 그런부분들은 한번만 읽고 넘기는 식으로 했다.(나중에 필요하면 그때 찾아보면 된다는 마인드) 또한 가지고 있던 궁금증에 대해 해소가 되어주기도 한 책이다. (아래 간단히 언급)

 

 책만 읽어서는 절대 온전히 체득하기는 어려운것 같고, 반드시 실제 데이터와 쿼리들을 통해 직접 사용해보고 고민해보는게 병행되어야지 좋은 책이지 않을까 싶다.

 

 + 추가) 도중에 어마어마한 띵작 유튜브발표영상을 보게되었다. 여기클릭

배민 테크 유튜브인데 제목은 "수십억건에서 queryDSL사용하기" 인데 영상이 기가막히게 유용할뿐만 아니라 기가막히게 재밌다.

압축된 영상에 주요한 알짜배기 내용들로 꽉꽉찬 봐야만하는 영상이다. jpa와 query DSL기술이 내부적으로 결국엔 어떻게동작하는지 파악하고 효율적으로 db와 상호작용하는 내용을 알 수 있다. 

 더해서, 지금 쿠스토랑에도 dto projection과 queryDSL을 별도 복잡하고 번거로운 클래스 분리나 상속없이 자연스레 사용중에 있는데 불과 몇년전에는 그게 당연한것이 아니였다는것이 놀랍기도 하였다.

---

포인트1.

 clustered index와 secondary index에 대해서는 알고 있었다. 인덱스간 어떻게 b+ tree타면서 작동하는지도 알고는 있었다. 하지만 왜 secondary index의 리프노드에는 실제 데이터가 아니라 참조데이터들(인덱스 컬럼 데이터, 데이터에 접근하기 위한 포인터) 만 들고 있는지 궁금했는데 이 부분을 명확히 해소해 주었다. 분명히 나중에 그 이유를 까먹을것이라 적어보자면 만약 secondary index가 실제 레코드가 저장된 주소를 가지고 있다면 클러스터링 키 값이 변경될 때마다 데이터 레코드의 주소가 변경되고 그때마다 해당 테이블의 모든 인덱스에 저장된 주솟값을 변경해야 하는 일이 발생하기 때문이라고 한다. 이런 오버헤드를 제거하고자 innoDB에서는 모든 secondary index는 해당 레코드가 저장된 주소가 아닌 pk값을 저장하도록 구현되었다고 한다.

 

포인트2.

 여기서도 스트리밍 처리가 가능했다 더라. 당연히 모든 쿼리는 안되고 어느정도 스트리밍 처리가 가능하겠다 싶은(내부적으로 생각해봤을때) 부분에 대해서 가능하다고 한다. 단 jdbc기술에서도 mysql처럼 전체 결과를 다 완성시켜놓고 처리하게끔 되있기 때문에 별도의 설정이 필요하다고 한다. 주로 대용량데이터 관련해서 사용할 것 같다.

 

포인트3.

 mysql 8.0.20 버전부터는 더이상 join을 할때 기본 알고리즘은 네스티드 루프 방식이 아니라 해시 조인 알고리즘으로 대체되었다고 한다. 네스티드 루프 방식은 간단히 말하면 2중 for문과도 같다. 후자의 방식은 더 적은 테이블의 조인키로 해시맵을 생성하는 방법으로 훨씬 더 빠른 속도로 처리가 가능하다고 한다.이 사실을 알고 나서 나는 mysql 버전 정보를 표기할때 8.0에서 8.0.36(현재 내 버전) 으로 더 구체적으로 작성하게 되었다 ㅋㅋ

-- 읽는중