Background Image
조회 수 37599 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

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

 

인덱스, 아는 만큼 보인다!
DBMS 개발자가 전하는 인덱스 활용 노하우

 

고성능 서비스를 구축하기 위한 DB 쿼리 튜닝의 핵심은 인덱스를 얼마나 잘 활용하는가에 달려 있다. 지난 3년 동안 CUBRID를 NHN 내/외부 서비스에 적용하면서 의외로 많은 개발자들이 DB 인덱스에 대해 “잘” 알지 못하고 “잘” 활용하지 못한다는 것을 발견하였다. 본 기고문에서는 6월 30일에 출시된 CUBRID 2008 R4.0에 적용된 다양한 인덱스 기법을 중심으로 인덱스 구조와 인덱스 활용 노하우를 쉽게 설명하고자 한다. 단, MySQL, MS-SQL, Oracle 등 다른 DBMS에서도 이와 동일/유사한 인덱스 기법이 적용되어 있으므로 본 기고문에서 소개할 인덱스 활용 노하우가 CUBRID에 국한되지 않는다는 점을 강조하고 싶다.

 

* 본 게시글은 월간 마이크로소프트웨어 8월호에 게재된 내용의 원작입니다.

   월간 마이크로소프트웨어에서는 약간 내용이 줄어서 게재된 관계로 본 게시글과 차이가 있을 수 있습니다.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
강동완  | NHN Business Platform 서비스 플랫폼 개발 센터 내 DBMS 개발랩 소속이다. CUBRID 차기 버전(코드명: Apricot)에 오라클의 Index Skip Scan 기법 (MySQL에서는 Loose Index Scan이라고 함)과 Function Index, MS-SQL Server의 Include Index 등 다양한 인덱스 활용 최적화 기법을 적용하기 위하여 개발에 몰두하고 있다.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

 

인덱스 구조와 스캔 방식을 이해하기


 

CUBRID의 인덱스는 B+-Tree 를 이용하여 인덱스를 구현한다. B+-Tree 는 B-Tree 의 한 종류로 일반적인 B-Tree 와는 달리 데이터 포인터들을 리프(Leaf) 노드에만 저장한다. 리프 노드의 상위 레벨인 넌리프(Non-Leaf) 노드는 전형적인 B-Tree 로 구성되는데, 리프 노드를 빠르게 찾기 위한 인덱스 역할을 한다. 리프 노드에는 키와 키에 대응하는 데이터의 포인터가 저장되어 있다. 리프 노드는 링크드 리스트로 연결되어 있기 때문에 범위 검색과 같은 순차 처리를 편하게 해준다. 그림 1 은 B+-Tree 의 전형적인 구조를 보여준다.

 

pic1.jpg


그림 1 B+-Tree 구조


B+-Tree 의 리프 노드는 서로 연결되어 있어 순차 처리가 가능하기 때문에 범위를 검색하는데 유리하다. 테이블은 처음부터 끝까지 모든 레코드를 읽어야 완전한 결과 집합을 얻을 수 있지만, 인덱스는 키 컬럼 순으로 정렬되어 있기 때문에 특정 위치에서 검색을 시작해서 검색 조건이 일치하지 않는 값을 만나는 순간 멈출 수 있다. 이것을 인덱스 범위 스캔(Index Range Scan)이라고 부른다. CUBRID는 범위 스캔을 B+-Tree 검색의 기본 연산으로 제공한다. 범위 스캔을 위해서는 두 개의 키가 필요한데, 범위의 양 끝을 표현하는 하위 키와 상위 키가 그것이다.

인덱스 범위 스캔은 두 단계로 진행된다. 첫 번째 단계에서는 루트에서부터 트리를 순회하여 리프 노드에서 하위 키를 찾아낸다. 두 번째 단계에서는 첫 번째 단계에서 찾은 키에서부터 상위 키까지 순차적으로 레코드를 읽어 처리한다. 상위 키가 현재 노드에서 발견되지 않으면 다음 노드를 읽어 상위 키를 가진 노드까지 검색을 계속해 나간다. 상위 키까지 순차 검색이 끝나면 전체 범위 검색이 완료된다.
두 번째 단계에서 상위 키까지 찾아가는 과정은 레코드에서 키를 읽어와 상위 키와 비교하는 과정의 연속이다. 상위 키가 최대 키이면 현재 노드의 키부터 마지막 노드까지 모두 검색 결과에 포함되기 때문에 비교 연산을 할 필요가 없어져 검색의 성능이 좋아진다. 이를 위해 옵티마이저는 입력된 쿼리를 재작성(rewrite)하며, CUBRID는 특정 키를 찾는 검색도 범위 검색으로 변환하여 수행한다. 이런 경우에는 하위 키와 상위 키 모두를 찾고자 하는 키로 동일하게 설정한다.

 

