옛 버전이 없습니다
옛 버전이 없습니다
5천여개의 파일이 있을 경우 FullSearch는 5~10초 정도 걸린다. http://wiki.kldp.org 의 경우 현재 2천3백여 페이지가 있는데 이 경우는 2~3초 걸렸다.
위키에서는 검색이 매우 중요한데 이정도 시간이면 꽤 느린 것이다. 위키의 규모가 작을때는 큰 문제가 되지 않겠지만 위키가 1만여페이지 가까이 되는 경우는 얘기가 달라진다.
현재 모니위키는 페이지를 fulltext indexing하지 않고 그냥 텍스트 서치에 의존하고 있다. 이것을 다음의 링크를 통해 발견할 수 있는 perl 스크립트를 적용하여 FastSearchMacro를 구현하였다.
http://www.heddley.com/edd/php/search.html
5000여개의 파일이 있을 때 FastSearch는 약 0.5~2초 걸렸다.
----
FastSearch를 사용하기 위해서는 wiki_indexer.pl은 하루에 한번정도 실행시켜야 하며, 5천여 페이지에서 약 5분여 동안의 시간이 걸린다. 이것을 php로 간단히 바꾸어 보니 약 7분여 소요.
----
FastSearch를 사용하기 위해서는 wiki_indexer.pl은 하루에 한번정도 실행시켜야 하며, 5천여 페이지에서 약 5분여 동안의 시간이 걸린다. 이것을 php로 간단히 바꾸어 보니 약 7분여 소요.
개발 노트 ¶
wiki_indexer.pl을 사용하지 않기 위해서는 페이지를 저장할때마다 fulltext 서치를 위한 인덱스를 생성시키면 될것이다. 단 하나의 페이지에 대한 인덱스를 업데이트하므로 속도 문제를 해결하게 된다.
- 10만 페이지정도에서도 괜찮은 속도를 나오게 하려면 ?
테스트 ¶
[[FastSearch(Moniwiki)]]
인덱싱 속도 ¶
- 5천 페이지 인덱싱 : ~5분 - 검색속도 ~1초
- 2만 페이지 인덱싱 : ~20분 - 검색속도 ~5초
인덱싱 속도 개선 ¶
인덱싱할 때
인덱싱 속도를 개선하려면,
unpack하고 sort하는 부분이 있다. 로직에서 이 부분이 크게 중요한 부분이 아닌데, 이 부분을 빼내면 5천페이지 7분 정도 걸리던 것이 2분 미만으로 단축된다. 또 인덱스 사이즈가 커질수록 느려지게 되는데, unpack과 sort를 제거하면 전체 페이지가 많아져서 인덱스 사이즈가 커지더라도 큰 속도 저하가 없다.
- 최초 인덱스를 생성할 때에
sort를 하지 않도록 한다.
- 최종적인 결과 출력을 할때에 출력 결과를 정렬하도록 한다.
- 페이지 ID는 정렬되어있지 않다. 따라서 미리 정렬하는 것은 출력 품질에 영향을 미치지 못한다.
- 인덱서에서 중복된 값을 제거하기 위해서
unpack후sort하고 다시pack하는 것.
- 중복된 값이 큰 문제가 되지 않으므로 아예 정렬/중복된 값을 무시하도록 한다.
- 인덱서에서 중복된 값을 제거하기 위해서
FullTextIndexer ¶
Dokuwiki Indexer와 비교 ¶
Dokuwiki는 인덱서를 내장하고 있다.
- Berkeley DB나 다른 DB엔진을 사용하지 않고 자체적인 인덱스방식을 사용한다.
- 한글 및 CJK 문자셋의 경우 단어를 모두 잘라내어서 한개의 문자로 분리해서 인덱싱. - 띄어쓰기가 없는 일본어/중국어의 경우 고려.
- 페이지를 생성할 때에 자동 인덱싱된다. 이와 별도로
bin/indexer.php(콘솔용),lib/exe/indexer.php(웹용) 인덱서가 따로 있다.
- 약 1천500 페이지를 가져와서 인덱싱해보니 ~10분 이상 걸린다. 자체적 구현의 인덱싱방식이 너무 느린듯.
TODO ¶
- 제목검색 인덱싱 방식 적용.
- 역링크검색 인덱싱 방식 적용.
FasetSearchMacro를 기본 FullSearch 매크로로 대치하기 ¶
config.php에 다음과 같은 설정을 넣으면 fullsearch가 fastsearch로 대치된다.
$myplugins=array('fullsearch'=>'FastSearch'); # 앞에는 소문자로, 뒤에는 플러그인 파일 이름에 맞게 FastSearch.php 파일을 찾게되므로 대소문자 구분.
----