검색 속도가 어떤지 좀 알려주세요. 정보
검색 속도가 어떤지 좀 알려주세요.
본문
검색어를 따로 빼내어서 and 검색이 가능하도록 개발중에 있습니다.
게시물이 35,000건 이라 그리 많은건 아니지만
만족할 만한 품질의 검색과 속도가 나오는것 같습니다.
제가 테스트 할때는 0.34초 정도 나오고 있습니다.
혹시나 버그 있으면 알려 주세요.
감사합니다.
ps. 이 코드만 제대로 된다면 5천건씩 구간별로 "다음검색" 할 필요없이 전체게시글에서 한번에 검색이 가능합니다. ^^
게시물이 35,000건 이라 그리 많은건 아니지만
만족할 만한 품질의 검색과 속도가 나오는것 같습니다.
제가 테스트 할때는 0.34초 정도 나오고 있습니다.
혹시나 버그 있으면 알려 주세요.
감사합니다.
ps. 이 코드만 제대로 된다면 5천건씩 구간별로 "다음검색" 할 필요없이 전체게시글에서 한번에 검색이 가능합니다. ^^
추천
2
2
관련링크
댓글 22개

정말 너무 빠른대요~ 누르면 바로바로 나오네요~

헐 정말 광속입니다
엄청 빨라요!!!!
엄청 빨라요!!!!


좋습니다.

목록 :0.0012469291687012
전체 : 0.046242952346802
전체 : 0.046242952346802

빠르네요. 길어야 1초

오.. 제대로 빠른데요...

게시판 구조가 바뀌는 건가요?
query문도 소개해 주세요.
query문도 소개해 주세요.

검색어: 첨부파일
목록 :0.2238621711731
전체 : 0.22437405586243
목록 :0.2238621711731
전체 : 0.22437405586243

"... 검색어를 따로 빼내어서 and 검색이 가능하도록...."
키워드 검색인가요?
아니면 wr_subject만 테이블에서 분리하셨나요?
궁금합니다.
키워드 검색인가요?
아니면 wr_subject만 테이블에서 분리하셨나요?
궁금합니다.

게시판을 게시판별로 테이블 생성하는것이 아니라 하나의 테이블에서 처리하도록 할 생각입니다.
작은 규모의 사이트에서는 10만, 100만건을 넘는 게시판은 없으리라 생각됩니다.
큰 사이트는 당연히 커스터마이징을 해야겠지요.
작은 규모의 사이트에서는 10만, 100만건을 넘는 게시판은 없으리라 생각됩니다.
큰 사이트는 당연히 커스터마이징을 해야겠지요.
제가 개발하는 솔루션이나 독립 프로그램에서 사용하는 방식입니다.
독립 테이블과 통합 테이블을 비교해보니 거의 수 배 이상 차이가 나더군요.
아시겠지만, 특히 통합 검색등에서 문제가 많이 나타나고 있습니다.
저 같은 경우,
마스터보드 테이블을 1개두고 여기는 게시판 환경설정값들에 대한 정보만 갖고 있고,
세컨보드개념으로 실제 게시판자료를 저장하는 테이블을 사용합니다.
물론 마스터보드에 대한 조인키값만 따로 두지요..
약 100만건 + mysql v4.1x 이상으로 풀텍스트인덱싱을 걸어서 테스트후 사용중인데 대략 0.05 ~ 0.7 정도(max) 나오고 있습니다.(마지막 테스트가 영화db 통합검색 작업시에 약 120만건 정도..)
오래전부터 건의드리고 싶었는데 구조가 너무 달라 건의를 못드렸었습니다만..
이번에 차기버젼에 적용할 예정이라니 개인적으로 상당히 반갑습니다..^^;
포털개념이나 레코드가 상당히 많은 사이트들을 그누보드와 영카트로 작업시 문제가 있어 상당히 고민을 했었는데..ㅡㅡ;
한 가지 더 건의를 드리자면,(이미 기획/설계에 포함되었으리라 생각하지만)
게시판별 디렉토리 생성방식은 현재 g4 처럼 독립디렉토리를 사용하는게 맞다고 보입니다.(달리 방법도 없으니...^^;)
기대하겠습니다.
* 참, 테스트링크에서 검색에 대한 홀/쌍따옴표와 특수기호에 대한 배려가 없는것 같습니다만.. 아직 개발중이라 그런것으로 생각됩니다.
예)
그 누 보 드 '
그 누 보 드 "
그 누 보 드()
그 누 보 드 and ()=''
기타 여러형식..
독립 테이블과 통합 테이블을 비교해보니 거의 수 배 이상 차이가 나더군요.
아시겠지만, 특히 통합 검색등에서 문제가 많이 나타나고 있습니다.
저 같은 경우,
마스터보드 테이블을 1개두고 여기는 게시판 환경설정값들에 대한 정보만 갖고 있고,
세컨보드개념으로 실제 게시판자료를 저장하는 테이블을 사용합니다.
물론 마스터보드에 대한 조인키값만 따로 두지요..
약 100만건 + mysql v4.1x 이상으로 풀텍스트인덱싱을 걸어서 테스트후 사용중인데 대략 0.05 ~ 0.7 정도(max) 나오고 있습니다.(마지막 테스트가 영화db 통합검색 작업시에 약 120만건 정도..)
오래전부터 건의드리고 싶었는데 구조가 너무 달라 건의를 못드렸었습니다만..
이번에 차기버젼에 적용할 예정이라니 개인적으로 상당히 반갑습니다..^^;
포털개념이나 레코드가 상당히 많은 사이트들을 그누보드와 영카트로 작업시 문제가 있어 상당히 고민을 했었는데..ㅡㅡ;
한 가지 더 건의를 드리자면,(이미 기획/설계에 포함되었으리라 생각하지만)
게시판별 디렉토리 생성방식은 현재 g4 처럼 독립디렉토리를 사용하는게 맞다고 보입니다.(달리 방법도 없으니...^^;)
기대하겠습니다.
* 참, 테스트링크에서 검색에 대한 홀/쌍따옴표와 특수기호에 대한 배려가 없는것 같습니다만.. 아직 개발중이라 그런것으로 생각됩니다.
예)
그 누 보 드 '
그 누 보 드 "
그 누 보 드()
그 누 보 드 and ()=''
기타 여러형식..

