Background Image
조회 수 864 추천 수 2 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

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

시작하며

이전 포스팅에서 CUBRID의 개발 문화: CUBRID DBMS는 어떻게 개발되고 있을까? 라는 주제로 블로그 글을 작성했었던 기억이 납니다. 날짜를 들여다보니 2021년 4월 29일에 작성되었으니 코로나 팬데믹을 이겨내고 CUBRID에서 여러 프로젝트를 진행하느라 시간이 훌쩍 지나갔네요. 그 사이 CUBRID는 11.2 (elderberry) 버전 릴리즈를 지나 11.3 (fig) 버전 릴리즈를 앞두고 있습니다.

이번에도 마찬가지로 [CUBRID의 개발 문화]라는 말머리를 가지고 CUBRID DBMS 프로젝트 빌드에 대한 이야기를 해보려고 합니다. 이전 포스팅의 ‘CUBRID DBMS는 어떻게 개발되고 있을까?’에서 소개했던 개발 프로세스프로젝트 기여 가이드의 내용과 조금 주제가 달라보일 수 있는데, 프로젝트 빌드에 대한 내용이 어떻게 개발 문화로까지 이어질 수 있는지 소개해 드리려고 합니다.

 

빌드 준비하기

누군가 코드를 기여하려고 할 때 빌드는 가장 먼저 해야 하는 첫 발걸음이면서, 동시에 제일 첫 번째로 마주하는 어려움입니다. 먼저 개발 환경에서 프로젝트를 빌드하기 위해서 여러 도구와 라이브러리를 설치하고, 프로젝트의 빌드 방법을 알아야 합니다. 이 때 기여하려는 개발자는 여러가지 어려움을 겪을 수 있습니다.

예를 들어:

  • (1) 나의 개발 환경에서 빌드가 가능한지 모름
  • (2) 필요한 개발 환경 (예를 들어 C++ 컴파일러), 라이브러리와 관련 도구를 어떤 것을 미리 설치해야 하는지 모름
  • (3) 빌드 필요 요소 (Build Requirements) 의 최소/권장 버전과 설치 경로를 모름
  • (4) 빌드 시스템/도구를 어떻게 사용하는지 모름

이러한 어려움에 대해서 물어보고 답을 받을 수 있는 커뮤니티 창구가 있으면 도움이 될 수도 있습니다. 하지만 대부분의 오픈소스 커뮤니티에서는 이러한 커뮤니티 창구가 없거나, 충분히 활성화 되어있지 않아서 답을 받아보지 못하거나 오랜 시간이 걸리게 됩니다. 많은 사람들이 이 단계에서 기여하기를 그만두게 될 것입니다.

 

빌드 준비를 도와주기

가이드 문서 작성하기

빌드를 시작해보기에 어려움을 겪을 수 있는 개발자를 도와주기 위해 빌드를 위한 가이드 문서를 코드와 함께 작성해야 합니다. 위의 ‘빌드 준비하기’ 에서의 어려움을 겪는 예를 기반으로 어떤 내용을 적어주면 좋을지 설명하면서 CUBRID 프로젝트의 사례를 소개합니다.

  • 나의 개발 환경에서 빌드가 가능한지 모름: 프로젝트를 빌드 가능한 OS와 그 버전에 대해 명시해주는 것이 좋습니다. 만약 주기적으로 여러 OS 환경과 버전에서 빌드 테스트를 (Continous Testing) 수행하고 있다면 그것을 보여줌으로써 더 확실한 정보가 될 수 있을 것입니다.
  • 필요한 개발 환경, 라이브러리와 관련 도구를 어떤 것을 미리 설치해야 하는지 모름: 기본적으로 C++ 컴파일러의 버전이나 자바 버전과 같은 지원하는 컴파일러와 함께 사용하는 라이브러리, 빌드 도구들을 어떤 걸 설치 해야하는지 알려주면 좋습니다. 만약 자동으로 설치된다면 어떤 것들이 설치될지도 알려준다면 혹시 이미 내 환경에 설치된 것과 충돌이 발생하지 않는지 확인할 수 있습니다. 아무런 정보 없이 빌드를 하면서 반복해서 빌드를 실패하고, 순식간에 지나가는 출력 속에서 에러를 찾아 헤매지 않도록 해야합니다.
  • 빌드 필요 요소의 최소/권장 버전과 설치 경로를 모름: 특히 ‘yum’, ‘apt’와 같은 패키지 설치 도구에서 ‘yum install g++’, 또는 ‘apt-get install cmake’와 같이 명령을 입력했을 때 리눅스 배포판이나 그 버전에 따라 기본적으로 설치되는 버전이 다르므로 빌드가 가능한 명확한 버전을 알려주어야 합니다. 또 패키지 설치 도구를 통하지 않고 라이브러리르 직접 설치하거나 빌드해야 하는 경우에는 다운로드 받을 수 있는 경로를 적어주어야 합니다.
  • 빌드 시스템/도구를 어떻게 사용하는지 모름: 프로젝트의 작성 언어나 플랫폼에 따라 다양한 빌드 도구를 사용할 수 있습니다. 자바 기반 프로젝트에서 사용하는 Ant, Maven, Gradle나 C/C++에서 Make, SCons, CMake, Ninja 등 다양한 빌드 시스템/도구가 있습니다. 이러한 빌드 시스템을 사용하여 작성한 스크립트를 처음부터 파악하기는 매우 어렵습니다. 같은 빌드 시스템을 사용하는 프로젝트라도, 빌드를 수행할 때 도구에게 넘겨주어야 하는 파라미터가 다르고 그 스크립트를 작성하는 컨벤션이 다를 수 있어 이해하지 못할 수 있습니다. 따라서 개발자가 기본적인 설정으로 쉽게 빌드해볼 수 있는 명령어나 스크립트를 제공해주어야 합니다.

