SEARCH ENGINE

검색엔진에 필요한 자료를 알아보자

Elasticsearch Snapshot만들기

SEARCH ENGINE
클러스터와 인덱스가 커질수록 누적된 데이터를 유지해야할 필요성이 커집니다. 실제로 복원 할 수 없는 데이터가 존재 한다면 당신은 어떻게 하시겠습니까? ELasticsearch에서는 버전별로 데이터를 저장하여 이전상태를 유지 할 수 있는 Snapshot이라는 기능을 제공합니다. 이 모듈은 인덱스의 스탭샷 또는 클러스터 전체의 스냅샷을 만들 수 있습니다. 또한 리포트로 데이터의 저장을 지원 합니다. 어떻게 만들고 실행하는지 알아보도록 하겠습니다. 먼저 스냅샷을 저장할 경로에 폴더를 만듭니다. #mkdir /home/javacafe/elastic/backup elasticsearch의 config의 elasticsearch.yml 파일을 열어 아래와 같은 내용을 마지막줄에 추가 합니다. path.repo: ["/home/javacafe/elastic/backup"] 서버의 설정은 실시간으로 반영 되지 않기 때문에 반영을 위해 elasticsearch를 재기동 합니다. 재기동이 되었다면 첫번째 해야 할 일은 elasticsearch에 백업 저장소를 만드는 일입니다. 백업 저장소는 request body에 데이터를 실어서 보냅니다. #curl -XPUT 'http://localhost:9200/_snapshot/my_backup' -d { "type": "fs", "settings": { "location": "/home/javacafe/elastic/backup", "compress": true } }' 해당 내용을 응

#024 Elasticsearch 설치 후 production mode로 실행시 bootstrap checks failed 에러 해결

SEARCH ENGINE
어제 Elasticsearch 5.0이 릴리즈 되고 엘라스틱서치의 변경 된 부분을 테스트 하기 위해 엘라스틱서치를 받아 설치 해 보기로 했다. 당연 centOS에서 실행 했으며, develop mode에서는 잘 동작하는 것을 확인하였다. 당연 로컬에서는.. 원격에 있는 PC 에 설치를 하여 URL을 불러 사용 하기 때문에 elasticsearch.yml 파일의 network.host 설정에 _global_로 변경 하고 실행 하는 순간...   ERROR: bootstrap checks failed max file descriptors [4096] for elasticsearch process likely too low, increase to at least [65536] max number of threads [1024] for user [space_home] likely too low, increase to at least [2048]   위와 같은 에러가 발생하는 것을 확인 하였다.. 이리 찾아보고 저리 찾아봐도 각기 다른 설정을 해 보라고 했지만... 안되었다.. 짬빱을 굴려.. 에러메시지를 잘 읽어 보니.. file open 갯수를 늘리라는 소리였다. 왜 open갯수를 전체로 늘리는 지는 잘 모르겠지만.. 원인은 알았으니.. 해결을 해야 했다. #ulimit -a 명령어로 확인을 해보니 open files의 갯수가 1024 개 밖에 되지 않았다. core file size (blocks, -c) 0 data seg size (kbytes, -d)

#023 Solr Cloud 주무르기

SEARCH ENGINE
이번 장 부터는 솔라 클라우드에 대해서 알아 보려 한다. 주요섹션은 아래와 같다. 1. security - SSL, Logging 2. Scalability - Clustering and Sharding 3. performance - Clustering and Sharding 4. API - HTTP 5. Availability - Replication 6. No loss of data - Replication 이상 끝!!

#022 색인 커스터마이징

SEARCH ENGINE
1. Directory 루씬의 추상 클래스인 Directory 클래스는 간단한 파일 형식의 저장 공간을 나타내는 Directory 클래스는 간단한 파일 형식의 저장 공간을 나타내는 API이다. 루씬에서 색인파일을 읽거나 쓰려는 경우 항상 Dicionary의 메소드를 통해 처리한다. 간단하게 설명하면, 1. SimpleFsDirectory 색인 파일 시스템에 저장하는 가장 기본적인 Directory 클래스, java.io.*패키지의 기능을 활용하여, 동시에 사용하려는 쓰레드 개수가 많아지면 성능이 떨어진다. 2. NIOFSDirectory 색인을 파일 시세템에 저장하지만 java.nio.* 패키지의 기능을 활용한다. 동시에 사용하려는 쓰레드의 개수가 많아져도 성능이 크게 떨어지지 않는다. 3. MMapDirectory 메모리 맵 I/O 기능을 활용해 파일의 내용일 읽어온다. 4. RAMDirectory 모든 파일을 메모리에 보관하는 Directory이다. 5. FileSwitchDirectory 두개의 디렉토리를 사용하여, 파일 확장자에 따라 두개의 디렉토리를 바꿔가며 사용한다. RamDirectory는 색인된 내용을 디스크 대신 메모리에 저장한다. 모든 색인을 메모리에 보관하면 읽기 쓰기 속도가 엄청나게 빨라지며, 따라서 색인을 메모리 안에 담을 수 있을 만큼 크기가 작고 원본 문서에서 언제든 재빨리 색인 할 수 있다. 루씬 매부적으로 자동 단위 테스트를 진행 할 때 테스트용 임시 색인을 저장할 공간으로 RAMDirectory를 많

