게시판 테이블은 설계방법?

Question

게시판이 데이터가 너무 많은 경우 댓글이랑 DB조회시 속도가 안나오면 게시판 테이블에 파티션을 할건데대체 어떤 기준으로 하나요? 보통은 레인지나 해시는 쓰긴한데게시판은 날짜별로 하기도 어려운게 게시판 본문이랑 댓글이 같은 날짜가 아닐수도 있고 1월 게시물에 2월달 답글이 달릴수도 있어서;보통은 게시판 테이블에 파티션은 어떻게 사용들 많이 하시나요?

르매 · Accepted Answer

어떤 DBMS 인지와 왜 파티셔닝을 고려하시는지 궁금하네요.파티션을 나눴을 때의 장점은 무척 제한적입니다. 대부분의 쿼리에서 파티션을 나누지 않는 쪽이 더 빠르죠.MySQL이라는 전제로 말씀드리면..먼저, INSERT 성능은.. 파티션이 나뉘어 있을 수록 느려집니다.나머지 SELECT, UPDATE, DELETE는 WHERE 절의 조건이 인덱스를 잘 사용하면서.. 조회 대상의 데이터가 위치한 파티션만 접근하도록 쿼리를 작성할 수 있는 지가 중요합니다.예를 들면 파티셔닝에 사용한 구분 컬럼을 반드시 WHERE 절에 포함 시켜야 필요한 파티션만 접근하게 되겠죠. 이런 걸 파티션 프루닝(Partition Pruning)이라고 부릅니다.말씀하신 게시판을 대상으로 한다면.. 이게 통합 게시판일 경우 게시판의 종류 별로 리스트 파티션을 만드는 정도를 생각해 보게 됩니다.그렇지 않고 게시글 자체가 여러 파티션에 골고루 분산 되게 하겠다??그건 아무 의미도 없습니다.INSERT는 기본적으로 느려지고, UPDATE나 DELETE는 포인트 쿼리라서 PK 컬럼으로 빠르게 1건을 처리할 테니 상관 없다 치는데요.결국 파티션을 고려한 이유는 게시글 목록을 조회하는 SELECT 성능 때문이 아닌가요?글쎄요.. 구분 컬럼이 매번 WHERE 절에 들어가야하는데.. 어떤 컬럼도 마땅치 않습니다. 결국 모든 파티션을 뒤지는 결과가 나올테고 더 느려질 뿐이겠죠.사실, 파티션은 대용량 로그 테이블을 일이나 월 단위로 빠르게 삭제하기 위한 용도로는 쓰지만, 그 외에 파티션이 실제 DB 성능 개선에 도움이 되는 경우는 드뭅니다.p.s인덱스를 탄다는 가정하에 데이터를 조회하는 속도는 테이블의 레코드 수가 중요한게 아니라, 인덱스의 B-Tree 구조에서 Tree의 depth가 중요한 겁니다. depth가 같으면 레코드가 100건 있으나 1천만건 있으나 조회 속도는 100% 같으니까요.물론 인덱스의 depth는 레코드 수가 증가하면 어느 순간 depth도 증가하지만.. 레코드 수처럼 선형적으로 금방 커지는 값은 아닙니다. 대부분의 테이블이 커 봐야 2 또는 3depth이고.. 4depth 는 드물거나 없죠.

stopoff · Answer

월별, 일주일 등 기간별로 하는 방법이 있겠죠일별로 쪼개지 않는 한 날짜로 나눠도 될 것 같은데요

게시판 테이블은 설계방법?

2개의 답변

Q&A 목록