MSFL :: 모리스 소프트웨어 공작소

Solr 를 사용하면서 항상 의미가 혼동되는 것 들이 존재하는데 그 중에서 Collection 과 Core 에 대해서 정리를 해 보도록 한다. (현재 이해한 것을 기준으로 정리한 것이라서 향후에 내용이 변경될 수 있다) Collection vs. Core 이 두 가지를 혼동되는 이유는 Solr 구성을 단일 노드로 할지 분산 노드로 할지에 따라서 구성이 다르고 그 구성에 따라서 의미가 달라지기 때문이다. 쉽게 생각해 보면 Collection 이라는 것은 물리적이 아닌 논리적인 인덱스 단위고, Core 는 물리적인 인덱스 단위라고 생각하면 된다. 이제 환경에 따라서 어떻게 다른 의미를 가지는지 정리해 보도록 하자. 분산 환경 분산 환경이라면 컬랙션을 운영하기 위한 클러스터를 구성하고 이 클러스터에 여러 개의 서버노드 (Solr 가 서비스 되는 ) Collection - 클러스터를 구성하고 있는 노드(물리적 및 논리적 서버들) 들에 걸쳐 분산되어 운영되는 논리적인 인덱스를 의미한다. Core - 분산 환경이 되면 컬랙션을 파티션으로 나누게 되며 각 파티션 별로 인덱스 데이터가 나뉘고 물리적으로 관리된다. 이 과정을 Sharding이라고 표현하는데 이렇게 분리된 파티션을 물리적으로 관리하고 서비스하는 단위가 Core 가 된다. 또한 Shard에 참여하는 Solr Instance 들이 여러 개일 경우는 복제본 (Replica)을 관리하는 단위도 Core 가 된다. 비 분산 환경 비 분산 환경이라는 것은 단독 서버로 Solr 가 운영되는 것을 기준으로 한다. 물론 하나의 서버에 여러 개의 노드 (여러 개의 Solr 구동 JVM 구성) 를 구성해서 분산 환경을 만들 수도 있지만 그 부분은 대상이 아니다. Collection - 여러 개의 컬랙션을 Solr Instance에 생성할 수 있고, 논리적인 인덱스와 물리적인 인덱스(Core) 가 1:1 로 매치 된다. Core - 물리적인 인덱스트를 서비스하는 단위로 컬랙션과 1:1 로