CUBRID의 사례

 

guide.jpg

 

CUBRID의 경우에는 최근 fig에서 업데이트 된 README 파일에서 Linux 와 Windows 환경에서 빌드할 수 있음을 소스로 부터 빌드 가이드에서 알려주고 있습니다. CUBRID의 엔진은 주로 C++로 구현되어 있지만, 저장 루틴 기능은 Java를 사용하고 있어서 C++ 컴파일러와 JDK 버전에 대해 명시하고 있습니다.

빌드 시스템은 CMake를 사용하고 있습니다. CMake는 빌드 시스템에서 필요로 하는 파일을 유연하게 생성할 수 있는데, 그런 만큼 꽤나 어렵게 느낄 수 있습니다. 특히 빌드 도구에 넘겨줄 수 있는 여러 파라미터에 따라 디버그/릴리즈와 같이 다른 모드로 빌드할 수 있습니다. 이런 파라미터를 잘 지정할 수 있도록, 복잡한 빌드를 좀 더 쉽게 하기 위해서 CUBRID는 Linux에서 build.sh, Windows에서 build.bat을 제공하고 있습니다. 다음은 ./build.sh -h 명령어로 사용법을 출력한 예입니다.

Usage: ./build.sh [OPTIONS] [TARGET]
 OPTIONS
  -t arg  Set target machine (32(i386) or 64(x86_64)); [default: 64]
  -m      Set build mode(release, debug or coverage); [default: release]
  -i      Increase build number; [default: no]
  -a      Run autogen.sh before build; [default: yes]
  -g      Specifies the generator for a build (make, ninja); [default: make]
  -c opts Set configure options; [default: NONE]
  -s path Set source path; [default: current directory]
  -b path Set build path; [default: <source path>/build_<mode>_<target>]
  -p path Set prefix path; [default: <build_path>/_install/CUBRID]
  -o path Set package output path; [default: <build_path>]
  -j path Set JAVA_HOME path; [default: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.302.b08-0.el7_9.x86_64]
  -z arg  Package to generate (src,zip_src,shell,tarball,cci,jdbc,rpm,owfs);
          [default: all]
  -? | -h Show this help message and exit

 TARGET
  all     Build and create packages (default)
  build   Build only
  dist    Create packages only

 EXAMPLES
  ./build.sh                         # Build and pack all packages (64/release)
  ./build.sh -t 32 build             # 32bit release build only
  ./build.sh -t 64 -m debug dist     # Create 64bit debug mode packages

 

CUBRID에서 사용하는 대부분의 의존 라이브러리들은 빌드할 때 CMake에서 함께 자동으로 설치하고 빌드하고 있는데, 의존 라이브러리를 다루는 빌드 스크립트 (3rdparty/CMakeLists.txt) 와 함께 의존 라이브러리의 목록과 버전을 적은 README 파일을 함께 참고할 수 있도록 하고 있습니다. 또 미리 개발자의 환경에 설치되어야 하는 빌드 필수 요소들에 대해서는 각 OS 환경에서 설치할 수 있는 스크립트를 다음과 같이 적어주고 있습니다.

