Background Image
제품 여행
2020.12.24 17:52

[CUBRID inside] Query Process란?

조회 수 1130 추천 수 1 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

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

CUBRID는 open source DBMS입니다. 소스 코드가 공개되어 있어 언제든지 확인하고 기여할 수 있습니다. 많은 사람이 CUBRID의 contributor가 되길 바라봅니다. 


Query Process란?


Query Process는 DBMS의 입력값인 SQL을 낮은 수준의 명령으로 변환하고 그것을 실행하는 전체 작업을 말합니다.
SQL에서 가장 먼저 진행되어야 하는 것은 TEXT로 작성된 SQL을 parse tree 구조로 만드는 것입니다. 이 작업은 PARSER에서 진행되는데, CUBRID는 PT_NODE 구조체를 반복적으로 사용하여 SQL을 parse tree로 변환합니다. 이 단계에서 syntax check가 진행되고 오타나 잘못된 예약어 등을 체크합니다. 그리고 SEMANTIC CHECK를 진행하는데, 여기서 작성된 테이블명이나 칼럼명 등이 존재하는 것인지 체크합니다. 

 다음으로 OPTIMIZER가 parse tree를 최적화하고 PLAN을 생성합니다. parse tree를 최적화하는 것을 QUERY REWRITE 혹은 TRANSFORMATION이라고 합니다. 좋은 성능을 위해 SQL을 다시 작성한다고 생각하면 됩니다. 동일한 데이터를 조회하는 SQL은 다양한 형태로 작성될 수 있습니다. 그렇기 때문에 가장 효과적인 방안으로 변환을 하는 것입니다.  여러 재작성 방법이 있는데 조회조건을 sub-query 안으로 넣어주는 predicate push등이 이에 해당합니다. 다음은 PLAN을 생성하는 것입니다. PLAN에는 어떻게 DATA를 조회할 것인가에 대한 정보가 있습니다. SQL은 어떤 데이터를 조회할 것인지에 대해서만 명시되어 있기 때문에 실제 데이터를 조회하기 위해서 이 단계가 필요합니다(이 단계 때문에 개발자가 어떻게 DATA를 조회할지에 대한 정보를 알지 못해도 됩니다). 여기서 어떻게 조회하는가에 대한 정보는 JOIN 테이블의 SCAN 순서, JOIN METHOD, SCAN METHOD등의 정보를 말합니다. 해당 정보가 PLAN 저장됩니다.

 XASL generator에서 PLAN과 parse tree의 정보를 종합하여 실행계획 정보를 생성하는데 이것은 EXECUTOR에서 바로 실행이 가능한 형태입니다. CUBRID는 이것을 eXtensional Access Specification Language(XASL) 형태로 저장합니다. XASL에는 어떻게, 어떤 데이터를 조회할지 명시되어 있습니다.

 마지막으로 EXECUTOR에서 XASL을 해석하여 heap_next(), index_scan_next()등의 operation을 실행합니다. 이것들은 데이터를 조회하거나 저장하는 낮은 레벨의 명령입니다. 이로써 Query Process가 완료되었고 DBMS 사용자는 원하는 데이터를 얻게 되었습니다. 지금까지 내용을 요약하면 아래 그림과 같습니다.

query process.jpg

 

CUBRID의 query Process를 간략하게 나타낸 것이며, 각 회색 박스 안에 두 번째 줄에 적힌 함수가 각 단계의 시작지점이므로 참고하기 바랍니다. Query Process의 작업을 요약하면 아래와 같습니다.

- PASER 단계를 통해 parse tree 구조체(PT_NODE)가 생성 
- SEMANTIC CHECK를 통해 정보가 추가된 parse tree가 생성
- REWRITER 단계를 통해 최적화된 parse tree로 변형 
- OPTIMIZER에서 어떻게 조회할지에 대한 PLAN을 생성 
- XASL GENERATOR에서 실행 가능한 XASL를 생성
- EXECUTOR에서 XASL을 실행하여 원하는 데이터 조회

 

PARSER


parser는 text인 SQL을 parsing 하여 parse tree를 생성합니다. 오픈소스 'BISON'을 사용하며, PT_NODE 구조체를 반복 사용하여 tree를 구성합니다. 아래는 간단한 SQL에 대해 parser가 parse tree를 생성한 예시입니다.
parser.jpg

 

위 그림에서 하나의 BOX는 PT_NODE 구조체를 나타냅니다. 파란색 부분은 PT_NODE.node_type 이고, 하늘색 부분은 PT_NODE.info 공용체를 나타낸 것입니다. PT_NODE 구조체는 node_type에 따라 공용체인 info의 선택되는 변수가 달라집니다. 예를 들면 'PT_SELECT'는 info.query를 사용하고, 'PT_EXPR'은 info.expr을 사용합니다. 다양한 parse tree의 구조를 확인하기 위해서는 parser_main() 함수 실행 이후 결과에 대해서 PT_NODE 구조체를 확인해 봐야 하는데, text 기반인 gdb보다는 DDD(display data debuger)를 사용하는 것을 추천합니다.

