Background Image

FORUM

  1. Home
  2. FORUM
  3. Q&A
2024.01.11 17:58

파티션 테이블 성능 문의

방글이
조회 수 116 추천 수 0 댓글 4
?

단축키

Prev이전 문서

Next다음 문서

가 크게 작게 위로 아래로 댓글로 가기 인쇄 첨부


* 질문 등록 시 다음의 내용을 꼭 기입하여 주세요.

OS
 Linux 64bit
CUBRID Ver.
 CUBRID 11.3
CUBRID TOOL Ver.
 SQLGate 9.18.0.1
응용 환경(API)
 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 와 비슷한 성능이 나오는 정도입니다. 실제 업무에서는 선언되는 컬럼이 다수 존재해서 적용하긴 힘들지만요.. 

 

Atachment
첨부 '1'
위로 아래로 댓글로 가기 인쇄 첨부
에디터 선택하기
?
Comments '4'
  • ?
    큐브리드_김주현 2024.01.16 14:30

    큐브리드를 이용해 주셔서 감사합니다.

    큐브리드에서 제공하는 "분할" 사용 시 아래와 같은 이점을 가집니다.
    -대용량 테이블의 관리 편의성 향상
    -데이터 조회 시 접근 범위를 줄임으로써 성능 향상
    -디스크 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하도록 하겠습니다.

    감사합니다.

    댓글
  • ?
    방글이 2024.01.16 14:53

    답변 주신 설명을 기반으로 제가 이해한게 맞는지 문의 드립니다.


    1. 타 DBMS 와 다르게 각 파티션 분할 구역 테이블을 직접 조회해야지 성능에 이점이 있다는 걸로 이해가 됩니다.
        즉, 파티션 테이블의 기준 컬럼으로 로컬 인덱스 조회가 안되고 분할된 파티션명을 직접 선언해서 조회 해야지 성능에 이점이 있다. 

        제가 이해한게 맞나요??

     

    2. 제시 해주신 Sub Classes 조회 방식으로 할 경우 기간 검색 조건이 2일 이상인 경우 어떻게 조회를 해야 성능 개선에 도움이 되나요? (union all 밖에 생각이 안나네요..)

     

    3. 기간 검색이 필요한 경우 먼저 Sub Classes 선정을 동적으로 구현하고 쿼리를 작성하는 구조인 것 같은데 진짜 이게 맞는 것인가요?

     

    4. 큐브리드 메뉴얼에 보면은 "분할 프루닝(partition pruning)은 검색 조건을 통해 데이터 검색 범위를 한정시키는 최적화 기법이다." 라고 명시 되어 있는데 답변 주신 내용과는 상반된 이야기여서 혼란스럽습니다.  

    여러가지 DBMS 사용해 봤지만 분할한 파티션을 직접 선언해서 사용하는 경우가 드물어서 문의 드립니다.

    댓글
  • ?
    큐브리드_김주현 2024.01.16 18:20
    답변 드립니다.

    처음 문의하신 내용과 두번째 제가 답변드린 포인트가 상이했던 부분이 있습니다.
    문의하신 내용이 영역분할을 했음에도 DATE_TIME BETWEEN 와 같이 기간검색을 할 경우를 문의하신 것 같구요
    제가 답변드린 것은 분할 사용 시, 성능에 유리할 수 있는 부분은 분할된sub classes를 호출하는 것이 유리하다라고 답변드리면서 혼돈을 드린 것 같습니다.

    1.. day별 영역분할에서 작성자님은 0101~0104와 같이 영역을 걸친 경우를 문의하신 것인데, 제가 0104 으로 해야 성능이점이 있다라고 답변 드린 것 같습니다.
    우선 영역을 넘어서는 경우(0101~0104와 같이) test나 test2에서 성능이점은 크게 없을 것 같습니다.

    2. 해당 케이스에서는 우선 union all이 최선일 것 같습니다.실 업무환경에서는 조건이나 스키마 구조에 따라 다를 수 있을 것 같습니다.

    3. 아닙니다. 성능을 문의하신 것같아 sub classes를 이용하는 것이 성능에 유리하다 라고 답변 드린 것이고,
    분할 테이블을 접근하는 방법 외에 시스템에 의해 부여된 분할 이름을 직접 명시하거나 table PARTITION (name) 절을 사용하여 각 분할에 직접 접근할 수 도 있겠습니다.

    -- to specify a partition with its table name
    csql> select * from dba.test__p__part_20240104;

    -- to specify a partition with PARTITION clause
    csql> select * from test PARTITION(PART_20240104);

    CUBRID에서 분할은 대량 데이터가 적재될때 이를 분할하여 관리하다가 재구성/분할추가/제거/일반테이블로변경및승격등을 통해 데이터 관리를 주 목적으로 제공되고 있습니다.

    감사합니다.
    댓글
  • ?
    방글이 2024.01.16 18:35

    답변을 기반으로 제가 이해한게 맞는지 다시 질문 드리겠습니다.

    1. 분할 영역 내에서만 조건 검색시 성능에 이점이 있다. (분할 프로닝 가능)
    - 예시1) 20240101 조건 검색시 파티션 테이블 성능 이점
    - 예시2) 20240101~20240103 조건 검색시 파티션 테이블, 일반 테이블 성능 동일

    2. 기간 검색시 분할 영역 2개 이상 넘어서는 경우 sub classes 방식으로 쿼리를 작성해야 성능에 이점이 있다. (분할 프로닝 불가능)

    이렇게 이해하면은 될까요?


    그리고 제시해주신 방법으로 테스트 해보았지만 전혀 성능 개선이 이루지지 않네요.


    1. 파티션 테이블

    SELECT  /*+ RECOMPILE */ ID, NM, DATE_TIME
    FROM     TEST PARTITION(PART_20240101)
    WHERE DATE_TIME BETWEEN '20240101093652000' AND  '20240104103652999'
    UNION ALL
    SELECT  /*+ RECOMPILE */ ID, NM, DATE_TIME
    FROM     TEST PARTITION(PART_20240102)
    WHERE DATE_TIME BETWEEN '20240101093652000' AND  '20240104103652999'
    UNION ALL
    SELECT  /*+ RECOMPILE */ ID, NM, DATE_TIME
    FROM     TEST PARTITION(PART_20240103)
    WHERE DATE_TIME BETWEEN '20240101093652000' AND  '20240104103652999'
    UNION ALL
    SELECT  /*+ RECOMPILE */ ID, NM, DATE_TIME
    FROM     TEST PARTITION(PART_20240104)
    WHERE DATE_TIME BETWEEN '20240101093652000' AND  '20240104103652999';

     

    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, [apig.TEST].DATE_TIME from [apig.TEST__p__PART_20240101] [apig.TEST] where ([apig.TEST].DATE_TIME>= ?:0  and [apig.TEST].DATE_TIME
    <= ?:1 )

      INDEX SCAN (apig.TEST.test_ix01) (key range: ([apig.TEST].DATE_TIME>= ?:2  and [apig.TEST].DATE_TIME<= ?:3 ))

      rewritten query: select [apig.TEST].ID, [apig.TEST].NM, [apig.TEST].DATE_TIME from [apig.TEST__p__PART_20240102] [apig.TEST] where ([apig.TEST].DATE_TIME>= ?:2  and [apig.TEST].DATE_TIME
    <= ?:3 )

      INDEX SCAN (apig.TEST.test_ix01) (key range: ([apig.TEST].DATE_TIME>= ?:4  and [apig.TEST].DATE_TIME<= ?:5 ))

      rewritten query: select [apig.TEST].ID, [apig.TEST].NM, [apig.TEST].DATE_TIME from [apig.TEST__p__PART_20240103] [apig.TEST] where ([apig.TEST].DATE_TIME>= ?:4  and [apig.TEST].DATE_TIME
    <= ?:5 )

      INDEX SCAN (apig.TEST.test_ix01) (key range: ([apig.TEST].DATE_TIME>= ?:6  and [apig.TEST].DATE_TIME<= ?:7 ))

      rewritten query: select [apig.TEST].ID, [apig.TEST].NM, [apig.TEST].DATE_TIME from [apig.TEST__p__PART_20240104] [apig.TEST] where ([apig.TEST].DATE_TIME>= ?:6  and [apig.TEST].DATE_TIME
    <= ?:7 )


    Trace Statistics:
      UNION
        UNION
          UNION
            SELECT (time: 1561, fetch: 916280, ioread: 10621)
              SCAN (index: apig.test__p__part_20240101.test_ix01), (btree time: 1051, fetch: 901889, ioread: 10620, readkeys: 9, filteredkeys: 0, rows: 900000) (lookup time: 907, rows: 900000)
            SELECT (time: 1718, fetch: 1018086, ioread: 8681)
              SCAN (index: apig.test__p__part_20240102.test_ix01), (btree time: 1154, fetch: 1002097, ioread: 8680, readkeys: 10, filteredkeys: 0, rows: 1000000) (lookup time: 1004, rows: 1000
    000)
          SELECT (time: 1711, fetch: 1018086, ioread: 8682)
            SCAN (index: apig.test__p__part_20240103.test_ix01), (btree time: 1153, fetch: 1002097, ioread: 8681, readkeys: 10, filteredkeys: 0, rows: 1000000) (lookup time: 1006, rows: 100000
    0)
        SELECT (time: 348, fetch: 203613, ioread: 1784)
          SCAN (index: apig.test__p__part_20240104.test_ix01), (btree time: 251, fetch: 200418, ioread: 1783, readkeys: 2, filteredkeys: 0, rows: 200000) (lookup time: 226, rows: 200000)

     

    2. 일반 테이블

    SELECT  /*+ RECOMPILE */ ID, NM, DATE_TIME
    FROM     TEST2
    WHERE DATE_TIME BETWEEN '20240101093652000' AND  '20240104103652999';

     

    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, [apig.TEST2].DATE_TIME from [apig.TEST2] [apig.TEST2] where ([apig.TEST2].DATE_TIME>= ?:0  and [apig.TEST2].DATE_TIME<= ?:1 )

    Trace Statistics:
      SELECT (time: 5223, fetch: 3156077, ioread: 29209)
        SCAN (index: apig.test2.test2_ix01), (btree time: 3515, fetch: 3106501, ioread: 29208, readkeys: 31, filteredkeys: 0, rows: 3100000) (lookup time: 3052, rows: 3100000)


     

    마지막 답변처럼 분할 영역 간 기간 검색에는 일반 테이블에 비해 파티션 테이블의 조회 성능 이점이 없는 것으로 보입니다.

     

    대용량 데이터를 다루는 실무에서는 활용성에 어려움이 있으므로 향후 타 DBMS 와 동일하게 파티션 키의 로컬 인덱스 만으로도 조회 성능에 이점이 있었으면은 좋겠습니다. 

     

    댓글