fulltext 인덱스에 대해
utf8에서만 가능하다.
my.cnf에 set-variable=ft_min_word_len=2 과 같이 설정해야 한글 두글자 이상 검색이 가능하다. (기본은 4글자로 알고 있습니다.)
공백을 구분하여 검색하므로 "그누"로 검색하면 "그누보드"는 검색이 안된다.
대충 이렇게 알고 있는데 맞는지요?
utf8에서만 가능하다.
my.cnf에 set-variable=ft_min_word_len=2 과 같이 설정해야 한글 두글자 이상 검색이 가능하다. (기본은 4글자로 알고 있습니다.)
공백을 구분하여 검색하므로 "그누"로 검색하면 "그누보드"는 검색이 안된다.
대충 이렇게 알고 있는데 맞는지요?

http://dev.mysql.com/doc/refman/4.1/en/fulltext-restrictions.html
보니까 ucs2가 안 된다고 하네요.
보니까 ucs2가 안 된다고 하네요.
네. utf-8 에서만 가능합니다. 영문의 경우는 v3.2x 부터 가능하나, 한글은 v4.1x 부터 가능하죠. (utf-8 버젼도 차기버젼에서 별도로 분리할 예정이시겠죠? 현재는utf-8 버젼만 따로 분리하여 한글 풀텍스트인덱스를 지원해 주는것도 괜찮은 방법 같습니다.)
그리고 말씀처럼 word_len 을 조정하면 2글자 이상 가능합니다.
[mysqld]
ft_min_word_len=2
[myisamchk]
ft_min_word_len=2
ft_max_word_len = ; 이 부분은 적절한 값이면 되겠죠
공백구분 검색에 관해서는 트릭이 있었던 것으로 기억합니다.
(작업했던게 재작년인가? mysql v4.1x 가 처음 나왔을때 utf-8 에서 풀텍스트인덱스를 지원한다고 해서 작업을 했었습니다.)
utf-8 에서 한글검색시 한글깨짐 문제는,
encodeURI 로 넘겨주면 php에서는 그냥 파싱이 되므로 상관이 없을 것이고..
그리고 말씀처럼 word_len 을 조정하면 2글자 이상 가능합니다.
[mysqld]
ft_min_word_len=2
[myisamchk]
ft_min_word_len=2
ft_max_word_len = ; 이 부분은 적절한 값이면 되겠죠
공백구분 검색에 관해서는 트릭이 있었던 것으로 기억합니다.
(작업했던게 재작년인가? mysql v4.1x 가 처음 나왔을때 utf-8 에서 풀텍스트인덱스를 지원한다고 해서 작업을 했었습니다.)
utf-8 에서 한글검색시 한글깨짐 문제는,
encodeURI 로 넘겨주면 php에서는 그냥 파싱이 되므로 상관이 없을 것이고..

