ioh's Development

WIL - 5주차 ("왜?"를 멈추지 않았더니 보이기 시작한 것들)

이번 주에 새로 배운 것"왜?"라는 질문이 깊이를 만든다이번 주는 유독 "왜?"를 많이 물었다. 복합 인덱스를 공부하다가 "카디널리티가 높은 컬럼을 앞에 놓으라"는 규칙을 만났다. 예전 같았으면 그대로 외웠을 것이다. 그런데 이번엔 "왜?"를 던져봤다. 왜 카디널리티가 높으면 앞이어야 하지? B+Tree에서 실제로 어떤 차이가 생기지? 등호 조건과 범위 조건이 섞이면 어떻게 되지? 파고 들어가니까 답이 달라졌다. 카디널리티보다 등호 조건이 먼저라는 게 진짜 규칙이었다. 카디널리티가 아무리 높아도 범위 조건이면 그 뒤 컬럼은 인덱스를 못 탄다. B+Tree의 리프 노드가 정렬되는 방식을 이해하고 나니, "왜 그런지"가 보였다. 외운 규칙이 아니라 원리에서 나온 판단이 되니까, 새로운 상황을 만나도 스스로 ..

RedisTemplate을 까보고 나서야 캐시를 제대로 쓸 수 있었다

redisTemplate.opsForValue().set(key, json, ttl) — 이 한 줄 뒤에 뭐가 있는지 모르고 쓰면, 캐시가 서비스를 살리는 게 아니라 죽인다 TL;DR이커머스 프로젝트에 Cache-Aside 패턴을 직접 구현했다. @Cacheable 대신 RedisTemplate으로 캐시 흐름을 직접 제어했는데, 구현하면서 get() 한 줄이 Master/Replica 라우팅을 거친다는 것, 커밋 전에 캐시를 삭제하면 stale 데이터가 영구화된다는 것, 같은 캐시 삭제인데 트랜잭션 관리 방식에 따라 무효화 전략이 달라야 한다는 것을 알게 됐다. RedisTemplate의 동작 흐름을 코드 레벨로 추적하고 나서야, 왜 이런 처리를 해줘야 하는지 납득이 됐다."그냥 쓰면 되지, 왜 까봐?"..

카디널리티가 높으면 앞에 놓으라는 규칙을 믿었다가 느려졌다

복합 인덱스 컬럼 순서의 진짜 1순위는 카디널리티가 아니었다 TL;DR복합 인덱스를 설계할 때 "카디널리티 높은 컬럼을 앞에"라는 규칙을 따랐다. 근데 EXPLAIN을 찍어보니 인덱스를 걸었는데도 filesort가 사라지지 않았다. 원인을 파보니 컬럼 순서의 진짜 1순위는 카디널리티가 아니라 조건 유형(등호 vs 범위)이었다. B+Tree 리프 노드의 정렬 원리를 이해하고 나서야 인덱스 설계가 풀렸다."카디널리티 높은 컬럼을 앞에" 이 규칙을 의심 없이 따랐다상품 목록 API에 복합 인덱스를 걸어야 했다. products 테이블 약 20만 건, 자주 쓰이는 WHERE 조건은 status와 brand_id.brand_id: 카디널리티 500 (고유 값 500개)status: 카디널리티 3 (ACTI..