개발자는 기록이 답이다

저는 Redis가 싱글 스레드로 동작하는데도 불구하고, 특정 명령어를 사용할때 동시성 제어가 필요있고 없고의 차이점에 명확하게 아하! 모먼트를 가질 수는 없었습니다. 이러한 고민을 해결하기 위해 Redis 명령어들이 어떻게 동작하는지 살펴보았습니다. 이번 포스팅에서는 이 주제에 대해 알아보고자 합니다. 📌 왜 GET과 SET을 같이 사용하는 것은 동시성 이슈가 발생할까?Spring Boot 프로젝트에서 Redis를 사용하다 보면, GET과 SET 명령어를 함께 사용할 때 동시성 이슈가 발생하는 경우가 있습니다. 그 이유는 Redis는 멀티플렉싱 I/O를 활용하여 여러 요청을 받으면서, 실제 요청들은 싱글 스레드로 순차적으로 처리하기 때문입니다.참고: 아래 예시에서는 GET 대신 SCARD를, SET 대..

2024.04.05 - [SQL/쿼리 최적화] - Index를 활용한 10만건의 레코드 Join쿼리를 최적화하자 Index를 활용한 10만건의 레코드 Join쿼리를 최적화하자 마이페이지에서 유저가 발급받은 쿠폰 이력을 조회하는 기능을 구현해야 했습니다 해당 기능 구현 시 쿼리 최적화를 고려했던 과정을 포스팅 해보고자 합니다. 📌 무조건 쿼리 속도가 빠르면 strong-park.tistory.com 지난번에는 간단한 쿼리를 이용해서 인덱스를 통해 성능을 개선한 내용을 포스팅했습니다. 쿼리 수행 시간이 약 19ms정도 개선되었는데, 이 정도의 차이는 상당히 적은 차이입니다. 왜냐하면 네트워크 IO작업 한번만 해도 10ms가 넘는 경우가 있기 때문입니다. 그래서 좀 더 복잡한 쿼리를 만들기 위해서는 (진행중인..

마이페이지에서 유저가 발급받은 쿠폰 이력을 조회하는 기능을 구현해야 했습니다 해당 기능 구현 시 쿼리 최적화를 고려했던 과정을 포스팅 해보고자 합니다. 📌 무조건 쿼리 속도가 빠르면 되는 걸까? 쿼리 최적화를 고려한 기능을 만들면서 궁금한 점이 생겼습니다. 어떤걸 기준으로 쿼리 최적화가 됐다 라고 하는 것일까? 레코드 건수가 제일 작은게 드라이빙 테이블로 되는 것 같은데, 각 테이블 당 레코드 건수를 몇개를 넣어야 하는 것일까? 실행 계획을 보면서 인덱스를 이것저것 설정해보니, 속도는 빠르지만 ALL인 상황, 속도는 느리지만 index인 상황, filtered가 높아지거나 낮아지거나 등 여러 가지 상황에 따라 실행 계획이 바뀌는 것 같습니다. 그래서 처음에는 어떤 걸 기준으로 쿼리가 최적화되었다라고 봐야..

InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공한다. 그 때문에 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어나다. 1. 프라이머리 키(PK)에 의한 클러스터링 엔진 InnoDB MyISAM 클러스터링 키 지원 지원 미지원 물리적 주소 사용 프라이머리 키 값 레코드의 주소 값 InnoDB 스토리지 엔진 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링되어 저장된다. 즉, 프라이머리 키 값의 순서대로 디스크에 저장된다는 뜻이다. 모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용한다. 프라이머리 키가 클러스터링 인덱스이기 때문에 프라이머리 키를 이용한 레인지 스캔은 상당히 빨리 처리 될 수 있다. 결과..