https://youtu.be/0r0-R8NhINs?si=201m4ZhbapFzGgo-

다로의 Elasticsearch

• 다로의 Elasticsearch
  • 1. LIKE 검색의 근본적인 한계
    • 1.1 풀스캔 구조의 문제
    • 1.2 언어 문제 (동의어 / 형태소)
  • 2. Elasticsearch가 등장한 이유
    • 2.1 ES의 핵심 특징
      • ✅ 문서 기반 (JSON)
      • ✅ 불변 구조 (Immutable)
  • 3. Elasticsearch의 확장 구조
    • 3.1 수평 확장 (Horizontal Scaling)
    • 3.2 핵심 구조
    • 3.3 샤딩 구조의 핵심
    • 3.4 안정성 (Replica)
  • 4. Elasticsearch의 핵심: 분석기(Analyzer)
    • 4.1 분석기 전체 흐름
    • 4.2 Character Filter
    • 4.3 Tokenizer
    • 4.4 Token Filter (핵심)
  • 5. 역색인(Inverted Index): 성능의 본질
    • 5.1 기존 방식 vs ES
      • ❌ 기존
      • ✅ ES
    • 5.2 예시
    • 5.3 검색 과정
  • 6. 핵심 정리 (실무 관점)
  • 7. 실무에서 진짜 중요한 인사이트
    • 7.1 검색은 DB 문제가 아니다
    • 7.2 성능은 저장 방식에서 결정된다
    • 7.3 Trade-off 이해가 핵심
  • 8. 결론

---

1. LIKE 검색의 근본적인 한계

1.1 풀스캔 구조의 문제

기존 RDB 기반 검색은 대부분 이런 형태다:

SELECT * FROM product WHERE name LIKE '%셔츠%'

이 방식의 본질은 단순하다.

👉 인덱스를 타지 못하고 전체 데이터를 뒤진다 (Full Scan)

결과:

• 데이터가 많아질수록 성능 급격히 저하
• CPU / IO 사용량 증가
• 검색 응답 시간 증가

즉, 확장성과 완전히 반대 방향의 구조

---

1.2 언어 문제 (동의어 / 형태소)

더 치명적인 문제는 이것이다:

👉 “셔츠” 검색 → “shirt” 결과 안 나옴

이유:

• DB는 문자열을 그대로 비교
• 의미(semantic)를 이해하지 못함

즉,

입력	결과
셔츠	셔츠만
shirt	shirt만

👉 사용자 입장에서는 “검색이 안 된다”

---

2. Elasticsearch가 등장한 이유

이 문제를 해결하기 위해 등장한 것이 바로 👉 Elasticsearch (ES)

핵심 정의:

검색 + 분석에 특화된 NoSQL DB

---

2.1 ES의 핵심 특징

✅ 문서 기반 (JSON)

{
  "name": "셔츠",
  "price": 10000
}

👉 RDB의 row 대신 document 사용

---

✅ 불변 구조 (Immutable)

ES는 데이터를 수정하지 않는다.

👉 수정 = 삭제 + 재생성

이 구조의 효과:

• OS 캐시 활용 극대화
• 락 없음 → 동시성 높음
• 읽기 성능 극대화

대신:

👉 쓰기 비용 증가 (Trade-off)

---

💡 핵심 철학:

“검색 속도를 위해 쓰기 비용을 희생한다”

---

3. Elasticsearch의 확장 구조

3.1 수평 확장 (Horizontal Scaling)

RDB:

• 서버 성능 업 (Vertical)

ES:

• 서버 개수 증가 (Horizontal)

👉 데이터가 늘어날수록 더 빨라질 수 있음

---

3.2 핵심 구조

개념	설명
Cluster	전체 시스템
Node	서버
Shard	실제 데이터 저장 단위
Index	테이블
Document	레코드

---

3.3 샤딩 구조의 핵심

예:

• 문서 90개
• 샤드 3개

👉 각 노드에 30개씩 분산

검색 시:

👉 90개 검색 ❌ 👉 30개씩 병렬 검색 ✅

---

3.4 안정성 (Replica)

• Primary shard → 원본
• Replica shard → 복제본

효과:

• 장애 복구 가능
• 읽기 분산 가능

👉 성능 + 안정성 동시 확보

---

4. Elasticsearch의 핵심: 분석기(Analyzer)

검색 성능의 진짜 핵심은 여기다.

👉 “검색이 잘 되게 저장한다”

---

4.1 분석기 전체 흐름

문장 → Character Filter → Tokenizer → Token Filter → 저장

---

4.2 Character Filter

역할: 👉 불필요한 문자 제거

예:

오늘은 셔츠를 샀다 👍
→ 오늘은 셔츠를 샀다

---

4.3 Tokenizer

역할: 👉 문장을 토큰으로 분해

오늘은 셔츠를 샀다
→ 오늘 / 은 / 셔츠 / 를 / 사다

특징:

• 형태소 분석 가능
• N-gram 가능

---

4.4 Token Filter (핵심)

여기서 게임이 바뀐다.

👉 동의어 처리

예:

셔츠 → shirt

저장 결과:

셔츠, shirt 둘 다 저장됨

---

💡 핵심 포인트:

검색을 잘하려면 “저장할 때” 준비해야 한다

---

5. 역색인(Inverted Index): 성능의 본질

5.1 기존 방식 vs ES

❌ 기존

문서 → 단어 찾기

✅ ES

단어 → 문서 찾기

---

5.2 예시

문서:

1. 오늘 셔츠를 샀다
2. 오늘 산 셔츠를 입었다

역색인:

셔츠 → [1, 2]
오늘 → [1, 2]
사다 → [1]
입다 → [2]

---

5.3 검색 과정

검색어: shirt

1. 분석기 → shirt
2. 역색인 조회
3. 문서 ID 반환

👉 O(1)에 가까운 속도

---

6. 핵심 정리 (실무 관점)

항목	LIKE 검색	Elasticsearch
속도	느림 (풀스캔)	매우 빠름
확장성	낮음	높음
동의어	불가능	가능
구조	RDB	분산 시스템
검색 품질	낮음	높음

---

7. 실무에서 진짜 중요한 인사이트

이 내용을 단순 기술이 아니라 “설계 관점”으로 보면:

---

7.1 검색은 DB 문제가 아니다

👉 데이터 구조 설계 문제

---

7.2 성능은 저장 방식에서 결정된다

• RDB: 저장 중심
• ES: 검색 중심

---

7.3 Trade-off 이해가 핵심

• ES: 읽기 ↑ / 쓰기 ↓
• RDB: 쓰기 ↑ / 읽기 ↓

👉 상황에 맞게 선택해야 한다

---

8. 결론

Elasticsearch는 단순한 검색 엔진이 아니다.

👉 검색을 위한 데이터 설계 철학 자체를 바꾸는 도구

---

LIKE 검색의 한계를 극복하려면:

1. 검색 구조를 바꾸고
2. 데이터 저장 방식을 바꾸고
3. 의미 기반 검색을 도입해야 한다

---

📌 참고 자료

• 영상: https://youtu.be/0r0-R8NhINs?si=6-Ij5gkv_vgYfB_3

---