인덱스 스캔을 통한 질의 처리 과정을 이해하기


CREATE TABLE tbl (a INT NOT NULL, b STRING, c BIGINT);
CREATE INDEX idx ON tbl (a, b);

그림 2는 CUBRID에서 위의 구문으로 테이블과 인덱스를 생성하고 데이터를 입력한 경우, 인덱스 리프 노드와 테이블 데이터의 관계를 나타낸 그림이다. 왼쪽 인덱스 리프 노드에는 인덱스 키와 키에 대응되는 OID(레코드의 물리적 주소 값)가 저장되어 있다.

 

pic2.jpg  
그림 2 인덱스 리프 노드와 테이블 데이터의 관계

 

SELECT * FROM tbl WHERE a > 1 AND a < 5 AND b < ‘K’ AND c > 10000 ORDER BY b;

 

위와 같은 SELECT질의가 주어졌을 때 WHERE 절에 있는 검색 조건은 아래의 3가지로 나눌 수 있다.
 Key Range: 인덱스 스캔 범위로 활용되는 조건이다. (a>1 and a < 5)
 Key Filter: Key Range에 포함될 수 없지만 인덱스 키로 처리 가능한 조건이다. (b < ‘K’)
 Data Filter: 인덱스를 사용할 수 없는 조건이다. 테이블 데이터를 검색하는데 적용된다. (c > 10000)
CUBRID의 질의 처리 과정은 다음과 같다.
1) 인덱스 스캔인 경우 먼저 Key Range와 Key Filter를 적용하여 조건에 부합하는 OID 리스트를 만들어 낸다. 이 과정은 Key Range의 시작부터 끝까지 계속된다.
2) OID를 이용해 데이터 페이지에서 해당 레코드를 읽어 Data Filter를 적용하거나 SELECT 리스트에 기술된 컬럼 값을 읽어와 결과를 저장하는 임시 페이지에 기록한다.
3) ORDER BY나 GROUP BY 절이 있으면 임시 페이지에 저장된 레코드들을 정렬하여 최종 결과를 생성한다. 그림 3은 위의 SELECT 질의가 처리되는 1), 2), 3) 과정을 보여 준다.

 

 

pic3.jpg


 그림 3 인덱스 및 테이블 데이터 검색을 통한 질의 처리 과정

 

인덱스 사용 시 이런 점을 주의하자


옵티마이저가 인덱스를 사용하도록 하기 위해서는 WHERE 절에 Range 조건이 있어야 한다. Range 조건은 값의 비교조건, 즉 크다, 작다, 크거나 같다, 작거나 같다, 같다와 같은 비교문으로 기술된다. 만약 Range 조건이 없다면 옵티마이저는 테이블 순차 스캔을 시도할 것이다.
또한, WHERE 절에 인덱스 키의 첫 번째 컬럼이 사용되어야만 인덱스 스캔을 수행한다. 인덱스가 여러 컬럼으로 조합되어 있는 경우 많은 사람들이 이중 한가지 컬럼만을 사용하더라도 비교가 가능하다고 생각하는 경우가 있는데, 그것은 잘못된 생각이다. 첫 번째가 없는 상태에서는 두 번째가 정렬된 상태라고 할 수 없기 때문에 범위를 정의할 수 없다. 따라서 반드시 첫 번째 컬럼이 조건에 있어야 하며, 뒤의 컬럼들은 없어도 상관없다.
인덱스는 값의 대소 비교를 통해 트리가 구성되어 있다. 따라서 값의 대소 비교가 아닌 것은 B+-Tree를 사용해서 값을 찾을 수 없다. <>, != 와 같이 부정형 조건이나 NULL 비교는 인덱스를 사용할 수 없다. 인덱스의 첫 번째 컬럼을 조건절에서 가공하는 경우도 인덱스를 사용할 수 없다. 다음은 인덱스를 사용하지 못하는 질의문의 예이다.

 

SELECT * FROM student WHERE grade <> 'A';
SELECT name, email_addr FROM student WHERE email_addr IS NOT NULL;
SELECT student_id FROM record WHERE substring(yymm, 1, 4) = ‘1997’;

 

인덱스 활용 최적화: 디스크 I/O를 최소화하는 것이 튜닝의 핵심이다!


B+-Tree는 특성상 어떤 리프 페이지든 접근하는데 거의 동일한 비용이 든다. B+-Tree를 사용하는데 가장 큰 비용이 드는 부분은 Key Range의 시작부터 끝까지 인덱스 리프 노드들을 따라 스캔하는 것과 이와 대응되는 테이블 데이터를 스캔하는 것이다.


