왼쫀 아래에 보면 dic(사전)들이 있습니다. 이것은 형태소분석기에서 사용하는 사전으로 색인시에 사용했던 사전들과 동일한 구조로 되어 있는 것이 바람직합니다. 물론 서비스 구성에 따라 형태소분석기 세팅 자체를 서로 다르게 할 수도 있습니다. 바로 옆에 있는 시소러스 사전은 별도로 동작하게 할 수도 있으나 대부분 형태소 분석기에서 사전과 같이 처리하는 것이 일반적인 예입니다. 이런 시소러스사전류는 검색시 입력되는 질의를 확장한다거나 할 경우 많이 사용됩니다.
여기서 질의를 확장한다라는 의미는 뭘까요? 쇼핑몰 검색을 예로 봅시다. 어떤 구매자가 나이키의 조깅화를 구입하려 하는데 갑자기 조깅화란 단어가 떠오르지 않는다면 어떤식으로 질의를 입력 할까요? 보통 나이키, 아니면 운동화 정도로 우선 검색을 할 것입니다. 이때 운동화라는 개념을 좀더 확장하여 조깅화, 런닝화, 축구화, 등등의 키워드들을 추가하여 검색하게 된다면 보다 쉽게 최종 결과에 도달할 수 있을 것입니다. 단, 부적절한 질의확장은 검색성능이나 결과 개수에 악영향을 미칠 수 있으므로 많은 연구가 필요할 것입니다. 당연히 시소러스 사전 자체도 서비스에 맞게 잘 구성되어 있어야 합니다.
다음으로.. 바로옆에 있는 index db는 색인기가 만들어 놓은 색인 정보들입니다. 이전 강좌에서 설명했던 내용이니 확인해 보시면 될 것이구요.. 다른것 하나는 term cluster dic인데 검색 엔진의 기본기능이 아닌 관계로 넘어가겠습니다. ^_^;
사용자가 검색질의 엔진에 던지게 되면 방식은 여러가지가 있습니다. 물론 서비스를 구성하는 것에 따라 방법이 달라지게 되구요. 많이 쓰이는 것들은 인터넷 검색엔진들이 되겠지요. 보통 CGI를 통해 질의를 받아서 CGI가 엔진으로 전달하고 결과를 받게 됩니다.
엔진에서 클라이언트 API를 제공하거 어떤 프로토콜을 제공해 준다면 윈도용 어플리케이션에서도 결과를 받아볼 수 있겠지요. 어차피 소켓통신을 하는 데몬이기에 프로토콜만 알게 되면 어떠한 응용 프로그램에서도 엔진과 바로 맞붙어서 데이타를 주고 받을 수 있습니다.(당연하겠지요?) 그래서 이런 경우에는 client api, activeX 콘트롤, 일반 APPs, 관리도구 등에서 다양하게 접속하여 엔진의 결과를 받을 수 있습니다.
그러나 검색포탈이나 SI업체들의 검색엔진은 프로토콜을 공개하지 않습니다. 이유는 당연하겠지요. 네이버가 검색 프로토콜을 공개한다면 하루에도 수십번 해킹을 당할 수 있을 것입니다. 하지만 검색엔진을 직접 개발하는 한 그룹내에서는 이런한 프로토콜을 공개하는 것이 개발시 도움이 될 수 있습니다.
아무튼, 클라이언트에서 입력된 검색질의는 엔진에서 받아들이게 되면 맨 처음 질의분석기(Query Analayzer)라는 녀석이 받아들입니다. 그래서 유효한 검색질의인지, 유효하다면 엔진이 이해할 수 있는 방식으로 검색질의를 파싱한 후 어떤식으로 검색을 수행할지, 어떤 필드에서 검색을 할지, 키워드를 확장할지 등등을 결정하게 됩니다.
결정이 되면 바로 연산기(calculator)로 파싱된 질의를 전달하여 질의에 대한 연산을 수행합니다. 이때 연산기는 자연어처리모듈, 논리연산 처리모듈, 숫자처리 모듈들을 내장하여 검색옵션에 맞게 결과를 계산하게 됩니다.
연산기가 계산대상이 되는 데이타를 먼저 로딩하기 위해 파싱된 텀별로 index DB의 데이타를 읽기 위해 Retriever에게 질의를 던지게 되면 Retriever는 필요한 정보들을 index DB에서 로딩하여 연산기로 전달해 줍니다.
연산기가 모든 연산을 마치게 되면 결과는 순위화된 문서들의 일련번호와 문서들의 랭킹점수등이 남게 됩니다. 이러한 내용들을 Stream Generator로 전달하게되고 Stream Generator는 최종 사용자가 확인할 수 있는 결과(제목, 본문, URL, 기타 부가정보등등)를 만들어서 다시 질의분석기 에게 돌려주게 됩니다.
그러면 질의분석기는 정해진 프로토콜에 맞게 Stream을 정리하여 클라이언트에 전달하게 되고 최종 검색결과를 클라이언트에서 마음대로 조작한 후 보여지게 됩니다.
그림에서 오른쪽에 Summary Server와 Log Server가 있습니다. 후자는 일반검색엔진과는 별 상관이 없는 부분입니다. Summary Server는 보통 검색엔진 내에 요약정보를 따로 두는 경우가 많습니다. 그러나 대용량 데이타일 경우는 요약정보가 하나의 서버에 같이 존재하게 되면 Disk I/O문제도 발생할 수 있으며 여러가지 성능에 안좋은 영향을 미칠 수 있으므로 위와 같이 요약서버 자체를 분리하여 구성할 수도 있습니다.
이상 간단한 검색기 구조였습니다.
댓글 없음:
댓글 쓰기