ElasticSearch
사실 ELASTICSEARCH의 기술은 새롭고 찾기 어렵지 않다.
Elasticsearch는 2010년 Shay Banon에 의해
Apache Lucene 위에 오픈소스 검색 엔진으로 처음 출시되었습니다.
그러니까 역사가 꽤 깊은 베이스가 있다는 것이다
왜 사용해야하는가?
-
검색기능 : 분산 아키텍쳐와 인덱싱 및 검색에 대한 최적화 알고리즘을 사용하여 대용량
데이터 세트에서 빠르게 검색을 수행할 수 있다. -
확장성 :수평적 확장 가능. 샤딩 및 복제를 통해 데이터를 분산 저장하고 처리할 수 있습니다
-
다양한 검색 기능: 풀스텍 필터링 정렬 집계 하이라이팅 등 효과적인 검색가능
-
데이터 모델 : 스키마를 안사용하는 json 문서 모델.
-
통합: Elasticsearch 는 Logstash, Kibana , Beats 와 같은 친구들과
엄청난 시너지를 낼수있다.
-
접근성 : 오픈소스.
-
처리기능 : 실시간 데이터 처리 및 다양한 서비스/plugin을 통해 다양한 문제 처리 가능
왜 꺼려지는가?
- 복잡한 설정과 운영 :
- 노드 샤드 클러스터 복제 전략들을 이해하고 관리하느데 힘들수도 있다.
이러한 복잡함을 줄이기 위해 꾸준히 유저가 신경 안쓸수있도록 업데이 트 중이다
- 메모리 및 디스크 사용량:
- Elasticsearch는 인덱싱 및 검색을 위해 메모리와 디스크 공간을 사용합니다. 대용량 데이터 세트를 처리하는 경우 적절한 메모리 및 디스크 리소스를 할당해야 할 수 있습니다.
- 학습 곡선 :
- Elasticsearch를 제대로 사용하려면 logstash, kibana , beats 또한 다룰줄 알아야한다.
ELK 들어가는 과정:
Postgres로 사용한 쿼리문입니다. 처음에는 FULL SCAN으로 사용했고 시간이 무시무시하게 걸렸다.
SELECT * FROM your_table_name WHERE your_column_name LIKE '%keyword%';다음은 Btree 인덱스를 사용했습니다. 앞에 %prefix 사용 불가능하여 데이터를 다 받아오지 못했습니다
SELECT * FROM your_table_name WHERE your_column_name LIKE 'keyword%';다음 FULLTEXT 를 사용했다. data, 속도 사용하기 나쁘지않았다. 하지만 100% 원하는 결과를 보여주지는 않았다.
SELECT * FROM your_table_name WHERE your_column_name @@ to_tsquery('keyword');postgres indexing의 n-gram (2) 은 ex 성수동 = 성수, 수동 을 받고 성수동을 못받아오는 문제가 있었다.
그리고 데이터가 많아 질수록 postgres의 FULLTEXT의 효율성이 조금 씩 떨어져갔다.
- Postgres에도 다양한 extension 과 plugin을 통해 설정을 바꿔서 더 좋은 효과를 볼수도 있다고 한다 (by gpt)
그래서 inverted-indexing 등을 사용하여 data가 많을 때 fulltext 서치의 효율성을 유지할 수 있는, 검색환경애 최적화된 ELASTICSEARCH를 도입했다.
출처: https://esbook.kimjmin.net/06-text-analysis/6.1-indexing-data
데이터가 많아지면 inverted-indexing의 효과가 빛난다. 그래서 elasticsearch가 다른 db 보다 더 빠르고 효율적인것이다.
ELASTICSEARCH 의 쿼리와 Mapping으로 N-gram을 설정할수있고 옳바른 node와 sharding을 통해 scaling 또한 가능하다. 그 외에도 많은 기능이 있습니다 꼭 한번 사용해보는걸 추천합니다.
해결해야할 문제:
1. Term이 Wildcard보다 더 빠르게 결과를 반환해야하는데 현재 같은 시간이걸림
2. Category 검색시 postgres가 이상할 정도로 더 빠름. 다른 서버의 응답속도를 의심하는중.
3. Monitoring - 멘토님이 추천하심.