parsing은 BISON을 통해 진행됩니다. BISON의 동작 원리에 대한 이해는 아래 링크를 통해 확인하기 바랍니다. 
https://www.gnu.org/software/bison/manual/html_node/index.html

parse tree를 생성하는 과정에 자연스럽게 syntax check가 진행되며, 간단한 rewrite도 진행됩니다. 위 예시는 조회조건의 변경이 있었습니다. 새로운 sql 구문의 추가나 변경 시에 parser의 수정이 있어야 하는데 csql_lexer.l, csql_grammar.y 파일의 수정이 필요합니다. csql_grammar.y에서 grammar의 action 부분에는 PT_NODE를 생성하는 로직이 포함되어 있으니 관련 있는 키워드를 통해 로직을 확인하는 것이 중요합니다.  

 생성된 parse tree를 체크하기 위해 tree를 탐색해야 하는데 parse_walk_tree() 함수가 이를 수행합니다. pre-order와 post-order 함수를 인자에 추가 할 수 있어 tree를 탐색하며 적절한 동작을 할 수 있습니다. 또한 node_type에 따라 어느 info의 공용체가 사용되는가에 대해서는 parse_walk_tree()에서 적용되는 apply 함수를 확인하면 되는데,  pt_init_apply_f() 함수에서 어떠한 apply 함수가 적용되는지 확인할 수 있습니다. 예를 들면 'PT_SELECT'의 경우 pt_init_apply_f() 함수에서 확인하면 pt_apply_select()를 사용하는 것을 알 수 있는데 해당 함수에서 info의 어느 변수를 사용하는지 확인이 가능합니다.

 

PRE FETCH


타 DBMS와 차이를 보이는 것은 'PRE FETCH' 단계가 있는 것입니다. 이 단계를 SEMANTIC CHECK의 한 부분으로 생각해도 되겠습니다.
CUBRID는 CAS와 CUBRID server가 분리된 3-tier 구조이기 때문에 TABLE의 스키마 정보 등 meta-data에 대한 client(CAS)와 server(CUB_SERVER)의 동기화가 필요합니다. SQL에 포함된 테이블 정보에 대해서 CAS가 cub_server에 요청하여 데이터를 받고 CAS의 work space공간에서 해당 데이터를 cache하여 사용합니다.

 

pre fetch.jpg

위 그림은 cub_server와 CAS 간에 meta-data를 주고받는 흐름을 나타낸 것입니다.

1. QUERY가 입력되면 pre_fetch에서 CAS의 work space에 해당 table이 cache되어 있는지 확인
   1.1 cache되어 있음 : CHN(cache coherency number)번호를 server에 전송하여 최신 object임을 확인. 아닐경우 server로 부터 object 수신
   1.2 cache되어 있지 않음 : server로 부터 object 수신
2. CAS의 work space에 Classname_cache라는 전역변수에 해당 object를 cache함
   2.1 Ws_commit_mops에는 해당 transcation에 관련 있는 object를 linked list로 관리함.
3. commit 시 : Ws_commit_mops의 object 삭제
   3.1 rollback 시 : Classname_cache에서 해당 transation의 관련 있는 object를 decache함.

PRE FETCH는 CUBRID가 3-tier로 구성되어 있기 때문에 필요한 단계입니다. 분산 처리 측면에서 의미가 있는 단계입니다.

SEMANTIC CHECK


SEMANTIC CHECK 단계에서는 크게 3가지 작업을 진행합니다.
 첫 번째는 테이블명등의 정보를 체크하고 관련 정보를 추가하는 것입니다. 이렇게 테이블명 혹은 칼럼명과 같이 schema정보에서 참조하는 정보는 pt_node의 node_type이 PT_NAME으로 생성됩니다. 즉 node_type이 PT_NAME인 node에 대해서 체크하고 정보를 추가하는 작업이 필요합니다. pt_resolve_names() 함수에 관련 작업을 진행합니다.
 두 번째는 type을 체크하는 작업입니다. 스키마의 등록된 type과 이에 대칭되는 상수 혹은 다른 칼럼의 type이 호환 가능한지 확인하고 필요에 따라 CAST 함수를 추가해줍니다. type check에는 문자열의 charset과 collation도 포함됩니다. pt_semantic_type() 함수에서 관련 작업을 진행합니다.
 세 번째는 constant fold입니다. 상수만으로 구성된 함수나 연산 등을 EXECUTOR 단계에 가기 전에 미리 처리합니다. 예를 들면 'select 1+2 from dual'에서 1+2의 연산을 미리 계산하여 3으로 변환합니다.  CUBRID에서는 CAS에서 따로 수행되기 때문에 DB SERVER의 부하를 줄여주는 역할을 합니다. pt_fold_constants_post() 함수에 관련된 주요 소스 코드가 있습니다.