CUBRID의 I/O는 페이지 단위로 이루어진다. 이것은 하나의 레코드에서 하나의 컬럼만 읽으려 해도 레코드가 속한 페이지 전체를 디스크로부터 읽어온다는 것을 뜻한다. 따라서, 질의 성능을 좌우하는 가장 중요한 성능 지표는 I/O를 수행하는 페이지 개수이며, 이는 옵티마이저의 판단에 가장 큰 영향을 미친다. 옵티마이저가 인덱스를 읽을지, 테이블을 읽을지 결정하는데 있어 가장 중요한 판단 기준은 읽어야 할 레코드가 아니라 읽어야 할 페이지 개수인 것이다.


디스크 I/O는 메모리 액세스에 비해서 비용이 아주 크다. 질의 수행에 필요한 모든 데이터 페이지와 인덱스 페이지를 DB 버퍼에 올려놓고 처리할 수 있다면 좋겠지만 그러기에는 한계가 있다. 결국 디스크 I/O를 최소화 하고 대부분의 연산을 DB 버퍼에서 처리할 수 있도록 질의 처리 과정에서 액세스하는 페이지 수를 최소화시키는 것이 튜닝의 핵심이다. 액세스하는 페이지 수가 적으면 자연스럽게 물리적으로 디스크에서 읽어야 할 페이지 수도 줄어들기 때문에 DB 버퍼 히트율(DB buffer hit ratio)이 높아져서 데이터베이스의 전체적인 성능이 높아지게 된다. 그럼 지금부터 인덱스 스캔 과정에서 액세스해야 할 페이지 수를 줄일 수 있는 기법들에 대해 알아보자.

 

최적화 기법 1. Key Filter 활용


앞서 설명한 바와 같이 Key Filter는 Key Range에는 포함될 수 없지만 인덱스 키로 처리 가능한 조건이다. 이러한 Key Filter가 WHERE 조건절에 포함되면 인덱스 스캔 중에 데이터 페이지에 접근하는 횟수를 줄일 수 있다. 데이터 페이지를 읽는 것은 랜덤 액세스 이기 때문에 인덱스 페이지를 스캔하는 것보다 많은 비용이 든다. 따라서 WHERE절에 Key Filter를 주는 것이 성능에 유리하다.  또한, Data Filter가 Key Filter로 적용될 수 있도록 인덱스에 컬럼을 추가하는 것도 방법이 될 수 있다. 예를 들어 user 테이블에 (groupid, name)으로 구성된 인덱스 idx_1이 있는 상태에서 아래 질의를 수행한다고 가정해 보자.

 

SELECT * FROM user WHERE groupid = 10 AND age > 40;


groupid=10인 조건을 만족하는 레코드가 100건이고 그 중 age>40인 레코드가 10건이라고 하면, 인덱스 스캔으로 100건의 OID를 가져온 후, 최악의 경우 데이터 페이지로 100회의 액세스를 수행할 것이다. 그러나, idx_1 인덱스에 age 컬럼을 추가하여 (groupid, name, age)로 만들면 age > 40 조건이 Key Filter 조건으로 처리되어 인덱스 스캔으로 10건의 OID만 추출할 수 있다.

 

최적화 기법 2. 커버링 인덱스


만약 사용되는 인덱스 내에서 SELECT 질의에 대한 결과를 모두 얻을 수 있는 상황이라면 데이터 페이지에 저장되어 있는 레코드를 읽어오지 않아도 인덱스 키의 값으로만 결과를 만들어 낼 수 있다. MS-SQL Server 에서는 이와 같이 인덱스가 하나의 질의를 모두 “커버”한 경우에 대해서 “커버링 인덱스”라고 한다. CUBRID 2008 R4.0에도 커버링 인덱스가 도입되었다.

 

SELECT a, b FROM tbl WHERE a > 1 AND a < 5 AND b < ‘K’ ORDER BY b;

 

위의 질의는 커버링 인덱스가 적용될 수 있다. 질의에 사용된 컬럼은 a, b 뿐이고 모두 인덱스 컬럼이기 때문이다. 그림 4를 통해 커버링 인덱스에 의해 질의가 처리되어 테이블 데이터 페이지를 액세스 하는 부분이 없는 것을 확인할 수 있다. 대신 인덱스 스캔 결과로 인덱스 키 값을 그대로 Key Buffer에 저장한 후 이 값을 읽어 최종 결과를 만들어 낸다.


pic4.jpg  
그림 4 커버링 인덱스를 활용한 질의 처리 과정

 

