아래 머리 아픈 query란 글을 읽다 몇글자 긁적입니다.
확실히 일반적인 답변이 없는 게시판의 listing은 HINT를 쓴 index_desc면 됩니다만,
답변형 게시판의 경우는 알고리즘이 첨가되어야 하는데,
일반적으로 업데이트형과 업데이트없는 알고리즘 두가지에 의해서 listing을 합니다.
1. 업데이트형 게시판 알고리즘
position알고리즘
앞번호의 글쓰기와 삭제에 의해서 다수의 업데이트가 발생하는 좋지 않은 알고리즘입니다.
2. 업데이트 없는 게시판 알고리즘
pos고정알고리즘
position을 고정시킨채 답변을 소숫점으로 늘려 답변의 depth만큼 소숫점이 늘어나는 알고리즘
잡다한 로직이 들어가서 직관적이지 못하고, 퍼포먼스는 시험을 못해봤지만 상위에 속할겁니다.
(다음이라던가 대형사이트가 사용하는 것으로 보여지는데..
fid, thread알고리즘
fid란 그룹아이디와 thread란 depth와 순서를 나타내는 두개의 컬럼으로 리스팅합니다.
퍼포먼스와 아이디어는 괜찮지만, query에서 order by fid desc, thread를 해결할 수 있는
방법이 결합인덱스로도 해결되지 않는 이 query를 누가 획기적으로 해결해줄지..
대략 게시판에 따라서 몇만건정도를 버틸 수 있습니다.
hirarchical query
오라클하면 hirarchial query죠..
fid, thread가 만건에서 버벅이던 것을 이것으로 돌려주면 1건을 where절로 값찾아 오는 듯
거의 수백만건이란걸 느끼지 못하고 0.0xx초에 리스트가 주르륵 나옵니다,
가장 직관적이고, 단순히 데이터에 대한 로직이 들어있을 뿐만 아니라, listing에 대한
로직이 없다는 장점도 가지고 있습니다.
그밖에 hirarchical query를 적용한 xsql을 이용한 xml출력이 가장 효율적입니다.
실제 퍼포먼스를 일일이 비교해보지 못했으니 금주나 다음주내에 대략 한 500만-1000만건으로
퍼포먼스를 비교 해보고 글을 올려보도록 하겠습니다.
또, 추가해서 b tree알고리즘으로 직접 적용해본 적은 없지만, 이 방법도 좋을 듯 싶네요..
listing으로 고민하시는 분들께 도움이 되었으면 좋겠네요..
이만~
p.s : 홈페이지 만드는 중입니다~(만들다 말았는데..)내용도 없고 들은것도 없네요.^^;;
210.220.189.26이구요, 아직 되는 건 없이 대략적인 페이지에 대한 윤곽을
잡은 상태인데, 그냥 한번씩 오셔서 보시구 메일로 조언해주시면 감사하겠습니다~^^
|
