네이버 기술 서적 시리즈인 TECH@NAVER의 열한 번째 책 "시작하세요! 큐브리드"를 2015년 5월 29일에 출간했습니다. TECH@NAVER_011 시작하세요! 큐브리드 저자: 이동현, 김남영, 김영헌, 최중연 출판사: 위키북스 출간일: 2015. 5. 29. 페이지: 386쪽 가격: 22,000원(온라인 서점가: 19,800원) "시작하세요! 큐브리드"는 네이버가 만든 오픈 소스 데이터베이스 큐브리드의 특징을 소개하고 큐브리드를 설치하는 방법부터 성능을 최적화하고 보안을 유지하는 등의 개발·운영 기술까지 자세하게 알려줍니다. 네이버 책 바로가기 책 구성 간단 스케치 "시작하세요! 큐브리드"는 큐브리드 설치와 설정, 데이터베이스 접속, 운영, 최적화 방법을 다루며, 기본적인 데이터베이스 이론보다는 실제 사용법 위주로 설명합니다. 1장에서는 큐브리드의 역사, 라이선스, 적용 사례, 기능적 특징을 다룹니다. 2장에서는 리눅스와 윈도우에 큐브리드를 설치하는 방법, 질의 도구를 설치하는 방법을 설명합니다. 3장에서는 큐브리드의 프로세스 구조(3계층 구조), 큐브리드 볼륨의 구조와 함께 큐브리드 데이터베이스를 구동하고 종료하는 방법을 설명합니다. 4장에서는 응용프로그램을 큐브리드 데이터베이스와 어떻게 연동하는지 살펴봅니다. 5장에서는 큐브리드에서 사용하는 SQL 구문을 간단한 예를 통해 살펴보고, 큐브리드가 지원하는 자료형과 SQL 구문을 다른 데이터베이스와 비교하면서 설명합니다. 6장에서는 트랜잭션 및 잠금을 다룹니다. 7장에서는 큐브리드의 백업 및 복구를 다룹니다. 8장에서는 큐브리드의 HA(high availability) 기능을 다룹니다. 9장에서는 큐브리드 모니터링을 다룹니다. 10장에서는 큐브리드에서 보안을 설정하는 방법을 다룹니다. 11장에서는 큐브리드의 성능을 최적화하기 위해 질의와 인스턴스를 튜닝하는 방법을 다룹니다. 마지막으로 부록에서는 큐브리드 SQL 전반을 요약하고, 본문에서 미처 다루지 못한 다른 DBMS와의 차이, 다국어 지원, 큐브리드 버전 정보를 다룹니다. 그림 1 큐브리드 HA 구성의 예 이 책의 특징을 꼽으라면 큐브리드의 가장 큰 장점은 모든 기능을 무료로 사용할 수 있다는 것입니다. 또한 엔진 소스 코드를 수정하지 않는 한, 큐브리드를 사용하도록 개발된 패키지 소프트웨어 및 설루션은 소스 코드를 공개하지 않아도 상업적인 목적으로 서비스하거나 판매할 수 있습니다. 라이선스 비용이 전혀 들지 않아 많은 중소 규모 서비스에 적용되면서 개발자가 운영자를 겸하는 경우가 많습니다. "시작하세요! 큐브리드"는 다른 DBMS를 다뤄본 경험은 있으나 큐브리드는 처음 접하는 개발자와 운영자를 위한 책입니다. 2008년 11월 큐브리드가 인터넷 서비스에 최적화된 DBMS를 지향하며 국내 최초의 오픈 소스 DBMS로서 서비스를 시작한 지도 어느덧 6년이 넘게 흘렀습니다. 네이버에서는 큐브리드를 사용해 여러 대규모 웹 서비스를 운영하고 있습니다. 또한 각종 공공 기관 및 기업체의 웹사이트 등에서도 큐브리드를 사용하고 있습니다.