커버링 인덱스는 데이터 페이지를 읽지 않는다는 점, 그리고 해당 질의를 자주 사용하게 되면 인덱스가 DB 버퍼에 캐시되어 있을 가능성이 높다는 점에서 디스크 I/O를 줄이는데 큰 역할을 한다. 따라서 레코드 크기에 비해 인덱스 키의 크기가 작고, 커버링 인덱스를 이용하는 질의가 자주 수행되는 것이 확실하다면, 커버링 인덱스를 사용하여 SELECT 질의 성능을 크게 향상시킬 수 있다.

 

최적화 기법 3. Sort 연산 대체


인덱스 스캔을 통해 생성된 결과 집합은 인덱스 컬럼 순으로 정렬된 상태이므로 ORDER BY, GROUP BY절에 의한 정렬 연산을 생략하도록 질의를 작성할 수 있다. 이를 위해서는 인덱스 컬럼의 순서대로 ORDER BY나 GROUP BY 절에 컬럼이 지정되어야 한다. 단 인덱스 컬럼이 조건절에서 ‘=’ 연산자로 동등 비교되는 경우에는, 해당 컬럼이 ORDER BY나 GROUP BY 절에서 중간에 생략되어도 된다. 그림 5는 인덱스 스캔에 의해 GROUP BY 정렬이 생략되는 질의 처리 과정을 보여 준다.

 

SELECT COUNT(*) FROM tbl WHERE a > 1 AND a < 5 AND b < ‘K’ AND c > 10000 GROUP BY a;



 

pic5.jpg
그림 5 GROUP BY 정렬 최적화된 질의 처리 과정


앞에서 인덱스 스캔을 하기 위해서는 조건절에 인덱스 첫 번째 컬럼이 명시되어야 한다고 설명했다. 하지만 인덱스 컬럼에 NOT NULL 제약 조건이 설정되어 있다면 옵티마이저는 조건절에 인덱스 첫 번째 컬럼이 없더라도 최소 키값과 최대 키값으로 Key Range를 자동으로 추가하여 인덱스 스캔이 가능하도록 최적화한다. 즉, 인덱스 리프 노드의 처음부터 끝까지 스캔하게 되는데, 이를 오라클에서는 인덱스 전체 범위 스캔(Index Full Range Scan) 이라고 부른다.

 

SELECT * FROM tbl WHERE b < ‘K’ ORDER BY a;


이 질의는 옵티마이저에 의해 인덱스 전체 범위 스캔이 수행되는 예이다. CUBRID Manager라는 질의 실행 도구로 해당 질의문의 실행 계획을 확인하면, 그림 6에서처럼 Key Range가 자동으로 추가되어 ORDER BY 정렬 연산이 생략되는 것을 알 수 있다.

 

pic6.jpg
그림 6 옵티마이저에 의해 정렬 최적화된 질의의 실행 계획

 

최적화 기법 4. LIMIT 최적화


LIMIT 절은 질의의 최종 결과 개수를 제한한다. Data Filter가 없는 질의에 LIMIT 절이 있으면 Key Range에 해당하는 키 값 전부를 스캔할 필요 없이 LIMIT 절에 기술된 개수만큼의 결과를 확보하자 마자 스캔을 중단할 수 있다. 이는 Range의 끝까지 스캔하고 나서 결국은 버리게 되는 페이지를 액세스하지 않기 때문에 불필요한 I/O를 제거할 수 있다.

SELECT * FROM tbl WHERE a = 2 AND b < ‘K’ ORDER BY b LIMIT 3;
이 질의는 LIMIT 최적화에 의해 필요한 결과를 얻은 후 인덱스 스캔이 중단되는 예이다. 만약 a = 2인 인덱스 키가 10페이지에 걸쳐 저장되어 있더라도 LIMIT 절에 명시한 3개의 키 값만 스캔하므로 1개의 페이지만 읽게 된다.
 

pic7.jpg
그림 7 LIMIT 최적화된 질의 처리 과정

 

한편, IN 절을 사용한 질의에 대해서도 LIMIT 최적화를 적용할 수 있다. CUBRID는 인덱스 컬럼이 IN 절에 사용되면 Key Range를 IN에 사용된 개수만큼 생성하고, 각각에 대해 인덱스 스캔을 수행한다. 다만, 아래 질의처럼 LIMIT 절에 결과 개수가 명시된 경우, 3번의 인덱스 스캔에 대해 각각 3건의 결과만 획득하고 인덱스 스캔을 중단한다. 즉, 각각의 인덱스 스캔에 대해서 LIMIT 최적화가 적용되는 것이다.

 

SELECT * FROM tbl WHERE a IN (2, 4, 5) AND b < ‘K’ ORDER BY b LIMIT 3;