가이드 문서 개선하기

가이드 문서를 작성하는 것은 많은 노력이 필요하지만 빌드를 해보면서 겪을 수 있는 모든 문제를 완벽히 해결해줄 수 없습니다. 이제는 기여를 기대해볼 차례입니다. 위의 내용을 따라 작성한 가이드로 잘 안내했다면, 문제가 발생하는 부분은 보통 사소한 부분입니다. 예를 들어 시간이 지나면서 최신 버전의 리눅스 배포판 버전을 사용하는 개발자의 환경에 기본적으로 설치되는 라이브러리의 버전이 너무 높다라거나 라이브러리를 설치할 때 환경변수를 설정하지 않았다와 같은 것입니다. 이런 문제의 보고와 가이드 문서 개선은 오픈소스 기여의 좋은 출발점입니다.

따라서 개발자가 오픈소스 세상에 발자취를 남길 수 있도록 문서를 별도의 웹사이트에서 따로 관리하기 보다는 가이드 문서를 소스 코드와 똑같이 기여할 수 있게 해야 한다고 생각합니다. 그것은 개발자들이 오픈소스에 기여하려는 이유와도 같습니다.

가상 환경 제공하기

충분히 위의 내용과 같이 가이드 문서를 작성하더라도 개발자의 환경에서 이미 설치/설정된 라이브러리와 충돌 또는 잘못 설정된 환경 변수 등의 문제로 빌드 실패를 겪을 수 있습니다. 이 때 각 환경에 대해 트러블슈팅을 세세하게 제공해줄 수도 있지만 앞에서 설명한 것과 같이 아주 어려운 일입니다. 대신, 다음과 같은 도구를 이용하여 필요한 요소가 모두 갖추어진 가상 환경을 제공해주는 것도 하나의 방법입니다.

