bigserial 이라는 형식이 있습니다. 8바이트 int 형식의 시리얼입니다.

최대값은 9223372036854775807 이군요 -_-;

두번째 질문은 확답은 못드리겠구요..

10k 이상이라면 text 형식 보다는.. -_-;;;;;

흠.. 여튼 꼭 인덱스를 원하신다면 풀텍스트 인덱스를 고려해보심이 좋을것 같습니다.

원하시는 기능을 구현하게 해주는 일반적인 인덱스 방식은 BTREE 밖에 없습니다. 이를 응용한 풀텍스트 인덱스나 아니면 소스트리의 contrib 의 풀텍스트 인덱스를 참조하시면 되겠습니다..

게시판 본문을 인덱스를 잡고,

정녕코

where xxx like 'x%' 형태로 인덱스를 사용해야한다면,

create index table_contents_i on table (substr(contents, 1, 100))

이런식으로 부분 인덱스를 만드십시오.

그런데,

제가 보기에는

본문의 중간에 있는 내용으로 검색을 하려면, 결국 xxx like '%x%' 형태로 갈 수 밖에 없을터인데, 그러면 만들어놓은 인덱스를 사용하지 않을 것입니다.

그렇다면,

차라리 테이블 구조를 약간 바꾸어서

본문용 칼럼과 본문의 인덱스용 칼럼을 따로 두고 인덱스용 칼럼에 인덱스를 만드는 것이 더 타당하지 않을까싶네요.

근데, 게시판 본문을 정말로 like 'x%' 같이 검색하실 요량이십니까?

답변 감사드립니다.

일단 본문이 10k 인 것에 대해서 그 본문컬럼을 index 로 걸고 싶은 생각은 추호도 없습니다. ^^:

그냥 이렇게 통쨰로도 해보고 full text index 도 해보고

또는 부분 인덱스도 해보고 여러가지를 해 보았습니다.

그런 테스트 와중에 나온것이라서 제가 알기로도

btree 외엔 성격이 안 맞는거 만일 정말 그렇게 본문을 인덱스 걸려는

가정하에서 질문해 본 것입나다 ^^;

일단 대충의 자료 테스트를 위해서

여러가지 몇가지 테스트를 해 보았습니다.

원래 게시물이라는것이 하루 아침에 몇십만건 생기는것은 아니라서

full text index 를 처음부터 하면 어떻게 될지는 모르겠지만

기존 자료를 한꺼번에 넣고 할려니..

대충 내용이 있는 자료를 이용하여 입력하는데

6000 게시물에 대하여 full text index 인 경우 fti 의 row 가 무리 100 만을 넘어서더군요

6000 개 입력하는데도 너무나도 엄청난 시간이 걸려서.. 자료입력을 포기하고

대신 full text index 는 아니지만 본문을 512 주위로 빈칸을 이용하여

잘라 넣어 테스트를 해 보았습니다.

아무래도 full text index 보다는 효율이 떨어질지도 모르겠네요..

(근데 사실 그렇게 늦을거라곤 생각지 않습니다. fti 의 row 가 많으면 많을수록 본문내용이 길면 길수록 검색이 많은 row 가 검색되니깐.. 적당한 길이라면 적당한 row 만큼 나오니 검색은 빠를지 몰라도 조인이라던지 주위의 작업을통해 최종적으로 나오는 결과물은 적당한 길이로 자른것이 오히려 더 빠른경우가 허다하더군요..)

이렇게 하니 fti 의 갯수는 main 의 갯수의 대략 3 ~ 5 배의 갯수가 나오더군요..

아뭏튼 자료입력에 너무많은 시간이 걸려 모든걸 테스트 해볼수는 없었으나,

대충 지금은 그럭저럭 만족은 하고 있습니다.

(게시물 10만건 중 검색된 자료가 2만건 정도 나오는 검색에서도(본문은 대부분의 게시물에서 2k 이상을 차지하는 자료입니다.)

평균 1 초 수준에서 끝나니깐요..

오히려 검색하지 않고 전체 리스트를 보여주는게 시간이 더 걸리고 있는 상황입니다. ---;;

메인게시물에서 리스트에서 보여줄 항목들(id, num, subject, hit 등등) 을 따로 뺴내고, 제목과 본문은 512 앞뒤로 짤라 fti 에 따로 저장하고

리스트는 제목테이블에서 보여주며 검색은 fti 로 했습니다.

조인시 distinct 를 사용하고, 제목테이블에서 소트한후

offset 과 limit 를 적용하여 temp table 에 저장하고

tmp 에서 desc sort 후 계산하여 출력하는 방식을 채택했습니다.

전체 리스트는 제목리스트를 소트한후

전체페이지에서 페이지번호가 반 이하일경우는 앞부분에 offset 을 주고 반이후인경우에는 뒷부분에 offset 을 주어 limit 만큼 임시테이블에 저장하니

1페이지나 중간페이지나 5000 페이지가 넘어가는 페이지일지라도

대충 비슷한 속도를 가지네요 (처음부터만 옵셋을 가지면 페이지수가 많을 경우 뒤로 가면갈수록 속도저하가 심해지는데 이런식으로 하니

거의 전페이지가 속도가 비슷하게 나오는군요..

흐으음.. full text index 와 intersect 다시 한번 더 시도해봐야 겠네요..

fti_table intersect fti_table 은 생각도 못했네요..

그나저나 자료입력시간이 넘 오래걸려서 어캐 입력한다냐..아구..

쿼리 테스트를 위한 전체 자료 입력이라면, 당연히 python 같은 놈으로 일단 full text 자료를 만들고, fti 테이블에 copy 구문으로 일괄 입력한 다음에 인덱스를 만들어야지요. 그래야 쉽게 작업하실 수 있습니다.

그 다음 모든 것이 흡족하게 움직이면, 트리거를 하나 만드셔서 원문의 자료가 추가/수정/삭제 될 경우 fti 테이블의 자료를 변경하도록 해야겠지요.

전형적인 예제가 이곳 Files 자료실에 있는 full text index 관련 자료들입니다.