ORDER BY절은 전체 결과에 대한 정렬을 의미하기 때문에 Key Range가 여러 개이면 각각의 인덱스 스캔 결과를 모아서 다시 정렬을 해야 한다. 하지만 인덱스 스캔의 결과로 정렬을 대체할 수 있는 경우에는 스캔 과정에서 바로 병합(merge)할 수 있다.  CUBRID는 이 과정을 In-Place Sorting 이라고 부른다.
그림 8을 보면서 자세한 설명을 하면, 먼저 첫 번째 range(a = 2 AND b < ‘K’)에 대한 스캔을 통해 3건의 OID를 확보한다. 그 다음 두 번째 range(a = 4 AND b < ‘K’)에 대한 스캔을 시도하는데, 이 range의 첫 번째 키인 (4, ‘DAA’)는 첫 번째 range의 마지막 스캔 키인 (2, ‘CCC’) 보다 b 컬럼의 값이 크기 때문에 바로 스캔을 중단한다. 마찬가지로 다음 세 번째 range인 a = 5 AND b < ‘K’에 대한 스캔에서도 두 번째 키를 읽은 후 바로 스캔을 중단한다. 이처럼 In-Place Sorting 기법은 인덱스 스캔 범위를 더욱 축소하고, 최종 결과에 대한 별도의 정렬을 수행하지 않기 때문에 성능 향상에 많은 도움을 준다.

 

 

 pic8.jpg
그림 8 In-Place Sorting 기법에 의해 최적화된 질의 처리 과정

 

요약 정리


