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

  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

  윈도우 8.1 을 설치하고 설치 버전이 아닌 포터블 버전의 MySQL Workbench 를 실행하면 (x64, x86 모두) 오류가 발생하는 경우가 존재한다. .NET 환경의 개발자라면 이런 상황은 발생하지 않을 수 있지만 Java 개발 환경이라면 이 오류가 발생할 수 있다.   오류 원인은 MySQL Workbench의 기본 환경 요소 때문에 발생하는데 별다른 설명이 없이 그냥 오류나면서 끝나 버린다. -_-;;; Workbench 실행에 필요한 기본 요소는 다음과 같다. (이 부분은 MySql Workbench 다운로드 사이트  Prerequisites 에 설명되어 있다) Microsoft .NET Framework 4 Client Profile - 이 부분은 Windows 8.1 설치 시에 기본으로 설치되므로 직접적인 원인은 아니다. Visual C++ Redistributable for Visual Studio 2013 - .NET 개발 환경이라면 Visual Studio를 설치했으므로 문제가 되지 않지만 Java 개발 환경이라면 이 부분이 없을 가능성이 높기 때문에 여기서 다운로드 해서 설치를 하면 된다.   얼마 전부터 Java 개발을 하면서 .NET 개발 환경 구성을 하지 않다가 보니 항상 만나는 문제인데, 정리를 해 놓지 않으니 항상 까먹고 원인을 찾겠다고 똑같은 뻘짓을 계속 하고 있다. ㅠㅠ 이휴~   참고로 내 PC 에 .NET Framework이 설치되어 있는지를 확인하는 방법은 Registry  Editor 에서 아래와 같은 키 정보를 확인하면 된다.  여기 사이트 를 참조하면 내용과 다른 방법에 대해서 알 수 있다. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP

  현재 진행 중인 검색 (Solr + SolrJ) 프로젝트에서 Paging 처리를 하고 있는데 페이지를 랜덤으로 이동을 하게 되면 시간이 너무 오래 걸리는 증상이 발견이 되어, 이런 저런 테스트와 Solr 관리 화면을 통해서 start 와 rows 를 지정하고 검증을 해 보면 약간 느리다는 느낌을 받지만 그 다지 문제가 되지는 않을 정도로 결과가 나왔다. 그런데 막상 구현한 SolrJ 클라이언트를 통해서 검색을 하면 무려 11초 이상이 걸리는 증상이 계속되고 있다.     여러 가지 의심되는 부분들을 조정하면서 검증을 수행한 결과 Log4J 의 Logging 처리 때문이라는 것이 확인이 되었다. 이유는 기본 Log4J 에 LogLevel을 Debug로 설정 상태에서 Solr 의 결과를 Debug 출력하고 있었던 것이 문제가 된 것이다. 로그 출력을 INFO 수준으로 높이고 실행한 결과 대략 Solr 관리 화면에서 수행한 것과 비슷한 수행 시간이 걸리는 것을 확인했다.     검증을 위해서 결과 출력을 제외할 수는 없기 때문에 비 동기 방식으로 전환을 하여 적용하면 약간은 느리겠지만 정보를 확인하는데 문제는 없기 때문에 이번에는 비 동기 설정에 대해서 정리를 하도록 한다.   Log4J Async 설정     Log4J 에서는 AsyncAppender를 제공하고 있으며 이를 통해서 로그를 비 동기로 처리하게 된다. 설정 방법은 기존에 사용하는 것과 크게 다르지 않다. 다만 CONSOLE 이나 FILE 등의 Appender 를 사용하고 있었다면 AsyncAppender로 기존 Appender를 연결해서 사용하도록 해 주면 된다. 아래의 예제를 확인해 보자.   <?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> <log4j:configuratio