#021 색인 필드 설정

SEARCH ENGINE
Field클래스는 색인에 문서를 추가할 때 가장 핵심이 되는 클래스 중 하나이다. Field인스턴스를 생성할 때 색인 할 작업과 설정도 지정한다. 설정은 기능에 따라 구분해 소개하며, 색인 관련 설정, 저장 관련 설정, 텀백터 관련 설정 등의 순서로 설명한다. 1. 색인 관련 설정 Field.Index.ANALYZED 필드에 지정된 텍스트를 분석기에 넘겨 일련의 토큰을 뽑아 내 각 토큰을 검색할수 있게 한다. 일반적인 텍스트 필드에서 사용하기 좋다. Field.Index.NOT_ANALYZED 필드에 지정된 텍스트를 검색하게 역파일 색인에 추가하긴 하지만, 분석기로 텍스트를 처리하지는 않는다. 즉 텍스트 전체를 스트링으로 만든다. Field.ANALYZED_NO_NORMS norm값을 색인에 저장하지 않는다. norm값은 색인할 때 지정했던 중요도를 색인에 보관하지만 검색할때 메모리를 조금더 사용한다. Field.NOT_ANALYZED_NO_NORMS norm값을 색인에 저장하지 않는다 색인이 차지하는 용량과 검색 시점의 메모리 사용량을 절약하고자 할때 사용한다. 토큰을 하나만 갖고 있는 필드에 중요도를 지정하지 않는한 norm값이 필요하지 않는다. 위 Field 클래스는 루씬 3대에서 사용하였으며, 현재 4~5대 버전에서는 변경되었다. 1. BinaryDocValuesField: BytesRef 값을 저장한다. 2. DoubleDocValuesField: NumericDocValues로 double형의 시멘틱 슈거 값을 저장한다. 3. DoubleField:

#020 기본 색인 작업

SEARCH ENGINE
1. 색인에 문서 추가하는 방법을 살펴 보자. Lucene 5.4기준의 예제를 살펴 보자. package foo.bar; import org.apache.lucene.analysis.core.WhitespaceAnalyzer; import org.apache.lucene.document.Document; import org.apache.lucene.document.Field; import org.apache.lucene.document.StringField; import org.apache.lucene.document.TextField; import org.apache.lucene.index.*; import org.apache.lucene.queryparser.classic.MultiFieldQueryParser; import org.apache.lucene.queryparser.classic.ParseException; import org.apache.lucene.queryparser.classic.QueryParser; import org.apache.lucene.search.IndexSearcher; import org.apache.lucene.search.Query; import org.apache.lucene.search.ScoreDoc; import org.apache.lucene.search.TopDocs; import org.apache.lucene.store.RAMDirectory; import java.io.IOException; public cla

#019 루씬 색인 소개

SEARCH ENGINE
다루는 내용 기본적인 색인 작업 필드 중요도 지정 날짜 숫자 필드 정렬 고극 색인 기법 루씬은 해당 문서를 색인 할때 마다 루씬의 필드와 내용을 어떻게 처리 할것인가 하는 조정이 존재한다. 색인을 하려면 먼저 해당 원본을 루씬의 문서와 필드 구조로 변환해야 한다. 예를 들어 사용자가 title:lucene라는 검색을 하면 title의 lucene를 찾는 다는 뜻이다. 문서를 색인하는데 있어 크게 3가지 종류의 옵션을 사용할수 있다. 1. 필드의 내용을 색인 할 것인지 하지 않을 것인지. 2. 필드의 내용을 색인 할 경우 텀 백터를 저장할 것인지 아닌지. 3. 색인 여부와 관계 없이 필드의 내용을 저장 할 것인지. 또한 유연한 스키마 구조를 가지고 있기 때문에 스키마리스 구조로 루씬을 만든다면 각각의 데이터에 맞춰서 자동으로 스키마의 필드가 생성되며, 하나의 문서에 여러개의 서로 다른 필드가 추출될수 있으며, 비정규화된 데이터를 xml, json등의 형태로 변경하여 결과를 리턴 받을수 있는 구조로 만들수 있다. 다음으로는 텍스트 추출과 문서 생성과정을 보면 크게 루씬의 색인 절차는 3가지 형태로 분류 할수 있다. 1. 텍스트를 추출한다. 2. 텍스트를 분석한다. 3. 텍스트를 색인에 추가한다. 색인 작업을 진핼 할 때 가장 먼저 원본 문서의 파일에서 텍스트를 뽑아내고 루씬의 필드 객체를 만들어 최종적으로는 document객체에 생성하고, 텍스트 분석 절차를 거쳐 일련의 토큰 스트림을 반환한다. 그리고 마지막으로 세그먼트 구조의 색인
#018 루씬과의 만남

