#alias FastSearch
#keywords macro
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분여 소요.

== 개발 노트 ==
`wiki_indexer.pl`을 사용하지 않기 위해서는 페이지를 저장할때마다 fulltext 서치를 위한 인덱스를 생성시키면 될것이다. 단 하나의 페이지에 대한 인덱스를 업데이트하므로 속도 문제를 해결하게 된다.

 1. 10만 페이지정도에서도 괜찮은 속도를 나오게 하려면 ?

== 테스트 ==
{{{[[FastSearch(Moniwiki)]]}}}
=== 인덱싱 속도 ===
 1. 5천 페이지 인덱싱 : ~5분 - 검색속도 ~1초
 1. 2만 페이지 인덱싱 : ~20분 - 검색속도 ~5초

=== 인덱싱 속도 개선 ===
인덱싱할 때 `unpack`하고 `sort`하는 부분이 있다. 로직에서 이 부분이 크게 중요한 부분이 아닌데, 이 부분을 빼내면 5천페이지 7분 정도 걸리던 것이 2분 미만으로 단축된다. 또 인덱스 사이즈가 커질수록 느려지게 되는데, `unpack`과 `sort`를 제거하면 전체 페이지가 많아져서 인덱스 사이즈가 커지더라도 큰 속도 저하가 없다.

인덱싱 속도를 개선하려면,
 * 최초 인덱스를 생성할 때에 `sort`를 하지 않도록 한다.
 * 최종적인 결과 출력을 할때에 출력 결과를 정렬하도록 한다.
 * 페이지 ID는 정렬되어있지 않다. 따라서 미리 정렬하는 것은 출력 품질에 영향을 미치지 못한다.
  * 인덱서에서 중복된 값을 제거하기 위해서 `unpack`후 `sort`하고 다시 `pack`하는 것.
  * 중복된 값이 큰 문제가 되지 않으므로 아예 정렬/중복된 값을 무시하도록 한다.

<!> 현재 5만 페이지를 인덱싱하는 속도가 ~1시간 정도 걸리고 있다.

=== FullTextIndexer ===
=== Dokuwiki Indexer와 비교 ===
Dokuwiki는 인덱서를 내장하고 있다.
 1. Berkeley DB나 다른 DB엔진을 사용하지 않고 자체적인 인덱스방식을 사용한다.
 1. 한글 및 CJK 문자셋의 경우 단어를 모두 잘라내어서 한개의 문자로 분리해서 인덱싱. - 띄어쓰기가 없는 일본어/중국어의 경우 고려.
 1. 페이지를 생성할 때에 자동 인덱싱된다. 이와 별도로 `bin/indexer.php` (콘솔용), `lib/exe/indexer.php` (웹용) 인덱서가 따로 있다.
 1. 약 1천500 페이지를 가져와서 인덱싱해보니 ~10분 이상 걸린다. 자체적 구현의 인덱싱방식이 너무 느린듯.

== TODO ==
 1. 제목검색 인덱싱 방식 적용.
 1. 역링크검색 인덱싱 방식 적용.
== FasetSearchMacro를 기본 FullSearch 매크로로 대치하기 ==
`config.php`에 다음과 같은 설정을 넣으면 fullsearch가 fastsearch로 대치된다.
{{{
$myplugins=array('fullsearch'=>'FastSearch'); # 앞에는 소문자로, 뒤에는 플러그인 파일 이름에 맞게 FastSearch.php 파일을 찾게되므로 대소문자 구분.
}}}
----
[[FastSearch]]