인사이드 서치

루씬 고속 색인 방법 : 토큰을 재사용하라

webJOY — Wed, 2 Jul 2008 03:13:46 +0900

"버스 토큰"
from 네이버 기차여행카페 - 바이트레인

오픈소스를 가져다 쓸다면 "유지보수와 튜닝 문제"에 골치 아파질 때가 많다. 오픈소스 덕분에 빠르게 시작할 수 있지만 내부에 대한 이해 부족으로 해법을 찾기 어렵기 때문이다. 혹자는 오픈소스에는 개발자들이 많아 질문만 던지면 즉시 해결될 것이란 유언비어에 빠지는 분도 있는데, 실무에서 만나게 되는 시급한 문제에 대해서는 즉시 응대와 해결은 꿈도 꾸질 말아야 한다. 특히 국내 실정은 더하다.

루씬도 역시 오픈소스인 것 같다. 루씬 2.3.2 소스를 보고 있는데 색인어 추출 루틴들인 Analyzer 계열 클래스들의 복잡도가 만만치 않다. Payload란 실험적인 개념, PositionIncrement 개념, 수많은 클래스들 등이 주석과 함께 코드에 뒤범벅이 되어 있어 웬만한 내공이 아니면 이해하기 어렵다.

내부 이해야 믿으면 그만이지만 검색엔진 적용 시에 대용량 문서를 접하게 되면 속도 튜닝이 아주 힘들다. 루씬 색인속도 향상에 관해서는 Job tech blog를 한번 읽어보라. 이 블로그에 나와있는 5가지 팁 중에 4번째에 이 글 주제인 토큰 재사용에 관한 언급이 있다(나머지 팁들도 유용하다.)

루씬에서는 색인어를 토큰(Token)이라 부른다. 검색엔진의 색인속도에 영향을 주는 여러 요인들이 있지만 토큰을 추출할 때 마다 토큰 문자열을 매번 재 생성하지 않고 토큰 버퍼(Token Buffer)를 만들어 재사용하는 방식으로 6-7배 이상의 속도 향상을 기대할 수 있다(전체 색인 속도 향상을 말하는 것은 아님에 주의하자.) 루씬도 2.3 버전부터 토큰 버퍼 개념을 적용하고 있다. 토큰 버퍼를 사용하면 추출속도를 높일 수는 있으나 다음 추출 시에 토큰버퍼 내용이 지워지므로 사용법에 주의해야 한다. 아래 실험코드가 있다.

GeSHi © 2004, Nigel McNie
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.StringReader;
import java.net.URL;
 
import org.apache.lucene.analysis.Token;
import org.apache.lucene.analysis.TokenStream;
import org.apache.lucene.analysis.standard.StandardAnalyzer;
 
enum Interface {
  OLD_INTERFACE, NEW_INTERFACE
}
 
public class ReusableTokenTest {
  int textLength = 0;
  int numTokens = 0;
  long elapsedTime = 0;
 
  public void tokenInterface(Interface which) {
    try {
      StringReader reader = new StringReader(getLargeString());
      TokenStream tokens = new StandardAnalyzer().tokenStream(new String(
          "text"), reader);
      long startTime = System.currentTimeMillis();
      if (which == Interface.OLD_INTERFACE)
        this.useOldInterface(tokens);
      else
        this.useNewInterface(tokens);
      this.elapsedTime = System.currentTimeMillis() - startTime;
      this.output(which);
    } catch (Exception e) {
      e.printStackTrace();
    }
  }
 
  private void output(Interface which) {
    StringBuffer sb = new StringBuffer();
    if (which == Interface.OLD_INTERFACE)
      sb.append("Old Interface");
    else
      sb.append("New Interface");
    sb.append("\t");
    sb.append(this.textLength);
    sb.append(" (chars)\t");
    sb.append(this.numTokens);
    sb.append(" (tokens)\t");
    sb.append(this.elapsedTime);
    sb.append(" (msec)");
    System.out.println(sb.toString());
  }
 
  private String getLargeString() throws IOException {
    URL url = new URL("http://insidesearch.tistory.com/");
    BufferedReader in = new BufferedReader(new InputStreamReader(url
        .openStream()));
    StringBuffer sb = new StringBuffer();
    String str;
    while ((str = in.readLine()) != null) {
      sb.append(str);
    }
    this.textLength = sb.length();
    return sb.toString();
  }
 
