2010-03-16 10 views
0

약 1 백만 개의 웹 페이지를 검색 할 수있는 작은 웹 검색 엔진을 구축 중이며 거꾸로 된 인덱스를 만드는 가장 좋은 방법은 무엇입니까? DBMS 또는 무엇을 사용 하는가 ...? 스토리지 비용, 성능, 인덱싱 및 쿼리 속도와 같은 다양한 관점에서 볼 때? 나는 내 자신의 것을 만들기 위해 오픈 소스 프로젝트를 사용하고 싶지 않다.역 색인을 만드는 가장 좋은 방법은 무엇입니까?

답변

1

아마도 Lucene이나 Sphinx와 같은 F/OSS 도구를 사용하고 싶지 않을 수도 있습니다.

+1

정말 아무도 가장 적절한 답이 없다? – D3VELOPER

+0

@ D3VELOPER : 어쩌면 당신이 더 잘 물어볼 필요가 있을까요? :) – mfolnovich

+1

Lucene, Sphinx 및 Hadoop과 같은 F/OSS 도구에 대한 제 이해에 따라 고맙습니다. – D3VELOPER

3

현재 대부분의 폐쇄 소스 데이터베이스 관리자는 일종의 전체 텍스트 인덱싱 기능을 갖추고 있습니다. 그것의 인기를 감안할 때, 나는 대부분의 웹 페이지에 대해 1000 히트를주지 않을 것이라고 <p> 같은 것을 검색 할 수 있도록 HTML을위한 미리 작성된 필터를 가지고 있다고 생각합니다.

작업을 직접 수행하려면 HTML 필터링이 가장 어려운 부분 일 것입니다. 거기에서 역 색인은 많은 텍스트 처리를 필요로하며 큰 결과를 산출하지만, 기본적으로 모든 문서를 스캔하고 단어 목록과 위치를 작성합니다 (일반적으로 매우 일반적인 것을 필터링 한 후 의미있는 검색어가 아닐 "a", "an", "and"등의 단어) 그런 다음 모두를 하나의 큰 색인으로 정리하십시오.

전체 색인의 크기를 감안할 때 실제 메모 리에 쉽게 맞을 수있을 정도로 충분히 작은 두 번째 수준 색인을 추가하는 것이 좋습니다 (예 : 몇백 개 정도의 항목으로 제한). 정말 작은 (그러나 다소 비효율적 인) 버전은 단어의 첫 글자 만 따라 가게되므로 "A"단어는 0, "B"는 12345, "C"는 34567 등으로 시작합니다. 그다지 효과적이지는 않습니다. 예를 들어 "X"보다 "A"로 시작하는 단어가 더 많습니다. 색인을 작성한 다음 색인 전체에 균등하게 간격을 둔 단어를 몇백 개 선택하는 것이 더 효과적입니다. 그런 다음이를 첫 번째 수준 색인으로 사용하십시오. 이론 상으로는 B + 트리와 같은 좀 더 정교해질 수 있지만 일반적으로 과도 함입니다. 수백만 건의 문서 중에서 기회가 충분 해 자주 사용되는 수십만 단어 미만으로 끝날 가능성이 있습니다 인덱스 크기에 많은 차이가 있습니다. 심지어 그 중 일부 항목은 오타가 아닌 실제 단어가 될 것입니다 ...

0

Hadoop부터 시작 하시겠습니까? 클러스터를 통해 효율적으로 색인 빌드를 배포합니다. 어떤 언어 든 사용할 수 있습니다. Java 및 Python이 권장됩니다. Hadoop/MapReduce를 사용하면 웹 페이지를 쉽게 색인 할 수 있습니다. 하지만 디스크에 캐싱/저장해야하며 먼저 텍스트를 추출하려면 파서/토큰 화 프로그램이 필요합니다. 그물에는 무료로 사용할 수있는 파서가 몇 가지 있습니다. 수동으로 실행하려면 여기에서 시작할 수 있습니다. 인덱스가 있으면 인덱스를 저장하는 것이 다른 작업입니다.

+0

불명확 한 질문에 관해서는, 이것은 여전히 ​​좋은 답변이 아닙니다. Hadoop이 필요한 이유는 무엇입니까? 하나는 단순히 스크립트로 이러한 모든 웹 사이트를 긁어서 색인에 넣을 수 있습니다. 실제로지도 주위에지도 축소 프레임 워크를 두는 것은 중요하지 않습니다. – Overbryd

관련 문제