반응형
Lucene과 DB 검색 차이점
회사에서 루씬을 이용하여 Full-Text에 대한 '키워드 검색' 기능을 개발하면서 루씬이라는 라이브러리를 처음 접하게 되었다. 아직 연차가 낮고 아는게 많이 없다보니, 해당 기능을 구현하려면 당연히 위에서 말씀해주신대로 루씬을 써야되는구나 라고 생각하여 왜 이것을 써야하는지에 대한 생각을 해본적이 없었다. 그러다 최근 누군가에게 '루씬이 왜 빠른거에요?' 라는 질문에 답을 못했던 경험이 있어서 내가 진짜 기본적인 것들을 머리속에 정리를 안하고 사는구나 라는 생각에 바로 정리해본다....
Lucene 이란
루씬은 정보 검색 라이브러리로, 특히 Full-text 데이터를 인덱싱하고 검색하는데 특화되어있는 라이브러리다. 루씬을 설명할 때 많이 등장하는 개념이 Elasticsearch인데, 이 elasticsearch는 루씬 라이브러리를 적용한 정보 검색 '솔루션'을 의미한다. 즉, 루씬은 개발자가 자신의 어플리케이션의 목적에 부합하는 Indexing과 Query를 개발하도록 도와주는 '라이브러리' 임을 의미한다.
Lucene과 DB 검색의 차이점
- DB의 인덱싱은 full-text를 인덱싱하는 용도로 설계되지 않았기 때문에
%검색키워드%등의 쿼리를 사용할 경우 index가 제대로 적용되지 않는다. 그러므로, DB에서 LIKE를 이용하여 쿼리를 날리는 것은 성능을 저하시킬 수 있다. 또한, 필요한 검색 키워드가 여러개인 경우 LIKE를 그만큼 더 사용해야 되기 때문에 효율성면에 있어서도 좋지 않다. - 따라서 효율적인 검색 시스템을 위해서는 데이터(article, document 등등)를 인덱싱하고 키워드 테이블을 동시에 저장하는 인덱싱 메카니즘과 같은 기술이 필요하다. 그리고 이를 잘 구현한 것이 Lucene 이라고 말할 수 있을 것 같다.
- 아래 표는 Lucene vs Database Search 에 간략하게 차이점에 대한 내용이 나와 있어서 간단하게 번역을 해보았다.
| Lucene의 텍스트 인덱싱 | DB | |
|---|---|---|
| 인덱싱 | full-text index를 통해 데이터를 인덱싱하고 reverse index를 만든다. | LIKE 쿼리의 경우, 데이터는 기존 인덱스에 접근할 수 없다. |
| 매치 결과(검색 결과) | 매칭되는 단어 요소(용어)에 의해 언어 분석 인터페이스의 구현을 통해서 중국어와 또 다른 비영어권 언어의 문서(doc)를 얻을 수 있다. | "%org%" 로 사용하는 것은 "organization"과 매치된다. 다수의 유사 일치 키워드 같은 경우(Multiple fuzzy matching keyword), "%com%org%" 라고 쓰는 것은 xxx.org..xxx.com 의 단어 순서와 매치될 수 없다. |
| Matching | 매칭 알고리즘이 유사성의 정도를 매치시킨다. (A matching algorithm matches (similarity) to different degree) | degree control이 없다. 예를 들자면, 한 단어가 다섯번이 나타나던, 한 번만 나오던 똑같이 매칭된다. |
| 결과 출력 | 특별한 알고리즘을 통해서 match가 가장 많이 된 결과를 가장 맨 처음에 리턴하고, 상대적으로 덜 match 된 것이 각각 리턴된다. | 매치되는 것들에 대한 set이 모두 리턴된다. 따라서 이러한 temporary 한 결과 셋을 만드는데 많은 메모리를 사용하게 된다. |
| Customization | 중국어 지원을 포함한 인덱싱 법칙(Index rule)들로 어플리케이션을 쉽게 커스터마이징 할 수 있다. | 커스터마이징 불가능 |
| 결론 | 부하가 많이 걸릴만한 fuzzy query와 대용량 corpus(크고 구조화된 텍스트 집합으로 구성된 언어 리소스)에 이상적이다. | fuzzy query에 효율적이지 못함 |
다음에는 Lucene이 왜 Full-Text 검색에 효율이 좋은지 정리를 해보겠다.
Reference
- Lucene vs Database Search : https://www.programcreek.com/2011/08/lucene-vs-database-index/
반응형