지금의 검색은 위와 같이 시스템의 영향을 받는 방법이 아닌
변형된(?) 형태소 분석 방법을 취하고 있습니다.
가령 "그누보드" 를 예를 들어
그누보드, 누보드, 보드, 드 와 같이 키워드 입력이 되므로
풀텍스트 인덱스에서 지원하지 않는 키워드를 검색할 수 있고, 또한 euc-kr 도 가능하게 되어 있습니다.
인덱스 테이블을 얼마나 최적화 하느냐가 문제네요.
변형된(?) 형태소 분석 방법을 취하고 있습니다.
가령 "그누보드" 를 예를 들어
그누보드, 누보드, 보드, 드 와 같이 키워드 입력이 되므로
풀텍스트 인덱스에서 지원하지 않는 키워드를 검색할 수 있고, 또한 euc-kr 도 가능하게 되어 있습니다.
인덱스 테이블을 얼마나 최적화 하느냐가 문제네요.
아 형태소 검색방법이라면 키워드검색에 의한 적절한 매치가 되겠군요.
효율성도 풀텍스트 인덱스 검색보다 좀 더 뛰어날 수 있겠습니다만..
말씀대로 문제는 인덱싱이 될 것 같습니다. ^^;
테이블 설계가 끝나고 베타 오픈전에 최종 설계와 코딩을 볼 수 있다면 저도 로컬용 작업서버에서 검색에 대한 테스트가 가능할 것 같습니다.
10원들이 모여서 100원, 1000원이 되는 것이니..
생각지 못한 부분의 누락이나 효율성 증대를 꾀할수도 있으리라 봅니다.
(제 생각이니 개념치 마십시오.)
효율성도 풀텍스트 인덱스 검색보다 좀 더 뛰어날 수 있겠습니다만..
말씀대로 문제는 인덱싱이 될 것 같습니다. ^^;
테이블 설계가 끝나고 베타 오픈전에 최종 설계와 코딩을 볼 수 있다면 저도 로컬용 작업서버에서 검색에 대한 테스트가 가능할 것 같습니다.
10원들이 모여서 100원, 1000원이 되는 것이니..
생각지 못한 부분의 누락이나 효율성 증대를 꾀할수도 있으리라 봅니다.
(제 생각이니 개념치 마십시오.)

좀 자세한 소개를 부탁드립니다.
간략한 ERD도 부탁드립니다.
간략한 ERD도 부탁드립니다.

네 키워드 검색입니다. 누락되는 키워드가 없도록 하다보니 테이블이 커지네요.

겁나 빨라용~


서버에 사이트 캐슁이 설정되어있는모양입니다 (당연한얘기지만)
그래서 검색어를 매번 바꿔가면서 검색해야 제대로된 속도를 알수가 있습니다..
빠를때 1.4~1.7초
느릴때 3.4초까지 가네요.
내용검색을 하는거라면 게시글 숫자보단 글의 내용에 큰 영향을 받습니다.
글 내용이 많은걸 위주로 하셔야 신뢰성있는 테스트 결과가 나올수있습니다.
소팅 종류와 인덱싱 방법에 따라도 큰 차이가 있습니다.
찾는검색어가 글의 앞쪽에있는지 중반에있는지 후반에 있는지에따른 상태별로도
체크를 하셔야합니다. 확연한 차이가 납니다. (한단어로 계속 검색속도체크하는건 안된단 뜻도되네요)
현재 클릭시 그 누 보 드 이렇게 스페이스를 기준으로하는 and 검색으로 추측되는데요.
같은단어말고 단어를 변경해가면서 해보시기 바랍니다.
(사실 웬반한 게시판도 5만건 넘기는 어려우니 큰차이야 없겠지만 참고하시라고.. ㅎㅎ)
그래서 검색어를 매번 바꿔가면서 검색해야 제대로된 속도를 알수가 있습니다..
빠를때 1.4~1.7초
느릴때 3.4초까지 가네요.
내용검색을 하는거라면 게시글 숫자보단 글의 내용에 큰 영향을 받습니다.
글 내용이 많은걸 위주로 하셔야 신뢰성있는 테스트 결과가 나올수있습니다.
소팅 종류와 인덱싱 방법에 따라도 큰 차이가 있습니다.
찾는검색어가 글의 앞쪽에있는지 중반에있는지 후반에 있는지에따른 상태별로도
체크를 하셔야합니다. 확연한 차이가 납니다. (한단어로 계속 검색속도체크하는건 안된단 뜻도되네요)
현재 클릭시 그 누 보 드 이렇게 스페이스를 기준으로하는 and 검색으로 추측되는데요.
같은단어말고 단어를 변경해가면서 해보시기 바랍니다.
(사실 웬반한 게시판도 5만건 넘기는 어려우니 큰차이야 없겠지만 참고하시라고.. ㅎㅎ)

검색 속도는 logN에 비례하니까 게시물 수는 별로 영향을 안 줍니다,
인덱스가 잘 되어 있다는 한에서요.
인덱스가 잘 되어 있다는 한에서요.

그나저나 테이블을 통합한다니 좋습니다.
이렇게 되면 더 다양한 기능은 더 쉽게 구현할 수 있으리라 생각합니다.
이렇게 되면 더 다양한 기능은 더 쉽게 구현할 수 있으리라 생각합니다.