#018 루씬과의 만남

SEARCH ENGINE
  1부 1장의 내용을 보면 루씬에 대한 소개, 일반적인 검색 애플리케이션의 구조, 기본적인 색인 API, 기본적인 검색 API에 대해서 설명하고 있다. 이 글을 리뷰하는것은 필자의 주관적인 생각도 들어갈수 있으며, 모든 저작권은 루씬 저자와 옮긴이에게 있으며, 자세한 내용을 알고 싶다면 책을 사 보는것을 추천한다. 여기서 루씬이라는 것은 어떤 애플리케이션이건 간에 손쉽게 검색 기능을 추가 할수 있게 도와주는 강력한 자바 검색 라이브러리를 말한다. 더군다나 루씬의 직관적이고 간결한 API덕분에 단 몇개의 클래스 만을 사용해도 기본적인 색인과 검색 기능을 충분히 활용할수 있다. 다시말해 루씬은 고성능 정보 검색 라이브러리 이다. 루씬을 사용하면 애플리케이션에 정보 검색 기능을 추가 할수 있으며, 루씬의 API는 최소한의 노력으로 풀텍스트 색인과 검색 기능을 사용할수 있게 충분히 간결하면서도 매우 강력하다. 루씬의 핵심 JAR 파일 이외에 추가 기능을 담당하는 여러개의 확장 JAR파일이 있다. 확장 기능이지만 루씬을 사용할 때 거의 모든 애플리케이션에서 필요로 하는 중요한 JAR 파일도 있으며 예를 들어 맞춤법 검사 기능이나 결과 하이라이팅 등의 기능이 있다. 1.2 루씬의 역사 루씬은 최초에 더그 커팅이 개발했으며, 처음에는 소스포지 사이트의 루씬 프로젝트 페이지에서 내려 받을수 있었다. 그러다가 2001년 8월에 아파치 재단의 자카르타 프로젝트의 일원으로 아파치 재단에 합류하였으며, 2005년에는 아파치 재단의 최상위 프로젝트가 됐다. http://lucene.apache.

#017 루씬 인 액션을 시작하며..

SEARCH ENGINE
  오늘부터 공부하게될 루씬 인 액션이라는 책이다. 한주에 한부씩을 읽고 리뷰할 예정이다. 몇년전에 검색엔진을 만들어 보고 싶은 마음에 이책의 초판을 사서 보았는데, 그 책과 지금의 책을 읽어 보니 많은 기능들이 추가 된 것을 알 수 있었다.  먼저 챕터를 살펴보고 가기 전에 출판 서평을 먼저 보도록 하겠다.   * DB에 담겨 있는 수백만 건의 정보를 마음대로 조회하지 못하거나, 사내 인트라넷의 엄청난 디렉토리 구조 안에 저장된 수많은 문서 중 원하는 내용이 들어있는 문서를 찾지 못해 어려움을 겪고 있다면, 그렇다고 상용 검색 엔진을 구입해 사용하기엔 너무 부담스러운 경우, 루씬(Lucene)이 정답이다. 이 책은 외주 개발이든 사내 개발이든 간에 전문적인 검색 기능을 필요로 한다면 최우선으로 고려해야 할 루씬에 대해 색인부터 검색과 고급 설정까지 예제 기반으로 설명한다. [(개정판) 루씬 인 액션]을 기반으로 루씬의 A부터 Z까지 완벽하게 활용하는 고성능 검색 애플리케이션을 개발해보자. * 초판이 출간된 이후 5년간 루씬 프로젝트에서 많은 부분이 달라졌다. 영향력 있는 오픈소스 프로젝트는 대부분 그렇지만 루씬도 탄탄한 기술적인 기반을 갖고 있으며, 사용자와 개발자가 참여하는 안정적인 커뮤니티가 계속해서 유지되고 있고, 이런 잠재력이 뭉쳐 엄청나게 발전하는 중이다. 초판이 출간된 이후 추가되거나 변경된 기능을 살펴보면 대략 다음과 같다. - 준실시간 검색 - 문서에서 텍스트를 추출할 때 티카(Tika) 프로젝트 활용 - NumericField를 통해 숫자 필드를