오늘 커널 공부하다가 지루한 나머지 Distribute Indexing에 대한 공부를 좀 해봤다. (역시나 지루한 코드를 보는것보다 이런 개념 학습이 더 재미난다. ^^)

예전에 MapReduce에 대한 개념을 설명할 때가 있었다. 이때 내가 느낀것은 단 한가지 였다.
 
MapReduce는 큰일을 작은 일로 분산시켜서 처리할때 굉장히 심플한 처리 공정을 보여 준다는 것이다. 

그럼 여기서 Distribute Indexing을 하는 이유는 무엇인가?

1. 웹 데이터는 무지 많다.
2. 서버한대 한대의 안정성은 절대 보장 못한다.

위와 같은 이유로 구글같은 곳에서 MapReduce라는 개념을 쓴 것이고 이제는 거의 N개의 컴퓨터 문제는 MapReduce를 생각하는게 정석(?)이 되어 버렸다.

아래 그림에서 Data Flow를 보여준다.

여기서 Master는 일단 에러에 강하다고 가정을 하고,

Master의 역할은 놀고있는 Parser, Inverter 프로세스들을 Job에 할당하는 역할을 하고 프로세스가 죽거나 에러나 났을때 다시 프로세스를 생성하게끔 하고 필요없을때 Kill하게끔 하는 역할을 한다. 필요에 따라 더 많은 역할을 할수도 있겠다.

Parser는 MapReduce에서 Map에 해당하는 놈인데,Master가 놀고있는 Parser 하나를 집어와서 문서하나를 가져와 (term, DocID)쌍으로 만든 다음에 term의 시작문자에 따른 파티셔닝을 해 해당 파티션에 쓰는 작업을 시킨다.(문서 단위가 아니라 문서의 서브셋 단위로도 가능 할 것이다.)
그러니까 a-f, g-p, q-z 의 세가지로 파티셔닝이 되어 있다면 boy라는 term은 첫번째 파티션에 저장이 되는것이다. (Parser는 Sorting을 하면 안되겠다.)
파티션은 각기 분산된 서버라고 생각하자!

그렇게 Parser의 일이 다 끝나면(모든 문서의 파싱이 다 끝나면) Inverter가 일을 시작한다.

Inverter는 각 파티션에 접근해 term에 대해서 sorting을 한다.
그러면

(about, 10), (boy, 1),(boy, 3), (boy, 2), (cannon, 110)…… 

위와 같은 tupule쌍이 나오겠고,
저걸 posting 파일에 쓰기전에 아래와 같이 변형시킨 다음에

(about, 10), (boy, 1, 2, 3), (cannon, 110)…… 

알맞게 Posting 파일에 쓰면 될 것이다. 그렇게 되면  Posting File도 분할해서 만들어질텐데 이렇게 분산해서 운영을 한다면 더더욱 이런 구조가 맞을거란 생각이 든다.

MapReduce 방식의 분산 처리문제는 구글 입사 시험에도 단골로 등장할 정도니 개념이해도 확실히 해놓는게 좋을 듯 싶다. 응용을 하자면 저 방식을 웹 크롤링 할때도 쓸수 있다는 것이다. MapReduce 방식의 대표적인 크롤러는 Nutch 크롤러가 되겠다.

나중엔 MapReduce를 이용한 분산 크롤링과 업데이트하는걸 한번 생각해 봐야겠다.

Distribute Indexing과 MapReduce by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.