그 외에도 많은 체크나 변환이 포함되어 있습니다만 주요 내용을 요약하면 SEMANTIC CHECK는 스키마와 같은 meta data를 parse tree에 추가하고 그 과정에서 문제시 semantic error를 발생하는 단계입니다.

 

 

REWRITER (QUERY TRANSFORMATION)


REWRITER 단계에서는 SQL을 재작성합니다. parse tree에서 특정 패턴을 인식하고 그 구조를 변경하는 작업입니다. 주로 SQL의 성능 향상을 위한 작업입니다만, 이후 단계의 작업을 위해 변환하는 항목도 있습니다. 많은 변환 패턴이 있지만 몇 가지만 소개하겠습니다.

- predicate의 형식을 CNF(Conjunctive Normal Form)로 변환
- view를 view spec으로 derived table 변환
- predicate의 상수 변수를 host 변수로 치환
- uncorrelated subquery를 join으로 변환
- sub-query 밖의 관련 조회조건을 안으로 이동 
- 그 외 다수의 변환이 있음 

여기서 CNF변환과 view의 변환은 이후 작업 진행을 위해 진행되는 재작성입니다. 조회 조건을 CNF로 변환하는 것은 인덱스 스캔의 대상을 효과적으로 찾기 위함입니다. CNF는 논리곱 표준형으로 'AND'로 묶인 조회조건입니다. 아래 예시를 보면 CNF와 DNF의 차이를 확인할 수 있습니다.

(col1=1 or col2=1) AND (col3=1 or co4=1)       ==> CNF
(col1=1 and col2=1) OR (col3=1 and col4=1)   ==> DNF

CUBRID는 모든 조회 조건을 CNF로 변환하려는 시도를 하며, CNF로 변환되거나 작성된 조회조건만 인덱스 스캔의 대상이 됩니다. 이론상 모든 DNF는 CNF 변환이 가능하지만 조회조건의 개수가 늘어날 수 있는데 CUBRID는 한 개의 조회조건의 변환된 결과가 100개를 초과하면 해당 조회조건을 변환하지 않습니다.
rewriter.jpg  
위 그림에서 빨간색 박스 부분을 보면 predicate가 CNF 변환이 적용된 것을 볼 수 있습니다. 위 그림의 predicate는 'col1=1 and col2=1' 으로 그 자체로 CNF이므로 predicate의 자체는 변경되지 않았지만, 'AND','OR'와 같은 logical operation의 변경이 있었습니다. parser에서는 logical operation을 하나의 PT_NODE로 표현했지만, 변환된 이후에는 next(AND)와 or_next(OR) 포인터를 사용하는 구조로 변경되었습니다. 이러한 구조로 변경되었기 때문에 이후 predicate 검색은 아래와 같이 수행됩니다. 'PT_AND'와 'PT_OR' operation을 가지는 predicate는 cnf 변환이 안 된 것입니다.

while PT_NODE.next
   predicate 처리
   while PT_NODE.or_next
     predicate 처리

이 이외에도 다양한 재작성이 진행됩니다. qo_optimize_queries() 함수에 대부분의 재작성 소스 코드가 작성되어있습니다. 해당 함수의 진행 이전과 이후의 tree를 비교하여 어떠한 재작성이 진행되었는지 확인 할 수 있습니다. 또한 plan 정보에서 재작성된 SQL을 text 형태로 확인 할 수 있습니다.

 

OPTIMIZER


OPTIMIZER는 어떻게 DATA를 검색하는 것이 최적인지 예측하고 그 정보를 PLAN에 저장합니다. 관련 정보는 크게 3가지입니다. 첫째는 한 테이블에 대한 access method입니다. index scan, heap scan 등이 이에 해당합니다.  두 번째는 테이블의 join 순서입니다. 그리고 세 번째는 join method입니다. Nested loop join이나 sort merge join이 이에 해당합니다. 이러한 정보를 얻기 위해서 모든 가능한 plan의 cost를 측정하고 가장 낮은 cost를 갖는 PLAN을 결정합니다. 이를 위해 parse tree를 query graph 형태로 저장하게 되는데 아래에 매칭되는 주요 용어를 간단하게 정리하였습니다.

 

- NODE : table
- TERM : predicate(조회조건)
- SEGMENT : column
- EQCLASS : join predicate's columns

