| ES | Elasticsearch가 뭔데!

챌린지 팀에서는 서비스팀과 다르게 '성능향상' 이라는 부분을 초점으로 진행해야한다.

Java + Spring 걸음마 하고있었는데 어떻게 하면 빨리 걸을 수 있을까? 어떤 부분을 바꿔줘야 뛸 수 있을까? 를 고민하는 격

 

대량의 데이터를 수집하고 가공하고 사용하는데 있어 사용자가 불편함을 느끼지 않도록 서비스 할 수 있는 방법까지가 

우리가 해야할 고민이다.

 

데이터 수집 후 해야할 고민은 크게 두가지인데 검색 성능 향상과, 부하 및 안정화 부분 인 것 같다.

검색 성능 향상 부분에서 적용할 스택으로 엘라스틱 서치를 먼저 공부해보기로했다.

 

---

 

🌀 Elastic Search 그게 뭔데?

 

ES는 아파치 루썬 기반의 Java 오픈소스 분산 검색 엔진

방대한 양의 데이터를 신속하게 실시간으로 저장, 검색, 분석 할 수 있다.

 

그럼 왜 ES를 이용하는게 훨씬 빠를까?

ES는 데이터를 저장할 때 검색에 유리하도록 데이터를 역 인덱스 형태로 저장한다.

왼쪽(RDB) 인덱스 / 오른쪽(ES) 역 인덱스

만약 구글에서 햄버거집의 사이드 메뉴를 검색한다고 가정했을 때 데이터베이스가 RDB라면 아래와 같은 과정을 거쳐 보여지게 된다.

1. Doc1을 열어서 "치즈스틱"이 있는지 검색한다. 2. 키워드가 있으니 리스트에 저장한다 3. Doc2를 열어서 "치즈스틱"이 있는지 검색한다. 4. 키워드가 없으니 저장하지않는다. 5. Doc3을 열어서 "치즈스틱"이 있는지 검색한다. 6. 키워드가 있으니 리스트에 저장한다. 7. 저장된 리스트를 UI에 뿌려준다

이 과정을 ES를 적용한다면 "치즈스틱"이라는 키워드를 검색하였을 때 이 키워드가 포함된 도큐먼트만 쏙쏙 보여준다.

그렇기때문에 검색속도가 훨씬 빨라지는것!

 

RDS와 ES의 용어를 비교하여 대입해보면 아래 사진과 같다.

 

그럼 RDB를 빼고 ES로만 구성하면 되나요? 이렇게 좋은뎅?

ES도 단점이 있다. 내가 참조한 유튜브 강의에서는 이러한 단점 때문에 ES 단독으로 구성하는것은 추천하지 않는다하였다.

 

 

📍 엘라스틱서치 장단점

- 장점 
  : #hash-tag 방식으로 빠른 검색 능력을 제공한다.

  : 오픈소스를 사용하고, Bug FIX/Update가 자주 일어난다

  : RestAPI를 사용한다.
    ( select  == get, update == put, insert == post 등)

 

- 단점

: 일반적인 RDB보다 러닝커브가 있어 진입 장벽이 높다.

: 개별 레코드 검색시에는 RDB보다 수행 능력이 떨어지고, 특히 업데이트시 성능이 크게 떨어져서 업데이트가 잦은 애플리케이션이라면 엘라스틱서치는 적절한 기술이 아님

: 트랜잭션이 불가하고, Document간의 조인을 수행할 수 없어 조인을 수행하는 것 처럼 여러번을 별개로 수행해야한다.

( 만약에 2가지의 테이블을 조인하는 작업이 필요하다면, 2번의 쿼리를 수행해야한다. 대신 이렇게 수행해도 ES가 더 빠르다고 하긴 함)