drupal 검색 시스템 and 한글 검색... kldp 건의 사항...
전 kldp 자주 오는 사용자는 아닌데,
kldp가 drupal로 전환해서 저도 제 사이트(http://gagax.com) 별 생각 없이(kldp가 선택했으면 좋겠지라는 생각에) drupal로 사이트 전체를 전환한 뒤 후회한 적이 종종 있었는데 -_-;
다시 back하기는 너무 어렵고 그냥 사용하고 있습니다.
(제 사이트 제일 특이한 기능은 socket 연결되는 실시간 flash 채팅방과 연동했습니다 ^^)
Drupal 검색은 내부적으로 = 검색을 사용해서 "태그는" 을 "태그"로 검색했을 때 나오지 않고, kldp도 그런 부족한 점을 느껴 google search로 바꾼 것 같은데,
내부 검색을 = 에서 like 로 바꾸면 "태그"(또는 "태그*")로 검색해도 "태그는"이 검색되게 할 수 있습니다.
MySQL의 경우 like "단어%" 검색시 index 사용하기 때문에 테스트해본 결과(제 소규모 사이트에선) 부하가 별로 안 늘어나는 것 같습니다. 지금은 단어* 형태로 제공하고 검색을 제공하고 있습니다.
KLDP도 그렇게 하면 google search에 의존하는 것을 벗어날 수 있지 않을까 라는 생각을 조심스럽게 건의해봅니다.
한가지 더 고려해볼 수 있는 것이, drupal이 너무 느려서 drupal db 전체를 아예 ram disk에다가 쑤셔 넣어봤는데, 로그인하거나 페이지 왔다갔다하면서 느껴질 정도로 성능이 빨라졌습니다. (그러나 mysql cache기능이 워낙 뛰어나서 실제 테스트해본 결과 select가 많은 db를 ram disk에 넣으면 오히려 느려집니다, drupal은 여기저기 update도 많이 쓰는 듯) 당연히 서버 끄거나 부팅하면 날아가는데, 그건 매 시간, 하루, 일주일, 부팅시마다 마다 crontab을 이용해서 백업하면 됩니다. 제 디비는 작아서 6분마다 백업하다가 서버의 싸구려 sata 하드가 불량나버리는 바람에 -_-; 이제는 그냥 디스크에 저장해서 사용하고 있지만, 몇 가지 부하면에서 중요한 테이블만 옮겨도 성능 향상이 가능성이 있다는 것을 고려해볼만하다고 생각합니다. 원래는 부팅할때 rc.local에서 디비를 자동으로 메모리에 올리고 mysql을 띄우도록 수정했었습니다.
코맨트(댓글) 달 때 제목 끄는 것도 좋은 것 같습니다. 대체로 내용만 쓰고 제목 입력하는 것은 불편하고 중복성 있다고 생각됩니다.
마지막으로 건의하고 싶은 것은, 저도 제 사이트에서 수정한 것인데 이미지 첨부시 이미지 출력되도록하는 것인데, kldp도 특정 스킨은 나오는 것 같던데 -_-; 왜 디폴트 스킨을 그렇게 하지 않았는지 모르겠습니다.
추가: KLDP는 혹시 drupal 5(현재는 rc1 까지 밖에 안나왔음) 로 옮길 계획이 있는지 아시는 분도 있으면 감사... Drupal 5 나오면 제 사이트도 drupal로 옮겨볼까 생각중입니다. Drupal 5 구성이 저는 4 보다 좋은 것 같습니다.
이런 글 올린다고
이런 글 올린다고 권순선님이 들어줄 가능성은 1%도 안됩니다. 그냥 참고 쓰던지 KLDP 오지 마세요. 그게 속편합니다.
;;
그럼 kldp 말고도 혹시 drupal 사용하는 분에게 도움이 됬으면 ㅋㅋ
drupal 4.x는 소스
drupal 4.x는 소스 차원에서 보자면 phpBB등에 비해 상당히 잘 설계된 것은 분명합니다만, 일부 api나 db부분에서 비효율적으로 작성된 곳이 꽤 많더군요. 대표적인 예로, 모듈을 관리할 경우 모든 모듈을 읽어들이는데, 메모리 부족이 나서 메모리를 늘려 줘야 한다거나, 위에서 지적하셨 듯이 db에 update가 쓸데 없이 많다거나 등등.
drupal 5.x로 넘어가면서 plugin의 meta정보를 따로 *.info라는 텍스트파일로 분리를 해두어 위에서 지적한 문제점을 제거했더군요.
또, drupal 4.x는 테마 만들기가 너무 어렵습니다. 이 부분은 특히 한국인의 입맛에 맞지 않는 부분이 아닌가 하네요.
drupal 5.0이 아직 rc1이므로 이곳에 바로 적용하기는 무리일 것 같습니다만, drupal 5.x는 테마도 많이 지원하는 것 같고, 지금 상황보다 좀 더 나아지지 않을 까 합니다.
kldp의 drupal 자체 검색을
말씀해 주신 방법으로 시도를 했었습니다.
그런데 현재 검색 데이터가 너무 많은 관계로 자원 소모가 매우 큽니다.
알고 계시듯이 검색어를 만들어 내는 방법에 한글과 관련된 처리가 안되고 있어서 데이터가 더 많을거라고 예상됩니다.
위의 테스트 후에 원하는 정도의 속도 개선을 얻을 수 없어서 drupal 자체의 검색 기능을 빼자고 권순선님께 건의하고 대신에 구글 검색을 넣게 되었습니다.
국내에서 오픈소스와 관련해 제일 필요로 하는 기능이 아마도 한글 검색을 위한 기반 라이브러리가 아닐까 생각이 듭니다.
알려주신 ramdisk 방법 대신 현재 대부분의 table들을 innodb로 바꾸고 innodb의 버퍼를 크게 잡아 주었습니다.
최근 db서버를 높은 사양으로 제공받을 수 있게 되어서 추가로 쿼리캐시도 늘려줘 가면서 상태를 모니터(가끔^^) 하고 있습니다.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
검색 부분은
검색 부분은 phpBB쓸때도 비슷한 문제가 있던 것으로 기억합니다.
결국 제대로 된 한글 인덱서가 있어야 하는건가요?
phpBB당시에 잠시
phpBB당시에 잠시 KLDP의 소스를 손본적이 있습니다.
물론 검색관련된 부분이었는데 당시 한글이 검색이 안되어서 이것저것 찾다가 SQL부분을
두부분으로 나누어서 해결했었던 것으로 기억합니다.
(정확하게 기억나질 않네요.)
이부분은 사실 언어적인 차이점 때문에 발생하는 문제라고 생각합니다.
간단하게 말해서 우리나라처럼 조사를 이용하는 나라가 거의 없다고 알고 있습니다.
즉, '은는이가을를...'등을 단어의 뒤에 첨가해서 주어나 목적어를 만드는 언어는 거의 없습니다.
영어도 독어도 불어도 일본어도 중국어도 제가 알고 있는 나라들의 언어를 보면 우리나라
빼고는 조사를 갖는 나라가 없다는 겁니다. 즉, 그들은 단지 단어만을 검색하는 것에 익숙해
있고 왜 한국사용자들은 단어중의 단어를 찾는지를 의아하게 생각할 수도 있고 그 자체가
이상하게 보일 수도 있다는 것이죠.
간단한 단어를 생각해보면 louse(기생충)을 찾는데 lousewort(송이풀)가 나온다면 그들은
얼마나 황당해 할까요?
우리나라에서는 이런 유사성을 띄는 단어가 나오면 그게 아니라고 넘어갈 수 있겠지만
(분명 찾는 단어가 포함되어있으니까...) 그들은 잘못된 결과를 찾았다고 생각할 수도
있다는 겁니다.
결과적으로 찾는 단어가 한국어와 같이 접미사 접두사를 갖는 언어이면 '%단어%'를 포함시키고
like로 찾고 그렇지 않다면 '% 단어 %' like로 찾는 것이 필요한게 아닌가 생각합니다.
사실 phpBB의 경우에도 그렇고 아마 drupal도 그렇다고 생각되는데 한글 인덱스를 갖고 있는게
아니라 본문을 직접 검색하는 형태로 사용하고 있다고 알고 있습니다.
조금 다른 이야기 이지만 google의 경우에는 조금 재미있는 현상이 있습니다. 즉, 유사단어를
찾아주는 부분입니다. '검색'이라는 단어를 찾으면 '찾기'라는 단어까지 같이 찾아주는
서비스더군요. 좀더 유연한 검색이라서 재미있기는 하지만 정작 찾고자하는 단어를 알아서
바꾸어서 찾아버려서 예전보다는 조금더 검색에 힘들기는 합니다. :-)
------------------------------
좋은 하루 되세요.
------------------------------
좋은 하루 되세요.
> 간단한 단어를
> 간단한 단어를 생각해보면 louse(기생충)을 찾는데 lousewort(송이풀)가 나온다면 그들은
> 얼마나 황당해 할까요?
일본어 중국어같은 경우는 띄어쓰기를 전혀 하지 않습니다. 일본어는 약간의 조사가 있으나 떼어내기는 그리 어렵지 않겠으나
역시 띄어쓰기가 없기때문에 위의 지적하신 문제가 발생할 소지가 있지요 :)
또 조사가 붙는 교착어는 상당히 많습니다. 핀란드어가 대표적으로 교착어중 하나지요
drupal 5.x 가 나오고
drupal 5.x 가 나오고 지금 사용하는 추가 모듈들도 5.x 에서 모두 사용할 수 있다면 당연히 옮겨 가야죠. :-) 아마 5.x 나오고 난 후에 바로 이전하기는 어렵겠지만 궁극적으로는 이전될 것입니다. 물론 마음 같아서는 당장 이전하고 싶지만...
그리고 db를 ram에 넣는 문제는 자주 백업을 해 주어야 하는 문제 때문에 적용이 어렵습니다. db 사이즈가 크기 때문에 mysqldump 로 백업을 하면 백업받는 순간에 db가 lock 되기 때문에 그 동안에는 사이트를 이용할 수 없는 상황이 되어 어렵습니다. db가 크기 때문에 mysqldump 시간도 오래 걸리고, 램디스크 사이즈도 커야 하고요.
검색은 like 를 이용하지 않고 그냥 쓰더라도 상당히 부하를 많이 줍니다. 그렇기 때문에 어쩔 수 없이 다른 방법을 채택한 것이고요... 부하가 낮아지고 조사를 제대로 처리하게 되면 built-in 검색을 사용하지 않을 이유가 없습니다. :-)
제목 입력은 어차피 필수가 아니기 때문에 크게 문제가 되지는 않는다고 보고 있습니다.
이미지 썸네일 추가는 편리하긴 하지만 추가해야 할 모듈이 많이 늘어나기 때문에 적용하지 않고 있고요. 이곳이 사진 동호회라면 당연히 추가했겠지만 그렇지 않고, 이미지가 포함된 글도 그다지 많지 않기 때문에 크게 필요성을 느끼지 못하고 있습니다.
http://drupal.kldp.org 에 자주 놀러 오세요... :-)
>그리고 db를 ram에
>그리고 db를 ram에 넣는 문제는 자주 백업을 해 주어야 하는 문제 때문에 적용이 어렵습니다. db 사이즈가 크기 때문에 mysqldump 로 백업을 하면 백업받는 순간에 db가 lock 되기 때문에 그 동안에는 사이트를 이용할 수 없는 상황이 되어 어렵습니다. db가 크기 때문에 mysqldump 시간도 오래 걸리고, 램디스크 사이즈도 커야 하고요.
mysqldump는 부하가 너무 크고 lock이 너무 길게 일어납니다. 저는 mysqlhotcopy로 binary 복사를 합니다. 느낌상 수배~수십배 빠른 듯합니다(전환한 benchmark는 X).
그러나 제가 알기로는 myisam table만 지원됩니다.
>제목 입력은 어차피 필수가 아니기 때문에 크게 문제가 되지는 않는다고 보고 있습니다.
그렇지만 입력이 선택사항인지 잘 모르기 때문에, 상당히 불편해보입니다. 특히 댓글은 사이트에서 가장 많이 쓰이는 기능 중의 하나이고, 소스 수정 없이 설정만 바꿔서 없앨 수 있는 부분이니까, 그냥 없애는 것도 좋을 듯한 것 같습니다.
>검색은 like 를 이용하지 않고 그냥 쓰더라도 상당히 부하를 많이 줍니다.
이건 제가 디비 index에 대해 잘 몰라서 궁금해서 그런데, mysql mysisam(innodb는 잘 모르겠지만 비슷할 듯)은 확실히 like '검색%' 이나 = '검색' 모두 index를 사용하는데, like를 index 사용하게 했을 때(즉 '검색%' O, '%검색%' X) 검색되는 결과 갯수가 더 많아서 느린 것 이외에 = 검색 보다 많이 느립니까?
innodb 를 혼용해서
innodb 를 혼용해서 쓰고 있으므로 mysqlhotcopy는 못 쓰겠네요.
댓글 제목을 보면 특별히 제목을 따로 입력하는 경우는 별로 많이 보지 못했습니다. 사람마다 차이가 있을 듯한데요... 필수 항목은 어차피 * 로 표시되니 대충 알고 있지 않을까요?
검색은 어쨌든 자체적으로 할 경우 부하가 많이 걸린다는 것이 제가 하고 싶은 이야기였습니다. 자세한 내부 구조는 저도 잘 모르니 pass.... :-)
검색과 관련해서는
현재 kldp.org의 데이터가 매우 많은 편입니다.
보통 주제나 코멘트가 많아질수록 검색어는 그보다 더 높은 비율로 많아질 겁니다.
마지막으로 검색기능을 확인하고 있었을때 검색어 테이블에 1000만건 정도가 들어가 있었습니다.
이런 상황에서 인덱스를 이용하고 =검색만 썼을때도 로드나 실행시간(단일 실행시간이 최소 2-3초가 소요되었던걸로 기억합니다.)이 매우 길었습니다.
이때 =검색 대신 like검색(전방일치만)을 쓰더라도 로드의 차이가 크지 않을거라는 생각에 말씀해주신 방법을 썼었지만 미처 생각하지 못했던 부분에서 실행시간이 훨씬 더 길어지는 결과를 초래했습니다.
검색 결과 갯수가 많아지고, 이로인해 내부적으로 사용하는 임시테이블의 크기가 커져서 높은 로드를 야기했습니다.
결과적으로 속도, 만족스런 검색결과중 어느쪽도 잡을 수 없다는 판단하에 구글검색으로 넘어가게 되었습니다.
-- Signature --
青い空大好き。
蒼井ソラもっと好き。
파란 하늘 너무 좋아.
아오이 소라 더좋아.
넵 ^^ 제 작은
넵 ^^
제 작은 사이트에서도 검색이 느리기 때문에... 이해되었습니다.
참고로 임시 테이블 많이 사용하면 메모리 많으면 MySQL 임시 디렉토리를 ram disk로 지정해주면, 성능 향상 보고되는 글들을 여러개 읽어봤습니다.
뭐 백업 문제는
결국 mysql replicate를 이용해서 이중화해주고 replicate된 서버를 이용해서 전용 백업서버를 구성해주어야 한다는것이 흔히 나온 결론적인 답인것으로 기억을 하고 있습니다. -_-a 물론 이게 좋은 방법이긴 합니다만, 비용적인 측면에서 효율적인 방법은 아니지요. ^^ 그래서 수익성 사업이 아닌 곳에 손쉽게 적용하기 쉬운 방법은 아니라고 봅니다. 그래서 램디스크를 손쉽게 사용하지 못하는 것이지도 하지요.