안녕하세요.
문의사항이 있어서 글을 남깁니다.
기존에 마스터 테이블에 pk, 제목, 내용, 속성1~속성N... 이런 테이블(게시판은 아닙니다)이 있습니다.
이 경우에 내용 컬럼이 다른 컬럼에 비해서 양이 매우 크다고 할 경우에 마스터 테이블의 대부분(95% 이상)을 차지한다고 할 경우에
내용만 다른 테이블(pk, 내용)에 저장을 하게 되면 마스터 테이블 검색 속도가 향상이 되나요?
대부분의 페이지가 속성1~속성N을 사용하여 제목 리스트를 가져오는 쿼리로 이루어져 있고, 상세보기 페이지에서만 내용을 조회합니다.
마스터 테이블 조회쿼리가 풀스캔을 하지만 않으면 마스터테이블 크기와는 관계가 없는지 궁금합니다.
리스트에서 내용 일부를 가져오는 쿼리를 생각을 못했네요.
select pk, 제목, 속성1... 속성 N, (select substring(내용, 100) from 내용 테이블 D where M.pk = D.pk) 내용
from 마스터테이블 M
where 속성N = ...
위의 쿼리처럼 수정을 하게 되면 마스터테이블에 내용 컬럼을 두었을때하고 내용 컬럼만 별도로 분리해서 사용하는 경우하고
차이점이 없는건가요?
안녕하세요.
서브 질의를 사용하시게 되면 질의 결과 개수만큼 서브질의가 수행되게 되므로 그것보다는 인라인 뷰를 활용하시는 것이 좋겠습니다.
select 제목, substr(본문, ...)
from (select 키, 제목 from 목록테이블 where rownum between 1 and 20) as t(키,제목), 내용테이블
where t.키 = 내용테이블.FK
where rownum 부분은 CUBRID의 페이징방법입니다.
이조차 성능에 문제가 될 수 있다면, 본문이 거의 수정이 되지 않는다는 전제하에 목록에 보이는 본문의 일부를 아예 목록테이블에 중복시킬 수 도 있을 것입니다.
안녕하세요.
항상 빠르고 상세한 설명까지 감사합니다.
현재 운영하는 사이트가 언론사라서 한번 올라간 기사는 내용 수정이 거의 없습니다.
그리고 내용 수정하는 페이지는 관리자에 있는 하나의 메뉴에서 모두 이루어지기 때문에 마스터 테이블에 내용중 첫부분 일부(200byte)를 저장하는 방식으로 하는게 좋을꺼 같은데요, 그렇게 되면 내용 테이블 조회는 뷰페이지에서만 조회하게 될꺼 같습니다.
그리고 내용 수정이 될 경우에는 마스터 테이블의 내용, 내용테이블의 내용을 같이 수정해 주는 로직으로 프로그램을 변경할까 합니다.
그리고 pk가 yyyymmddNNNN(일련번호) 형식이기 때문에 내용 테이블을 파티션 테이블의 레인지 분할을 이용하여 월별로 분할하게 되면 성능 향상이 있을거 같은데요.
이 방법이 맞는지 한번만 더 확인해 주시면 감사하겠습니다.
안녕하세요.
금일 출장 관계로 이제서야 확인이 되었습니다.
검색위주의 시스템이라면 잘아시겠지만 일정 부분 데이터의 중복은 성능을 위해서 충분히 고려해볼 가치가 있는 일입니다.
분할 부분은 사용하시는데 특별한 문제는 없습니다. 다만 분할키로서 필드를 그냥 사용하시는 것이 성능상 좋습니다. 즉, 분할 조건을 수식으로 하지말고 필드를 그냥 이용하는 것입니다. 해당 테이블에 접근할때마다 분할키에 대한 평가가 이루어지기 때문입니다.
따라서 월별로 분할을 한다면 yyyymm 을 저장하는 필드를 추가하여 관리하고 이 값을 분할키로 하여 구성하는 것이 좋습니다.
현재 성능 관점에서 분할 자체가 기대만큼 좋은 성능을 주지는 못하고 있습니다. 따라서 기사종류별, 기간별로 테이블 자체를 별도로 하시는 것이 좋을 것 같습니다.
예. 좋은 방법입니다. 자주보는 테이블의 레코드길이가 짧은 것은 검색에 매우 유리합니다. 말씀하신 것처럼 키,제목 정도로 목록에 보여주는 정보 위주로 테이블을 구성하고, 상세보기에 해당하는 본문은 별도 테이블로 가는 것이 좋습니다.
다만 하나의 테이블이(데이터관점에서) 두개의 테이블로 분리되므로 목록테이블과 상세보기테이블에 대하여 작성자,작성일자 등에 대하여 중복될 수 있는 데이터의 위치에 대하여 관심을 가지셔야 합니다. 분리하시고 목록보기시 조인하여 질의하면 의미는 반감합니다.
목록정보에 두고, 상세보기시 목록을 조인하면 조인대상이 한건일터이니 도움이 될 것으로 보입니다.