제가 구글 모조품 제작법을 공개합니다.

익명 사용자의 이미지

구글은 단어를 가지고 검색을 하죠.
즉 search 라고 입력해 놓는다면 구글은 search 라는 단어가 든
문서들을 검색합니다.

제가 이야기 할것은 크롤링 방법과, 정렬 및 검색 방법 입니다.
(물론 제가 이야기한대로 하면 성능은 그리 좋지는 않을 것이지만
여러분 재량껏 제작해 보시기 바랍니다. 이는 펄로도 얼마든지
제작할 수 있고, 수천만 페이지.. 아니 수억 페이지에서도
문제없이 돌아가는 방법입니다.)

크롤링 방법은 우선 한 웹사이트에 들어가면, 하부 링크들이
있는데, 이들을 하나씩 하나씩 검사하는데, 웬만하면 멀티쓰레드를
굴리는게 좋은 방법일 것입니다.
그다음 링크를 검사하다가 받은 문서에 있는 단어 하나 하나들을
채취하여서 단어 하나당 하나의 방을 만듭니다.
(물론 단어가 또하나 생기면 그것은 방을 만들지 않고
생략됩니다.)
그다음 또 이야기 할것은.. 디렉토리에 문서를 저장하는데..
search,engine,help,.. 라는 단어가 포함된 문서의 번호(ex10240) 라면
search,engine,help,.. 의 디렉토리를 첵킹하고 없으면 만들고 해서
그 번호를 저장하는데 그냥 저장하는 것이 아닌..
search/10240-10-5-1
engine/10240-8-6-2
help/10240-5-7-3
...
이런 식으로 주는데.. 명심할 것은 10240-10-5-1 중에 10240 은
문서의 번호이고, 10은 문서에 주는 그 단어에 상응하는 점수이고
(점수 타이틀 - 메타태그 - 문서내용 에서 검색된 순으로 주고
앞에 붙을수록 많은 점수가 붙는다. 특히 문장이 길지도 짧지도
않게 할수록 유리.. 그러므로 크롤링을 할때 평균을 구해서
저장해 둔 후 그 평균에 가까운 바이트 수인지 맞춰 본다.)
5 는 0으로 부터의 몇번째 단어인가고, 1 은 타이틀, 메타태그,
일반 문서 내용 인데, 1은 타이틀, 2는 일반문서, 3은 메타태그
등등등.. 해서 저장합니다.
(여기서 이야기했던 5와 1은 분명히 "..." 를 입력하여 검색시
문장검색이 가능하게 만들기 위함으로 만들어 놓은 필드 입니다.)
이제 그렇게 되면.. 번호만 매기고 저장을 합니다.
합니다. 이제.. 그러면 그 번호랑 똑같은 파일을 또 url,
타이틀,메타태그, 내용 순으로 저장한 파일을(10240 이 됩니다.)
보관해두는 방을 만듭니다. 그다음 분명이 그것들을 가지고
후에 다시 크롤링할때 씁니다.
그리고.. 찾아둔 링크들과 링크 번호는 다른방에 저장후에
위에 말한대로 문서 채취 및 저장후에 다른 링크롤 찾습니다.
그다음.. 정해진 쓰레드 수에 의해서 5개로 정해지면 5개의
url 을 긁는 식으로.. 하면 되겠습니다. 그래서 수십개 하면..
또하나 링크가 생기면.. 또다시 링크를 저장후에 다시 나갑니다.
그렇게 하면 되구요...

검색 방법은 정말 원초적인데.. search 한단어만 찾는다면..
search 디렉토리만 찾습니다. and 연산자를 쓰고 search engine 치면
search 와 engine 디렉토리를 첵킹후에 같은 번호들이 있는 것들을
모조리 메모리에 저장후 문서를 읽으면 되겠습니다.
or 연산자는 search 와 engine 의 문서를 모조리 찾은 다음에
둘을 무조건 통합후 정렬후 번호 중복 여부를 본 다음 끝내면
되고..
만약에 "" 연산자를 쓴다면 search engine 라는 것만 찾게 되는데..
search 가 4번째 단어고 engine 가 5번째 단어라는 식으로..
0 1 2 3 .... 이렇게 딱 들어 맞는 결과만 내보냅니다.

아차.. 하나 빠졌는데.. 점수를 봐서(미리 알고리즘에 따라서
점수를 매겨놔서 그냥 and 나 or 검색시 합계를 구하기만 하면
됩니다.) 높은 순으로 정렬을 해야 합니다.

아차 더 좋게 만들려면 SQL 서버나 버클리 DB 도 한번 고려해
보시는게 좋을 듯 합니다.

----------------------------------------------------

이렇게 하면 그래도 구글보단 못하지만 어느정도 흉내를 냈다는
생각을 할 수 있을 것입니다.

자 어떻습니까.. 이제 알아서 만들어 보시길 바랍니다.
물론 이 아이디어는 상업용으로 써도 무방하고, 저도 이 아이디어에
기반해서 훗날 간단한 웹검색엔진을 만들어보죠.

.... 아차 한가지 이야기가 빠졌는데요..
전문검색을 한다면 1개 문서당 평균 20000 바이트 된다 칩시다.
그리고 인덱스 데이타도 1개 문서당 1000 바이트 된다 치고.
그렇게 된다면.. 1개 문서당 21000byte 잡아먹고, 그게 한
1억개를 목표라면 210 기가가 된다는 이야기인데..
아직 210 기가가 되는 하드가 없는것으로 아는데..
어떻게 구축하는지.. 원리를 간단히 좀 알려 주시기 바랍니다.

익명 사용자의 이미지

여러 개의 단어를 치고서 검색을 하게 될 때에 만약에 경우를 위해
단어 수 제한을 두어야 합니다. (10개정도)
그리고 한 단어가 64byte 가 넘는 것이 있다면, 자동으로 무시를
해 버려야 합니다.

익명 사용자의 이미지

제가 중요한 것 하나를 빼먹었는데...
분명히 페이지수를 10~20개로 나누도록 해야 합니다.

익명 사용자의 이미지

서버가 6000대? 8000대? 라고 했던 기사를 본적이 있었습니다.
레드햇을 튜닝해서 쓴다고 했던것 같은데.. 자세히는 잘 모르겠군요.

6000대에 평균 10기가씩만 붙어 있다고 해도 60테라..
8000대에 평균 80기가씩 붙어 있다고 하면 어마어마하겠죠. 수백테라는 될테니까요..

킬로, 메가, 기가, 테라, 헵타. 그 다음엔 뭐죠? 아무튼 구글이 헵타를 돌파할 날도 그리 멀지 않을지도 모르죠..