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을 이해하지 않고 사용하는 게 정말 문제점이 없을까? 장기적인 관점에서(유지보수와 확장 측면에서) 긍정적으로 생각하기..

프로젝트 진행이 거의 7개월이 넘어간다. 알고리즘, CS 공부와 병행하는 상황이라, 프로젝트에 시간을 많이 투자하질 못해서 아쉽긴 하지만, 프레임워크만 잘 사용한다고, 애플리케이션 코드의 퀄리티와 이해도가 깊어지는 것은 아니니, 꼭 병행해야만 했었던 부분이었다. 어쨌거나, 기간이 길어지고, 그 기간 동안, 다양한 학습을 하면서, 진행했던 프로젝트 코드들을 살펴보니, 다음과 같은 문제점들을 발견했다. 데이터 액세스 로직 구현의 경우, myBatis를 활용하였는데, 자바 객체와 릴레이션의 구조적인 차이로 인해 POJO 스타일의 코드를 일부 포기할 수 밖에 없었다. (ex. 자바의 경우, 의존하는 객체는 해당 인스턴스 변수를 참조하는 방식으로 구현해야 하는데, 릴레이션의 경우, FK를 참조해야 한다.) 간단한..

이 작업일지는, 기술적인 부분보다는 특정 결과를 얻는데 까지 겪은 과정과, 고민의 흔적을 남기고자 쓴 글입니다. 따라서, 기술적인 부분에 대해서는 다소 내용이 추상적일 수 있습니다. 이번에는 저번 일지에서도 언급했듯이, 배포 프로세스를 익혀보고, 익혀본 프로세스를 자동화하는 과정을 가져보았다. 배포 자동화를 하기 위해 github action을 사용해보았다. jenkins와 같은 ci툴을 활용하지 않은 이유는, 따로 ci 서버를 운영하는 것이 취준생으로서는 조금 부담스러웠고, jenkins의 사용법보다는 자동화 프로세스에 대한 나의 논리를 확립시키는 것에 더 집중하고 싶었다. 배포 자동화는커녕, 배포 자체를 스스로 해본 적이 없었기 때문에, 이번 작업은 점진적인 반복과 스스로에게 질문을 하고 그 질문의 ..