코딩 메모장

1. 네스티드 루프 조인 (Nested Loop Join)조인 연결 컬럼에 모두 인덱스가 있을 때 사용하는 기본 조인 방식드라이빙 테이블에서 레코드 1건 읽기 ↓즉시 드리븐 테이블에서 일치하는 레코드 찾기 ↓별도 버퍼 없이 바로 반환 (중첩 반복문과 유사)드리븐 테이블 인덱스가 없으면 왜 느린가?드라이빙 테이블 일치 레코드 = 1,000건 ↓드리븐 테이블 인덱스 없음 ↓드리븐 테이블 풀 스캔 1,000번 수행 → 매우 느림👉 옵티마이저는 최대한 드리븐 테이블이 인덱스를 사용하도록 실행 계획을 수립한다.2. 블록 네스티드 루프 조인 (Block Nested Loop Join)드리븐 테이블에 인덱스를 사용할 수 없을 때 조인 버퍼를 활용하는 방식블록 네스티..

풀 테이블 스캔(Full Table Scan) 선택 조건레코드 수가 너무 적을 때인덱스를 거치는 것보다 전체 스캔이 더 빠른 경우 (보통 테이블이 1페이지로 구성된 경우)적절한 인덱스 조건 없음WHERE절이나 ON절에 사용할 수 있는 인덱스가 없는 경우일치 레코드가 너무 많을 때인덱스 레인지 스캔이 가능하더라도, 조건에 맞는 레코드가 너무 많다고 판단한 경우리드 어헤드리드 어헤드(Read Ahead): 앞으로 필요할 데이터를 요청 전에 미리 디스크에서 읽어 버퍼 풀에 적재해두는 InnoDB의 최적화 기법이다. - 풀 테이블 스캔 시 리드 어헤드 동작 흐름① 포그라운드 스레드가 처음 몇 개의 페이지를 읽기 시작 ↓② 특정 시점이 되면 백그라운드 스레드로 읽기 작업을 넘김 ↓③ 백그..

인덱스 레인지 스캔인덱스 레인지 스캔은 인덱스에서 어디부터 어디까지 읽을지 범위가 정해졌을 때 사용하는 방식.예시) WHERE name >= 'Kim' AND name 와 같은 범위 검색에서단계 1: “어디서부터 읽을지 찾는 과정” 단계트리 위에서 아래로 내려가면서 시작 지점을 찾는다.단계 2: 스캔 단계시작 리프 노드를 찾았으면 리프 노드 안에서 정렬된 순서대로 쭉 읽는다.리프 노드는 서로 링크(포인터) 로 연결되어 있어서, 한 리프 노드를 끝까지 읽으면 링크를 타고 다음 리프 노드로 이동해서 계속 읽음단계 3: 실제 데이터 읽기 단계 👉 이 단계에서 랜덤 I/O 발생인덱스에는 보통 키 값과 레코드 주소(PK 또는 ROWID)인덱스에서 얻은 주소를 이용해실제 데이터 페이지를 다시 읽음최종 레코드 반..

인덱스 키 값의 크기인덱스 키가 커지면 발생하는 일로는 인덱스는 디스크에 저장되고, 검색 시 디스크 또는 메모리(Buffer Pool)에서 한 페이지 단위로 읽힌다.그런데 인덱스 키 값이 길어질수록 한 페이지에 저장할 수 있는 레코드 수가 줄어든다.👉 같은 데이터를 찾기 위해 더 많은 페이지를 읽어야 할 수 있음으로, 디스크 I/O 증가하고 검색 속도 저하인덱스 키 값이 작아야하는 이유인덱스에 저장되는 값의 바이트 수가 적어야한다는 의미왜 작아야 좋을까?InnoDB는 인덱스를 16KB 페이지 단위로 저장한다.키가 작으면한 페이지에 더 많은 인덱스 레코드 저장 가능B-Tree 높이가 낮아짐디스크 I/O 감소메모리 캐시 효율 증가인덱스의 선택도기본 상황SELECT *FROM bt_testWHERE coun..

CPU랑 메모리CPU랑 메모리는 전기로만 움직이는 장치로, 기술이 발전하면서 속도가 엄청 빠르게 좋아졌다.CPU → 계산 속도 엄청 빨라짐메모리 → 데이터 읽고 쓰는 속도 엄청 빨라짐하드디스크(HDD)랑 SSD(Solid State Drive)하드디스크(HDD)는 안에 원판이 실제로 돌아가는 기계 장치로물리적으로 움직여야 함읽을 위치까지 헤드가 이동해야 함시간이 오래 걸림👉 그래서 CPU/메모리만큼 빨리 발전하지 못했다.이러한 기계식 하드디스크 드라이브를 대체하기 위해 전자식 저장 매체인 SSD(Solid State Drive)가 출시됨.SSD는 기존 하드디스크 드라이브에서 원판를 제거하고, 그 대신 플래시 메모리를 장착움직이는 부품 없음그냥 전기 신호로 바로 읽음위치 이동 개념이 거의 없음👉 랜덤으..