  private void useOldInterface(TokenStream tokens) throws IOException {
    Token token;
    while ((token = tokens.next()) != null) {
      useToken(Interface.OLD_INTERFACE, token);
    }
  }
 
  private void useNewInterface(TokenStream tokens) throws IOException {
    Token token = new Token();
    while ((token = tokens.next(token)) != null) {
      useToken(Interface.NEW_INTERFACE, token);
    }
  }
 
  private void useToken(Interface m, Token token) {
    this.numTokens++;
    if (m == Interface.NEW_INTERFACE) {
      String s = new String(token.termBuffer(), 0, token.termLength());
    }
    else {
      String s = token.termText();
    }
  }
 
  public static void main(String[] args) {
    new ReusableTokenTest().tokenInterface(Interface.OLD_INTERFACE);
    new ReusableTokenTest().tokenInterface(Interface.NEW_INTERFACE);
  }
}
 
Parsed in 0.125 seconds

위 코드는 http://insidesearch.tistory.com에서 비교적 큰 문자열을 받아 StandardAnalyzer를 사용해 토큰을 만든다. 이 코드를 돌려보면 새로운 인터페이스를 사용하면 6~7배 정도 속도가 향상됨을 볼 수 있다(아래 결과 참조). 이 정도면 수억개의 토큰을 다루는 대용량 문서들을 색인할 때는 수 십분 가량의 속도 향상을 기대할 수 있을 것이다.

Old Interface 56012 (chars) 9105 (tokens) 39 (msec)
New Interface 56012 (chars) 9105 (tokens) 6 (msec)

요약하면 새로운 토큰 인터페이스를 사용하여 추출 속도를 높이려면 기 정의된 토큰 객체를 재사용한다는 점만 기억하면 된다. 내부 토큰버퍼 크기 재조정 작업은 알아서 Token 클래스 내부에서 척척 해 준다. 외부에서 getTermText()를 사용해 내부에서 만들어준 문자열 객체를 사용하지 말고 termBuffer()를 호출해 내부 토큰버퍼(char [])에서 termLength() 만큼 복사해서 사용하면 된다.

@webJOY

참고로 토큰버퍼 내부 동작원리에 대해서는 DEV 용식님이 블로그을 참고하라.

이클립스로 루씬 소스 다루기

webJOY — Fri, 27 Jun 2008 03:05:05 +0900

요즘 자바 매력에 푹 빠져있다. 아니 이클립스란 괴물의 매력에 빠져 있다는 것이 더 옳을 것 같다. 2주 정도 만지작거린 도구지만 지금까지 보아왔던 개발도구 중에 단연 으뜸인 것 같다. 있을 것 같다고 생각하면 진짜 그런 기능이 있는 소프트웨어가 좋은 소프트웨어라고 생각하는데 이 이클립스가 그렇다.

요즘 회사에서 이클립스를 가지고 파일럿 코딩을 하고 있다. 이에 부스팅받아 생계터전인 검색바닥도 다질겸 소스 배포판을 다운받아 이클립스 작업공간에 가져다 놓고 테스트 프로그램도 작성해보고 내부코드도 수정해가면서 배울려고 했는데 각자는 환상인데 궁합을 맞추려니 쉽지 않았다. 구글링을 해보아도 이클립스에 루씬소스를 올리고 컴파일하는 방법에 대해 나와 있지 않아 약간의 삽질 경험을 공유하려 한다. 루씬, 이클립스 둘다 초짜인데 눈 대중으로 작업한 결과다.

