1. 들어가며: 격리 수준은 왜 필요한가? 이전 포스팅에서 다중 트랜잭션 환경에서 데이터베이스의 가장 큰 숙제는 데이터의 정합성(Consistency) 유지와 시스템 성능(Performance)의 최적화 사이에서 균형을 잡는 일이라는 것을 알았다. 모든 트랜잭션을 하나씩 순차적으로 처리하면 정합성은 완벽하겠지만, 수많은 요청이 몰리는 현대 서비스에서 이는 불가능에 가깝다. 반대로 성능을 위해 모든 간섭을 허용하면 데이터는 아수라장이 될 것이다. 이러한 문제를 해결하기 위해 도입된 개념이 바로 격리성 수준(Isolation Level)이다. 이는 "여러 트랜잭션이 동시에 실행될 때, 서로의 연산을 어디까지 노출하고 격리할 것인가"를 정의하는 설정이다.2. 격리성 수준(Isolation Level)의 개요..

1. 들어가며: 단일 트랜잭션을 넘어 다중 트랜잭션의 세계로 우리는 앞서 하나의 트랜잭션이 어떻게 시작되고, COMMIT 또는 ROLLBACK을 통해 어떻게 종료되는지 학습하였다. 하지만 이는 데이터베이스를 혼자 사용하는 이상적인 상황(단일 트랜잭션)을 가정한다. 실제 은행 서비스나 뉴스 서비스와 같은 환경에서는 수많은 사용자가 동시에 데이터를 읽고 쓰는 다중 트랜잭션 환경이다. 이처럼 여러 트랜잭션이 뒤섞여 실행될 때, 아직 완료되지 않은(Uncommitted) 트랜잭션의 변경 사항을 다른 트랜잭션이 보게 된다면 어떤 일이 벌어질까? 우리는 이를 통해 동시성 제어의 실질적인 필요성을 체감하게 된다. 2. 동시성 제어의 필요성: 비즈니스 사례 비교2.1. 금융 서비스: 데이터 부정합의 치명적 결과 (트..

1. 들어가며: 왜 Lock을 배우기 전에 트랜잭션을 알아야 하는가? 데이터베이스에서 Lock(잠금)은 특정 자원에 대해 여러 요청이 동시에 들어올 때 데이터의 일관성을 지키기 위한 장치이다. 하지만 '언제까지 잠금을 유지할 것인가?', '어떤 단위로 잠금을 적용할 것인가?'라는 질문에 답하기 위해서는 반드시 트랜잭션(Transaction)의 개념이 선행되어야 한다. 트랜잭션은 데이터베이스의 상태를 변화시키는 하나의 논리적인 작업 단위를 의미한다. Lock은 바로 이 트랜잭션의 독립성을 보장하기 위해 사용되는 도구이다. 따라서 트랜잭션의 정의와 성질(ACID)을 명확히 이해해야만, 이후에 다룰 다양한 Lock의 종류와 격리 수준(Isolation Level)을 깊이 있게 파악할 수 있다.2. 트랜잭션..

1. 들어가기 앞서지금까지 학습했던 Index를 이용하여 성능 최적화 경험을 실습을 통해 알아보자. 우선 우리는 일반적인 E-Commerce를 프로젝트로 가정하고 진행한다. 즉, 아래와 같이 전형적인 Member, Product, Order, OrderItem(중간 테이블)의 구조로 진행된다. 2. 코드 분석 (중요 엔드포인트)OrderController에는 아래 두 개의 중요한 검색 엔드포인트가 있다. 2.1. 복합 조건 주문 검색 API (/complex-search)호출 예시) GET /api/chapter3/orders/complex-search?startDate=2024-01-01T00:00:00&status=COMPLETED&minAmount=100000&page=0&size=20기능: 여러 ..