인덱스의 키(key) 길이가 길거나 키 분포가 좋지 않으면 CUBRID의 성능이 많이 저하됩니다. 이러한 현상은 CUBRID의 인덱스 구조 때문에 발생합니다. 이 글에서는 CUBRID의 인덱스 구조를 살펴보고 키의 길이와 구조에 따른 성능 저하의 원인을 알아보겠습니다. CUBRID 인덱스 구조 CUBRID의 인덱스는 디스크 I/O 특성을 고려하여 B+ 트리로 구성되어 있다. B+ 트리는 키와 그에 대한 링크를 블록(페이지)으로 묶어서 처리한다. 그래서 B+ 트리의 깊이(depth)가 줄어들고 하향식(top-down) 탐색 시 디스크 I/O 횟수를 최소화할 수 있다. 그림 1 B+ 트리 구조 그림 1은 B+ 트리 구조를 개략적으로 나타낸 것이다. 여기서 non-leaf 페이지와 leaf 페이지는 인덱스 페이지다. 그리고 각 인덱스 페이지는 여러 개의 레코드(record)로 구성되어 있다. 다음 절에서는 이 레코드의 구조를 살펴보겠다. 인덱스 페이지의 레코드 구조 다음은 인덱스 페이지인 non-leaf 페이지와 leaf 페이지의 레코드 구조를 나타낸 그림이다. 그림 2 인덱스 페이지의 레코드 구조 그림 2와 같이 non-leaf 페이지의 레코드에는 링크 정보(child)와 키가 저장되고 leaf 페이지의 레코드에는 키와 키에 해당하는 테이블 레코드의 링크 정보인 OID(object ID)가 저장된다. 그리고 인덱스 페이지의 레코드는 페이지 안에서 키의 순서대로 정렬되어 있다. 인덱스의 모든 레코드에 키가 저장되기 때문에 키의 길이는 인덱스 페이지에 저장되는 레코드의 개수에 많은 영향을 미친다. 키의 길이가 길어지면 하나의 페이지에 저장할 수 있는 레코드의 개수가 줄어들므로 인덱스에 더 많은 페이지가 사용된다. 이로 인해 인덱스의 깊이가 증가해 인덱스 접근 시 더 많은 페이지를 읽어야 하고 성능도 저하된다. 키가 중복되는 경우에는 하나의 키에 OID만 여러 개 저장된다. 따라서 키가 중복되어도 그렇지 않은 경우보다 더 많은 페이지를 사용하지 않으므로 키의 길이에 비해 성능에 미치는 영향이 적다. 그러나 OID를 저장할 때 단순 배열을 사용하기 때문에 키 분포가 나쁠수록 배열에 접근하는 비용이 증가하게 된다. 사용자가 긴 키를 인덱스로 사용하거나 중복이 많은 키를 인덱스로 사용하면 인덱스의 레코드가 한 페이지에 수용하지 못할 만큼 커질 수가 있다. 다음 절에서는 이러한 레코드를 저장하는 방법을 알아보겠다. 키의 길이가 길어서 레코드가 커진 경우 인덱스 키의 길이를 MySQL은 767바이트, MS-SQL은 900바이트로 제한한다. 하지만 CUBRID에는 인덱스 키의 길이에 제한이 없다. 그래서 키의 길이가 페이지 크기보다 큰 인덱스도 생성할 수 있다. 이 경우에는 인덱스의 레코드를 하나의 페이지에 수용할 수 없다. 이때는 다음 그림과 같이 인덱스 페이지의 레코드에 키를 저장하지 않고 별도의 페이지에 키를 저장한다. 그리고 인덱스 페이지의 레코드에는 키가 저장된 페이지에 대한 링크 정보만 저장한다(앞으로 이를 오버플로 키라고 하겠다). CUBRID

CUBRID는 2008년 11월 CUBRID 2008 R1.0을 출시한 이후 2014년 5월 CUBRID 9.3을 출시할 때까지 많은 기능을 추가해 왔습니다. 그 결과 CUBRID는 기본적으로 ANSI SQL-92 표준을 따르는 것 외에 계층 질의, MERGE 문, 분석 함수(analytic function) 등을 추가로 지원하게 되었습니다. SQL:2011 표준까지 발표된 지금, CUBRID를 포함한 주요 DBMS에는 어떤 특징적인 SQL 기능이 있으며, CUBRID 9.3은 이 중에서 어떤 기능들을 지원하고 있을까요? 여기서 '특징적인 SQL'이란 일반적인 SELECT, INSERT, UPDATE, DELETE 외에 좀 더 특수해 보이는(사용 방법이 복잡해 보이지만 잘 알고 쓰면 사용자에게 편할 것 같은) 기능을 제공하는 SQL 구문을 이 글에서 임의로 지칭한 표현입니다. 이 글에서는 특정 DBMS에 국한하지 않고 SQL의 특징적인 기능들을 살펴보고, 해당 기능이 SQL의 어떤 표준에 속하는지, 어떤 DBMS가 해당 기능들을 지원하는지 알아보겠습니다. 이 글에서 다루는 DBMS는 Oracle 12c, SQL Server 2008, MySQL 5.6, CUBRID 9.3입니다. 이 글에서 DBMS별로 비교하는 SQL 기능의 대부분은 다음 페이지의 표에서 가져왔습니다. * DBMS별 비교표: http://www.sql-workbench.net/dbms_comparison.html 표기 규칙 내용을 살펴보기에 앞서 다음 사항을 염두에 두기 바란다. * 표에서 기능을 지원함을 나타내는 O 표시에 붙은 (*)는 기능의 일부만 지원함을 의미한다. * 표에서 기능을 지원하지 않음을 나타내는 X 표시에 붙은 (*)는 지원한다고 보기는 애매하지만 대체 기능이 존재하거나 차기 버전에서 지원 예정임을 의미한다. * SQL 표준이 아니거나 표준 여부를 파악하지 못한 경우 표준에 대해 명시하지 않았다. 질의문 기능 Oracle SQL Server MySQL CUBRID 윈도 함수(window function) O O X O(*) Common Table Expressions(CTE) O O X X 계층적 질의(hierarchical query) O X X O PIVOT 연산자 O O X X(*) GROUP BY ... ROLLUP O O O O temporal database O X X X 병렬 질의 처리 O O X X 문자열 집계 O(*) X O O 윈도 함수 OVER 절을 사용하는 윈도 함수(window function)는 SQL:2003 표준으로 제정되었고 SQL:2008 표준에서 확장되었다. 윈도 함수는 각 그룹의 누적, 이동, 중앙 집계를 계산하는 함수이며, 각 그룹에 대해 여러 개의 행을 반환한다는 점이 집계 함수(aggregate function)와 다르다. CUBRID에서는 분석 함수(analytic function)라고 불리는 함수 중 누적, 이동, 중앙 집계를 계산하는 일부 함수가 윈도 함수에 속하는데, CUBRID 9.3 버전에서는 WIN