먼저 루씬 소스를 다운받아 원하는 폴더에 푼다. 이클립스가 소스를 Import하면 복사하기 때문에 아무 곳에 풀면 된다.
이클립스 File > New > Java Project 메뉴로 Jar 컴파일용 프로젝트(예, LuceneSource)를 만든다. 새로운 프로젝트가 만들어지면 이클립스는 자동으로 src란 폴더를 만든다. 이 폴더에 적절히 루씬 코드를 import해야 한다.
이클립스 File > Import 메뉴로 루씬소스의 특정 폴더를 읽어 들인다. 루씬 폴더를 무작정 import하면 namespace를 찾을 수 없어 이클립스의 친절한 빨간불들을 보게 된다. Import 메뉴를 클릭해서 나온 마법사에서 Import Source로 File System을 선택하고 Next를 클릭한다. 다음에 나타나는 마법사의 From Directory Browse 버튼을 클릭해서 루씬소스 코드의 lucene-2.3.2/src/java 폴더를 클릭해서 읽어 들인다. 아래 화면과 같이 설정되어야 한다. Import할 소스를 java > org > apache > lucene 순으로 선택하지말고 lucene를 직접 클릭해야 한다. 무슨 차이가 있는지는 모르겠다.
이클립스 File > Export 메뉴로 Jar 파일을 특정 폴더에 lucene.jar 파일을 생성한다.
이클립스 File > New > Java Project 메뉴로 테스트용 프로젝트(예, LuceneStudy)를 만든다.
테스트 프로젝트의 Build Path > Add External Archives... 메뉴를 이용해 소스 프로젝트에서 생성했던 lucene.jar 파일을 찾아 선택한다.
테스트 프로젝트에 루씬 기능을 테스트할 Java Class를 만들고 실행해본다. 잘 동작하면 제대로 설정한 것이다.

위 7 단계를 통과하고 생성된 프로젝트 모습은 아래 그림과 같아야 한다. 루씬 소스 배포판에는 루씬 Jar 라이브러리를 위한 소스 폴더(src/java/)가 있고 테스트, 데모, 기타 폴더들이 있다. 루씬 Jar 라이브러리에는 소스 폴더만 필요하다. 이런 점 때문에 루씬 Jar 라이브러리 생성용 프로젝트와는 별도로 테스트 코드를 위한 프로젝트도 만들었다. 한 프로젝트 안에 넣으면 루씬 내부 코드와 테스트 코드를 동시에 수정하면서 작업이 가능하기 때문에 더 좋을 것 같다. 이 정도만 해도 디버깅을 할 때 루씬 내부코드까지 보면서 할 수 있으니 툴 삽질은 여기까지만 한다.

이클립스로 루씬 소스를 분석할 환경을 마련했다. 분석환경이 잘 도는지 확인도 할 겸 LuceneStudy 프로젝트에 StandardAnalyzer 기능을 테스트하는 Analyzer.java를 만들어 넣어보자. 아래와 같은 코드를 넣고 실행해보라.

GeSHi © 2004, Nigel McNie
public class Analyzer {
  public static void main(String[] args) {
    StringReader reader = new StringReader(new String(
        "jongwanyun@gmail.com 메일주소"));
 
    StandardAnalyzer analyzer = new StandardAnalyzer();
    TokenStream tokens = analyzer.tokenStream(new String("email"), reader);
    Token token = new Token();
    try {
      int tokenId = 0;
      while ((token = tokens.next()) != null) {
        StringBuffer out = new StringBuffer();
        out.append(tokenId++);
        out.append("\tToken: [");
        out.append(token.termBuffer());
        out.append("]\t");
        out.append("Type/start/end/length: [");
        out.append(token.type());
        out.append(",");
        out.append(token.startOffset());
        out.append(",");
        out.append(token.endOffset());
        out.append(",");
        out.append(token.termLength());
        out.append("]");
        System.out.println(out.toString());
      }
    } catch (IOException e) {
      e.printStackTrace();
    }
  }
}

@webJOY

XML CDATA 제대로 다루기

webJOY — Wed, 18 Jun 2008 23:28:17 +0900

오늘 오전시간을 XML CDATA Section 오류 디버깅을 하면서 보냈다. MySQL DB에 있는 테이블을 XML로 덤프하여 색인용 원시 텍스트파일을 만드는 작업을 하던 도중에 복병(?)을 만났기 때문이다. Python으로 MySQL 테이블을 읽어 print 문을 사용하여 XML 파일을 생성하고 난 후에 Java SAXParser로 읽는 작업이었는데 "org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x{2}) was found in the CDATA section" 오류가 났다. 4백만건이 넘는 대용량 테이블이었기 때문에 Java SAXParser에서 이 오류를 한번 볼 때 마다 Python code를 점검하여 다시 덤프받느라 고생했다.