1. 들어가며 이전 장에서 우리는 데이터베이스의 두뇌인 옵티마이저가 최적의 경로를 찾는 과정인 '쿼리 실행 계획'의 개념을 살펴보았다. 이번 장에서는 실제 MySQL에서 제공하는 도구를 활용하여 실행 계획을 확인하는 방법과, 출력되는 지표 중 핵심적인 'Type'을 해석하는 방법을 상세히 고찰해 보고자 한다.2. 실행 계획 확인 방법: DESC 명령의 활용 MySQL에서 실행 계획을 확인하는 방법은 매우 간단하다. 실행하고자 하는 SELECT 쿼리 앞에 DESC 또는 EXPLAIN 키워드를 붙여 실행하면 된다.DESC SELECT * FROM book;실행 결과로 출력되는 표에는 다양한 정보가 포함되어 있으나, 성능 최적화 관점에서 반드시 주목해야 할 핵심 항목은 다음과 같다.id: 쿼리 내의 처리 순서..

1. 들어가며 인덱스의 원리와 유형을 학습하는 것만으로 모든 성능 문제가 해결되지는 않는다. 인덱스는 데이터를 효율적으로 찾기 위한 도구일 뿐이며, 이 도구를 실질적으로 어떻게 활용할지 결정하는 상위 개념인 쿼리 실행 계획을 이해해야 한다. 이를 위해 먼저 MySQL의 내부 구조를 살펴본다.2. MySQL의 내부 구조 MySQL 시스템 내부에는 크게 옵티마이저(Optimizer)와 스토리지 엔진(Storage Engine, InnoDB)이 존재한다. 이들의 관계를 도서관에 비유하면 다음과 같다.옵티마이저(사서): 도서관의 사서와 같은 역할을 수행한다. 특정 책이 어느 서가에 있는지, 그리고 그 책을 찾는 가장 빠른 경로가 어디인지 안내하는 지휘 통제실이다.스토리지 엔진(서가): 실제 데이터가 저장된 ..

1. 들어가며인덱스의 물리적 구현 방식인 B+Tree 구조에서 가장 핵심적인 차이는 '리프 노드(Leaf Node)에 무엇을 저장하는가'에 있다. 데이터베이스는 데이터를 저장하는 물리적 방식에 따라 인덱스를 클러스터드와 논클러스터드로 분류하며, 이 차이를 이해하는 것이 쿼리 성능 최적화의 시작이다.2. 클러스터드 인덱스(Clustered Index): 실제 데이터가 담긴 '책장' MySQL의 InnoDB 엔진에서 클러스터드 인덱스는 단순한 보조 수단이 아닌 테이블 그 자체를 의미한다. 데이터가 저장되는 물리적인 순서가 인덱스의 정렬 순서와 일치하며, 테이블당 단 하나만 존재할 수 있다.구조적 특징: B+Tree의 리프 노드에 도달하는 순간, 해당 행(Row)의 모든 컬럼 데이터가 직접 저장되어 있다.비..

1. 들어가며 앞서 인덱스를 '데이터를 미리 정렬해 둔 사본'이라고 설명했다. 그렇다면 데이터베이스는 이 정렬된 데이터를 단순히 선형 리스트(Linear List) 형태로 보관할까? 만약 수천만 건의 데이터를 단순히 일렬로 정렬해 둔다면, 데이터를 하나 추가할 때마다 뒤에 있는 수천만 건의 데이터를 한 칸씩 밀어내야 하는 성능 재앙이 발생한다. 정렬된 리스트에서 특정 값을 찾는 이진 탐색 자체는 O(log N)으로 효율적이다. 그러나 데이터베이스 환경에서는 데이터의 삽입·삭제가 빈번하게 발생하며, 이 경우 정렬된 리스트 구조는 대규모 데이터 이동을 유발해 치명적인 성능 저하를 일으킨다. MySQL에서는 이를 해결하기 위해 B+Tree라는 자료구조를 이용한 InnoDB 엔진을 사용한다. 인덱스의 깊은 ..