fulltext 검색 사용후기의 후기
결과물
그누보드 스킨
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EA%B7%B8%EB%88%84%EB%B3%B4%EB%93%9C+%EC%8A%A4%ED%82%A8&sop=and&x=30&y=14
match(wr_subject,wr_content) 와 같은 구문은 속도가 현저히 느려서 사용을 하지 못합니다.
그러므로 게시물은 wr_subject + wr_content 가 합쳐져서 fulltext 필드에 저장됩니다.
앞으로는 제목 따로 내용 따로 검색이 되지는 않습니다.
이것이 단점이라면 속도는 포기하셔야 합니다.<div class='small'>[이 게시물은 관리자님에 의해 2011-10-31 17:27:00 MySQL에서 이동 됨]</div>
그누보드 스킨
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EA%B7%B8%EB%88%84%EB%B3%B4%EB%93%9C+%EC%8A%A4%ED%82%A8&sop=and&x=30&y=14
match(wr_subject,wr_content) 와 같은 구문은 속도가 현저히 느려서 사용을 하지 못합니다.
그러므로 게시물은 wr_subject + wr_content 가 합쳐져서 fulltext 필드에 저장됩니다.
앞으로는 제목 따로 내용 따로 검색이 되지는 않습니다.
이것이 단점이라면 속도는 포기하셔야 합니다.<div class='small'>[이 게시물은 관리자님에 의해 2011-10-31 17:27:00 MySQL에서 이동 됨]</div>
댓글 12개
14년 전
다음 다음도 필요없어졌군요. 대단하셔요.
피눈물의 결과.. 리자님을 찬양하세! ^^
피눈물의 결과.. 리자님을 찬양하세! ^^
Dream
14년 전
ㅎㅎㅎ
14년 전
다음 다음도 필요없어진건 아닌듯..ㅠㅠ
14년 전
저는 금번 리자님의 작업을 통해
http://tong2.sir.co.kr 에서 보여지는 것처럼 [다음] [다음] ... 이 필요없고 + 속도도 짱짱하게
http://sir.co.kr 에도 그대로 적용된 건줄 알았어요.
근데, 하나는 포기해야 되는게 맞군요. 물론 속도를 포기하면 안되겠네요.
여튼 찬양은 계속 하겠습니다! ^^
http://tong2.sir.co.kr 에서 보여지는 것처럼 [다음] [다음] ... 이 필요없고 + 속도도 짱짱하게
http://sir.co.kr 에도 그대로 적용된 건줄 알았어요.
근데, 하나는 포기해야 되는게 맞군요. 물론 속도를 포기하면 안되겠네요.
여튼 찬양은 계속 하겠습니다! ^^
14년 전
FULLTEXT 의 기능이 도입된 버전에 대한 내용이 있어 퍼옵니다.
기능 : 버전
기본적인 FULLTEXT 검색 : 3.23.23
인자 구성 기능 : 4.0.0
BOOLEAN 검색 : 4.0.1
구문 검색 : 4.0.2
기능 : 버전
기본적인 FULLTEXT 검색 : 3.23.23
인자 구성 기능 : 4.0.0
BOOLEAN 검색 : 4.0.1
구문 검색 : 4.0.2
sjsjin
14년 전
수고 하셨습니다.
오래전부터 제가 줄곧 건의한게 차후버젼엔 반영될듯...^^;
그러나 적으신 내용중 아래 내용은 문제가 좀 있는 것 같습니다.
# match(wr_subject,wr_content) 와 같은 구문은 속도가 현저히 느려서 사용을 하지 못합니다.
이는 잘못알고 계신듯 합니다.
제가 500만건까지 풀텍스트로 잡아서 오래전부터(4.1처음 나올때부터)작업해 봤지만 속도가 현저히 느린것은 경험하지 못했습니다.
풀텍스트 인덱스도 규칙이 있는데 규칙대로만 하는경우라면 전혀 문제가 없습니다.
예를 들어,
1. 풀텍스트 인덱스가 wr_subject, wr_content 로 잡힌경우는 쿼리에 이 순서로 쿼리가 가면 됩니다.
2. wr_subject 만 검색하는 경우는 풀텍스트 인덱스가 wr_subject 용으로 별도로 하나 있어야 합니다.
마찬가지로 wr_content 로만 하는 경우도 그렇습니다.
3. 만약 위 2개 컬럼외에 다른 컬럼도 묶어서 풀텍스트로 검색할경우는 역시 해당 컬럼과 순서가 그대로 포함된 풀텍스트 인덱스가 별도로 있어야 합니다.
# 마지막으로 엔진이 innodb 라면 풀텍스트 인덱스가 적용되지 않습니다.
이런경우는 게시판이나 쇼핑몰의 경우 레코드가 집중되고 검색을 많이 사용하는 테이블은 myisam 으로 잡아서 풀텍스트를 사용하고 나머지 테이블은 innodb 로 잡아서 처리하면 됩니다.
# 위와 더불어 서버사양이 받쳐준다면 금상첨화가 됩니다.
이상입니다.
오래전부터 제가 줄곧 건의한게 차후버젼엔 반영될듯...^^;
그러나 적으신 내용중 아래 내용은 문제가 좀 있는 것 같습니다.
# match(wr_subject,wr_content) 와 같은 구문은 속도가 현저히 느려서 사용을 하지 못합니다.
이는 잘못알고 계신듯 합니다.
제가 500만건까지 풀텍스트로 잡아서 오래전부터(4.1처음 나올때부터)작업해 봤지만 속도가 현저히 느린것은 경험하지 못했습니다.
풀텍스트 인덱스도 규칙이 있는데 규칙대로만 하는경우라면 전혀 문제가 없습니다.
예를 들어,
1. 풀텍스트 인덱스가 wr_subject, wr_content 로 잡힌경우는 쿼리에 이 순서로 쿼리가 가면 됩니다.
2. wr_subject 만 검색하는 경우는 풀텍스트 인덱스가 wr_subject 용으로 별도로 하나 있어야 합니다.
마찬가지로 wr_content 로만 하는 경우도 그렇습니다.
3. 만약 위 2개 컬럼외에 다른 컬럼도 묶어서 풀텍스트로 검색할경우는 역시 해당 컬럼과 순서가 그대로 포함된 풀텍스트 인덱스가 별도로 있어야 합니다.
# 마지막으로 엔진이 innodb 라면 풀텍스트 인덱스가 적용되지 않습니다.
이런경우는 게시판이나 쇼핑몰의 경우 레코드가 집중되고 검색을 많이 사용하는 테이블은 myisam 으로 잡아서 풀텍스트를 사용하고 나머지 테이블은 innodb 로 잡아서 처리하면 됩니다.
# 위와 더불어 서버사양이 받쳐준다면 금상첨화가 됩니다.
이상입니다.
14년 전
제가 테스트 한 내용을 아래 링크로 비교 해보았습니다.
SQL_NO_CACHE 옵션을 사용하여 캐시가 되지 않도록 하였습니다.
검색어 : 그누보드 다운로드
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EA%B7%B8%EB%88%84%EB%B3%B4%EB%93%9C+%EB%8B%A4%EC%9A%B4%EB%A1%9C%EB%93%9C&sop=and
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EA%B7%B8%EB%88%84%EB%B3%B4%EB%93%9C+%EB%8B%A4%EC%9A%B4%EB%A1%9C%EB%93%9C&sop=and&opt=1
&opt=1 이 붙으면 match(wr_subject,wr_content) 로 그렇지 않으면 match(wr_fulltext) 를 사용합니다.
wr_subject
wr_content
wr_fulltext
는 모두 fulltext 로 잡았습니다.
데이터 건수는 코멘트 합쳐서 42만여건 입니다.
wr_fulltext 는 wr_subject 와 wr_content 를 합친것입니다.
SQL_NO_CACHE 옵션을 사용하여 캐시가 되지 않도록 하였습니다.
검색어 : 그누보드 다운로드
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EA%B7%B8%EB%88%84%EB%B3%B4%EB%93%9C+%EB%8B%A4%EC%9A%B4%EB%A1%9C%EB%93%9C&sop=and
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EA%B7%B8%EB%88%84%EB%B3%B4%EB%93%9C+%EB%8B%A4%EC%9A%B4%EB%A1%9C%EB%93%9C&sop=and&opt=1
&opt=1 이 붙으면 match(wr_subject,wr_content) 로 그렇지 않으면 match(wr_fulltext) 를 사용합니다.
wr_subject
wr_content
wr_fulltext
는 모두 fulltext 로 잡았습니다.
데이터 건수는 코멘트 합쳐서 42만여건 입니다.
wr_fulltext 는 wr_subject 와 wr_content 를 합친것입니다.
sjsjin
14년 전
wr_fulltext 컬럼을 wr_subject, wr_content 의 내용을 여기에 다 집어넣었다는 뜻인지요?
위 링크이 결과를 볼 때 풀텍스트가 안걸려 있는것 같습니다만..
별도의 컬럼을 사용하는것은 불필요 합니다.
match(wr_subject,wr_content) 를 사용한다면 해당 테이블 인덱스에 wr_subject,wr_content 를 1개의 풀텍스트 인덱스로 잡아주고,
match(wr_subject 나 wr_content)를 사용한다면 이 역시 개별적으로 테이블 인덱스에 해당 컬럼을 풀텍스트 인덱스로 잡아주면 됩니다.
그리고 노캐시로 검색을 하더라도 현재 결과는 생각외의 결과입니다.(처리시간)
해당 테이블 엔진이 myisam 이 맞는지도 확인이 필요하고(innodb는 불가)...
# 위의 세부 내용들을 적어주신다면 정보공유와 문제점 해결이 좀 더 원활할것 같습니다.
위 링크이 결과를 볼 때 풀텍스트가 안걸려 있는것 같습니다만..
별도의 컬럼을 사용하는것은 불필요 합니다.
match(wr_subject,wr_content) 를 사용한다면 해당 테이블 인덱스에 wr_subject,wr_content 를 1개의 풀텍스트 인덱스로 잡아주고,
match(wr_subject 나 wr_content)를 사용한다면 이 역시 개별적으로 테이블 인덱스에 해당 컬럼을 풀텍스트 인덱스로 잡아주면 됩니다.
그리고 노캐시로 검색을 하더라도 현재 결과는 생각외의 결과입니다.(처리시간)
해당 테이블 엔진이 myisam 이 맞는지도 확인이 필요하고(innodb는 불가)...
# 위의 세부 내용들을 적어주신다면 정보공유와 문제점 해결이 좀 더 원활할것 같습니다.
14년 전
아~ 제가 인덱스를 잘못 잡았네요.
wr_subject 와 wr_content 를 따로 잡은것을 같이 잡아서 실행하니 wr_fulltext 보다 속도가 빨랐습니다. ^^
속도문제로 따지자면 이렇게 사용하는것이 맞는데 문제는 ft_min_word_len 에 설정된 값이 보통 4 이므로 이것을 변경할 수 없는 경우는 3글자 이하의 단어에 대해 검색이 어려운 것으로 알고 있습니다.
match(wr_subject,wr_content)
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EC%84%B8%ED%8C%85+%EC%99%84%EB%A3%8C&sop=and&opt=1
match(wr_fulltext)
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EC%84%B8%ED%8C%85+%EC%99%84%EB%A3%8C&sop=and&x=25&y=12
바로 이것을 구현하기 위하여 사용기를 올리게 되었습니다.
wr_subject 와 wr_content 를 따로 잡은것을 같이 잡아서 실행하니 wr_fulltext 보다 속도가 빨랐습니다. ^^
속도문제로 따지자면 이렇게 사용하는것이 맞는데 문제는 ft_min_word_len 에 설정된 값이 보통 4 이므로 이것을 변경할 수 없는 경우는 3글자 이하의 단어에 대해 검색이 어려운 것으로 알고 있습니다.
match(wr_subject,wr_content)
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EC%84%B8%ED%8C%85+%EC%99%84%EB%A3%8C&sop=and&opt=1
match(wr_fulltext)
http://tong2.sir.co.kr/bbs/board.php?bo_table=cm_free&sca=&sfl=wr_subject%7C%7Cwr_content&stx=%EC%84%B8%ED%8C%85+%EC%99%84%EB%A3%8C&sop=and&x=25&y=12
바로 이것을 구현하기 위하여 사용기를 올리게 되었습니다.
sjsjin
14년 전
네. 무슨뜻인지 알겠습니다.
호스팅의 경우 서버설정에서 ft_min_word_len = 보통 3으로 설정되어 있는곳이 많더군요.
이는 말씀대로 바이트를 말하는게 아니라 완성된글자수를 말하므로 3글자 미만은 풀텍스트를 타지 못하게 된다는 얘기므로,
말씀대로의 현상이 나타나게되어 문제가 생길 수 있습니다.
서버호스팅이나 코-로케이션의 경우야 문제가 없지만,
일반호스팅의 경우, 저는 서버설정사항에 따라 풀텍스트를 타면 풀텍스트로 날리고 아니면 레코드수가 좀 되는 사이트 작업인경우는 instr 로 처리하고 아니면 like %검색어% 로 처리합니다.
# 그리고 말씀대로 ft_min_word_len = 3 인경우 2글자로 검색시에 위와같은 방식으로 처리가 가능합니다만..
만약 검색어가 단지 '스킨' 이라면?? 위 방법대로는 기대가 어려울것 같습니다.
# 국내호스팅사들도 풀텍스트에 대한 인식이 많이 달라져있으므로 ft_min_word_len = 2 정도로 해주는곳들도 차츰 늘어나리라 생각하고 있습니다.
호스팅의 경우 서버설정에서 ft_min_word_len = 보통 3으로 설정되어 있는곳이 많더군요.
이는 말씀대로 바이트를 말하는게 아니라 완성된글자수를 말하므로 3글자 미만은 풀텍스트를 타지 못하게 된다는 얘기므로,
말씀대로의 현상이 나타나게되어 문제가 생길 수 있습니다.
서버호스팅이나 코-로케이션의 경우야 문제가 없지만,
일반호스팅의 경우, 저는 서버설정사항에 따라 풀텍스트를 타면 풀텍스트로 날리고 아니면 레코드수가 좀 되는 사이트 작업인경우는 instr 로 처리하고 아니면 like %검색어% 로 처리합니다.
# 그리고 말씀대로 ft_min_word_len = 3 인경우 2글자로 검색시에 위와같은 방식으로 처리가 가능합니다만..
만약 검색어가 단지 '스킨' 이라면?? 위 방법대로는 기대가 어려울것 같습니다.
# 국내호스팅사들도 풀텍스트에 대한 인식이 많이 달라져있으므로 ft_min_word_len = 2 정도로 해주는곳들도 차츰 늘어나리라 생각하고 있습니다.
14년 전
"만약 검색어가 단지 '스킨' 이라면?? 위 방법대로는 기대가 어려울것 같습니다."
이것을 해결하기 위해 사용기를 올린것 입니다.
ft_min_word_len 설정에 관계없이 한글 1글자도 fulltext 검색이 가능해 졌습니다.
이것을 해결하기 위해 사용기를 올린것 입니다.
ft_min_word_len 설정에 관계없이 한글 1글자도 fulltext 검색이 가능해 졌습니다.
sjsjin
14년 전
네. 맞습니다.
그냥 쓰다보니 헷갈렸던듯..;;
그냥 쓰다보니 헷갈렸던듯..;;
댓글 작성
댓글을 작성하시려면 로그인이 필요합니다.
로그인하기