색인용 원시 텍스트파일 포멧은 주로 텍스트 파일을 사용한다. 색인 원문이 저장된 장비와 검색장비 간에 플랫폼이 다를때 발생하는 endian 문제를 피하기 위해서다. XML은 이런 장점에 더해 문서 구조를 더 잘 표현할 수 있는 장점이 있어 일부 검색엔진의 경우 색인용 원시 텍스트파일로 UTF-8 인코딩된 XML을 사용하기도 한다. 검색 콜렉션을 담고 있는 대용량 DB 테이블에서 색인용 XML을 덤프받을때 덤프 속도 문제로 DOMWriter와 같은 validation을 하는 XML Generator를 사용하지 않고 print를 사용해 validation 없이 종종 직접 생성한다. 또 골치아프고 속도를 느리게 만드는 char escaping을 하지 않기 위해 CDATA 섹션으로 필드를 감싼 형태로 덤프하곤한다.

현업에서 이런 방식으로 XML을 많이 사용하기 때문에 위 오류에 대한 대처 방안을 구글 검색을 통해 쉽게 찾을 줄 알았다. 한시간 가량이나 구글링을 해서야 원인을 찾았다. SAXParseException은 validation 없이 CDATA 섹션을 만들기 때문이었다. 데이터베이스에 레코드를 넣을 때 print문을 사용해 직접 덤프하도록 준비해서 넣지 않기 때문에 제어문자와 같은 unicode도 함께 저장되어 덤프 후 XML을 다시 파싱할 때 이런 종류의 문자를 파싱할 때SAXParse 오류가 발생한다. 파싱 오류를 해결하려면 CDATA 섹션안에 들어가면 안되는 unicode range를 print문으로 XML을 덤프할 때 제거해야 한다. 이 unicode range는 XML 스펙 1.0에 다음과 같이 명기되어 있다.

Character Range

[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */

CDATA Sections

[18]	`CDSect`	::=	`CDStart CData CDEnd`
[19]	`CDStart`	::=	`'<![CDATA['`
[20]	`CData`	::=	`(Char* - (Char* ']]>' Char*))`
[21]	`CDEnd`	::=	`']]>'`

위를 보면 CDATA 섹션안의 문자열에는 2가지 들어가지 말아야 하는 조건이 있다.

첫째. CDATA 종료열인 ']]>' 문자열이 들어가면 안된다.
둘째. 유니코드 문자만 포함되어야 한다. 특히, 제어문자들은 포함되지 말아야 한다.

위 조건을 만족하도록 print문으로 XML 파일을 만들면 SAXParseException이 나타나지 않는다. 비록 문자들을 모두 scan하면서 위 조건에 맞는지 조사해야 하기 때문에 수백만 건이 포함된 테이블을 XML로 덤프할 때는 조사 시간이 누적되어 월씬 덤프하는데 오래 걸리게 되지만 SAXException을 구경하는 것 보다는 좋다.

대용량 문서 때문에 validation을 하지 않는 방식으로 XML을 생성해야만 하는 경우에 가장 좋은 방법은 데이터베이스에 넣을 때 아에 위 문자들이 들어가지 않도록 방지하거나 제거하는 것이다.

@윤종완

주1) 마크 맥라렌의 블로그에 둘째 조건을 체크해 오류 문자를 제거하는 Java 코드를 소개하고 있다. 관련된 trackback도 읽으면 도움이 된다.

주2) 위 방법은 XML 1.0 스펙을 준수하는 XML Parser에 적용된다. XML 1.1 스펙을 보면 Char Range가 좀 다르다. XML 1.1을 준수하는 Xerces와 같은 경우에는 다른 현명한 방법을 제공하고 있을지도 모르겠다.

구글 개발자가 말하는 분산 시스템 구축 시 교훈

webJOY — Thu, 22 May 2008 00:39:03 +0900

기술 지향적인 구글 사상과 그 아우라로 인한 엄청난 성공 때문에 많은 개발자들이 잘 알려지지 않은 구글 인프라에 대해 막연한 동경을 가지곤 한다. 하지만 상세한 정보가 없기 때문에 거대한 인프라를 어떤 생각을 가지고 만들었는지에 대해 살펴볼 기회가 거의 없었다. 구글 빅 테이블 논문 뒷편에 기재된 "교훈(Lesson)"장을 통해 구글 개발자들이 대단위 분산 시스템 개발 시에 어떤 자세로 만들었는지를 살짝 볼 수 있어 소개한다. 이 장에 의하면 성공한 구글 인프라로 알려진 빅 테이블 설계, 개발, 적용하면서 구글 개발자들은 다음과 같은 4가지 중요한 교훈을 얻었다고 한다.

