분당아재의 솔직한 블로그

'수집기'에 해당되는 글 1건

  1. 검색엔진 이야기(3) - 검색엔진의 구조 1

검색엔진 이야기(3) - 검색엔진의 구조

IT산책

검색엔진 이야기 세번째입니다.
오늘은 검색엔진의 전체적인 흐름에 대해서 이야기 하겠습니다.

그동안 검색엔진에 대해서 올렸던 포스트에 관심이 있으시면 아래 링크를 참고하시기 바랍니다.


먼저 검색엔진의 일반적인 구조를 살펴보겠습니다.


검색엔진의 구조는 크게 데이터를 수집하는 수집부문, 수집된 데이터를 역파일(inverted File)로 만드는 색인부문, 실제 사용자에게 검색서비스를 하는 검색부문으로 나눌 수 있습니다.
검색엔진을 만드는 회사마다 조금씩 다른 구조를 가질 수 있겠지만 일반적으로 3부문으로 구분하면 큰 문제는 없습니다.

1. 수집부문
무언가 검색을 하기 위해서는 가장 먼저 검색대상이 되는 것으로부터 데이터(텍스트)를 수집하는 것이 첫번째 작업입니다.

검색대상으로는 일반 기업이나 공공기관에서 많이 사용하는 전자결재, 지식관리(KMS), 문서관리(EDMS), 게시판, 자료실 등 일반적인 RDB(Oracle, MS-SQL, MySQL, Informix, Sybase 등)에 저장된 거의 모든 데이터가 해당됩니다.

전자결재, KMS, EDMS 등도 공급하는 솔루션회사 별로 제품의 성격, DB 스키마 등이 다 다르기 때문에 사실 검색엔진 입장에서는 수집이 가장 힘든 작업 중 하나입니다.

이런 RDB를 수집할 때는 Bridge라고 불리우는 수집기 모듈을 사용합니다.
업체에 따라 DB Gateway, DB Bridge 등으로 불리는데 여기서는 Bridge라는 용어로 설명을 하겠습니다.

DB Bridge에서 검색대상 데이터를 수집할 때는 JDBC 방식으로 데이터를 수집합니다.
각 검색대상에서 검색이 될만한 필드를 뽑아서 SQL로 구성한 후 DB Bridge에 해당 SQL를 전달하여
원하는 필드값들을 Select하여 텍스트로 저장하도록 합니다.
이렇게 저장된 텍스트를 가지고 색인 작업을 수행합니다.

때론, RDB가 아닌 다른 시스템을 검색하는 경우도 있습니다.
IBM의 Notes 시스템을 검색하거나 Exchange 서버의 메일이나 게시판을 수집하는 경우가 그것인데요. 이 경우에는 Notes를 전문적으로 수집하는 Notes Bridge, Exchage 서버의 메일을 수집하는 Exchage Bridge 등 전용 수집기를 써야 합니다.

인터넷 상의 웹문서를 수집하는 경우도 있습니다.
이 경우에는 WebBridge라는 것을 사용해야 하는데요. 이것에 대해서는 과거에 써 높았던 포스트를 참고하시기 바랍니다.



하지만 어떤 경우는 수집기를 통한 결과는 텍스트 형태의 임시 파일로 저장됩니다.
수집기의 역할을 검색대상으로 부터 텍스트를 추출하여 색인기로 전달하는 것 입니다.

2. 색인부문

수집기를 통하여 수집된 텍스트를 검색이 잘 되도록 역파일(Inverted File)로 변환하는 역할을 색인기(Indexer)가 담당합니다.
이 색인기가 어떤 알고리즘으로 설계되고 동작되는지에 따라 그 검색엔진의 성능이 좌우됩니다.

과거에는 검색대상이 되는 시스템의 DB량이 많지 않아서 웬만한 색인 알고리즘을 갖고도 데이터를 색인하고 검색하는데 무리가 없었습니다.
그러나 지금은 기업/공공기관에서 보유한 데이터 양이 수십G Byte에서 많게는 Tera Byte에 이르기 때문에 웬만한 검색엔진들은 색인하다가 시스템 다운이 되기도 합니다.

이런 이유로 인해서  대용량 검색을 지원하지 못하는 검색엔진 회사들은 어느새 시장에서 사라졌습니다. 지금은 와이즈넛, 코난, 다이퀘스트 등 몇 개 회사가 왕성하게 영업중입니다.

역시 이런 이유로 인해서 색인파일의 구조나 성능에 대한 측정값 등은 보안에 꽤 민감한 사항입니다.
자칫 경쟁사로 부터 공격의 대상이 될 수 있으니까요.
색인에 대한 이야기는 간단하게 접도록 하겠습니다.

3. 검색부문

사용자가 입력한 검색질의(Query)에 대해서 색인파일을 잘 뒤져서 검색결과 목록을 작성한 후 다시 사용자에게 제공하는 역할을 하는 것이 검색기(Searcher)입니다.

검색기도 기술적으로 굉장히 중요한 부분입니다.
포탈이나 쇼핑몰 같이 동시에 많은 사용자가 많은 Query를 보낼 때 검색결과를 제대로 찾아서 전달할 수 있는가?
각종 오름차, 내림차 등 정렬, 페이지 처리, 한 페이지에 보여줄 검색결과 개수, 상세 조건검색,
결과 내 검색 등 다양한 옵션에 대해서 모두 빠른 시간에 검색결과를 보여줘야 하기 때문에 이 부분도
상당한 기술이 필요합니다.

또한, 검색기는 Daemon이나 Service 형태로 늘 실행되면서 사용자의 Query를 기다려야하기 때문에
절대로 죽어서는 안됩니다. (물론, 대부분의 검색엔진들은 가끔씩 죽기도 합니다. ㅎㅎㅎ)

요즘은 이런 중요하고도 기본적인 검색기능 이외에
검색어 자동완성 기능, 인기검색어, 연관검색어, 테마 검색 등 사용자의 입력 편의를 위한 다양한 부가기능이 더 중요하게 여겨지기도 합니다.

어느새 검색엔진 본래의 역할은 기본이 되어버렸고
어떤 회사에서 눈에 보기 좋은 부가기능을 더 많이 갖고 있는가가 업체를 선택하는 중요한 요소가 되었습니다.
사용자들이 그만큼 게을려졌다는 것이겠지요. ㅜ.ㅜ


포스트를 적다보니 처음 의도와는 다른 방향으로 간 것 같습니다.
두서없이 적다보니 내용도 좀 부실해 졌네요.
나중에 좀더 보완해서 올려보도록 하겠습니다.