1.0 Overview MySQL 8.0 이후로, InnoDB가 관여하는 부분에서 성능에서 critical 한 부분은 대부분 개선된 걸로 알고 있다. 그런데, 그건 대부분 시스템 관리 부분, 혹은 하드웨어상에서 비효율적으로 작동되는 부분을 개선했을 뿐이지, 개발자의 쿼리문을 자동으로 최적화해주는 옵티마이저의 경우는, 쿼리의 종류에 따라, 최적화를 효과적으로 처리할 수도 있고, 아닐 수도 있다. 특히 인덱스의 경우, 종류에 따라 개발자가 어떻게 구성하느냐에 따라, 효율적인 검색 성능을 나타낼 수도 있고 아닐수도 있다. 즉 쿼리 튜닝에 있어서 인덱스는 절대 빼놓을 수 없는 부분이라 할 수 있다. 1.1 디스크 읽기 방식 1.1.1 HDD와 SSD HDD는 다른 하드웨어와는 달리 기계식 디스크 장치이다. SS..

Overview 저번 문서에서는 MySQL의 아키텍처에 대해서 알아보았다. 내용이 깊고 방대하여 Real MySQL 8.0 서적에서 나온 모든 내용을 정리하진 못했고, 서비스 개발에 필요하다고 생각하는 부분 위주로 정리를 했었다. 만약 이 글을 읽고 있는 사람 중에서 좀 더 깊고 다양하게 알고 싶으신 분들은 해당 서적을 읽어보는 것을 추천한다. 이번 문서에선, 트랜잭션과 락 그리고 격리 수준(isolation level)에 대해서 알아보겠다. spring에서는 보통 @Transactional을 통해 aop proxy를 활용하여, transactionManager를 직관적으로 사용할 수 있게 해준다.(물론 transactionManager를 직접 DI 하여 사용하는 경우도 있다.) 클라이언트 요청이 한번에..

0. Overview 이번 게시글에서는 MySQL의 핵심 구조은 InnoDB 스토리지 엔진의 구조에 대해 서술해보겠다. 이렇게 '구조'에 대해서 공부하는 것은 프로젝트의 기능 구현에 직접적으로 도움이 되진 않을 것이다. 그러나, '구조'를 통해 작동원리를 모르고 데이터 액세스 로직을 사용할 경우, 데이터 액세스 로직을 가성비 있게 사용하지 못하는 경우가 발생한다. 애플리케이션의 성능을 떨어트리는 요소가 네트워크 IO와 데이터베이스 IO인데, 그중에서 개발자가 종종 관여하는 부분이 데이터베이스라는 점을 감안해보면, 구조를 파악하여, 성능을 최대한 확보하는 것은 매우 중요해 보인다. 1.1 MySQL의 전체 구조 우선 전체적인 구조를 나타내기 위해, 전체 구조 그림으로 나타내 보..

Overview SQL 자체를 사용해본 경험은 있지만, 사실 SQL 자체를 이해하려고 하진 않았다. 프로젝트를 진행하는 데, 꼭 SQL을 깊게 이해할 필요는 없다고 생각했기 때문이다. 하지만 이러한 생각은 반은 맞고 반은 틀리다고 본다. 물론, 기능 구현을 하기 위해선 SQL 자체를 깊게 알 필요는 없다. 하지만, 보통 애플리케이션은 DB 서버를 따로 운영하여, 여러 was가 공유하는 형태로 작동한다. 즉 네트워크 IO + DB IO(디스크 IO)를 여러 was에서 공유한다는 뜻이라고 할 수 있다. 요컨대, 애플리케이션의 성능을 저하시키는 요소를 2가지나 가지고 있는 상황인데, 과연 SQL을 이해하지 않고 사용하는 게 정말 문제점이 없을까? 장기적인 관점에서(유지보수와 확장 측면에서) 긍정적으로 생각하기..