1. 생각할 수 있는 모든 장애 포인트를 고려하라.

2. 쓸려고 하는 명확한 기능만 구현하라.

3. 시스템 곳곳을 모니터링 하라.

4. 구조가 단순해질 때까지 지속적으로 개선하라.

위 4가지 교훈은 언듯보면 천재들이 '교훈'이라고 말한 것 치고는 너무 단순해 보인다. 실제 빅 테이블 논문을 클릭해보라. 4번째 교훈의 '단순'이란 단어가 어울리지 않음을 쉽게 알 수 있다. 그럼 이런 구글러들의 교훈을 어떻게 해석해야 할까? 개인적으로는 복잡해질 수 있는 분산 시스템을 개발할 때에 "실용성을 염두에 두고 추적가능하고 명료하도록 지속적으로 개선하라"로 해석함이 맞을 듯 싶다.

덧 붙이자면 빅 테이블을 만든 구글러들도 빅 테이블을 "창조"한 것은 아니었다. 개인적 볼 때 구글러들은 "익히 알려진 기술들의 창조적 조합의 천재"인 것 같다. 빅 테이블에서도 마찬가지였다. 기존에 연구되던 복잡한 분산 B 트리나 광대역 분산 저장소, 그리고 컬럼 데이터베이스의 장점들 중에 빅 테이블을 사용할 구글 제품에 딱 필요한 것만을 조합해 설계, 구현한 것이 빅 테이블이기 때문이다. 여러분이 복잡한 분산 시스템을 설계하고 있고 성공한 인프라를 만들길 원한다면 위 4가지 교훈을 계속 되새겨 보라.

존 마에다 교수의 "단순함의 법칙"이 친근하게 느껴지는 이유는 뭘까?

@webJOY

구글 빅테이블(Google Bigtable)에 관한 오해

webJOY — Fri, 16 May 2008 02:52:55 +0900

최근 몇몇 블로그 글을 읽다 보면 구글 빅테이블(Google BigTable)을 관계형 데이터베이스의 대체 저장소로 오해하고 있는 듯한 글들이 눈에 띈다. 이런 오해의 근원은 빅 테이블이 몇몇 구글 서비스의 저장소로 사용되었음을 "Bigtable: A Distributed Storage System for Structured Data"란 논문에서 언급하였기 때문인 것 같다. 또, 구글 빅 테이블의 오픈소스 클론 프로젝트인 HyperTable 개발자인 더그 주드(Doug Judd)가 기업용 소프트웨어 개발 커뮤니티인 인포큐과의 인터뷰에서 현재 MySQL이 차지하고 있는 웹 콘텐트 저장소로 자리매김하고 싶다란 견해를 밝혔다. 이런 측면만 보면 구글 빅테이블과 관계형 데이터베이스를 직접 비교하는 우를 범할만도 하다.

모든 데이터베이스는 레코드 단위로 데이터를 저장하는 로우 기반 데이터베이스와 필드 단위로 데이터를 저장하는 컬럼 기반 데이터베이스로 구분할 수 있다. 제목, 작성일, 본문 필드를 가진 사용자가 작성한 글을 글 단위로 저장한다면 로우 기반 데이터베이스가 되고 제목, 작성일, 본문 필드 각각을 따로 저장하면 컬럼 기반 데이터베이스가 된다. 구글 빅테이블은 컬럼 기반 데이터베이스에 해당된다. 반면에 최신 관계형 데이터베이스는 이 두가지를 혼용하여 사용한다고 한다.

저장 구조가 다르기 때문에 이 두가지 형태의 데이터베이스는 사용처에 따라 각자의 성능을 최대로 발휘된다. 데이터를 레코드 단위로 저장, 인출하는 관계형 데이터베이스는 한 레코드 전체를 읽어 사용해야 하는 경우에 한번에 읽을 수 있어 더 유리하다. 반면에 컬럼 데이터베이스는 컬럼 단위로 쓰거나 읽어야 하는 경우에 더 유리하다. 구글의 빅테이블은 웹 크롤러가 저장하고 분산 인덱서가 인출하는 웹 저장소로 시작되었기 때문에 컬럼 기반 데이터베이스 형태로 설계되었다. 이런 선택은 특정 색인필드만을 대량 고속으로 인출해야 하는 분산 웹 색인기의 사용 패턴에 기인한다.