인덱스가 좋다고 해서 인덱스를 많이 만드는 것이 능사가 아니다. 오히려 인덱스 관리 비용이 증가하고 INSERT, UPDATE, DELETE 성능 저하의 원인이 될 수 있다.
DB 튜닝의 핵심은 적절한 수의 인덱스를 생성하고 질의가 이 인덱스들을 활용할 수 있도록 질의를 최적화하는 것이다. 이를 위해서는 DBMS에 구현된 인덱스 구조와 다양한 활용 기법들을 이해하고, 질의 패턴과 사용 빈도, I/O 비용, 저장 공간에 대한 비용을 전체적으로 고려하여야 한다.

 


  1. 인덱스, 아는 만큼 보인다!......DBMS 개발자가 전하는 인덱스 활용 노하우

    인덱스, 아는 만큼 보인다! DBMS 개발자가 전하는 인덱스 활용 노하우 고성능 서비스를 구축하기 위한 DB 쿼리 튜닝의 핵심은 인덱스를 얼마나 잘 활용하는가에 달려 있다. 지난 3년 동안 CUBRID를 NHN 내/외부 서비스에 적용하면서 의외로 많은 개발자들이 DB 인덱스에 대해 “잘” 알지 못하고 “잘” 활용하지 못한다는 것을 발견하였다. 본 기고문에서는 6월 30일에 출시된 CUBRID 2008 R4.0에 적용된 다양한 인덱스 기법을 중심으로 인덱스 구조와 인덱스 활용 노하우를 쉽게 설명하고자 한다. 단, MySQL, MS-SQL, Oracle 등 다른 DBMS에서도 이와 동일/유사한 인덱스 기법이 적용되어 있으므로 본 기고문에서 소개할 인덱스 활용 노하우가 CUBRID에 국한되지 않는다는 점을 강조하고 싶다. * 본 게시글은 월간 마이크로소프트웨어 8월호에 게재된 내용의 원작입니다. 월간 마이크로소프트웨어에서는 약간 내용이 줄어서 게재된 관계로 본 게시글과 차이가 있을 수 있습니다. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 강동완 | NHN Bu...
    Date2011.08.12 Category제품 여행 Byadmin Views37599 Votes0
    Read More
  2. 죽지 않아야 한다. 날리지 말아야 한다. 빨라야 한다.

    무중단 서비스를 위한 DB 서버 이중화 구축 죽지 않아야 한다. 날리지 말아야 한다. 빨라야 한다. * 본 게시글은 월간 마이크로소프트웨어 7월호에 게재된 내용입니다. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 오보명 obm@nhn.com | NHN Business Platform 서비스 플랫폼 개발 센터에서 플랫폼 확산 업무 및 오픈소스 라이선스 컨설팅 업무를 담당하고 있다. 4년 전 CUBRID라는 국산 DBMS와 인연을 맺은 이후, CUBRID 의 국내/해외 확산 업무를 담당하고 있으며 CUBRID 글로벌 커뮤니티 사이트(http://cubrid.org)를 운영하면서 전세계 개발자들과 소통하고 있다. ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 2011년 6월 17일(금) 자정 00:00부터 오전 09:30분까지 국내 홈쇼핑 선두 업체의 쇼핑 사이트가 시스템 점검을 이유로 서비스 운영을 일시 중단했다. 해당 업체의 2010년 매출액과 ...
    Date2011.08.03 Category제품 여행 Byadmin Views51502 Votes0
    Read More
  3. CUBRID BI 변경 뒷이야기

    CUBRID 2008 R4.0 Beta 출시에 맞춰 CUBRID BI (Brand Identity)가 변경되었습니다. BI를 변경하게 되었던 배경은 1) 글로벌 진출에 따른 차별화된 아이덴티티 확립, 2) 오픈소스의 친근한 이미지와 기업 솔루션의 전문적 이미지를 함께 추구할 수 있는 아이덴티티 확립, 3) 별도의 심볼을 제작하여 홈페이지, 사용자 커뮤니티, 제품 아이콘 등으로 아이덴티티를 확장 활용할 수 있는 필요성 3가지로 정리할 수 있습니다.   금년 2월부터 브랜드 디자인 컨셉에 대한 세부적인 논의가 시작되었고, CUBRID가 추구하는 컨셉을 “성능, 안정성, 기능 향상을 위해 끊임없이 진화하는 오픈소스 DBMS”로 정하고, 이를 위해 브랜드 심볼은 “도전, 진화, 성장, 혁신, 친근, 신선함”의 이미지를 제공하는 것으로 정리를 했습니다.   4월 초에 1차 작업으로 총 9개의 시안이 나왔으며, 이중 3개가 선별되어 한국/중국/루마니아로 구성된 CUBRID 커뮤니티 멤버들을 대상으로 선호도 조사가 진행되었습니다.     첫번째 로고는 “큐브(Cube)”와 “구조(Structure)”, 두번째는 “큐브(Cube, Data)”와 “연결(Bridge, Connect), 세번째는 “기하학(Geometry)”과 “무한(Infinite)”이라는 모티브를 기...
    Date2011.05.20 Category알려요~ By정병주 Views49189 Votes0
    Read More
  4. NHN은 CUBRID를 얼마만큼 사용하고 있을까?

    지난 주 목요일 전자신문 정보통신면(7면) 좌상단에 “NHN, DBMS 국산 ‘큐브리드’로”라는 제목으로 기사가 크게 게재되었습니다(관련 기사 참조). 국내 최대 규모의 데이터베이스를 보유하고 있는 NHN이 네이버 서비스와 사내 인프라에 적용되는 데이터베이스관리시스템(DBMS)을 모두 CUBRID로 교체한다는 내용으로 as-is와 to-be에 대해서 기술되어 있습니다. 기사 내용을 정리해 보면 아래와 같습니다.   As-is       - NHN은 3년 전부터 CUBRID DBMS를 적용하기 시작 -> 오픈소스 DBMS로 전환하기 전인 CUBRID 7.x 버전부터 사용     - 현재 네이버에서 제공하는 80여개의 서비스에 적용했음(NHN 전체 서비스의 30% 수준)     - DB 서버 수 기준으로 NHN 전체 서버 중 5~6%에 해당     - 적용 분야도 카페 덧글, 블로그 덧글 등 대용량 서비스를 포함한 핵심 분야   To-be       - DB 서버 수 기준으로 2011년 말까지 NHN 전체 서버의 약 30%에 CUBRID가 적용될 전망     - CUBRID DBMS 적용 서비스를 지속적으로 확대해 향후 2~3년 안에 가능한 모든 DBMS를 CUBRID로 전환할 계획   2008년 11월 CUBRID가 오픈소스 DBMS로 전환되고 2년 3개월이 조금 넘은 시점인데 NHN의 주...
    Date2011.03.15 Category고객 적용사례 By정병주 Views30173 Votes0
    Read More
  5. CUBRID vs. Oracle 총소유비용(TCO) 비교

    작년 말 CIO BIZ+ 기사를 통해 오라클이 서버용 SW 라이선스 정책을 수정했다는 내용을 확인하게 되었습니다.   내년부터 HP서버용 오라클 SW 가격 ‘2배’...썬은 50%↓   기사 내용의 요지는 스팍 프로세서의 라이선스 팩터(코어에 대한 라이선스 가중치)를 0.75에서 0.5로 내리고, HP 아이테니엄 프로세서(팩터 0.5)와 IBM 파워 프로세서(팩터 0.75)에 대한 팩터는 1로 조정을 함으로써 HP/IBM 서버 기반으로 Oracle DBMS를 구축할 경우 라이선스 비용이 증가하게 되었다는 것입니다(Oracle for HP는 100%, Oracle for IBM은 33% 가격 인상 효과). 반대로 SUN 서버 + Oracle 조합으로 구매하는 사용자는 DBMS 라이선스에 대한 비용을 절감할 수 있고요.   IBM이야 자체적으로 DBMS 제품(DB2)을 보유하고 있기 때문에 상대적으로 영향을 덜 받겠지만, HP는 상황이 달라지는 것 같습니다. 최근 코리아크레딧뷰로(KCB)가 유닉스 서버 가상화 및 통합 사업을 진행하면서 기존 HP 서버를 IBM 서버로 전면 교체하기로 결정을 했다고 합니다(관련 기사: HP 유닉스서버, 오라클 가격인상 직격탄 맞다). 반면 MS와의 협력을 강화하여 어플라이언스 4종을 발표하는 행보를 보이고 있고요(...
    Date2011.01.29 Category라이선스 고찰 By정병주 Views44626 Votes0
    Read More
  6. CUBRID vs MySQL vs PstgreSQL 제품릴리스 시기 비교

    얼마 전 큐브리드가 제품 다운로드 10만건을 돌파했다는 소식을 전하면서 지인으로부터 많은 격려와 축하를 받았다. 큐브리드가 한 일이라기 보다는 큐브리드를 사용하고 있는 사용자들이 축하를 받아야 하겠지만 어찌됐던 기쁜 일이 아닐 수 없다. 생각해 보면, 국산 소프트웨어로서 그것도 오픈소스 소프트웨어로서 일반 애플리케이션이나 솔루션이 아닌 DBMS라는 조금은 어렵고 제한적인 소프트웨어를 10만건씩 다운로드 했다는 것은 이례적인 일이 아닐 수 없다. 이러한 결과가 가능할 수 있었던 것은 로그인없이 어느 누구나 제품을 다운로드 할 수 있도록 한 정책덕분도 있겠지만, 큐브리드를 기반으로 한 다양한 오픈소스 소프트웨어와의 연동으로 더 많은 사용자를 확보한 덕분이라고 할 수 있다. 뿐만 아니라, 무료로 진행하는 큐브리드 교육뿐 아니라 실시간으로 제품에 대한 궁금증을 8시간안에 해결해 주는 온라인 기술지원도 있었기에 가능했을 것이다. 그러나 무엇보다 지속적인이고 주기적인 제품 업데이트가 없었다면 가능했을까? 이러한 주기적인 업데이트를 하기 위해 이미 해외를 중심으로 추후 버전에 포함되었으면 하는 기능과 성능에 대한 의견을 적극적...
    Date2010.12.22 By멜라니 Views30541 Votes0
    Read More
  7. CUBRID 서비스 계약에 대한 이해 – 독립 소프트웨어 벤더(ISV)

    지난 달에 최종사용자(End-user)를 위한 CUBRID 서비스 계약에 대해 간략하게 살펴보았습니다. 금번에는 독립 소프트웨어 벤더(ISV: Independent Software Vendor)들이 CUBRID 기반으로 응용 소프트웨어(애플리케이션)를 개발/포팅하여 판매하는 경우에 대해서 설명을 드리도록 하겠습니다.   우선, CUBRID는 오픈소스 DBMS이고, DBMS 엔진은 GPL v2 or higher, 인터페이스는 “BSD 라이선스”를 적용하고 있다는 것은 잘 알고 계실 것입니다. 여기서 인터페이스 함은 JDBC, PHP, ODBC, OLEDB, CCI (C Client Interface) 등을 의미하며, 일반적으로 DBMS 기반의 애플리케이션을 개발할 때 주로 사용합니다. 따라서, CUBRID는 ISV들이 애플리케이션 개발/포팅을 완료한 후 최종사용자를 대상으로 비즈니스를 전개할 때 애플리케이션 소스코드를 공개할 필요가 없으며, 이와 관련된 상세한 내용은 “차별화된 라이선스 정책, 큐브리드 OSS 라이선스 가이드”를 참고하시기 바랍니다.      첫번째 모델은 ISV가 큐브리드사 기술지원 서비스 계약 없이 자체적으로 애플리케이션을 개발하여 판매하는 방식입니다. 주로 소규모의 애플리케이션에 적합하며, 최종사용자에 대한 CUBRID 기술...
    Date2010.11.16 Category라이선스 고찰 By정병주 Views33504 Votes0
    Read More
  8. 오픈소스 소프트웨어 기반의 성공적인 비즈니스 모델

    11월 2일 지식경제부가 주최하고 정보통신산업진흥원, 한국공개SW활성화포럼, 한국공개소프트웨어협회에서 주관한 제2회 공개SW Day 행사에 참석을 했었습니다. 행사의 주요 일정으로 개발자 대회 시상식과 트레이닝 캠프가 진행되었으며, 오전에 카네기멜론대 실리콘밸리 캠퍼스에서 소프트웨어 매니지먼트 프랙티스를 가르치고 있는 Tony Wasserman 교수가 “Building a Business on Open Source Software”라는 주제로 해외초청 강연을 해 주셨습니다.   Wasserman 교수는 강연을 시작하기 전 본인의 노트북과 LCD 프로젝터 간 연결이 매끄럽지 못해 잠시 난관에 부딪쳤는데, 그 와중에 “오픈소스 소프트웨어 행사에서 윈도우 기반의 노트북으로 발표를 하는 것이 맞느냐?”라는 질문을 던져 청중들에게 웃음을 선사했습니다(Wasserman 교수는 리눅스 OS를 사용함). 총 11개의 비즈니스 모델에 대해서 발표를 해 주셨고, 대부분 일반적인 내용들이라 새로움 또는 신선함에 대한 욕구 충족은 되지 않았지만, 전반적으로 핵심 내용만 잘 기술되어 있어서 발표자료의 일부를 발췌해 보았습니다(영어 단어가 평이하여 번역하지 않음).   Subscription Model - User downloads softw...
    Date2010.11.13 Category오픈소스 이야기 By정병주 Views43651 Votes0
    Read More
  9. CUBRID 서비스 계약에 대한 이해 – 최종사용자

    CUBRID는 오픈소스 라이선스를 채택하고 있습니다. DBMS 엔진은 GPL v2 or higher, 인터페이스는 BSD 라이선스를 적용하고 있으며, 소프트웨어 사용에 아무런 제약조건이 없습니다. 따라서 상용 소프트웨어와 같이 소프트웨어 라이선스(사용권)를 얻기 위해 비용을 지불할 필요가 없습니다. (참고: CUBRID 라이선스 및 서비스 정책에 대한 고찰)     CUBRID는 별도의 라이선스 비용 없이 서비스 비용만 지불하면 되며, 고객들을 만날 때 자주 질문 받는 내용 중 하나인 서비스 정책과 계약 방법에 대해 살펴 보도록 하겠습니다.   CUBRID의 서비스 정책은 크게 프로페셔널 서비스와 서포트 서비스로 나뉘어집니다.      프로페셔널 서비스는 개발 단계에서 제공되는 서비스로서 DB 설계 지원, 스키마 리뷰, 질의 리뷰, 데이터 변환 및 성능 튜닝 서비스 등이 포함되어 있습니다. 비용은 시간당 9만원(VAT 별도)이며, 지원 받고자 하는 시간만큼 계약을 체결하고 서비스를 제공 받으시면 됩니다.   응용 개발이 끝나면 일반적으로 운영 단계로 넘어갑니다. 운영 단계에서는 정기적인 예방점검(PM: Preventive Maintenance)을 통해 문제 발생을 선제적으로 방지하고, 각종 온라인...
    Date2010.10.12 Category라이선스 고찰 By정병주 Views36012 Votes0
    Read More
  10. 함께이기에 더욱 보람된 오픈소스 소프트웨어 확산! XE와 함께하는 큐브리드

    지난 SW업계에 있으면서 늘 들어왔던 사용자들의 소프트웨어에 대한 인식 재고에 대해 절감을 하는 게 아마도 가장 최근이 아닐까 싶습니다. IT환경속에서 무형의 자산인 소프트웨어의 활성화가 하드웨어만큼 발전하지 못한 것도 어찌보면 이 이유에서지 않을까 싶은데요… 국내에서 몇 되지 않은 오픈소스 소프트웨어 업체로서 어찌 보면 쉽지 않은 도전을 하고 있는 큐브리드에게는 더욱 더 실감하는 부분이 아닐까 싶습니다. 예전 외국의 오픈소스 사용현황 및 참여도 현황 자료를 보니 외국의 경우, 여기서 말하는 외국이라 하면 대부분이 선진국을 말하지만 이웃 중국이나 태국의 경우에도 오픈소스 소프트웨어에 대한 관심과 참여도가 우리나라 보다 높게 나타나고 있었습니다. 그만큼 국내에서 오픈소스 소프트웨어라는 분야에 있다는 것이 쉽지 않은 게임이라고 할 수 있겠죠. 더욱이 소프트웨어 중에서도 어렵다는 데이터베이스쪽에서의 오픈소스는 외부에서 프로젝트에 참여할 개발자를 발굴하고 같이 성장하는 것이 더욱더 어려워 보입니다. * 출처: 레드햇과 조지아 공과대학교가 공동으로 전세계 75개국의 오픈소스 환경을 비교, 분석한 ‘오픈소스 인덱스’ 보고서....
    Date2010.07.22 By멜라니 Views43758 Votes0
    Read More
Board Pagination Prev 1 ... 5 6 7 8 9 10 11 12 13 14 ... 16 Next
/ 16

Contact Cubrid

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