Solr 를 사용하기 위해서는 몇 가지 용어들을 확인하고 이해해야 하기 때문에 간단하게 나름대로 정리하도록 한다. (현재 이해를 근거로 정리한 것이므로 향후 변경 또는 추가/삭제가 발생할 수 있다) 이 정리는 Solr Wiki의 Solr Teminology 를 기준으로 한 것이다. 발 번역을 한 것 + 무작정 이해한 것이 덧붙여져 엉뚱한 내용도 많이 포함되어 있을 수 있으므로 원문을 검토해서 이해해야 한다. ㅠㅠ SolrCloud SolrCloud 를 구성한다면 아래의 용어들에 혼동을 느끼기 쉽기 때문에 별도로 구분해서 정리해 놓는다. SolrCloud - Solr 에서 제공하는 분산 기능을 의미하고 고 가용성과 장애 복구 및 분산 인덱싱과 검색을 제공하는 아키텍처라고 이해하면 된다. Cluster - 클러스터는 Solr를 구성하는 모든 노드들의 집합을 의미한다. 클러스터는 하나의 Solr 인덱스를 서비스하기 위한 구성을 가진다. 즉, 단일 schema.xml 과 solrconfig.xml 을 공유한다. Node - 노드는 클러스터에 포함되는 각 논리적 서버(Solr 가 서비스되는 JVM 인스턴스 단위) 를 의미한다. 물리적인 서버에 하나의 노드가 존재할 수도 있고, 여러 개의 노드가 존재할 수도 있다. Partition - Solr 에서 관리하는 문서들을 특정한 단위 (일반적으로 Hash 기준으로 묶어서 처리) 로 분리한 하위 집합을 의미한다. 유사한 경우는 데이터베이스에서 하나의 대량 데이터를 가진 테이블을 여러 개의 세그먼트로 파티셔닝 하는 것과 같다. Collection - 컬랙션은 SolrCloud 클러스터에서 관리되는 논리적인 인덱스를 의미한다. 이 컬랙션은 하나 또는 그 이상의 Shard로 구성되고 설정 세트(Config Set) 와 연관되어 있다. 이 때 하나 이상의 Shard로 구성된 것을 분산 인덱스라고 한다. 보통은 이 컬랙션의 이름을 참조해서 분산 검색 에 필요한 각 Shard에 대한 관리용 파라미터로 사용

  Solr 의 Data Import 는 다양한 데이터 소스에서 데이터를 Solr 의 문서로 변환하여 Index를 구성하기 위한 도구로 Full / Delta Import 처리가 존재한다. Full Import - 일반적으로 기존 문서들을 삭제 (Clean) 하고 새롭게 문서들을 구성하는데 사용한다. Delta Import - 마지막으로 처리된 Full / Delta Import 시점 (last_index_time) 부터 추가/변경/삭제 되 데이터를 처리하는데 사용한다. (Non clean)   last_index_time 은 위 두가지 import 에서 유용하게 사용될 수 있다. 이제 의미를 알아 보도록 하자. last_index_time 은 어떤 값일까?   Solr 의 DataImportHandler (이하 DIH) 는 동작한 Import 작업에 대한 최종 설정 값 (last_index_time) 정보를 conf 경로에 “dataimport.properties” 라는 파일에 저장 을 한다. 저장되는 단위는 db-data-config.xml 에 지정된 Entity 단위로 기록 하게 된다. 그리고 entity와 상관없는 last_index_time 이 존재해서 동작한 시간을 추가로 기록하고 있다. 테스트 결과 delta-import 에서 이 값을 사용하는 것을 확인하였다. 아래는 실제 구성된 정보를 보여주는 것이다. [ SolrHome / Core / conf / dataimport.properties 의 내용] #Wed Dec 17 16:02:58 KST 2014 test.last_index_time=2014-12-17 15:51:59 test2.last_index_time= 2014-12-17 15:59:24 last_index_time= 2014-12-17 15:59:24   여기서 중요한 것은 last_index_time 이라는 값 (timestamp) 이 어떤 값인지에 대한 것이다. 결론

   구글 코드 및  GitHub  등  Solr Data Import  관련된 오픈 소스들이 많다  .  물론  Quartz 를 이용한 스케줄러에 대한 것도 많이 존재한다  .  지금 정리하는 내용은  GitHub 에 존재하는 사이트를 기준으로 했고 ,  이 사이트는  Google Code  의 소스를 기반으로 해서 확장 (?) 한 것으로 보인다 .  사용한 코드도 소스를 적용할 환경과 요구에 맞도록 변경해서 사용한 것이기 때문에 실제 사이트에서 제시하고 있는 내용과는 다를 수 있다 .  물론 설정 방법은 동일하게 사용한다 . Scheduler  관련 사이트들    스케줄러 기능을 사용하기 위해서는 다음과 같은 구성요소가 필요하다 . Solr DataImport Scheduler   ( 원본 참조 경로 ) Quartz Job Scheduler Apache HttpClient Scheduler  설치와 구성    설치와 구성은 다음과 같이 설정하면 된다 .   DataImportScheduler-0.0.1.jar  파일을  Solr  설치 서버  ( 주로 톰캣 ) 의 클래스패스  ( 별다른 설정이 없다면  WEB-INF/lib)  에 복사한다 .  구동에 필요한 배포 대상  Jar  들은 아래와 같다 . Quartz-2.2.1.jar Quartz-jobs-2.2.1.jar Fluent-hc-4.3.2.jar jta-1.1.jar 당연한 것이지만 , Solr, Lucene, Http, slf4j  등의 관련  Jar  들은 이미 구성된  Solr  서버에 존재하므로    빠진 부분만 추가로 배포하면 된다 .   웹 설정  ( 별다른 설정이 없다면  WEB-INF/web.xml)  에 다음과 같이 리스너를 설정한다 . Solr  서버의  ServletContextListener 를 상속하여  Context  가 초기화 및 제거 될 때  Quartz Scheduler 를  On/Off  처

  Solr 기반 검색 어플리케이션을 테스트하면서 재미있는 증상이 발견 되었다. 증상이라는 것이 일반적인 전체 데이터 조회 (q=*:*) 에서 Score 기반의 정렬에서는 특정 필드가 보이지만, 개별 필드에 대한 정렬 (sort=DueDate desc) 을 실행하면 특정 필드가 사라지는 현상이다.     이런 현상 때문에 여러 가지 테스트를 진행하면서 원인을 파악하던 중에 Solr 에서는 값이 존재하지 않는 필드를 조회할 때 무시하는 상황이 존재한다는 것이다. 즉, 문서에 10개의 필드가 존재하고 전체 필드를 조회할 때 해당 문서에 A 라는 필드가 값이 없다면 이를 제외한 9개의 필드만 반환하는 상황이다.     특정 필드처럼 보였던 이유는 MySQL 에서 Data Import 를 수행할 때 StartDate / EndDate / DueDate 의 일자 컬럼이 존재하는데 EndDate의 경우는 값이 존재하지 않을 수 있기 때문에 Solr 로 전달될 때 NULL 값이 전달되고, Solr 에서는 값이 NULL 이기 때문에 해당 문서에 EndDate를 처리하지 않는 상황인 것이다. 따라서 전체 데이터를 조회할 때는 Score 순서에 따라서 문서들이 보여지면서 EndDate 가 존재하는 데이터들이 보였지만, DueDate를 기준으로 정렬을 다시 구성해서 조회할 때는 상위에 보여지는 문서들에 EndDate 값이 존재하지 않아서 조회 결과에 EndDate 필드가 누락되어 보여진 것이다. 계속 페이징을 해서 내려가 보면 EndDate가 존재하는 문서는 제대로 해당 필드가 보인다.     이 문제를 해결하기 위해서는 Schema.xml 의 필드 정의에서 아래와 같이 기본 값을 설정하여 NULL Value 로 인해서 해당 필드가 누락되지 않도록 설정해 주면 된다. <field name="endDt" type="tdate" indexed="true" sto

  Solr 에 외부 데이터를 Import 할 때 사용하는 것이 DataImport 패키지다. Solr 를 다운로드하면 존재하는 별도의 라이브러리로 Solr 에서 Batch Import 역할을 담당한다. 다양한 데이터 소스로 부터 데이터를 처리하는 방법을 제공하고 있기 때문에 실제 적용할 때는 관련된 Wiki 정보 를 확인해 보면 된다.   Solr 에서 자체적으로 제공하는 UpdateHandler 와는 다르게 동작하는 것으로 파악이 된다. 즉, UpdateHandler에서 처리하는 Chain 들의 처리를 DataImport에서 따로 설정해서 처리를 하여야 한다는 점이다. 이런 처리를 수행할 때 주의할 점이 존재한다.   데이터를 가져올 특정 테이블에 HTML 태그들을 포함하는 "content" 컬럼이 존재할 경우에 이를 가져와서 HTML 이 존재하는 정보 (원본 데이터 그대로) 화 HTML 이 제거된 정보를 사용하여야 하는 경우라면 아래와 같이 설정을 하여 처리를 하게 된다. <dataConfig> <dataSource type="JdbcDataSource" name="ds-1" driver="com.mysql.jdbc.Driver" url="DB 연결 문자열" batchSize="-1" user="사용자 아이디" password="사용자 비밀번호" /> <document> <entity name="Entity이름" pk="id" transformer="TemplateTransformer, HTMLStripTransformer" query="

  이번 프로젝트는 검색엔진을 구성해 보는 것이다. 전문 검색업체를 통해서 진행되는 것은 아니고, 이미 구축되어 있는 시스템에 검색엔진을 연계하는 작업이다. 주변에서 검색 엔진을 연동하는 프로젝트들을 좀 보았지만 막상 혼자서 시작하려니 막막하다.   항상 그렇듯이 구글을 통해서 사용가능한 검색엔진을 찾던 중에 Lucene이라는 것을 알게 되었고, 이미 개념을 탑재하신 분들도 Lucene을 권장한다. 단, Lucene은 말 그대로 엔진일 뿐, 실제 사용을 위해서 주변 머리를 정리하는 것도 일이라... 좀 더 많은 검색을 통해서 Solr 와 ElasticSearch 라는 두 가지 오픈소스 검색엔진을 찾았다. 정확히는 Lucene 엔진을 실제 사용하기 쉽게, 그리고 실 사용에 필요한 많은 추가 기능들을 탑재한 검색 서버라고 하는 것이 맞을 듯 하다.   아무리 잘 만든 검색 서버라고 해도 사용할 사람이 지식이 없으면 말짱 도루묵인 것처럼... 막상 찾아놓고도, 그리고 Tutorial을 봤음에도 정작 중요한 개념들과 어떤 것들이 어떻게 설정이 되어야 제대로 사용하는 것인지에 대한 고민만 늘어간다. 그래서 "Solr in action" 이라는 책을 근거로 해서 하나씩 정리를 해 볼 생각이다.   앞으로 진행은 Solr in action의 챕터별 단원별로 하나씩 정리를 하되, 발 번역한 내용에 문제가 많을테니, 가급적이면 이해된 내용을 기준으로 짧게 정리를 해 볼 생각이다. 이미 많은 분들이 많은 부분들과 중요한 기법들을 정리해 놓은 것들이 많기 때문에 여러가지를 참조하면서 느리더라도 가능하면 쉽게 이해하고 사용할 수 있도록 정리가 되었으면 하는 희망을 가지고 진행하도록 하자.   그리고 현재 시점의 버전인 4.10.2 (Solr, Lucene, SolrJ 모두 동일 버전) 를 기준으로 한다. (다른 글들은 이전 버전을 기준으로 하고 있어서 크고 작게 변경된 부분이 많다) Part I - Meet Solr     Chapte