컬럼 기반 데이터베이스는 컬럼 데이터형이 동일하기 때문에 이질 데이터형을 가진 필드를 가진 로우 기반 데이터베이스에 비해 압축 효율이 더 좋기 때문에 저장공간 효율면에서 우월하다. 특히, 컬럼 값이 띄엄띄엄 있는 대용량 데이터를 다룰 경우에 더 좋아진다. 반대로 무작위 인출 연산이 필요한 경우에는 압축해제 시간과 여러 컬럼을 인출해 합쳐야 하는 부담으로 로우 기반 데이터베이스 비해 성능이 떨어진다.

이와 같은 구조적인 차이로 인해 구글 빅테이블은 MySQL과 같이 주 저장구조로 로우 기반 데이터베이스인 관계형 데이터베이스와는 다른 목적으로 설계되어 대치물로 비교되어서는 절대 안된다. 컬럼 기반 데이터베이스가 컬럼의 합인 레코드를 모두 읽어야 하는 경우에 성능이 떨어짐에도 불구하고 저장 효율이 높고 컬럼 단위 인출 속도가 높다는 특징으로 단순한 구조의 대용량 웹 콘텐트의 저장소와 같은 특수한 경우에만 적합하기 때문이다. 한 개의 큰 테이블만을 사용자에게 제공하는 구글 베이스가 이와 같은 특수 사용예다. 논문에 언급한 구글 서비스들도 단순한 구조의 데이터만을 구글 빅테이블에 올리고 있다.

구글 서비스에서 구글 빅테이블을 웹 콘텐트 저장소로 일부 채택했다고 해서 모든 웹 서비스의 데이터 저장소로 구글 빅테이블을 사용할 수 있을 것이라고 오해하면 안된다. 잘 알려진 구글 인프라들은 대용량 검색인프라에 뿌리를 두고 설계되었기 때문에 설계 중심에는 오프라인 처리가 기본 사상이다. 비록 구글 빅테이블과 같이 온라인 처리를 지원하는 인프라라도 오프라인 대용량 처리가 기본 사상이기 때문에 온라인 처리는 특수한 경우에만 효율적이게 된다. 따라서 관계형데이터베이스가 충분히 처리 가능한 수 백만개의 데이터를 다루는 곳에서는 부적합한 경우 또는 사용할 수 없는 경우가 더 많다. 사용자 계정정보, 구매 기록과 같이 트랜잭션과 완벽한 관계성 준수가 필요한 경우는 부적합하고 문자열이 위주인 게시판 또는 정적 웹 페이지를 많이 저장하고 인출할 때 유용하다. 특히, 수억개로 누적될 수 있는 있는 웹 로그, UCC, 크롤된 텍스트를 저장하고 인출하는데 적합하다.

[1] 구글 빅테이블 논문: http://labs.google.com/papers/bigtable.html
[2] 인포큐 인터뷰: http://www.infoq.com/news/2008/04/hypertable-interview
[3] 하이퍼테이블: http://hypertable.org/
[4] 컬럼 기반 데이터베이스: http://en.wikipedia.org/wiki/Column-oriented_DBMS

@webJOY

스탠포드 대학에서 사용하는 정보검색 교재

webJOY — Thu, 1 May 2008 04:03:07 +0900

검색엔진을 만들다 보면 참고할 책이 별로 없어 도제식으로 선배가 만든 엔진에 대해 배우거나 루씬 같은 오픈소스 검색엔진 코드를 보면서 배우게 된다. 핵심구조가 고정된 엔진만을 보고 배웠을 때 서비스 기획의도에 적합하도록 색인구조와 같은 핵심구조를 변경하기란 매우 어려워 질의를 처리할 때 기교를 부리는 편법을 쓰곤 한다. "루씬 인 액션(에이콘)"이나 대학 교재로 많이 사용되는 "최신정보검색론(홍릉과학출판사)" 같은 책들은 루씬 색인의 활용법 또는 이론적 배경 설명에 머물러 색인구조 설계와 같은 핵심구조 설계에는 큰 도움이 되지 못 한다. 검색엔진 핵심구조 설계에 필요한 요소들을 그나마 가장 잘 설명하고 있는 "Managing Gigabytes"가 있지만, 이 책은 1994년에 초판을 거쳐 1999년에 개정판이 출간되었기 때문에 최신 기술들에 대한 소개가 부족하고, 적용이 힘든 이미지 검색에 상당히 많은 장이 할애되어 있어 비록 바이블 격이지만 아쉬운 점이 많은 책이다.

