게시판 검색시에 예전에 count(*)를

DB상에서 직접 선택해오는것이 느려지는 원인이 된다고

지속적으로 주변에서 심한 압박을 준 관계로...^^;

전 일단 DB에서 검색결과 자료만 빼오고

그 자료를 전달받은 프로그램쪽에서

몇개의 row가 있는지를 count 하는 방식으로 처리한 적은 있습니다.

검색시라...검색어가 고정되어 있지 않을테니...

통계 자료로는 해결하기가 좀 어렵지 않을까 생각이 드네요.

물론 트리거를 걸면 됩니다.

하지만.. 트리거를 거는 것 보다 차라리

테이블 생성시 초기값을 1 row 넣는것이 더 좋지 않나 생각해봅니다.

왜냐하면.. 트리거나 등등으로 하면

매번 자료가 insert 될떄마다 count 컬럼의 값을 가져와야 하는데

이런 불필요한 동작을 매번 해야 하기 때문이지요.

count 와 같은 특별한 경우 처음의 하나의 row 가 추가가 되고 나면

무조건(자료가 모두 삭제된다 하더라도) 통계테이블에 1 row 는 있끼 때문에 그래서 차라리 초기값으로 0을 주고

매번 채크하는 불필요한 동작을 없애는게 더 좋지 않나 하네요

아, 트리거 얘기는 말이죠.

테이블 생성시 초기값을 넣어두면 되는데,

혹시 나중에 db 초기화를 하거나 해서

다른 사람이 다시 셋팅할때 혼란이 올까 해서

생각했던 것이구요..

물론 매번 카운트해서 있는지 없는지 체크 해야 하는게

부담된다는건 생각하고 있었습니다 ^^

그냥 초기값 넣어줘야 할것 같군요 :-)

자료 검색 결과의 총 갯수를 구하는 부분은

두가지 입니다.

전통적으로 일단 count(*) 쿼리로 전체 검색결과를 구하고,

다음 limit offset 쿼리로 그 가운데, 특정 부분을 가져오는 방법.

결국 두번의 똑 같은 쿼리 해야하지요.

다른 한 방법은 이곳 DSN 게시판 처럼, count(*) 부분을 생략하고, 일단 모든 검색 결과를 클라이언트로 가져와서 클라이언트에서 특정부분만 보여주는 방법입니다.

경험상으로는 검색결과가 수백건 미만이면 둘의 차이가 나질 않더군요. 오히려 첫번째 방법이 부하가 더 많습디다.

-----------

이것과 다른 출발로, 고급 검색엔진의 검색결과 캐쉬 처리 방식을 도입하는 것도 좋은 방법 중 하나입니다.

이는 알고리즘이 조금 복잡해지는데, DSN에서 도입하려다 개발기간이 너무 길어 투자한 시간보다 얻는 이익이 없어 포기했었습니다.

개요만 설명하면,

검색 대상의 원소스 마지막 변경 시간을 가지고 있고,

검색어 캐시 정보 테이블이 있고, 그곳에는 해당 검색어와 그 검색어를 사용한 마지막 변경 시간을 가지고 있고, 이 두개의 마지막 시간이 서로 틀리면,(원소스 자료가 변경이 되었다면) 기존 캐시 검색 결과를 파기하고 다시 원 소스에서 검색하는 방식입니다. 그리고 그 결과를 캐쉬테이블에 두고.

즉, 잦은 자료 변경이 일어나지 않는다면, 윗 방식의 검색 캐시 도입은 디비 서버 부하를 줄이는데 크게 기여할 것입니다. 이때 캐시 정보는 당연히 기반 RDBMS와 독립적이어야합니다. 지금 생각하고 있는 것은 sqlite 입니다. 이놈 쓰는 딱일 듯 싶은데, 그리고 그 sqlite 파일은 웹서버 쪽에 두고.

아무튼 안해봐서 이익이 클지 손실이 클지는 모르겠지만.