List of Articles
번호 제목 글쓴이 날짜 조회 수
공지 CUBRID 사용자를 위한 DBeaver 도구 출시 안내 admin 2024.04.23 49
공지 SQLGate for CUBRID 영구 무료 라이선스 제공 file admin 2020.04.09 4458
3914 프로세스 점유에 대해 질문 드립니다. 1 file 이석희 2009.02.24 13458
3913 프로그램 개발 후 배포 관련 3 늘푸른거북이 2009.02.12 25365
3912 풀스캔 1 벌래잡이 2016.11.18 13756
3911 표준프레임워크의 공통컴포넌트에 게시판설치관련 3 file 큐브리 2012.08.31 22767
3910 표준SQL 지원 관련 문의 1 뒷태지존 2013.06.25 7933
3909 포트에 대해 질문이 있습니다. 1 쿨랑 2011.01.11 7790
3908 포트 및 설정 관련 재 질문 드립니다. 1 푸추어핸접 2013.10.29 8374
3907 폐쇄망에서의 큐브리드 운영문의 1 woorirk 2015.01.16 7509
3906 평창농업기술정보센터입니다. ^^ 2 secret 바보천사 2009.04.24 13
3905 페이징과 전체 카운트 쿼리 가져올 수 있도록 해주세요.ㅠㅠ 1 마산이프로 2011.10.29 30076
3904 페도라 10에서 큐브리드 rpm 설치시 오류 1 스나이퍼 2009.03.26 16391
3903 펑션 오류 문의드립니다 8 초코초코초 2022.12.17 141
3902 패키지 분화가 가능할까요? 1 ienfant 2010.01.15 9565
3901 패스워드 암호화 알고리즘 1 igloojs 2019.05.17 285
3900 파티션키 여러개의 컬럼 구성 가능 여부 1 타임 2021.09.07 211
3899 파티션 테이블에 대해서.. 1 알칸펠 2014.01.17 11067
» 파티션 테이블 성능 문의 4 file 방글이 2024.01.11 116
3897 파티션 테이블 목록을 조회 할려고 하는데요. 1 Philip Park 2020.03.25 206
3896 파티션 테이블 대량 DROP 처리 문의 (ibatis) 1 방글이 2024.01.04 79
3895 파티셔닝으로 성능향상 미비? 1 라면 2016.08.04 13222
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 ... 200 Next
/ 200

Contact Cubrid

대표전화 070-4077-2110 / 기술문의 070-4077-2113 / 영업문의 070-4077-2112 / Email. contact_at_cubrid.com
Contact Sales

Site Map