cost의 계산은 칼럼의 1 / Number of Distinct Value(NDV) 을 선택도(selectivity)로 사용합니다. 모든 데이터가 고르게 분포되어 있다고 가정하고 데이터 조회 이전에 몇 개의 행이 조회될지 예측하는 것입니다. 상대적으로 적은 행을 가지는 테이블을 먼저 조회하는 것이 유리할 가능성이 높습니다. 먼저 term(predicate)에 대해서 cost를 계산 및 인덱스 스캔이 가능 여부 등을 체크합니다. 관련 함수는  qo_analyze_term()입니다. term에 대한 분석이 완료되면 node(table)들을 순회하며 생성될 수 있는 모든 경우의 plan의 cost를 비교하고 그중 가장 최적의 plan을 결정합니다. planner_permutate()에서 그 작업을 진행합니다.

optimizer.jpg
위 그림은 join 순서가 A->B이고, index join method가 선택되었을 때 plan 객체를 나타낸 것입니다. 한 박스는 QO_PLAN 객체이고 파란색 부분이  plan_type, 그 밑의 부분이 공용체인 plan_un 정보입니다. parser의 PT_NODE와 비슷하게 plan_type에 따라 공용체 plan_un의 정보가 달라지는 구조입니다.
PLANTYPE_SCAN에는 각 테이블의 scan_method와 인덱스 관련 term이 저장됩니다. term(조회조건)은 인덱스 스캔 가능 여부에 따라 key range, key filter, data filter로 나눌 수 있습니다. 이것이 각각 term, kf term, sarg term에 저장됩니다. PLANTYPE_JOIN에는 outer와 inner 테이블 정보 및 join method 정보가 포함되어 있습니다. 그리고 마지막으로 PLANTYPE_SORT에 order by 절 관련된 내용이 생성됩니다.

 

XASL GENERATOR


XASL은 eXtensional Access Specification Language의 약자입니다. CUBRID는 EXECUTOR에서 이 XASL을 해석하여 원하는 데이터를 얻습니다. 접근 사양이라는 것은 어떻게 그리고 어떤 데이터를 접근할 것인가에 대한 정보이고, 이것은  OPTIMIZER에서 생성된 PLAN과 parse tree에 저장되어 있습니다. 이 두 가지 정보를 종합하여 XASL 형태로 저장합니다. XASL generator를 OPTIMIZER 단계의 부분으로 생각해도 무리는 없을 것 같습니다. 

 

xasl generator.jpg
위 그림은 JOIN  순서가 A->B->C일 때 생성된 PLAN을 가지고 XASL_NODE가 생성되는 모습을 나타낸 것입니다. 한 개의 XASL_NODE는 한 개의 access spec을 가지고 이는 한 개의 테이블 조회에 대한 정보를 담는다고 생각하는 것이 이해가 쉬울 것 같습니다. 물론 partition table 같은 경우 한 개의 XASL_NODE 여러 개의 access spec을 가질 수 있습니다. 일반적으로 SQL에서 table이 존재할 수 있는 위치는 FROM절 입니다. 이것은 join 형태로 작성될 수도 있고, sub query로 작성될 수 있습니다. 위 그림에서는 join으로 연결되어 있으며 이것이 scan_ptr로 연결된 것을 확인 할 수 있습니다. 이러한 XASL_NODE를 연결하는 주요 포인터는 아래와 같습니다.

- APTR : uncorrelated sub query
- DPTR : correlated sub query 
- SCAN_PTR : join

correlated sub query는 외부에 참조하는 칼럼이 있는 것이며, uncorrelated sub query는 외부 참조 칼럼이 없는 것을 뜻합니다.

SELECT 1 
   FROM TBL1 A
              ,(SELECT * FROM TBL2  WHERE COL1 = A.COL1) B
              ,(SELECT * FROM TBL3 WHERE COL1 = 3) C

위에서 B는 correlated sub query이고, C는 uncorrelated sub query입니다. sub query를 구분한 이유는 correlated sub query의 경우 참조되는 데이터가 먼저 조회돼야 하므로 scan의 순서가 정해집니다. 반면에 correlated sub query는 그런 순서의 제약이 없어 가장 먼저 scan을 진행 할 수 있습니다. 위 그림은 join만 존재 하기 때문에 scan_ptr만 사용되었는데, sub query가 사용되면 그 성격에 따라 aptr과 dptr로 XASL node가 연결됩니다. 대부분의 SQL이 3가지 pointer로 XASL_NODE를 연결하는 것으로 표현이 가능합니다.

 

EXECUTOR


