* 질문 등록 시 다음의 내용을 꼭 기입하여 주세요.
|
Linux 64bit |
|
CUBRID 11.3 |
|
SQLGate 9.18.0.1 |
|
java |
* CUBRID 응용 오류, SQL 오류 또는 SQL 튜닝 관련된 문의는 반드시 다음의 내용을 추가해 주세요. 비밀글이나 비밀 댓글도 가능합니다.
* 저희가 상황을 이해하고, 재현이 가능해야 알 수 있는 문제들이 많습니다. 가능한 정보/정황들을 부탁합니다.
에러 내용 및 재현 방법 | 재현 가능한 Source와 SQL |
관련 테이블(인덱스, 키정보 포함) 정보 | CUBRID 홈 디렉토리 아래 log 디렉토리 압축 |
-------------- 아래에 질문 사항을 기입해 주세요. ------------------------------------------------------------------------
업무 테이블을 직접 보여드리기 힘들어... (성능 테스트 생성 스크립트(test.sql) 첨부파일 참조)
성능 테스트용으로 일반 테이블, 파티션 테이블, 더미 데이터를 생성하여 성능 테스트를 하였습니다.
TRACE 정보 확인 결과 일반 테이블에 비해 파티션 테이블의 성능에 이점이 없는 것으로 보입니다.
해당 결과가 정상적인 상황인지 문의 드리며 성능 개선에 도움되는 의견도 부탁드립니다.
1. 파티션 테이블
SELECT /*+ RECOMPILE */ ID, NM
FROM TEST
WHERE DATE_TIME BETWEEN '20240101093652000' AND '20240104093652999';
Query Plan:
INDEX SCAN (apig.TEST.test_ix01) (key range: ([apig.TEST].DATE_TIME>= ?:0 and [apig.TEST].DATE_TIME<= ?:1 ))
rewritten query: select [apig.TEST].ID, [apig.TEST].NM from [apig.TEST] [apig.TEST] where ([apig.TEST].DATE_TIME>= ?:0 and [apig.TEST].DATE_TIME<= ?:1 )
Trace Statistics:
SELECT (time: 4849, fetch: 3023625, ioread: 206178)
SCAN (index: apig.test.test_ix01), (btree time: 3848, fetch: 3005651, ioread: 206173, readkeys: 27, filteredkeys: 0, rows: 2999381) (lookup time: 3434, rows: 2999381)
2. 일반 테이블
SELECT /*+ RECOMPILE */ ID, NM
FROM TEST2
WHERE DATE_TIME BETWEEN '20240101093652000' AND '20240104093652999';
Query Plan:
INDEX SCAN (apig.TEST2.test2_ix01) (key range: ([apig.TEST2].DATE_TIME>= ?:0 and [apig.TEST2].DATE_TIME<= ?:1 ))
rewritten query: select [apig.TEST2].ID, [apig.TEST2].NM from [apig.TEST2] [apig.TEST2] where ([apig.TEST2].DATE_TIME>= ?:0 and [apig.TEST2].DATE_TIME<= ?:1 )
Trace Statistics:
SELECT (time: 4490, fetch: 3023613, ioread: 90647)
SCAN (index: apig.test2.test2_ix01), (btree time: 3458, fetch: 3005644, ioread: 90647, readkeys: 27, filteredkeys: 0, rows: 2999381) (lookup time: 3035, rows: 2999381)
※ 참고로 커버링 인덱스를 적용하면은 타 DB 와 비슷한 성능이 나오는 정도입니다. 실제 업무에서는 선언되는 컬럼이 다수 존재해서 적용하긴 힘들지만요..
큐브리드를 이용해 주셔서 감사합니다.
큐브리드에서 제공하는 "분할" 사용 시 아래와 같은 이점을 가집니다.
-대용량 테이블의 관리 편의성 향상
-데이터 조회 시 접근 범위를 줄임으로써 성능 향상
-디스크 I/O를 분산함으로써 성능 향상 및 물리적 부하 감소
-여러 분할로 나눔으로써 전체 데이터의 훼손 가능성 감소 및 가용성 향상
-스토리지 비용의 최적화
문의하신 내용을 요약하면 "분할한 test 와 분할하지 않은 test2의 성능이 동일하다"로 이해 됩니다.
비교하신 test2에서 오류가 있는 듯합니다.
분할하지 않은 test2와의 비교가 아닌, 원본인 test와 그 하위에 존재하는 sub classes와 비교를 해주셔야 겠습니다.
<Class Name>
dba.test
<Sub Classes>
dba.test__p__part_20240101
dba.test__p__part_20240102
dba.test__p__part_20240103
dba.test__p__part_20240104
dba.test__p__part_20240105
dba.test__p__part_20240106
TC1. test테이블에서 20240104 데이터만 검색하는 경우
SELECT /*+ RECOMPILE */ ID, NM
FROM TEST
WHERE DATE_TIME like '20240104%'
결과 SELECT (time: 1102, fetch: 1008089, ioread: 8682)
TC2. 분할 된 test테이블 중 sub classes인 PART20240104(test__p__part_20240104) 에서 데이터를 검색하는 경우
SELECT /*+ RECOMPILE */ ID, NM
FROM test__p__part_20240104
결과 :SELECT (time: 726, fetch: 13188, ioread: 715)
TC1과 TC2비교 시, 시간과 fetch량 감소를 확인하 실 수 있겠습니다.
내부적으로 분할에 관한 성능을 높이는 작업은 진행중이며 빠른 시일안에 release하도록 하겠습니다.
감사합니다.