예전에 Distribute Indexing에 대해서 글을 써본적이 있는데, 아주 아이디얼하게 시작 문자로 분산을 시켰었다.

오늘은 어떤것을 기준으로 대용량 분산을 하면 될지 한번 생각해 보려고 한다.

아마도 이것은 Query Processing에 대한 글과도 관련이 있을거 같다는 생각이 든다.
(top k개의 결과만 가져오면 된다는 가정을 하고 기술하기 때문이다.)

hadoop과 같은 mapreduce기반의 시스템은 분산시 쓰이는 function을 제공한다. 그리고 또한 이것들을 직접 만들어서 적용이 가능하다. 그럼 어떻게 분산을 키시는게 대용량 검색을 최적으로 만들까?

첫번째는 term을 기반으로 분산을 키시는 경우를 생각해 보자.

term을 기준으로 분산을 시킬경우 분산의 의미를 살리기가 힘들다. 왜냐면 흔하게 나오는 term일 경우 해당 서버에서 다른 서버로 전송하고 결과를 merge하는데 네트워크 리소스가 많이 들것이다. 그리고 또한 그 해당 서버가 병목이 되기 쉽다. 이렇게 한다면 분산 시스템의 장점을 살리기 어렵다.

그러면 문서를 기준으로 분산을 시킬 경우 어떻게 될것인가?  문서를 기준으로 분산을 시키는 경우도 위의 term의 경우처럼 굉장히 많이 발생하는 단어에 대한 단점은 다소 해소될 것이다. 그러나 사람이 검색이라는 짓을 할때 자신이 찾고자 하는 문서의 이미지를 떠올리고 그 문서를 대표할만한 단어를 선택을 하는 과정을 겪는데 그 단어의 적중률이 상당히 정확할 것이라고 했을 경우 특정 문서가 포함된 local disk의 서치가 늘어나는 반면, 네트워크간의 데이터의 이동은 term을 기준으로 했을때에 비해서 적어질 것이다.
하지만 이것의 단점은, 확률적인 계산을 하고자 할때(예. idf)  여타의 다른 주기적인 process를 통해서 결과를 누적시켜야 할것이다.

host를 기준으로 분산을 시킬 경우는 많은 갯수의 query가 올라올 경우 몇몇 소수의 index에 집중이 될 가능성이 많다는 단점이 있을테고…

url을 해싱해서 분산을 시키는 경우가 분산이 가장 잘 될거라 생각되는데 이때 검색 결과로 많이 제시될 확률이 높은 것들을 분류해서 url 해싱 분산을 시키고, 나머지 것들은 양이 어느정도가 되었든지 간에 소수의 서버에 넣는 방법이다. 
많이 서치가 될만한 것들만 다수의 서버에 집중 분산을 시키고, 결과로 나올 가능성이 적은 문서들은 따로 상대적으로 적은 서버에 넣는것이다.
대부분의 쿼리에서 top k의 결과를 가져오는건 다수의 서버에서 작업이 될것이고, 가끔가다 잘 나오지 않는 쿼리의 경우 소수의 서버에서 결과를 가져올 것이다.
검색 결과로 많이 나올만 한 문서들은 여러 방법으로 분류가 가능하겠지만, 일반적으로 PageRank방법을 생각하면 이해가 편할거 같다.

위에서는 서치 타임에 대한 로드를 생각해서 생각을 했는데, 위의 분산 방식은 반드시 크롤링 타임에 대한 고려를 기반으로 해야한다.
요즘 대부분 대용량 검색에서는 크롤러에서 바로 색인을 build하는 방식을 따르기 때문이다.

ps. 다음 포스팅에는 Distribute Crawling에 대해서 한번 생각해 봐야 겠다.

Dsitributed Index by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.