XASL을 해석하여 data를 조회하거나, 저장, 변경하는 단계입니다. Volcano model (Iterator Model)로 구현되어 있는데, 이는 데이터를 조회하는 데 있어 연관된 join, sub query, predicate의 평가를 진행하여 하나의 행을 확정하고 다음 행의 조회를 이어서 수행하는 구조입니다. qexec_execute_mainblock()함수가 이 단계의 시작 지점입니다.

 

executor.jpg
위 그림은 SQL에서 XASL이 생성되고 이를 실행하는 순서를 나타낸 것입니다. 아래와 같은 순서로 scan이 진행됩니다.

1) join의 순서가 첫 번째인 tab a의 XASL node가 시작 node가 된다.

2) tab a node의 aptr인 빨간색 박스의 node가 먼저 scan 되어 결과를 temp file에 저장한다.

3) tab a node에 대한 scan이 진행되고 1row 조회한다.

4) join 관계인 tab b node에 대해서 위 단계에서 1row 조회된 데이터를 사용하여 scan을 진행한다.

5) 이전 조회 결과set을 사용하여 dptr인 tab c node를 scan한다.

6) 지금까지 조회된 1row의 대한 결과를 temp file에 저장한다.

7) (3)단계로 이동하여 새로운 1row를 조회하고 전체 row가 조회될 때까지 반복한다.

aptr과 dptr과 같은 sub-query pointer는 독립적인 XASL_NODE입니다. 그래서 시작지점과 동일한 qexec_execute_mainblock() 함수를 호출합니다. 이에 반해 join은 main block과 연결되어 여러 테이블의 스캔을 같이 수행하여 하나의 행을 생성합니다. 호출되는 함수는  qexec_execute_scan()입니다. 하나의 행이 결정되어 저장되는 것은 qexec_end_one_iteration() 함수에서 진행됩니다.

 

