반응형 DB8 서버 부하를 줄이는 마법: Redis(글로벌) vs Caffeine(로컬) 캐시 전략 총정리 System Performance Optimization데이터를 가장 빨리 가져오는 법, 캐시(Cache) 설계의 정석 안녕하세요, code-resting입니다. 모든 요청을 데이터베이스(DB)에서 처리한다면 서버는 금세 비명을 지를 것입니다. 성능 좋은 백엔드 서버의 핵심은 "얼마나 DB 조회를 줄이느냐"에 달려 있죠. 오늘은 상황에 맞는 캐시 선택 기준과 효율적인 아키텍처를 살펴보겠습니다.1. 로컬 캐시 vs 글로벌 캐시캐시는 어디에 저장하느냐에 따라 크게 두 종류로 나뉩니다.📍 로컬 캐시 (Caffeine, Ehcache)장점: 네트워크 비용 없음, 압도적으로 빠름.단점: 서버 간 데이터 불일치 발생, 메모리 공유 불가.용도: 설정값, 공지사항 등 자주 안 변하는 데이터.🌐 글로벌 캐시 (Red.. 2026. 3. 8. [실전] Spring Data Elasticsearch로 구현하는 '한글 자동 완성' 검색 시스템 Search Implementation Series 02이론을 넘어 실전으로! Elasticsearch 자동 완성 구현하기 안녕하세요, code-resting입니다. 지난 시간에는 Elasticsearch의 역색인 원리를 살펴보았습니다. 오늘은 이를 스프링 부트에 연동하여, 한국어 검색에서 필수적인 Nori 분석기 설정법과 Edge n-gram을 활용한 '검색 자동 완성' 기능을 구현해 보겠습니다.1. 의존성 설정 및 도메인 모델링Spring Data Elasticsearch를 사용하면 익숙한 Repository 패턴으로 ES에 접근할 수 있습니다.// build.gradledependencies { implementation 'org.springframework.boot:spring-boot-st.. 2026. 3. 5. RDBMS로 감당 안 되는 검색, Elasticsearch로 10배 빠르게 만들기 (역색인의 비밀) Search Engine Deep Dive 검색의 패러다임 시프트, Elasticsearch와 역색인(Inverted Index) 안녕하세요, code-resting입니다. 서비스의 데이터가 백만 건, 천만 건을 넘어가면 사용자의 검색 요청은 점점 느려집니다. 특히 텍스트 중간에 포함된 단어를 찾는 LIKE '%검색어%' 쿼리는 인덱스를 타지 못해 전체 테이블을 스캔하게 되죠. 오늘은 이 문제를 근본적으로 해결해 주는 검색 엔진의 강자, Elasticsearch의 핵심 원리를 정리해 보겠습니다. 1. 왜 RDBMS 검색은 느릴까? RDBMS는 행(Row) 지향 구조입니다. 책의 본문을 첫 페이지부터.. 2026. 3. 4. "인덱스 걸었는데 왜 느려요?" DB 성능을 깎아먹는 인덱스 설계 안티 패턴 5가지 Database Tuning Series성능의 양날의 검, DB 인덱스를 망치는 5가지 실수 안녕하세요, code-resting입니다. 쿼리가 느려지면 가장 먼저 하는 일이 "인덱스 추가"입니다. 하지만 인덱스는 공짜가 아닙니다. 잘못 설계된 인덱스는 INSERT 성능을 떨어뜨릴 뿐만 아니라, 오히려 옵티마이저를 헷갈리게 만들어 전체 시스템 성능을 저하시키기도 하죠. 오늘은 실무에서 자주 범하는 인덱스 설계의 치명적인 실수들을 짚어보겠습니다.1. 낮은 카디널리티(Cardinality)에 인덱스 걸기성별(남/여)이나 활성화 여부(Y/N)처럼 값의 종류가 적은 컬럼에 인덱스를 거는 것은 최악의 선택 중 하나입니다.❌ 문제점: 인덱스를 읽고 다시 테이블 레코드를 찾아가는(Random I/O) 비용이 그냥 전체.. 2026. 3. 3. 이전 1 2 다음 반응형