NEWS
-
Read More
공공부문 DBMS 정보자원 현황
행정안전부/한국지능정보사회진흥원(NIA)에서는 매년 '범정부EA기반 공공부문 정보자원 현황 통계보고서'를 발간합니다. 2022년도 통계보고서는 금년 7월 초에 공개가 되었으며, 최근에 전자신문에서 통계보고서를 기반으로 한 스페셜리포트 기사(공공SW 외산 쏠림 해법은?)를 게재하였습니다. 전자신문 기사에서 공공SW 외산 쏠림 해법으로 2가지를 제시했습니다. 오픈소스 소프트웨어를 활용하여 외산 종속을 탈피하거나 공공부문 SaaS 국산화를 추진하자는 것입니다. 사실 국내 SW 산업은 정보보호, 관제 등 일부 분야를 제외하고 OS, DBMS, WEB/WAS, 백업 등 대부분의 영역에서 외산 편중이 높은 상황입니다. 이제부터 DBMS에 한정해서 조금 더 살펴보겠습니다. 아래 데이터는 2021년 기준이며, Oracle이 63.6%로 여전히 1위 자리를 지키고 있으며, 이어서 Microsoft (SQL Server), 큐브리드, 티맥스데이터(Tibero)가 순위를 차지하고 있습니다. [출처 : 2022년도 범정부EA기반 공공부문 정보자원 현황 통계보고서, 55쪽] 비록 Oracle와 Microsoft의 수량 점유율이 약 80%로 쏠림 현상이 강하게 나타나고 있으나, 큐브리드와 티맥스데이터의 수량을 합치면 15%가 ... -
Read More
[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시 성능 저하가 없다는 점입니다. 하지만 단점은 메모리 크기가 한정되어 있다는 것입니다. 단점 때문에 모든... -
Read More
2018년 CUBRID 정기교육을 마무리 하며..
큐브리드에서는 매년 정기적으로 정기교육을 실시하고 있습니다. 금년도에는 공개SW개발자센터에 공개SW커뮤니티를 등록하여 커뮤니티 활성화 및 큐브리드를 사용자를 위한 교육을 진행했습니다. 정기교육이 어떻게 진행되고 있는지, 커리큘럼, 자주 듣는 궁금증 등에 대해 알아보겠습니다. 『2018년 정기교육 일정』 일시 장소 참석인원 03월 20일 ~ 21일 공개SW역량프라자(상암) 23명 05월 29일 ~ 30일 공개SW개발자센터(선릉) 06명 09월 04일 ~ 05일 공개SW역량프라자(상암) 24명 10월 16일 ~ 17일 공개SW역량프라자(상암) 13명 정기교육은 2일 과정으로 4회 진행되며, 교육에 참여해주신 분들에게 교육 교재와 자료를 나눠드리고, 점심식사도 제공하고 있습니다. 『신청방법』 http://www.cubrid.com/education에서 일정을 확인할 수 있으며, 교육일정 1개월 전에 온라인 신청을 오픈합니다. 『커리큘럼』 다음과 같이 1일차, 2일차로 교육내용이 다르며, 2일동안 교육을 참여해주시는 것이 도움이 됩니다. 또한 실습과정도 포함되어 있습니다. 2일 과정을 수료해주신 분들에게는 큐브리드에서 발급한 수료증을 나눠드립니다. 1일차 CUBRID 소개 ... -
Read MoreNo Image
CSQL에서 PreparedStatement 사용하여 Query Plan 확인하기
CSQL에서 PreparedStatement 사용하여 Query Plan 확인하기 Prepare statement를 이용하여 값을 질의에 포함하지 않고 bind 했을 경우와 질의상에 값을 직접 포함하였을 경우, 일부 상황에서 값에 대한 해석이 모호해져 질의 플랜이 다르게 만들어져 질의의 성능이 달라지는 경우가 있습니다. 이를 위해 csql 에서 prepare statement 사용하는 방법을 정리하였습니다. 아래 확인 예시는 11.2 에서 해결된 부분이나, 그 이전 부분에서 질의 수행 계획이 달라졌음에 대한 이해를 위해 사용하였습니다. CSQL에서 PreparedStatement 사용 1. Prepared Statement 생성 PREPARE stmt_name FROM 'sql문'; 2. Prepared Statement 실행 EXECUTE stmt_name [USING value, value2 ...]; 3. Prepared Statement 해제 {DEALLOCATE | DROP} PREPARE stmt_name; 사용 예시(2가지) 1. csql > PREPARE pstmt FROM 'SELECT 1 + ?'; csql > EXECUTE pstmt USING 4; csql > DROP PREPARE pstmt; 2. csql > PREPARE pstmt FROM 'SELECT col1 + ? FROM tbl WHERE col2 = ?'; csql > SET @a=3, @b='abc'; csql > EXECUTE pstmt USING @a, @b; csql > DROP PREPARE pst... -
Read More
CUBRID Internal: 큐브리드 데이터의 디스크 저장 (Double Write Buffer)
들어가며 데이터베이스의 데이터는 디스크로부터 메모리에 할당되어서 읽힌 다음 수정을 하기도 하고, 새로이 생성되어 메모리에 할당되는 데이터가 있다. 이러한 데이터는 결과적으로는 디스크에 저장되어야 영구적으로 저장됨을 보장할 수 있다. 이 글에서는 큐브리드에서 데이터를 디스크에 저장하는 방법 중 하나를 소개하여서 큐브리드 제품에 대한 이해를 돕고자 한다. 현재 글을 쓰는 시점의 버전은 11.2이다. Double Write Buffer Double Write Buffer의 정의, 목적, 매커니즘을 거쳐 모듈에 대해 전반적인 설명을 하고자 한다. Double Write Buffer 란? 큐브리드는 기본적으로 Double Write Buffer를 통해서 디스크에 데이터를 저장한다. Double Write Buffer는 메모리와 디스크 양쪽에 구성되어 있는 버퍼영역이다. 기본적으로 2M의 크기로 설정되어 있으며, cubrid.conf 파일 내에서 그 크기를 32M까지 조절 할 수 있다. Note 큐브리드에서는 Double Write Buffer를 사용해서 DB페이지를 디스크에 저장하는 방법과 DB 페이지를 바로 디스크에 저장하는 방법이 있다. 이번 글에서는 Double Write Buffer를 사용해서 저장하는 방법만 언급하도록 하겠다. Double Write... -
Read More
CUBRID Internal: Disk Manager #1: 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table)
이전글: CUBRID Internal: 큐브리드의 저장공간관리 (DIsk Manager, File Manager) 볼륨은 어떻게 관리될까? - 볼륨 헤더(Volume Header)와 섹터 테이블(Sector Table) - 앞선 글에서 디스크 매니저(Disk Manager)가 섹터의 예약(reservation)을 관리한다고 이야기하였다. 이번 글에서는 볼륨 내의 섹터들이 어떻게 관리되는지에 대한 구체적인 이야기와 이를 위해 볼륨이 어떻게 구성되어 있는지를 다룬다. 여기서 다루어지는 볼륨의 구조는 그대로 non-volatile memory (SSD, HDD 등)에 쓰여진다. 볼륨 구조 디스크 매니저의 가장 큰 역할은 파일생성과 확장을 위해 섹터들을 제공해주는 것이다. 이를 위해 각 볼륨은 파일들에 할당해줄 섹터들과 이를 관리하기 위한 메타(meta)데이터로 이루어져 있다. 메타데이터들이 저장된 페이지를 볼륨의 시스템 페이지(System Page)라고 하며, 볼륨에 대한 정보와 각 섹터들의 예약 여부를 담고 있다. 시스템 페이지는 다음과 같이 두가지로 분류할 수 있다. 볼륨 헤더 페이지 (Volume Header Page, 이하 헤더 페이지): 페이지 크기, 볼륨 내 섹터의 전체/최대 섹터, 볼륨 이름 등, 볼륨에 대한 정보를 지니고 있는 페이지 섹터 테이... -
Read More
CUBRID Flashback
Introduction 큐브리드 11.2 버전이 릴리즈되면서 Flashback 기능도 함께 소개되었습니다. 아래에서는 큐브리드에서 제공하는 Flashback 에 대한 기능을 이해하기 위한 Background와 흐름, 그리고 사용방법에 대해 소개해드리겠습니다. Background Supplemental logging 사용자가 트랜잭션을 수행하면 트랜잭션 로그가 기록됩니다. 트랜잭션 로그에는 사용자가 변경하기 전의 데이터 (UNDO)와 사용자가 변경한 후의 데이터 (REDO)가 저장됩니다. Flashback에서는 별도의 전용 데이터 공간을 만들기 보다는 이미 로그 볼륨에 저장된 트랜잭션 로그를 사용합니다. 트랜잭션 로그의 UNDO와 REDO를 이용해 사용자가 수행한 SQL구문을 추측합니다. 하지만 트랜잭션 로그에는 데이터베이스의 물리적인 변경에 대한 데이터만을 가지고 있기 때문에, 논리적인 단위 (SQL 구문)으로 반환해야하는 Flashback을 위해서는 추가적인 데이터가 필요합니다. 추가적인 데이터에는 트랜잭션을 수행한 사용자 정보 등이 있으며, 해당 정보는 Supplemental log를 통해 저장됩니다. 따라서, Flashback을 수행하기 위해서는 ‘supplemental_log’ 시스템 파라미터를 1 또는 2로 설정해줘야... -
Read More
CUBRID QA 절차 및 업무 방식 소개
큐브리드의 QA 절차 및 업무 방식에 대해 소개하겠습니다. CUBRID QA팀이 하는 일? QA(Quality Assurance)팀은 CUBRID의 품질 보증에 대한 전반적인 절차를 다루는 업무를 맡고 있습니다. 단순 테스트뿐만 아니라, 개발 프로세스에 직간접적인 관여와 QA Tool 확장 및 유지보수, 제품 결함 관리, 제품 릴리즈 등 제품이 출시되는 과정에서 여러가지 일을 하고 있습니다. 특히, 개발과정의 처음부터 끝까지 참여하여 품질 저하에 문제가 될 만한 부분이 있는지 검증하고, 개선안을 제안하는 등 개발 프로세스 전반적으로 개입하여 제품 품질을 높이는 일을 하고 있습니다. CUBRID QA 절차 CUBRID QA 절차는 크게 다음과 같이 볼 수 있습니다. 각 절차에 대한 상세한 과정은 다음과 같습니다. 1. Kick off 참여 -먼저, 개발팀으로부터 프로젝트를 할당 받으면, 킥오프를 참여합니다. 요구사항 및 목표를 파악하고, 사용자 관점에 부합하지 않을 경우 개선을 요청합니다. 프로젝트에 따라 검증방법이나 절차가 달라질 수도 있고 때에 따라 새로운 환경이 필요할 수 있기 때문에 여러 가지 의견들을 종합하여 팀 내 담당자를 선정합니다. 2. 테스트 환경 구축 -프로젝트를 위해 어... -
Read More
CUBRID의 개발 문화: CUBRID DBMS 프로젝트 빌드 가이드와 빌드 시스템 개선
시작하며 이전 포스팅에서 CUBRID의 개발 문화: CUBRID DBMS는 어떻게 개발되고 있을까? 라는 주제로 블로그 글을 작성했었던 기억이 납니다. 날짜를 들여다보니 2021년 4월 29일에 작성되었으니 코로나 팬데믹을 이겨내고 CUBRID에서 여러 프로젝트를 진행하느라 시간이 훌쩍 지나갔네요. 그 사이 CUBRID는 11.2 (elderberry) 버전 릴리즈를 지나 11.3 (fig) 버전 릴리즈를 앞두고 있습니다. 이번에도 마찬가지로 [CUBRID의 개발 문화]라는 말머리를 가지고 CUBRID DBMS 프로젝트 빌드에 대한 이야기를 해보려고 합니다. 이전 포스팅의 ‘CUBRID DBMS는 어떻게 개발되고 있을까?’에서 소개했던 개발 프로세스와 프로젝트 기여 가이드의 내용과 조금 주제가 달라보일 수 있는데, 프로젝트 빌드에 대한 내용이 어떻게 개발 문화로까지 이어질 수 있는지 소개해 드리려고 합니다. 빌드 준비하기 누군가 코드를 기여하려고 할 때 빌드는 가장 먼저 해야 하는 첫 발걸음이면서, 동시에 제일 첫 번째로 마주하는 어려움입니다. 먼저 개발 환경에서 프로젝트를 빌드하기 위해서 여러 도구와 라이브러리를 설치하고, 프로젝트의 빌드 방법을 알아야 합니다. 이 때 기여하려... -
Read MoreNo Image
Index의 capacity에 관한 정보 열람
Index Capacity 정보 들어가며 DBMS의 여러 기능 기능이나 구성 요소들 중에서 가장 중요한 것은 무엇일까요? Index는 '가장' 중요한은 아니더라도 적어도 '아주 아주' 중요한 요소가 아닐까 생각 합니다. Index가 없다면 데이터를 쌓아 두기만 할 수 있을 뿐 사실상 관리는 못하는 그런 시스템이 될 테니까요. 자료가 많으면 많을 수록 Index는 더 중요해 집니다. 이렇게 중요한 Index를 분석할 때에도 목적에 부합하는 여러가지 도구와 방법들이 있을 수 있습니다. 이 페이지에서는 그 중에서 Index의 Capaicty에 대한 정보를 리뷰해 보고자 합니다. 기본적인 사용 방법이나 설명은 매뉴얼을 통해 얻을 수 있으므로 여기서 설명은 생략합니다. INDEX CAPACITY 정보 얻기 우선 CUBRID에서는 Index의 Capacity 정보를 다음과 같은 두 가지 방법으로 쉽게(?) 알아 볼 수 있습니다. 1. diagdb tool ------------------------------------------------------------- BTID: {{0, 5952}, 5953}, idx0 ON dba.tbl, CAPACITY INFORMATION: Distinct Key Count: 0 Total Value Count: 0 Average Value Count Per Key: 0 Total Page Count: 2 Leaf Page Count: 1 NonLea...