CUBRID는 엔진 소스 코드의 높은 허들을 (복잡한 시스템에 대한 분석 비용) 낮추기 위해 오픈소스 커뮤니티에서 좀 더 모듈/프로젝트를 쉽게 기여할 수 있는 cubrid-contrib (https://github.com/CUBRID/cubrid-contrib) 저장소를 운영하고 있습니다. CUBRID는 @lsahn-gh (https://github.com/lsahn-gh) 님이 최근 기여한 ‘Sandbox’ 프로젝트를 통해 Docker 가상 환경에서 빌드/개발 환경을 제공하고 있습니다.

sandbox.jpg

 

또 아직 CUBRID 저장소에 반영하지 않았지만, Vagrant 환경에서 각 CUBRID 버전을 빌드하는 위한 가상 환경과 그 가이드도 참고할 수 있습니다.

이제 빌드하고 개발해보자 그런데..?

이제 프로젝트에 기여하기 위한 첫 번째 산을 넘었습니다. 기여하기를 시작할 때 간단히 어떤 곳에 출력문을 추가해보거나 ‘프로그램을 죽여보는’ 코드를 집어넣은 뒤 빌드하고 실행해보면서 기능을 넣어볼 곳을 분석하기도 합니다.

이제 점점 프로젝트의 코드를 분석해서 알아가고 새로운 기능을 넣어봅니다. 이제는 소스 코드를 고쳐보고 빌드하고 테스트하는 것을 반복하는 (FIX - BUILD - TEST) 행복한 (?) 무한 루프 속에 자연스럽게 들어왔습니다.

이 때 프로젝트의 규모가 점점 더 커지다보면 한번의 루프를 반복하는 것도 꽤나 오랜 시간이 걸립니다. 예를 들어 겨우 코드 한줄 (!) 을 고쳐보고 테스트 하려고 하는데 거의 30분을 기다려야만 빌드가 완료됩니다. 이것은 점점 개발자의 생산성에 영향을 주기 시작합니다.

(농담을 하자면) 이제 30분 동안 문서도 작성해보고 방금 작성한 코드를 더 아름답게 바꿀 순 없을까 고민도 합니다. 그러다 이것을 반복하다보면 멍해지며 생각에 빠집니다. 아.. 최고의 복지는 제대로 일할 수 있게 해주는 것이라던데, 진행이 안되는구나. 역시 더 비싸고 좋은 장비를 사주었어야 하는걸까, 저 옆의 어디는 그거 준다던데...

아주 무서운(?) 농담이지만 개인적인 경험에 따르면 빌드 성능이 개발자가 기능을 개발할 때 집중력과 적극성에 분명한 영향을 준다는 것을 강조하려는 것입니다.

 

빌드 성능 개선하기

빌드 성능에 신경을 쓰는 것은 중요합니다. CUBRID와 같은 대규모 시스템의 경우에는 특히 빌드 시간이 꽤나 오래 걸립니다. CUBRID의 경우에는 Github의 Pull Request에서 매 commit 마다 빌드 테스트를 진행하므로 빌드 성능은 생산성에도, 비용에도 영향이 있습니다.

빌드 성능을 개선하는 많은 방법이 있겠지만 대표적으로 증분 빌드병렬 빌드를 잘 지원하는 것이 있습니다.

  • 증분 빌드: 규모가 큰 프로젝트를 빌드 할 때, 이전에 빌드 되었지만 최신 상태인 것은 다시 빌드하지 않도록 하는 것
  • 병렬 빌드: 빌드하면서 만들어지는 의존성과 오브젝트를 파악하여 병렬적으로 동시에 생성

이러한 방법은 빌드 시스템이나 도구에서 제공하지만 빌드 도구를 잘 선택하고 스크립트를 잘 작성해야 충분한 성능을 이끌어낼 수 있습니다. 빌드 성능을 개선하는 방법에 대해 설명하자면 너무 길어지므로 CUBRID가 개선한 사례로 설명하려고 합니다.

CUBRID는 Linux 환경에서 기본적으로 사용하고 있던 Make를 사용하고 있었는데, 빌드 성능을 저해하는 몇 가지 문제가 있었습니다.

  • 빌드 스크립트의 버그: 의존 라이브러리에 대한 의존성이 제대로 설정되지 않아 병렬 빌드에 성능 저하가 발생
  • Make는 너무 느리고 무겁다: Make 도구는 오랜 역사를 지닌 만큼 많은 것들을 고려하고 있어 비교적 빌드 속도가 느림
  • 병렬 빌드를 위한 CPU 개수 확보: CUBRID는 Circle CI에서 빌드 테스트를 매 commit 마다 수행하는데 사용하는 Docker Containor의 CPU 개수가 적음

위의 문제를 기반해서 먼저 빌드 스크립트의 의존성을 제대로 설정하도록 수정하고, Circle CI에서 CPU를 2개만 제공하는 Medium을 Large로 변경했습니다. 또 Make보다 비교적 가볍고 빠른 Ninja 빌드 시스템으로 빌드할 수 있도록 도입했습니다.

다음의 결과로 보면 CUBRID 11.0 에서 12분이 걸리던 빌드 속도가 거의 절반인 6분으로 줄어든 것을 볼 수 있습니다.

linux_perf.jpg

 

CUBRID의 Windows 환경에서는 Appveyor에서 MSVC로 빌드하는데, 거의 30분 넘게 빌드를 기다려야 합니다. Appveyor는 오픈소스 커뮤니티 플랜의 경우에는 무조건 1 CPU로만 동작하기 때문에 병렬 빌드가 동작하지 않습니다. 따라서 충분한 자원을 확보해주고, 병렬 빌드가 작동하도록 개선했습니다.

 

windows_old_perf.jpg

 

개선 결과를 보면 Appveyor에서 거의 31분이 걸리던 빌드가 Circle CI에서 거의 13분 수준으로 향상된 것을 볼 수 있습니다.

windows_new_perf.jpg

 

Circle CI에서 Linux (build → test)Windows 환경 (build-windows)에서 테스트를 보면, 거의 동시에 끝나는 것을 볼 수 있어 각 테스트 워크플로우가 끝날 때마다 함께 대응할 수 있습니다.

total_perf.jpg

 

마무리

빌드에 대한 가이드는 프로젝트에 새로 합류하는 개발자의 좀 더 편안한 온보딩에 도움을 주고 그 비용을 줄여줍니다.

또 프로젝트에서 릴리즈 노트에 적히는, 눈에 보이는 기능 개발이나 성능 개선도 중요합니다. 그러나 어떻게 보면 눈에 보이지 않을 수 있는 빌드에 대한 개선은 개발자들이 코드를 작성하고 기여하는 활동 (코드 리뷰, 피드백에 대응하고 수정하는) 에 영향을 주어 프로젝트의 지속적인 발전의 윤활유가 될 것입니다.

 

참고

다음의 링크에서 위에서 소개한 빌드 가이드와 개선 사항에 대한 이슈를 참고할 수 있습니다.


  1. DBMS와 효과적인 SQL 처리

    DBMS는 SQL을 효과적으로 처리하기 위해서 어떠한 노력을 하고 있을까요? - 질의 재작성기(Query Rewriter) 여러 개발자에게 동일한 요구사항을 주고 질의를 작성하게 하면 서로 다른 형태로 작성할 수 있습니다. 질의를 어떻게 작성하느냐에 따라서 성능에 차이가 발생할 수 있기 때문에 개발자가 질의를 효과적으로 작성하는 것은 중요한 일이지만, DBMS가 상당부분 그 일을 대신하고 있습니다. 위 질의를 작성한 그대로 수행하게 되면 부질의 결과를 임시파일에 저장하고 그것을 재가공해야 합니다. 하지만 오른쪽 질의처럼 작성되어 있다면, 따로 부질의를 수행해서 저장할 필요도 없고, 인덱스의 사용도 가능합니다. 위와 같이 부질의를 제거하고 주질의에 합병하는 것을 뷰머징이라고 합니다. DBMS는 가능한 경우 뷰머징을 진행하며, 인라인 뷰와 뷰 객체에 대해서도 동일하게 합병을 진행합니다. 부질의가 뷰머지가 불가능한 경우에 주질의에 있는 조회조건을 부질의로 넣는 것을 predicate push라고 합니다. 조회시 스캔하는 양을 줄일 수 있기 때문에 상당히 성능을 향상시킬 수 있습니다. 필요 없는 select list와 조인 테이블 그리고 order by절등을 제거하여, 필요...
    Date2023.12.29 Category제품 여행 By박세훈 Views922 Votes1
    Read More
  2. CUBRID Internal: B+ 트리의 노드(=페이지)와 노드 분할 방법

    목차 1. 개요 2. B+ 트리의 노드(= 페이지) 2.1. 오버플로 노드 (BTREE_OVERFLOW_NODE) 2.2. PAGE_OVERFLOW 페이지 3. 노드 분할 3.1. 노드 분할이 발생하는 경우 3.1.1. 새로운 키가 입력되는 경우 3.1.2. 기존 키의 크기가 증가하는 경우 3.1.3. 기존 레코드에 테이블 레코드의 OID가 추가되는 경우 3.1.4. 기존 레코드에 MVCC 아이디가 추가되는 경우 3.2. 사용자가 키를 입력하는 패턴에 따라 달라지는 노드 분할 #1 3.2.1. 시나리오 #1 - 1부터 27까지 오름차순으로 증가하는 패턴으로 키를 입력하는 경우 3.2.2. 시나리오 #2 - 1부터 27까지 불규칙 패턴으로 키를 입력하는 경우 3.2.3. 비교 결과 4. 똑똑하게 노드 분할하기 4.1. 사용자가 키를 입력하는 패턴에 따라 달라지는 노드 분할 #2 4.1.1. 오름차순으로 증가하는 패턴으로 키를 입력하는 경우 4.1.2. 내림차순으로 감소하는 패턴으로 키를 입력하는 경우 4.1.3. 불규칙 패턴으로 키를 입력하는 경우 5. 루트 노드 → 브랜치 노드 → 리프 노드 순서의 노드 분할 6. 참고 개요 큐브리드는 B+ 트리 인덱스를 사용하고 있습니다. B+ 트리 인덱스는 새로운 키가 입력되거나 기존 레코드가 변경될 때, B+ 트...
    Date2023.12.27 Category제품 여행 By주영진 Views973 Votes4
    Read More
  3. Visual Studio Code 소개

    시작하며 Visual Studio Code (이하 VSCode) 는 마이크로소프트에서 오픈소스로 개발하고 있는 코드 에디터입니다. VSCode는 활용하기에 따라 메모장과 비슷한 기능을 하기도, IDE(통합 개발 환경) 로써의 기능을 하기도 합니다. 이미 많은 개발자들이 VSCode를 사용하고 있습니다. 그러나 VSCode의 사용이 낯선 개발자들을 위해 이 글에서는 VSCode의 기본적인 사용 방법을 소개드리려고 합니다. 설치 및 시작 VSCode는 공식 웹 사이트(https://code.visualstudio.com)에서 자신의 운영체제에 맞는 버전을 다운로드 받아 설치할 수 있습니다. 설치하고 난 뒤 VSCode를 실행하면 다음과 같은 화면을 마주할 수 있습니다. 이제, 수정하고 싶은 파일을 VSCode 내부로 끌어다 놓거나, Open File, Open Folder 를 통해 파일 및 폴더를 열어 로컬에 있는 코드를 개발할 수 있습니다. 하지만 VSCode의 성능을 온전히 이용하려면 확장(Extension)을 설치하여 응용하는 것을 추천합니다. 확장 (Extensions) 확장은 다음 버튼을 누르거나 Ctrl+Shift+X 를 입력하여 확장 탭에 진입할 수 있습니다. 초기에는 확장이 설치되지 않은 상태인데, Search Extensions in Marketplace 라고 적혀...
    Date2023.12.21 Category나머지... By송일한 Views988 Votes2
    Read More
  4. CUBRID QA 절차 및 업무 방식 소개

    큐브리드의 QA 절차 및 업무 방식에 대해 소개하겠습니다. CUBRID QA팀이 하는 일? QA(Quality Assurance)팀은 CUBRID의 품질 보증에 대한 전반적인 절차를 다루는 업무를 맡고 있습니다. 단순 테스트뿐만 아니라, 개발 프로세스에 직간접적인 관여와 QA Tool 확장 및 유지보수, 제품 결함 관리, 제품 릴리즈 등 제품이 출시되는 과정에서 여러가지 일을 하고 있습니다. 특히, 개발과정의 처음부터 끝까지 참여하여 품질 저하에 문제가 될 만한 부분이 있는지 검증하고, 개선안을 제안하는 등 개발 프로세스 전반적으로 개입하여 제품 품질을 높이는 일을 하고 있습니다. CUBRID QA 절차 CUBRID QA 절차는 크게 다음과 같이 볼 수 있습니다. 각 절차에 대한 상세한 과정은 다음과 같습니다. 1. Kick off 참여 -먼저, 개발팀으로부터 프로젝트를 할당 받으면, 킥오프를 참여합니다. 요구사항 및 목표를 파악하고, 사용자 관점에 부합하지 않을 경우 개선을 요청합니다. 프로젝트에 따라 검증방법이나 절차가 달라질 수도 있고 때에 따라 새로운 환경이 필요할 수 있기 때문에 여러 가지 의견들을 종합하여 팀 내 담당자를 선정합니다. 2. 테스트 환경 구축 -프로젝트를 위해 어...
    Date2023.11.17 Category나머지... By윤시온 Views1105 Votes1
    Read More
  5. CUBRID의 개발 문화: CUBRID DBMS 프로젝트 빌드 가이드와 빌드 시스템 개선

    시작하며 이전 포스팅에서 CUBRID의 개발 문화: CUBRID DBMS는 어떻게 개발되고 있을까? 라는 주제로 블로그 글을 작성했었던 기억이 납니다. 날짜를 들여다보니 2021년 4월 29일에 작성되었으니 코로나 팬데믹을 이겨내고 CUBRID에서 여러 프로젝트를 진행하느라 시간이 훌쩍 지나갔네요. 그 사이 CUBRID는 11.2 (elderberry) 버전 릴리즈를 지나 11.3 (fig) 버전 릴리즈를 앞두고 있습니다. 이번에도 마찬가지로 [CUBRID의 개발 문화]라는 말머리를 가지고 CUBRID DBMS 프로젝트 빌드에 대한 이야기를 해보려고 합니다. 이전 포스팅의 ‘CUBRID DBMS는 어떻게 개발되고 있을까?’에서 소개했던 개발 프로세스와 프로젝트 기여 가이드의 내용과 조금 주제가 달라보일 수 있는데, 프로젝트 빌드에 대한 내용이 어떻게 개발 문화로까지 이어질 수 있는지 소개해 드리려고 합니다. 빌드 준비하기 누군가 코드를 기여하려고 할 때 빌드는 가장 먼저 해야 하는 첫 발걸음이면서, 동시에 제일 첫 번째로 마주하는 어려움입니다. 먼저 개발 환경에서 프로젝트를 빌드하기 위해서 여러 도구와 라이브러리를 설치하고, 프로젝트의 빌드 방법을 알아야 합니다. 이 때 기여하려...
    Date2023.09.08 Category오픈소스 이야기 By유형규 Views864 Votes2
    Read More
  6. No 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...
    Date2023.05.11 Category제품 여행 By김지원 Views903 Votes1
    Read More
  7. No 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...
    Date2023.04.26 Category제품 여행 By사니조아 Views734 Votes1
    Read More
  8. 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, 이하 헤더 페이지): 페이지 크기, 볼륨 내 섹터의 전체/최대 섹터, 볼륨 이름 등, 볼륨에 대한 정보를 지니고 있는 페이지 섹터 테이...
    Date2023.03.30 Category제품 여행 By김재은 Views972 Votes2
    Read More
  9. JPA와 CUBRID 연동 가이드

    JPA? JPA는 자바의 ORM 기술 표준으로 인터페이스의 모음입니다. 표준 명세를 구현한 구현체들(Hibernate, EclipseLink, DataNucleus)이 있고, JPA 표준에 맞춰 만들면 사용자는 언제든 원하는 구현체를 변경하며 ORM 기술을 사용할 수 있습니다. 이번 CUBRID 연동 가이드에서는 대표적으로 많이 사용하는 Hibernate를 사용하여 작성했습니다. 버전 정보 SpringBoot: 2.7.8 Hibernate: 5.6.14.Final Java: 11 CUBRID: 11.0.10, 11.2.2 JPA와 CUBRID 연동 1) 라이브러리 설정 Maven 프로젝트에 JPA(Hibernate), CUBRID JDBC 라이브러리를 넣기 위해 pom.xml에 설정을 합니다. CUBRID JDBC를 받기 위해 repository도 같이 추가해야 합니다. 2) JPA 설정 필요한 라이브러리를 다 받은 뒤 JPA 설정 파일인 persistence.xml에 설정을 해줘야 합니다. 해당 파일은 표준 위치가 정해져 있기 때문에 /resources/META-INF/ 밑에 위치해야 합니다. DBMS 연결 시 필요한 정보와 JPA 옵션들을 설정해 줍니다. 기본적으로 driver, url, user, password를 설정하고, 방언(dialect)도 필수적으로 설정해야 합니다. DBMS가 제공하는 SQL 문법과 함수들이 조금씩 다르기 때문에 JPA가 어떤 DBMS...
    Date2023.02.22 Category나머지... By김동민 Views2003 Votes3
    Read More
  10. dblink를 이용한 remote-server materialized view 기능

    Materialized View Materialized View(이하 MView) 이것은 말 그대로 View의 일종으로 일반 View는 논리적인 스키마인데 반해, MView는 물리적 스키마입니다. 논리적 스키마는 실제 데이터가 데이터베이스에 저장되어 있지 않고 데이터를 가져오기 위한 SQL질의만 저장되어 있다라는 것이고, 물리적 스키마 혹은 테이블이라는 것은 셀제 데이터가 데이터베이스에 저장되어 있다라는 것입니다. MView는 필요한 결과를 가져오는 질의가 빈번하게 자주 사용 될 경우, 질의 실행 시간 속도 향상을 위해 데이터베이스 테이블을 만들어 저장해 두는 것으로 실행 비용이 많이 드는 조인이나, Aggregate Function을 미리 처리하여 필요할 때 테이블을 조회 하도록 하는 것 입니다. 예를 들면 대용량의 데이터를 COUNT, SUM, MIN, MAX, AVG 처럼 자주 사용되는 Aggregate Function 실행 속도를 향상을 위해서, 질의 실행 결과을 데이터베이스 테이블로 생성해 두는 벙법입니다. 즉, 자주사용되는 View의 결과를 데이터베이스에 저장해서 질의 실행 속도를 향상시키는 개념입니다. 이번 글에서는 일반적인 MView와 더불어 현재 작업 중인 데이터베이스 로컬 서버가 아닌 원격지(remote) ...
    Date2023.02.20 Category나머지... Bybwkim Views1441 Votes2
    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