원제가 "An Introduction to Information Retrieval"인 이 책은 3명의 저자가 2002년 가을학기와 2003년 겨울학기에 스탠포드에서 "정보검색과 정보추출" 강의를 하면서 정리한 내용을 캠브리지 대학 출판사와 출판한 것으로 PDF 버전으로 공개되어 무료로 다운받을 수 있다. 2008년에 책으로 출간될 예정이지만 다운로드 페이지에는 출간 후에도 이 PDF 파일들을 유지하겠다고 되어 있어 특히나 매력적이다. 검색엔진과 맞물려 많이 사용되는 분류기술들에 대한 소개와 웹 크롤링과 인덱싱에 대한 기술도 소개하고 있어 전체를 바라보는데는 큰 도움이 되는 책이다. 반면에 대학 교재라는 한계로 구현에 이르는 상세한 내용이 부족하고 확률모델과 같은 실용적이지 않은 기술들에 일부 장이 할애된 점에서는 아쉽다.

크리스토퍼와 하인리히는 NLP 교재로 많이 사용되는 "Foundations of Statistical Natural Language Processing" 을 쓴 NLP 배경을 가진 교수들이고, 프랍하카은 "Randomized Algorithm"이란 알고리즘 책을 쓴 야후 사람이다. 백그라운드로만 보면 "정보검색"에 분야와 거리있는 사람들이 모여 쓴 책이지만 1장 ~ 7장까지 정리된 정보검색 관련 알고리즘들은 오히려 MG 검색엔진을 만들며 쓴 "Managing Gigabytes"보다 더 깔끔히 정리되어 있다.

흔하지 않은 검색 관련된 신간이고 또 무료 버전이 있어 더욱 매력적인 책이다. 현재 검색엔진을 만들고 있거나 새로 입문하려는 분들에게는 옆에 놓고 틈틈히 공부하기에 좋은 책인 것 같다.

@webJOY
10BEA3HbFfX2jwrZKQhsNR2EOoJ

집단지성 프로그래밍

webJOY — Wed, 30 Apr 2008 01:30:09 +0900

작년 11월 부터 주말에 시간을 내 번역한 "집단지성 프로그래밍(한빛미디어)"가 출간되었다. 집단지성도 프로그래밍할 수 있는가 하고 생각하면 참 거창하기도 우습기도 한 제목이지만, 보면 볼수록 매력적인 책 이름이다. 제임스 서로위키의 "대중의 지혜(The Wisdom of Crowds)"에서 800명의 비전문가들이 도살된 후의 소 무게를 1 파운드 차이로 정확하게 예측해 코가 납짝해졌던 프랜시스 골튼의 이야기 처럼 웹 2.0 서비스에 참여한 상호 독립적인 군중들의 판단을 모아 가치있는 결론을 유추하는 프로그램을 작성한다고 보면 제목으로 제격이다.

한 가지 재미난 점으로 이 책의 아마존 판매순위로 개발자들이 웹 2.0을 바라보는 은근한 시각을 유추할 수 있다. 웹 2.0 세상에서 개발자들은 Ajax, Mashup 같은 용어들을 먼저 접하게 되지만 좀 더 파고들면 들수록 참여, 개방, 공유로 대표되는 웹 2.0 사상을 대표할 수 있는 핵심과는 다소 먼 느낌을 받게 된다. 책 원저자인 토비 세가란이 가지런히 정리했다고 하나 기계학습, 인공지능 관련된 수식이 난무하는 골치 아픈 책이 아마존 책 판매랭킹 순 웹 2.0 분야 1위까지 등극한 것으로 볼 때 은연 중에 웹 2.0 사상을 다루는 법에 대해 개발자들의 집단지성이 발현되어 나타난 결과가 아닐까 생각든다.

v59kbYisdutjF3N+0gxEY8r1Kf7hrTMVdstNoCR1MJM=