Background Image

FORUM

조회 수 242 추천 수 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 와 비슷한 성능이 나오는 정도입니다. 실제 업무에서는 선언되는 컬럼이 다수 존재해서 적용하긴 힘들지만요.. 

 

  • ?
    큐브리드_김주현 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 도구 출시 안내 5 admin 2024.04.23 5069
공지 SQLGate for CUBRID 영구 무료 라이선스 제공 file admin 2020.04.09 8992
3955 테이블이 어떤 스키마(데이터베이스)에 속해있는지 알 수 있는 방법이 있나요? 3 엘L 2024.01.29 327
3954 테이블 생성시 REUSE_OID 옵션끄기 문의드립니다 1 원샷 2024.01.25 258
3953 큐브리드 DB에 테이블 생성 후, 저장된 데이터 LIKE 조건 안되는 현상입니다. 1 file 하코 2024.01.24 268
3952 실 ip db서버 이중화 관련 질문 1 zexpand 2024.01.18 250
3951 SQLGate for CUBRID (CUBRID v9.3 and later) 폐쇄망 사용법? 1 임소식 2024.01.18 240
3950 큐브리드 파일 읽기 쓰기 문의 1 임소식 2024.01.18 541
3949 CUBRID Manager 윈도우 버전 배포 해주세요. SQLGate for CUBRID 버그가 많아요. 2 도프 2024.01.17 299
3948 Cubird db 접속 문제 1 file 폰호두 2024.01.17 271
3947 Django Cubrid DB Conntection Error 4 thejoin 2024.01.16 261
3946 CUBRID DB 접속 불가 1 file 싸뤼 2024.01.16 222
3945 Cubrid admin localhost 연결 불가 7 file 싸뤼 2024.01.12 321
» 파티션 테이블 성능 문의 4 file 방글이 2024.01.11 242
3943 트리거 삭제 오류 1 file slqk135 2024.01.08 272
3942 restoredb 시 log 내용 문의 1 file 별하나에 2024.01.08 237
3941 파티션 테이블 대량 DROP 처리 문의 (ibatis) 1 방글이 2024.01.04 206
3940 JAVA SP 에서 addBatch 오류 문의 1 방글이 2024.01.03 240
3939 DB서버 에러로그 1 file leeee 2023.12.27 294
3938 오라클의 SUBSTRB 기능 문의 3 방글이 2023.12.26 244
3937 멀티host상태에서 admin툴 로그인방법 문의합니다 2 file 원샷 2023.12.20 221
3936 DB 서버가 start 되지 않아 문의드립니다. 4 그로구 2023.12.19 267
Board Pagination Prev 1 ... 4 5 6 7 8 9 10 11 12 13 ... 206 Next
/ 206

Contact Cubrid

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