격리 수준: 하나 트랜잭션 애에서 또는 서로 다른 트랜잭션 간의 작업 내용을 어떻게 공유하고 차단할 것인지를 결정하는 레벨을 의미한다.READ UNCOMMITED는 일반적인 데이터베이스에서는 거의 사용하지않고, SERIALIZABLE 또한 동시성이 중요한 데이터베이스에서는 거의 사용되지않는다.READ COMMITTED 격리 수준에서는 트랜잭션내에서 실행되는 SELECT 문장과 트랜잭션 외부에서 실행되는 SELECT 문장의 차이가 별로지만, REPEATABLE READ 격리 수준에서는 기본적으로 SELECT 쿼리 문장도 트랜잭션 범위 내에서만 작동한다. READ UNCOMMITTEDREAD UNCOMMITTED에서는 더티 리드(Dinty read)이라고 하는 현상이 발생한다.사용자 Aemployees 테이..

요약다중 WAS 환경에서의 안정적인 실시간 알림 전송을 위한 Kafka 기반 SSE 아키텍처 구축기본 포스팅은 Server-Sent Events(SSE)를 기반으로 하는 알림 시스템을 다중 WAS 환경에서도 안정적으로 운영하기 위해 Kafka를 도입한 전체 설계 및 구현 과정을 기술한 엔지니어링 아카이브이다.특히 다음과 같은 내용을 중심으로 구성되어 있다.단일 인스턴스에만 유효한 SseEmitter의 한계 → Redis 공유 불가Redis Pub/Sub 접근의 단점: 트랜잭션 불일치, 알림 유실 등Kafka 기반 브로커 아키텍처 도입: 알림 전송의 일관성, 확장성 확보단일 파티션 + 고유 consumer group 방식을 통한 브로드캐스트 패턴 구현멱등성, 순서 보장, DLQ 기반 재처리 구조 등 실전 ..

요약대규모 트래픽 대응을 위한 Redis 캐시 전략 실전 적용기본 포스팅은 튜닝 레포트 시스템에서 반복적으로 발생하는 피크 트래픽을 효과적으로 처리하기 위해, Redis 기반 캐시 구조를 도입하고 성능 개선을 검증한 전체 과정을 상세히 기록한 기술 보고서다.특히 다음과 같은 내용을 중심으로 구성되어 있다.월/목 오후 12:30 정기 발행 → 150명 동시 접속 시나리오 기반 부하 테스트캐시 미적용 시 평균 2.46초, 최대 8.53초 응답 지연 발생Cache Aside + Write Back 전략 도입을 통한 응답 시간 및 자원 사용량 최적화Redisson 락, TTL Jitter, 캐시 워밍업 등 실전 환경에 맞춘 캐시 안정화 기법 적용적용 후 DB 부하 98% 감소, 응답 속도 53ms로 46배 개선..

요약이 글은 튜닝 레포트 시스템에서 사용자의 동시 리액션 요청이 발생할 때 Redis 캐시의 JSON 객체가 충돌하며 생기는 Race Condition 문제를 어떻게 해결했는지, 실전 적용 경험을 바탕으로 정리한 기술 포스트다.다음과 같은 내용을 다룬다.문제 정의: Redis에 저장된 JSON을 동시에 수정할 때 발생하는 동시성 충돌5가지 대안 기술 비교: HINCRBY, Lua Script, Redis WATCH, SessionCallback, Redisson 분산 락선택 기준과 검토 포인트: 구조 호환성, 유지보수 난이도, 멀티 인스턴스 적합성 등최종 선택 – Redisson RLock: 기존 JSON 구조를 유지하며, Spring Boot 환경에서 안전하고 직관적으로 구현 가능 문제 정의멀티 인스턴..

1. 배경 및 문제 정의Cache Stampede란?Cache Stampede는 특정 캐시 키가 TTL 만료된 순간, 다수의 클라이언트 요청이 동시에 캐시 미스를 일으켜 백엔드(DB, 서비스 계층)에 집중적인 부하를 발생시키는 현상이다.기존 구조의 문제점모든 도메인에 대해 동일한 TTL(예: 30분)을 부여하고 있음.결과적으로, 모든 도메인의 캐시가 동일 시점에 만료되며, 인기 도메인일수록 동시에 재조회가 발생해 스탬피드 발생 위험이 커짐.2. 해결 전략 요약전략설명 기대 효과1. TTL Jitter도메인마다 고유 TTL을 부여 (기본값 ±3분 랜덤)TTL 동시 만료 분산, 스탬피드 완화2. Mutex Locking (Redisson)캐시 미스 발생 시 락을 획득한 요청만 DB 조회 허용동시성 제어, D..