본문 바로가기

개발 지식/Lucene

Lucene과 DB 검색 차이점

반응형

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' 카테고리의 다른 글

Lucene과 DB 검색 차이점  (0) 2021.04.12