게시판별 테이블 vs 통합 테이블 정보
게시판별 테이블 vs 통합 테이블
본문
관리하는 측면에서는 테이블의 갯수가 적을수록 좋습니다.
그러나 갑자기 규모가 커져서 게시글의 수가 많아지기라도 하면 테이블 하나로 관리하는 경우 인덱싱이 제대로 되지 않은 상태에서는 상당한 부하가 걸릴수 있습니다.
그렇다고 여러 테이블로 나누어 놓자니 게시판의 갯수가 늘어나면 관리하기 어려운점이 있구요.
이러지도 저러지도 결정을 못하는 상황입니다. ㅠㅠ
네이버에서 가장 큰 규모의 카페는 중고나라로 알고 있는데요.
현재 전체글보기 옆에 괄호안의 숫자가 (60,553,726)건으로 표시되고 있습니다.
혹시나 예전글도 다 보관하고 있는지 궁금하여 첫글을 찾아 보았습니다.
http://cafe.naver.com/joonggonara/1 은 삭제가 되고 없구요.
http://cafe.naver.com/joonggonara/2 는 보관이 되어 있네요. 2003.12.15 21:58
아마도 예전 게시물을 전부 보관하고 있기는 한것 같아 목록으로 넘겨 보기로 했습니다.
1000 페이지 까지는 보여주는데 1001 페이지를 넘어가면 다시 1페이지로 넘겨 버리는군요.
페이징 기법상 그렇게 처리한거 같은 느낌입니다.
MySQL의 경우 limit 로 페이징을 처리하게 되면 뒤로 갈수록 속도가 느려집니다.
그런데 여기서 어마어마 한건 현재 시간이 10:18 인데 오늘 날짜 07:45 에 올라온게 이미 1000 페이지를 넘겼다는 것입니다. ㅎㄷㄷ
네이버카페의 경우 카페당 하나의 테이블에서 처리하는것으로 보이는데 여러분들은 어떻게 보시는지요?
추천
0
0
댓글 5개
의견을 드린다면 limit 로 페이징을 할 경우 속도가 느려진다면 이미 그 사이트는 단독서버로 튜닝을 통해서 해결하지 않을까 싶습니다.
대부분의 중소형 사이트는 인덱싱만 제대로 걸어도 큰 문제가 없더군요.
통합테이블로 한다면 여러 다양한 부가기능이 더 많이 나오지 않을까 싶습니다.
그누보드 관련 개발을 하다보면 그누보드 구조상 아주 가끔 union 을 어쩔수없이 쓰게되는경우가 있는데 이 union 이 속도에 아주 안좋은건 아실껍니다.
서로 장단점이 있을것 같긴한데 개인적으로 통합테이블로 간다에 한표 던지고 싶습니다.^^
대부분의 중소형 사이트는 인덱싱만 제대로 걸어도 큰 문제가 없더군요.
통합테이블로 한다면 여러 다양한 부가기능이 더 많이 나오지 않을까 싶습니다.
그누보드 관련 개발을 하다보면 그누보드 구조상 아주 가끔 union 을 어쩔수없이 쓰게되는경우가 있는데 이 union 이 속도에 아주 안좋은건 아실껍니다.
서로 장단점이 있을것 같긴한데 개인적으로 통합테이블로 간다에 한표 던지고 싶습니다.^^
네 저도 그런 생각을 했습니다.
대형 커뮤니티의 경우 배포한 그대로 사용하지는 않을것 입니다.
독자적인 코드나 튜닝으로 해결하겠지요.
저는 관리적인 측면에서 더 편한 방법을 찾고 있습니다.
대형 커뮤니티의 경우 배포한 그대로 사용하지는 않을것 입니다.
독자적인 코드나 튜닝으로 해결하겠지요.
저는 관리적인 측면에서 더 편한 방법을 찾고 있습니다.
네이버의 경우 DBMS의 구조는 비슷한데 튜닝정도가 다르지 않을까요?
이를테면, 프로시저를 사용한다던지 버퍼에 대한 룰이 있다던지 말이죠.
하나의 테이블을 통해서 처리하더라도 서비스에 맞게 튜닝한것과
다양한 사용자층을 고려한 배포버전과는
튜닝방법론 적으로 차이를 보이는게 아닐까요.
다른 이야기지만 저는 보드를 통합으로 씁니다.
서비스별 스킨으로 사용하지 않고, 서비스에 맞는 모듈을 만들어요. 배포목적이 아니라 자기 서비스에맞게 만드니까 그렇게 쓰는거죠. : )
스킨에 의존해야한다면, 통합하는 테이블구조보다는 개별 접근 하도록 하는게 사용자의 휴먼에러위험도 적고 좋을것 같습니다.
이를테면, 프로시저를 사용한다던지 버퍼에 대한 룰이 있다던지 말이죠.
하나의 테이블을 통해서 처리하더라도 서비스에 맞게 튜닝한것과
다양한 사용자층을 고려한 배포버전과는
튜닝방법론 적으로 차이를 보이는게 아닐까요.
다른 이야기지만 저는 보드를 통합으로 씁니다.
서비스별 스킨으로 사용하지 않고, 서비스에 맞는 모듈을 만들어요. 배포목적이 아니라 자기 서비스에맞게 만드니까 그렇게 쓰는거죠. : )
스킨에 의존해야한다면, 통합하는 테이블구조보다는 개별 접근 하도록 하는게 사용자의 휴먼에러위험도 적고 좋을것 같습니다.
사실 오랫동안 사용하다 보니 스킨별로 게시판을 관리하는 것도 일이더라구요.
지금은 게시판 설정 부분에 구분을 두고 예외 처리하는 방법으로 스킨의 수를 줄여 문제를 해결하고 있습니다.
지금은 게시판 설정 부분에 구분을 두고 예외 처리하는 방법으로 스킨의 수를 줄여 문제를 해결하고 있습니다.
지금 상태에서는 게시판별 테이블 정책을 유지해야 할것 같습니다.
예를 들어서 휴대폰 신청 게시판이 있고, 입력 항목이 20개이며, 관리자는 각 항목에 대해서 검색할 수 있어야 한다.
라는 조건이 있을 때
1) 게시판을 생성하고
2) 해당 테이블 스키마를 변경
하겠죠.
이미 이런 식의 스킨이 있으므로 통합테이블 구성은 어렵겠죠.
통합하려면 추가로 장착한 필드(SIR 같은경우 검색필드) 를 분리하는 작업을 해야할거에요.
예를 들어서 휴대폰 신청 게시판이 있고, 입력 항목이 20개이며, 관리자는 각 항목에 대해서 검색할 수 있어야 한다.
라는 조건이 있을 때
1) 게시판을 생성하고
2) 해당 테이블 스키마를 변경
하겠죠.
이미 이런 식의 스킨이 있으므로 통합테이블 구성은 어렵겠죠.
통합하려면 추가로 장착한 필드(SIR 같은경우 검색필드) 를 분리하는 작업을 해야할거에요.