지금까지 CUBRID의 Query Process에 대해서 개괄적으로 설명하였습니다. 다음에는 조금 더 자세히 각 단계의 상세 내용에 관해서 이야기해보겠습니다.


  1. 이노베이션 아카데미와 CUBRID의 산학협력

    이노베이션 아카데미 (42서울) 42SEOUL(42서울)은 아키텍트급 소프트웨어 인재를 양성하는 것을 목적으로 하는 교육 과정이며, 프랑스에서 시작된 에꼴42의 교육 방식 및 인프라를 수입하여 운영하는 형태를 띈다. 에꼴42(Ecole 42)는 프랑스의 대형 통신사 CEO이기도 한 자비에 니엘(Xavier Niel)이라는 억만장자가 프랑스에서 2013년에 설립했다. 설립 당시에도 자기주도 학습 및 동료 평가를 내세운 무료 소프트웨어 교육 기관이라는 점으로 주목받았다. 현재는 브라질, 미국, 일본 등 세계 여러 곳에도 42 캠퍼스가 있다. 2019년에 대한민국 서울에도 42 서울 캠퍼스가 들어왔다. 42의 특징 중 하나로, 자기주도적 학습을 지향하기에 교재나 교수가 따로 없고 모든 것은 스스로 인터넷 또는 각종 도서 등을 통하거나 동료들과의 협업 및 교류를 통해 학습을 하게끔 유도한다. 교육생들 스스로 방법을 찾아 나아가라는 의도이며, 정해진 교재 및 교수가 없기 때문에 필연적으로 많은 삽질과 불분명한 요구사항을 맞닥뜨리게 된다. 심지어 문제를 풀어야 하는데, 뭘 배우고 공부해야 하는지 조차도 제대로 알려주지 않는다. 이는 소프트웨어 현장을 그대로 모방하여 실전 경...
    Date2022.02.22 Category알려요~ By민준 Views284 Votes0
    Read More
  2. Scouter를 통한 CUBRID 모니터링

    Scouter를 통한 CUBRID 모니터링 Scouter 확장을 통해 CUBRID에 항목을 모니터링할 수 있습니다. CUBRID 11.0 버전을 기준으로 개발되었으며, CUBRID 10.2.1 버전부터는 전체 기능을 사용할 수 있습니다. Scouter(Server, Client)는 2.15.0 버전부터 기능 사용이 가능하며, 추후에도 Scouter Github에 참여하여 버그 수정 및 기능이 추가됩니다. 현재(2022-01-10) 2.15.0 버전이 최신 버전이며, Multi Agent 지원 및 버그 수정 내용이 PR 되어 있는 상태입니다. 1. Scouter 란? Scouter는 Open Source APM(Application Performance Management) 이며, 어플리케이션 및 OS 자원등에 대한 모니터링 기능을 제공합니다. Scouter 기본 구성 Scouter 제공 정보 ​- WAS 기본 정보 각 요청의 응답속도 / 프로파일링 정보, 서버 요청 수 / 응답 수, 처리 중인 요청 수, 응답속도의 평균, JVM 메모리 사용량 / GC 시간 , CPU 사용량 - 프로파일링 정보 서버 간 요청의 흐름, 각 SQL 쿼리의 수행 시간 / 통계, API 호출 수행 시간, request header 정보, 메소드 호출 시 수행 시간 대표적인 Agent 목록 - Tomcat Agent (Java Agent) : JVM 과 Tomcat WAS 성능 수집 - Host Agent (OS Agen...
    Date2022.01.10 Category제품 여행 Byhwanyseo Views1712 Votes0
    Read More
  3. [CUBRID] QUERY CACHE에 대해

    QUERY CACHE에 대해 큐브리드 11.0 버전이 출시되면서 QUERY CACHE 힌트를 지원하게 되었습니다. 이 글에서는 QUERY CACHE에 대해 알아보는 시간을 가져보겠습니다. 1. QUERY CACHE란? Query Cache는 SELECT 쿼리문을 이용하여 조회한 값을 저장하고 있다가, 같은 쿼리 문을 요청하였을 때 미리 캐싱된 값을 반환하는 DBMS 기능입니다. 자주 변경되지 않는 테이블이 있고 동일한 쿼리를 많이 받는 환경에서 매우 유용하게 사용될 수 있습니다. QUERY_CACHE 힌트를 사용한 쿼리는 전용 메모리 영역에 캐시되고 그 결과도 별도의 디스크 공간에 캐시됩니다. 쿼리 캐시 특징 1. QUERY_CACHE 힌트는 SELECT 쿼리에만 적용됩니다. 2. 테이블에 변화(INSERT,UPDATE,DELETE)가 일어나게 되면 해당테이블과 관련된 Query Cache내의 정보들은 초기화 됩니다. 3. DB를 내리면 Query Cache는 초기화 됩니다. 4. max_query_cache_entries와 query_cache_size_in_pages 설정 값을 통해 캐시될 크기를 조절할 수 있습니다. (default 값은 모두 0 입니다.) max_query_cache_entries는 최대 캐시할 수 있는 질의 개수에 대한 설정 값으로 1이상으로 설정되면 설정된 수 만큼의 질의가 캐시됩니...
    Date2021.10.29 Category제품 여행 By김민종 Views1546 Votes1
    Read More
  4. [CUBRID inside] HASH SCAN Method

    - HASH SCAN Hash Scan은 hash join을 하기 위한 스캔 방법입니다. view 혹은 계층형 질의에서 Hash Scan이 적용되고 있습니다. view와 같은 부질의가 inner로써 조인될 경우 인덱스 스캔을 사용할 수 없는데, 이 경우 많은 데이터를 반복 조회 하게 되면서 성능 저하가 발생됩니다. 이때 Hash Scan이 사용됩니다. 위 그림은 인덱스가 없는 상황에서의 Nested Loop join과 Hash Scan의 차이를 보여줍니다. NL join의 경우 OUTER의 Row수만큼 INNER의 전체 데이터를 스캔합니다. 이에 반해 Hash Scan은 해시 자료구조 빌드 시 INNER 데이터를 한번 스캔하고, 조회시 OUTER를 한번 스캔합니다. 그렇기 때문에 상대적으로 매우 빠르게 원하는 데이터를 조회할 수 있습니다. 여기서는 Hash Scan의 내부 구조를 프로그램 개발 진행 과정의 흐름으로 작성하였습니다. - IN-MEMORY HASH SCAN CUBRID의 Hash Scan은 데이터양에 따라서 in-memory, hybrid, file hash의 자료 구조를 사용하고 있습니다. 먼저 in-memory 구조부터 살펴보겠습니다. memory의 장점은 random access시 성능 저하가 없다는 점입니다. 하지만 단점은 메모리 크기가 한정되어 있다는 것입니다. 단점 때문에 모든...
    Date2021.10.25 Category제품 여행 By박세훈 Views533 Votes2
    Read More
  5. CUBRID TDE(Transparent Data Encryption)

    CUBRID 11버전에 "TDE(Transparent Data Encryption)"가 추가되었습니다! 2021년 1월 출시된 CUBRID11에 TDE가 생김으로써 보안이 한층 강화되었는데요, TDE란 무엇일까요?! Transparent Data Encryption(이하: TDE) 의 약자로 사용자의 관점에서 투명하게 데이터를 암호화하는 것을 의미합니다. 이를 통해 사용자는 애플리케이션의 변경을 거의 하지 않고 디스크에 저장되는 데이터를 암호화할 수 있습니다. 어떤 해커가 한 조직을 해킹했을 때, 훔쳐가고 싶은 것 1위는 당연히 데이터베이스 내에 있는 중요한 데이터일 것입니다. 또는 회사 내부의 악의적인 의도를 가진 직원이 데이터베이스에 로그인하고 USB와 같은 저장매체에 모든 데이터를 옮겨가는 상황이 있을 수도 있습니다. 이러한 상황들에서 데이터를 보호할 수 있는 가장 쉬운 방법은 데이터베이스를 암호화하는 것인데요, 암호화 기술 중 데이터베이스 파일 자체를 암호화하는 기술인 TDE가 좋은 선택이 되겠죠?! 암호화된 데이터베이스는 키가 없으면 접근할 수 없기 때문에, 이 키 파일을 함께 가지고 있지 않다면 도난당한 파일은 쓸모없는 더미 파일이 될테니까요. TDE 암호화 기능은 대칭키 알고리즘을 사...
    Date2021.05.20 Category제품 여행 By김지원 Views1399 Votes1
    Read More
  6. CUBRID의 개발 문화: CUBRID DBMS는 어떻게 개발되고 있을까?

    시작하며 안녕하세요, 유형규 선임연구원입니다. 이번 포스트에서는 먼저 큐브리드 프로젝트의 개발 프로세스를 소개하고, 프로세스를 개선하기 위한 노력과 개발 문화를 소개하려고 합니다. 큐브리드에 입사한 지 벌써 거의 2년 반이 흘렀습니다. 처음 입사했을 때 하나의 팀이었던 개발 조직도 어느새 대단한 동료 개발자분들이 많이 입사하면서 세 개발팀과 QA팀까지 규모가 제법 커지면서 새로 합류한 신입 동료 개발자분들도 많아졌습니다. 입사 후 첫 메이저 버전 릴리즈를 경험하면서 릴리즈 과정을 돌아보며 동료 개발자들과 큐브리드의 개발 프로세스를 조금 더 개선하게 되었습니다. 오픈소스 데이터베이스 프로젝트, CUBRID의 개발 프로세스 큐브리드는 오픈소스 프로젝트 입니다. 큐브리드는 참여, 개방, 공유의 가치를 지향하며 이를 실현하기 위해 정보의 공유와 프로세스의 투명성은 큐브리드의 개발 프로세스와 문화에 녹아있습니다. 큐브리드에 기여하는 모든 개발자는 오픈소스 프로젝트 개발 프로세스를 기반으로 개발을 진행합니다. 이 의미는 큐브리드 사내의 개발자든 큐브리드에 외부 기여자 (컨트리뷰터) 모두 동일한 과정으로 개발을 진행한다는 것입...
    Date2021.04.29 Category오픈소스 이야기 By유형규 Views1456 Votes1
    Read More
  7. CUBRID를 이용한 스니핑 방지 - 패킷암호화

    보안의 필요성 현대인들은 일상생활에 깊숙이 파고든 PC와 스마트폰으로 웹 서핑을 즐깁니다. 그러다 보니 인터넷상에 전송 중인 데이터를 악의적인 의도로 데이터를 엿볼 수도 있습니다. 즉, 누군가가 전송 중인 데이터를 엿볼 수 있는 것을 스니핑(sniffing)이라고 합니다. 대표적으로 계정의 id, pw를 가로채 타인의 개인 정보를 이용하여 물리적인 손해 입히는 사례가 있습니다. 이에 대해 CUBRID는 사용자 데이터를 보호하기 위해서 패킷 암호화를 제공합니다. 패킷 암호화를 적용하면 전송할 데이터에 대해 패킷이 암호화되어 전송됨으로써 누군가 스니핑(sniffing) 하더라도 데이터를 해석할 수 없게 구현할 수 있습니다. CUBRID 패킷암호화 CUBRID는 클라이언트와 서버 간에 전송되는 데이터를 암호화하기 위해 SSL/TLS 프로토콜을 사용합니다. SSL은 대칭형(symmetric)키를 이용하여 송수신 데이터를 암호화합니다. (클라이언트와 서버가 같은 세션키를 공유하여 암복호함). 클라이언트가 서버에 연결할 때마다 새롭게 생성되는 세션키 생성에 필요한 정보를 암호화한 형태로 교환하기 위해서 비 대칭 (asymmetric) 암호화 알고리즘을 사용하며, 이를 위해서 서버의 ...
    Date2021.04.28 Category제품 여행 By황영진 Views2401 Votes1
    Read More
  8. ANTLR, StringTemplate를 사용해서 PL/SQL을 CUBRID Java SP로 변환하기

    ANTLR, StringTemplate를 사용해서 PL/SQL을 CUBRID Java SP로 변환하기 CUBRID DBMS(이하 'CUBRID')는 PL/SQL을 지원하지 않습니다. PL/SQL 문법으로 함수나 서브 프로그램을 만들어서 해왔던 작업들을 CUBRID에서 하려면 Java Stored Function/Procedure(이하 'Java SP')으로 변환해야 합니다. 데이터베이스 개발자나 관리자, 엔지니어는 PL/SQL 문법에는 친숙하지만 프로그래밍 언어에는 친숙하지 않은 경우가 대부분입니다. 또한 어플리케이션 개발은 사용하는 DBMS에 따라 달라지는 부분이 거의 없지만 PL/SQL을 Java SP로 변환하는 것은 새로운 시스템을 개발하는 느낌을 받아서 어려움을 느끼는 것 같습니다. 그래서 PL/SQL 을 Java SP 쉽게 변환하는 방법에 대해서 찾아보던 중 ANTLR에 대해서 알게 되었습니다. ANTLR는 파서를 만드는 도구입니다. 전세계에 있는 컨트리뷰터들로부터 도움을 받아서 다양한 프로그래밍 언어들의 파싱할 수 있도록 문법 파일들을 지원하고 있습니다. 공식 홈페이지에서는 ANTLR에 대해서 아래와 같이 소개하고 있습니다. "ANTLR (ANother Tool for Language Recognition)은 구조화 된 텍스트 또는 이진 파일을 읽고, 처...
    Date2020.12.31 Category오픈소스 이야기 By주영진 Views2799 Votes2
    Read More
  9. [CUBRID inside] Query Process란?

    CUBRID는 open source DBMS입니다. 소스 코드가 공개되어 있어 언제든지 확인하고 기여할 수 있습니다. 많은 사람이 CUBRID의 contributor가 되길 바라봅니다. Query Process란? Query Process는 DBMS의 입력값인 SQL을 낮은 수준의 명령으로 변환하고 그것을 실행하는 전체 작업을 말합니다. SQL에서 가장 먼저 진행되어야 하는 것은 TEXT로 작성된 SQL을 parse tree 구조로 만드는 것입니다. 이 작업은 PARSER에서 진행되는데, CUBRID는 PT_NODE 구조체를 반복적으로 사용하여 SQL을 parse tree로 변환합니다. 이 단계에서 syntax check가 진행되고 오타나 잘못된 예약어 등을 체크합니다. 그리고 SEMANTIC CHECK를 진행하는데, 여기서 작성된 테이블명이나 칼럼명 등이 존재하는 것인지 체크합니다. 다음으로 OPTIMIZER가 parse tree를 최적화하고 PLAN을 생성합니다. parse tree를 최적화하는 것을 QUERY REWRITE 혹은 TRANSFORMATION이라고 합니다. 좋은 성능을 위해 SQL을 다시 작성한다고 생각하면 됩니다. 동일한 데이터를 조회하는 SQL은 다양한 형태로 작성될 수 있습니다. 그렇기 때문에 가장 효과적인 방안으로 변환을 하는 것입니다. 여러 재작성 방법이 있는데 ...
    Date2020.12.24 Category제품 여행 By박세훈 Views1130 Votes1
    Read More
  10. 파일이 정상인가 ?

    기술 지원 시 파일 변조 또는 손상 되어 골치 아픈 경우가 간혹 발생 합니다. - 고객사 지원을 위해 파일을 반입하는 경우 CD 손상으로 인한 파일 손상 - 보안 프로그램(DRM,EFS)에 의한 파일 변조 - 네트워크를 통한 파일 전송 시 파일 손상 파일 변조 또는 손상이 발생하면, 파일 크기가 크게 변하지 않으며 정합성 여부를 명확하게 확인 할 수 없습니다. 이로 인해 기술 지원 시 뭐가 문제인지 당황스러울 때가 있는데요. 이와 같은 상황에서 불필요한 시간 발생을 최소화 할 수 있는 방법에 대해 기술 하였습니다. 무결성 검사 파일이 변조 되어 있지 않다는 검사를 하기 위해 여러가지 방법들이 있습니다만, 가장 효율적이고 쉬운 방법을 소개하겠습니다. md5 (MD5 128비트 해쉬 암호화 함수)툴은 Windows, Linux, OS X 등 많은 시스템에서 기본적으로 설치 되어 있습니다. 참고 자료 MD5-위키백과 : https://ko.wikipedia.org/wiki/MD5 암호화 해쉬 함수-위키백과 : https://ko.wikipedia.org/wiki/%EC%95%94%ED%98%B8%ED%99%94_%ED%95%B4%EC%8B%9C_%ED%95%A8%EC%88%98 사용 방법 Windows * 실행 > cmd certutil -hashfile <filename> <hash functuin> * ex cmd> certut...
    Date2020.08.29 Category제품 여행 By윤준수 Views2395 Votes1
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 ... 16 Next
/ 16

Contact Cubrid

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