들어가기 앞서
모든 것은 아파치 루씬에서 시작되었습니다. Doug Cutting이 발표한 역 색인(Inverted Index)구조는 빠른 검색 결과를 제공하였습니다.
아파치 루씬 -> 아파치 솔라 -> 엘라스틱 서치
기존 URI 검색 방식 -> Request Body 방식
검색 엔진 vs 검색 시스템 vs 검색 서비스
- 검색 엔진: 웹에서 정보를 수집해 검색 결과를 제공, 현대 카테고리별 검색 결과 제공
- 검색 시스템: 검색엔진을 기반으로 구축된 시스템, 색인하고 검색 결과를 사용자 인터페이스로 제공
- 검색 서비스: 검색 엔진 기반으로 구축한 검색 시스템을 활용해 검색 결과를 서비스
검색 시스템의 구성요소
- 수집기:
- 필요한 정보 수집
- 크롤러, 스파이더, 웜, 웹 로봇 등으로 불림
- 스토리지: DB에서 데이터를 저장하는 장소, 검색엔진은 색인한 데이터를 스토리지에 보관
- 색인기:
- 수집기에서 수집한 정보를 가공해서 저장해준다
- 다양한 형태소 분석기를 조합 -> 의미있는 용어 추출 -> 역색인 구조로 데이터 저장
- 검색기: 사용자의 질의를 입력받아 스토리지 기반으로 결과 반환
RDBM VS 엘라스틱 서치
1. 용어비교
| RDBM | ElasticSearch |
| 데이터베이스 | 인덱스 |
| 테이블 | 타입 |
| 행 | 문서 |
| 열 | 필드 |
| 스키마 | 매핑 |
| SQL | Query DSL |
| 파티션 | 샤드 |
2. CRUD 방식 차이
| RDBM | ElasticSearch | 기능 |
| SELECT | GET | 데이터 조회 |
| INSERT | PUT | 데이터 생성 |
| UPDATE | POST | 인덱스 업데이트 |
| DELETE | DELETE | 데이터 삭제 |
3. 사용자 데이터 방식 차이
| ID | name | sex | phoneNumber |
| 1 | 이난 | 여 | 018-0000-0000 |
| 2 | 인환 | 남 | 014-0000-0000 |
1) SQL문
SELECT * FROM USER WHERE NAME='이난'
실행 결과
| 1 | 이난 | 여 | 018-0000-0000 |
2) 엘라스틱 서치 Search API
GET http://localhost:25565/user/_search?q=Name:이난
실행결과(JSON 형태로 제공)
{
"ID" : 1,
"name" : "이난",
"sex" : "여",
"phoneNumber" : "018-0000-0000"
}
- 질의가 영문인 경우, 대, 소문자 구분없이 모두 찾아준다. -> RDBM은 불가능
- 구조화 되지 않은 비 정형 데이터 검색 가능
엘라스틱서치의 장점
최근 대량의 데이터 검색을 위해 NoSQL을 많이 사용한다. 엘라스틱서치도 NoSQL의 일종이다. 또한 mongoDB처럼 대용량 스토리지로도 활용이 다능하다
- 오픈소스 검색엔진
- 전문 검색(Full Text): 내용 전체를 색인해서 특정 단어가 포함된 문서를 검색
- 역색인: NoSQL임과 동시에 역색인 지원 -> 단어를 찾으면 단어와 관련된 문서 제공
- RESTFUL API: HTTP 기반의 RESTFUL API를 지원, JSON형식 사용 -> 다양한 운영체제, 언어 플랫폼에서 사용가능
- 통계 분석: 키바나를 이용한 통계분석 가능
- Schemaless: DB와 다르게 정형화 되지 않은 문서도 색인하고 검색 가능
- 샤드: 수십억개의 문서를 분산하여 빠르게 처리
엘라스틱서치의 단점
- 실시간 검색 X : 내부적으로 커밋과 플러시 등 여러 과정이 일어남
- 트랜잭션, 롤백 기능 제공 X -> 데이터 손실의 위험
- 데이터 업데이트 제공 X