응용 프로그램에서 DBMS(database management system)에 연결하여 질의를 처리할 때 꼭 필요한 것이 각 벤더에서 제공하는 드라이버입니다. Java를 이용할 때는 표준화된 JDBC(Java Database Connectivity)를 이용하여 쉽게 개발할 수 있습니다. 또한, 응용 프로그램 개발 생산성을 향상시킬 수 있는 여러 뛰어난 도구와 플랫폼이 제공됩니다. 이 글에서는 이러한 JDBC의 커넥션을 CUBRID가 내부적으로 관리하는 방법을 알아보겠습니다. CUBRID는 커넥션 관리 방식이 다른 DBMS와는 달라서 그에 따른 몇 가지 장점이 있고, 이는 응용 프로그램이 JDBC의 커넥션을 관리하기 위한 DBCP(database connection pool) 사용에 영향을 줍니다(DBCP는 Apache 프로젝트 중 하나로 개발되고 있으며, 다른 많은 상위 플랫폼에 기본적으로 포함되어 있습니다). 먼저, CUBRID의 커넥션 관리 방식을 알아보고 그에 따라 DBCP를 어떻게 설정하는지 알아보겠습니다. 드라이버 커넥션 검증 DBCP를 이용하여 DBMS와의 커넥션을 관리하다 보면 질의 처리 중 이미 끊어진 커넥션 객체를 응용 프로그램이 전달받을 수 있다. 예를 들어 DBMS는 자원을 효율적으로 사용하기 위해서 낭비되는 자원을 관리하는 설정을 제공하는데, 이 중 대표적인 것이 유휴 커넥션 최대 유지 시간이다(MySQL에서는 wait_timeout, 기본 값은 8시간). 이 설정으로 지정한 시간 동안 커넥션을 통해 아무 요청이 없으면 DBMS는 그 커넥션을 강제로 종료한다. 이처럼 응용 프로그램이 끊어진 커넥션 객체를 받을 수 있는 상황은 다음과 같다. * DBMS가 자원을 효율적으로 사용하기 위해 유휴 커넥션 강제 종료 * DBMS 재시작으로 인한 커넥션의 종료 * 네트워크 문제로 인한 커넥션의 종료 그러나 이러한 경우에서 응용 프로그램은 커넥션이 종료되었는지 알 수 없으므로, 커넥션 검증 없이 그대로 요청을 보내면 커넥션이 종료되었다는 예외를 받게 될 것이다. 물론, 응용 프로그램에서 모든 예외를 잘 처리하고 있다면 이런 경우에는 요청이 성공할 때까지 기존 커넥션을 반납하고 새 커넥션을 받는 과정을 반복하여 결국 요청을 처리할 것이다. 그러나 응용 프로그램에서 모든 예외를 처리하기는 힘들다. DBCP의 커넥션 검증이란 이러한 사태를 미연에 방지하기 위해 귀찮은 일을 응용 프로그램 대신 DBCP가 하는 것이다. DBCP는 여러 설정을 통해 커넥션 검증을 지원하는데, 그것은 먼저 CUBRID의 커넥션 관리 방식을 살펴본 후에 알아보겠다. CUBRID의 커넥션 관리 방식 앞에서는 드라이버 커넥션의 유효성 검사가 왜 필요한지 알아보았다. 하지만 CUBRID를 사용하는 경우는 이러한 커넥션 유효성 검사가 필요 없는데 그 이유를 알아보자. 먼저 CUBRID는 3 tier 구조로 되어 있다. 드라이버와 서버 사이에 브로커라는 미들웨어가 있는 구조이다. 브로커는 크게 두 종류의 프로세스로 구분되는데 한 개의 브로커 프로세스(cub_broke