Background Image
나머지...
2018.12.28 10:24

DBMS? 힐끗 다른 쪽을 바라봤다

조회 수 990 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

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

Databases-comparisons-on-DBEngine.jpg


 시스템 소프트웨어 개발자로 딱 60살까지만 이런저런 시스템, 특히 대용량 데이터를 다루는 시스템을 직접 설계하고 만들어보고 싶은 마음은 지금도 여전하다.

그리고 그러한 미련에 들어온 DBMS 개발바닥이다. 원래 우직하니 한 우물만 파는 스타일은 아닌데.. 어찌어찌 하다보니 10년째 데이터 처리 엔진쪽으로만 일하고 있는 자신을 바라보며 기특하단 생각도 든다. 하지만 최신 유행하는 다른 분야로 발빠르게 움직이지 못한 것이 못내 아쉬울 때도 종종 있다. 


이런 내 마음에는 아랑곳 없이 데이터환경이 휙휙 바뀌면서 하루가 멀다하고 새로운 모양의 시스템, DB들이 마구 쏟아져 나온다. 이런 추세속에서 여전한? 것들을 하고 있는 내 자신을 바라보고 있자면 old school에서 벗어나지 못하고 있는 듯 느껴져 왠지 마음이 급해진다. 이 글을 쓰고 있는 지금도 어디에선가는 새로운 DB(용어따지기 좋아하는 사람들을 위해 여기서 'DB'는 데이터베이스 자체가 아니라 DBMS혹은 DMS를 의미한다는 것을 밝힌다)가 글로벌 DB시장에 런칭하는 소리가 들리는 듯 하니 말이다.


그러나 이쪽 분야에서 일을 하면 할수록 데이터를 다루는 일에 신구라는 것이 없다는 생각이다. 다만 어떤 정보들을 관리할 것인가가 시스템의 선택에 중요한 역할을 하는 시대라는 것..

이젠 RDBMS(Relational Database Management System)를 두고 흔히 '전통적인 DBMS'라는 말을 쓰는 것을 자주 듣는다. 그 전통적인 DBMS의 엔진개발자로 오래 일해왔지만 보면 볼수록 공부할 부분이 많아진다는 생각엔 변함이 없다. 그와 더불어 이젠 요즘 유행하는 블록체인이나 인공지능쪽을 공부해볼까 하는 생각도 간혹 할때가 있지만 아직은 데이터를 처리하는 시스템 소프트웨어 개발자로 일하는 것이 더 즐겁다. 물론 블록체인이나 인공지능쪽이 데이터와 무관해서는 아니다. 오히려 그것들은 데이터의 처리방식보다는 데이터의 내용과 더 직접적인 관계가 있는 영역이라고 생각한다. 


전통적인 RDBMS에서 데이터는 관계성을 가지며 릴레이션 혹은 테이블이라는 스키마들로 모델링 된다. 모든 데이터는 도메인을 갖고 있으며 도메인에 추가된 제약조건들을 만족하는 값으로만 그 identity를 갖는다. 

E. F. Codd 박사가 'A Relational Model of Data for Large Shared Data Banks'를 통해 대용량(그 당시의) 데이터를 어떻게 다룰 것인지 릴레이션과 튜플, 그리고 정규화에 대해 이야기했던 시점으로부터 약 50년의 세월이 흘렀다. 그리고 대용량 데이터의 기준이 달라졌다. 아니 그 후로 지금까지 죽 계속 달라져왔다고 해야 맞을 것이다. 


비즈니스 쪽에서 '빅데이터'를 거론하며 마치 '빅데이터 시스템'이라는 것이 존재하는 것 마냥 사람들이 '빅데이터!''빅데이터!'를  외칠 때에도 시스템 소프트웨어 개발자들은 기존과 동일한 기술기반으로 빅데이터라는 놈을 해결했다. 그러나 아직까지도 빅데이터가 하둡을 의미하는 것으로 생각하는 사람이 존재하듯 특정 시스템을 모든 빅데이터문제를 해결해줄 답안으로 생각하는 사람도 분명 있을거라 생각한다. 


그러나 수많은 데이터 처리 기술들이 존재하는 이유는, 무엇을 정보로 볼 것이며 데이터를 어떻게 바라볼 것인가이다. 다시말해 정보를 어떻게 관리할 것인가가 시스템을 선택하고 설계하는데 있어 최우선적으로 고려해야 할 사항이다. 


RDBMS는 릴레이션이라는 관계성을 데이터에 부여함으로써 정보를 관리하는 한 가지 효과적인 방법을 제시했을 뿐이고 지금까지도 수많은 정보들을 관리하는데 유용하게 쓰이고 있을 따름이다. 


몇달 전 회사 근처에서 그래프 데이터베이스(이하 GDBMS) 관련 밋업이 있어 참석했던 적이 있다. 
그 회사에서 GDBMS를 개발하고 있는 개발자의 과반수가 예전, 같은 연구실 혹은 같은 회사 동료로 함께 일했던 경험이 있다보니 그네들이 만들고 있다는 것이 도대체 무언지 더 궁금한 것도 있었지만, 예전부터 GDBMS에 조금은 관심이 있던 차에 잘됐다 싶었다.


GDBMS는 DBMS시장에서 아직까지도 전통적인 강자인 RDBMS에 비하면 아직 갈 길이 멀지만 시장 성장세가 아주 빠른 제품에 속한다. 

그도 그럴것이 GDBMS는 SNS로 대변되는 '실시간으로 쏟아지는 대량의 비정형 데이터' 를 처리하기에 전통적인 RDBMS보다 우월한 면도 없지 않기 때문에, 최근 SNS를 통해 늘어나는 데이터의 처리가 곧 비즈니스가 되는 현실에선 RDBMS보다 나아보일 수도 있다.


그럼 GDBMS는 RDBMS랑 뭐가 어떻게 다른 것일까?

Graph라는 단어가 의미하듯 GDBMS는 그래프를 이용한? DBMS임에는 분명하다. '그래프'라는 용어를 수학적으로 이해하지 못하는 경우, 혹은 DBMS에 관해 전혀 지식이 없거나 데이터 관리 시스템에 대해 잘 알지 못하는 사람들은 그래프와 그래픽을 혼동하는 경우도 꽤 많다. 그래서 밋업에서 "그래픽데이터베이스라고 하는데 도대체 그래픽으로 뭘 보여준다는 건가요?" 라는 질문을 하는 경우도 봤다. 

그래프는 간단히 말하면 점(vertex)과 선(edge)으로 표현된다. 여기서 점은 흔히 객체로 모델링 되고 선은 관계 내지는 행동(상태의 변경)을 표현하기 위한 수단이 된다. 

GDBMS는 쉽게 말하자면 사용자에게 이러한 그래프의 개념으로 데이터를 모델링할 수 있도록 해주는 DBMS이다. 


앞서 데이터를 처리하는데 있어 중요한 것은 무엇을 정보로 볼 것인가와 데이터를 어떻게 바라볼 것인가라고 썼다. 

정보는 데이터 그 자체일 수도 있고 관련있는 데이터들의 집합 혹은 데이터의 위치, 데이터가 존재하는 이유, 데이터가 생성된 이력 등 무수히 많은 형태가 존재한다. 그동안 사람들, 그리고 수많은 조직들은 정말 제한적인 데이터모델 안에서 아주 많은 일들을 처리하며 살아왔다. 

하지만 90년대 초반부터 꿈틀대더니 이젠 이것 없이는 못살게 된 인터넷의 발달부터 인터넷기술을 밑에 깔고 등장한 많은 문화들, 그 중에 텍스트, 이미지, 사운드를 안가리고 매초마다 엄청난 정보데이터를 양산하는 SNS라는 문화적 기재로 인해 처리해야하는 정보의 성격에 아주 큰 변화가 일어났다. 불과 20년 남짓만에 정보의 구성요소가 되는 데이터를 바라보는 뷰가 하나 더 늘어야 하는 시대가 된 것이다. 데이터를 바라보는 뷰가 바로 데이터 모델이다. RDBMS는 릴레이션이라는 뷰를 제공함으로써 데이터를 모델링하기 쉽도록 해준 것 뿐이다. 


RDBMS가 주류시스템 소프트웨어가 된 당시에는 월스트리트로 대변되는 금융, 보험업무로부터 발생하는 데이터가 여러 비즈니스 영역들 가운데서도 가장 많았다. 또한 이 데이터들은 한 번 잘못 기입되거나 누락되면 엄청난 책임을 져야하는 경우가 많았기 때문에 이들에 대한 보장을 안정적으로 해줄 수 있는 시스템이 필요했다. 말로 풀어썼지만 간단히 말하자면 ACID속성을 갖는 트랜잭션 정보의 처리가 무엇보다 중요했다는 것이다. 그러한 데이터 처리환경에서 마치 자연선택설에 의한 결과인듯 DBMS는 트랜잭션처리에 특화된 성능과 안정적 우월성을 바탕으로 대부분의 데이터 처리 시스템의 기반으로 자리매김했다. 


수십년의 세월동안 데이터의 속성이 바뀌어도 데이터의 양과 응용방식이 바뀌어 왔음에도 DBMS가 아직까지도 그 자리를 내어주지 않은 것은 DBMS또한 그러한 환경변화에 매우 잘 적응하며 발전해왔기 때문이다. 2000년 초반 '클라우드'라는 개념이 대두되고 5년남짓일까 너도나도 여기저기서 클라우드 클라우드할 때만해도 DBMS는 위기를 느끼지 않았던듯 하다. 그러나 뭔가 얻어맞은 듯한 느낌이 들정도로 DBMS시장의 근간을 흔든 일이 2010년 초반 '빅데이터'라는 개념의 대두와 더불어 일어났다. 바로 NoSQL 이었고  MongoDB, Cassandra 등 수많은 NoSQL 제품들이 재조명되거나 봇물터지듯 시장으로 쏟아져 나왔다. 시스템의 구상과 개발이야 이전부터 있어왔지만 NoSQL의 약진은 빅데이터의 유행과 그 근간을 함께 한다. 빅데이터가 과연 무엇이냐를 놓고 2010년 초반 그 정의나 분류에 대해 참 말이 많았다. 아니 개념조차 제대로 잡지 못한채 스스로 자신이 빅데이터 전문가라며 당시 컨설팅을 하고 다닌 사람들이 이젠 어엿하게 빅데이터 시장에서 명함만 내밀어도 인정받는 사람들이 된 2010년 말에와 회상해 보면 NoSQL은 ACID를 다 만족시키지 않아도 된다는 어찌보면 당연한 것을 '그래 난 내가 원하는 것만 보장할래'라는 배짱 튀기기로 밀고 나간 것이었다.


이래서 DBMS보다 가볍다. 그래서 DBMS보다 특정 연산에 빠르다. 저래서 DBMS보다 싸다. 그래서.. 등등 

많은 이유들이 특정 트랜잭션 혹은 데이터 처리환경에서 그들의 손을 들어줬다. 그만큼 전통적인 DBMS는 비즈니스 레벨에서 데이터 처리 영역이 보다 세분화되어 대부분의 데이터 처리가 아닌 특정 데이터처리에 적합하다는 말을 들어야 하는 때가 왔다. 사실 아직도 ACID를 만족하는 트랜잭션 처리 분야는 데이터 처리 시장에서 매우 큰 부분을 차지하는 중요한 시장이다. 그럼에도 불구하고 상대적인 박탈감? 같은 것이 느껴진달까.. 예전에는 DBMS로 다 했는데 이젠 이건 뭐가 저건 뭐가 더 낫다는 결과들이 제시되며 왠지 '야 그동안 많이 해먹었으니 이젠 내려와라' 하는 느낌이다. 


그러나 과연 그럴까..? 데이터 처리 엔진을 굳이 유형별로 구분하고 분류해 두고 이런 환경엔 이게 최고 저런 환경엔 저게 최고라는 식의 논리로 한 시점에 베스트인것으로 보이는? 시스템을 설계하는 것으로 다 된 것일까? 데이터의 본질을 생각하면 정보의 본질을 생각하면 정보의 사용성이 어디에서 기인하는지를 생각해보면 그리고 거기에 더해 사용자의 편의성 정보관리의 주체와 기간 데이터의 유지비용 및 데이터 흐름의 적시성 등을 생각해보면 왜 지금도 새로운 데이터 처리 시스템들이 시장에 등장하고 있는지 알 수 있다. 


그럼에도 불구하고 데이터 처리의 기본은 데이터에 요구하는 속성에 기인한다. 

트랜잭션에 관한 이론은 이러한 데이터 처리에 있어 가장 근본적인 문제를 다룬 것이다. 마치 경제학에서 수요와 공급이 수많은 경제이론을 설명하는 이유와 시발점이 되는 것처럼 트랜잭션은 처리할 데이터의 가장 중요한 속성을 어떻게 볼 것인가를 짚고 있는 것이다. 그리고 그러한 것을 연구하는 분야가 바로 데이터 처리 시스템 연구분야이고 DBMS는 개발이 완료된 더이상 생각할꺼리가 별로 없는 시스템이 아니라 끊임없이 발전해나가고 있고 발전해 나가야 하는 시스템이다. 그래서 DBMS는 아직도 파야할 것이 많다. 


혹자들은 DBMS를 이미 legacy라 부르거나 기술하고 있을지도 모른다. 하지만 television을 레거시라 하진 않는다. 

DBMS는 브라운관TV가 아니다. television이다. 


  1. CUBRID 슬랏 페이지(slotted page) 구조 살펴보기

    내가 INSERT한 레코드는 어떤 구조로 파일에 저장될까? 운전을 하다 보면 가끔 엔진이나 미션 등이 어떻게 동작하는지 궁금할 때가 있다. 연료가 어떻게 엔진에 전달되는지, 엔진은 어떻게 연료를 연소하여 동력을 얻는지, 또 이를 미션에 전달하여 어떻게 차를 움직이게 하는지 등에 대해 말이다. CUBRID를 사용하는 사용자들도 가끔 이런 호기심이 생기지 않을까? 이런 호기심 많은 사용자를 위한 첫번째로 "사용자가 INSERT한 레코드는 어떤 구조로 파일에 저장될까?"란 주제로 이야기 해보려고 한다. 티타임을 이용해 가벼운 마음으로 읽을 수 있도록 작성하였으니 여유 시간에 재미로 읽을 수 있길 바래본다. 슬랏 페이지(slotted page) 구조 CUBRID도 OS나 다른 DBMS와 같이 성능상의 이유로 페이지(page) 단위 디스크 I/O를 수행한다. CUBRID 페이지 크기는 최소 4KB ~ 최대 16KB 이며, 디폴트로 16KB 디스크 페이지 크기를 사용한다. 슬랏 페이지 구조란 이런 페이지에 데이터 저장을 구조화하는 하나의 방식을 말한다. CUBRID 사용자가 INSERT 구문을 사용하여 데이터(레코드)를 입력하게 되면, 여러 처리를 거친 후 결국 디스크 페이지에 입력된 데이터가 쓰여지게 ...
    Date2019.06.18 Category제품 여행 By민준 Views2371 Votes0
    Read More
  2. Node.js 사용자들을 위한 CUBIRD 연동 방법 [4탄(최종)-CUBRID와 Node.js 커넥션 풀(Connection Pool)설정]

    1. 환경소개 OS CentOS7 64비트 Node.js 10.15.3 버전 Npm 6.4.1 버전 java 1.8.0_201 버전 Editer Eclipse DB CUBRID 10.1 (10.1.2.7694-64632b2)(64비트) 2. 커넥션 풀 (Connection Pool) 이란? 2-1) 개념 ● 데이터베이스와 연결된 커넥션을 미리 만들어서 풀(pool) 속에 저장해 두고 있다가 필요할 때 커넥션을 풀에서 쓰고 다시 풀에 반환하는 기법을 말합니다. ● 커넥션 풀을 사용하면 커넥션을 생성하고 닫는 시간이 소모되지 않기 때문에 애플리케이션의 실행 속도가 빨라지며, 또한 한 번에 생성될 수 있는 커넥션 수를 제어하기 때문에 동시 접속자 수가 몰려도 웹 애플리케이션이 쉽게 다운되지 않습니다. ● 웹 컨테이너가 실행되면 커넥션(Connection) 객체를 미리 풀(pool)에 생성해 둡니다. ● DB와 연결된 커넥션(Connection)을 미리 생성하고, 풀(pool) 속에 저장했다가 필요할 때에 가져다 쓰고 반환합니다. ● 미리 커넥션(Connection)을 생성했기 때문에 데이터베이스에 부하를 줄이고 유동적으로 연결을 관리할 수 있습니다. 3. 커넥션 풀 (Connection Pool) 환경 설정 ● node-cubrid는 자체적인 커넥션 풀(Connection Pool) 기능을 제공하고 있지는 않습니다...
    Date2019.06.13 Category제품 여행 By원종민 Views4608 Votes0
    Read More
  3. Node.js 사용자들을 위한 CUBIRD 연동 방법 [3탄-Callback과 Promise 패턴 개념 소개]

    개요. ●Callback과 Promise 패턴을 이야기 앞서 동기식과 비동기식 프로그래밍을 소개하겠습니다. 1. 동기식 프로그래밍 vs 비동기식 프로그래밍 1-1) 동기식 프로그래밍 ● 어떤 작업을 요청한 후 그 작업이 완료되기까지 기다렸다가 응답을 받아 처리하는 것을 말합니다. <예제 코드> <예제 결과> 동기식 프로그래밍 function addition(x){ return x+x; } var num = addition(2); console.log(num); //4 * 순차적으로 해당 덧셈작업이 완료되기 까지 기다렸다가 결과 값을 보여주게 됩니다. 1-2) 비동기식 프로그래밍 ● 어떤 작업을 요청한 후 다른 작업을 수행하다가 이벤트가 발생하면 그에 대한 응답을 받아 처리하는 것을 말합니다. <예제 코드> <예제 결과> 비동기식 프로그래밍 function addition(x, callback){ setTimeout(callback, 100, x+x); } var num = 0; addition(2,function(x){ num = x; }); console.log(num); //0 * setTimeout은 비동기를 표현하기 위해 사용하였습니다. * 0.1초 후 callback 함수가 실행되는 코드입니다. 해당 코드를 동기식으로 바라보면, console.log에는 4라는 결과 값이 출력되어야 하지만, 결과는 0이 됩니다. 그 이유로 console.log...
    Date2019.06.11 Category제품 여행 By원종민 Views822 Votes0
    Read More
  4. Node.js 사용자들을 위한 CUBIRD 연동 방법 [2탄-CUBRID와 Node.js 연동]

    1. test 디렉토리 & 파일 생성 1-1) 라우터 파일 생성 ● /routes/test.js 1-2) view 디렉토리& 파일 생성 ● views/test 디렉토리 생성 ● views/test/test_view.ejs 파일 생성 1-3) 프로젝트 최종 결과 2. node-cubrid 드라이버 모듈 설치 ● 모듈 공식 사이트 : https://www.npmjs.com/package/node-cubrid 2-1) node-cubrid 모듈 설치 ● npm install node-cubrid --save ● package.json 에서 node-cubrid 모듈 설치 확인 3. node-cubrid 모듈 적용 및 DB 연동 3-1) 컨트롤러(app.js)에서 라우팅(test.js) 설정. - app.js의 25번째 줄과 동일하게 app.use('/test',require('./routes/test')); 추가 app.js var createError = require('http-errors'); var express = require('express'); var path = require('path'); var cookieParser = require('cookie-parser'); // 접속한 클라이언트의 쿠키 정보에 접근하기 위한 모듈 var logger = require('morgan'); // 클라이언트의 HTTP 요청 정보를 로깅하기 위한 모듈 var indexRouter = require('./routes/index'); var usersRouter = require('./ro...
    Date2019.06.04 Category제품 여행 By원종민 Views2441 Votes0
    Read More
  5. Node.js 사용자들을 위한 CUBIRD 연동 방법 [1탄-Node.js 환경 설치 및 개념 소개]

    1. 환경소개 OS Window 10 64비트 Node.js 10.15.3 버전 Npm 6.4.1 버전 java 1.8.0_201 버전 Editor Eclipse DB CUBRID 10.1 (Window 10 64비트) / CUBRID Manager 10.1 (Window 10 64비트) 2. Node.js 소개 Node.js란? 1) 개념 - Node.js는 확장성 있는 네트워크 애플리케이션 개발에 사용되는 소프트웨어 플랫폼입니다. - 자바스크립트를 서버에서도 사용을 할 수가 있도록 설계가 되어 있는 서버개발을 위해서 나온 언어로 v8이라는 자바스크립트 엔진 위에서 동작하는 이벤트 처리 I/O 프레임워크로 웹서버와 같이 확장성 있는 네트워크 프로그램을 제작하기 위하여 고안이 된 것입니다. 2) 사용 이유 - 간단히 Node.js를 소개하면, 이전까지 Server-Clint 웹사이트를 만들 때 웹에서 표시되는 부분은 javascript를 사용하여 만들어야만 했으며, 서버는 ruby, java 등 다른 언어를 써서 만들어야 했는데, 마침내 한가지 언어로 전체 웹페이지를 만들 수 있게 된 것입니다. express란? 1) 개념 - 노드(NodeJS) 상에서 동작하는 웹 개발 프레임워크로 간편하게 사용하기 위해 사용합니다. * 프레임워크(Framework)란 : 소프트웨어의 구체적인 부분에 해당하는 설계와 구현을...
    Date2019.06.03 Category제품 여행 By원종민 Views2146 Votes0
    Read More
  6. No Image

    분산 시스템으로서의 DBMS, 그리고 큐브리드

    가끔 퇴근길에 서점에 들르곤 한다. 직업이 직업이라 그런진 몰라도 항상 IT코너에 머물러 어떤 새로운 책들이 출간되었나 보게 된다. 그러다보면 최근 유행하는 컨셉이나 아키텍쳐, 프로그래밍 언어나 개발방법론 등에 대해 트렌드가 뭔지 관찰하려고 안해도 자연히 접하게 되는 것 같다. 그 중 최근 유행처럼 사람들 입에 오르내리기도 하고 책으로 소개되기도 하는 개념들 중 MSA(Micro Service Architecture)라는 것이 있다. 뭔가 하고 들여다보니 MSA 개념에서 다루고 있는 '독립적으로 수행되는 최소단위의 서비스' 그리고 그 서비스들의 집합으로서의 시스템과 시스템의 분할에 관한 관점 및 해석은 십수년전 주목받던 SOA(Service Oriented Architecture)가 지향하는 서비스를 구성하는 기능별 시스템의 분할과 크게 다르지 않다. 이 글은 MSA와 SOA가 얼마나 비슷한 사상으로 소개된 개념인지를 이야기하고자 함이 아니다. 예전에도 의미있게 다뤄졌고 지금도 의미있게 받아들여지는 이러한 개념들이 시스템의 관점에서 더 좁게는 DBMS라는 시스템 소프트웨어적 관점에서 어떻게 해석될 수 있는가를 간단하게 짚어보고자 함이다. MSA의 개념이 제대로 구현되기 위해서...
    Date2019.03.29 Category나머지... By조성룡 Views1351 Votes0
    Read More
  7. [CUBRID 유틸리티] restoreslave에 대하여 알아보자.

    CUBRID는 10.1 version 이상부터 restoreslave란 명령어를 제공한다. CUBRID 9.3.x version 까지는 온라인 재구성을 위해 자체적으로 제공되는 shell script를 사용하였으나, 10.1 version 이상부터는 restoreslave 명령을 통해 보다 편하게 작업을 할 수있다. 해당 명령어를 통해 master의 구동 상태와는 상관 없이, slave를 재구축 할 수 있으며, 시나리오는 아래와 같다. 1. HA 서비스 중, 이중화가 깨졌을때. (1) 필요 환경 : master - slave의 이중화 환경. (2) 필요 파일 : master 서버의 backup file (3) 시나리오 - DB의 이중화가 깨지는 것을 재연하기 위해 slave의 db_ha_apply_info의 데이터를 삭제한다. - slave의 heartbeat를 종료한다. slave) $> csql -S -u dba --sysadm demodb sysadm> delete from db_ha_apply_info; - 위의 이중화 로그를 삭제하였을 경우, 동기화는 더이상 이루어지지 않는다. - 위의 행위로 인하여 DB 이중화가 깨졌다고 판단하고 이중화복구를 진행하여보자. - master에서 backup 받은 backup file은 slave에 옮겨놓은 상태이다. slave) $> cubrid service stop -- cubrid sevice 종료 $> ps -ef | grep cubrid -- CUBRID process가 모두...
    Date2019.03.29 Category제품 여행 By박동윤 Views742 Votes0
    Read More
  8. CUBRID 커버링 인덱스(covering index) 이야기

    CUBRID 2008 R4.0 버전 이상부터는 커버링 인덱스를 지원합니다, 커버링 인덱스는 “A covering index is a special case where the index itself contains the required data field(s) and can return the data.”라고 하는데 원문을 해석하면 커버링 인덱스는 인덱스 자체에 필수 데이터 필드가 들어 있고 데이터를 반환할 수 있는 특별한 인덱스라고 해석됩니다, 다시 정리하면 하나의 질의 내에 특정 인덱스를 구성하는 컬럼만 사용하는 경우 커버링 인덱스를 사용하게 됩니다. 아래 예제-1)에서 SELECT 질의의 WHERE 조건에 사용된 컬럼 i와, SELECT 리스트로 주어진 컬럼 j는 모두 인덱스 idx를 구성하는 컬럼입니다. 이와 같은 경우에 CUBRID는 SELECT 질의를 수행할 때 커버링 인덱스를 스캔 하게 됩니다, 이는 하나의 인덱스가 SELECT 문이 요구하는 조건과 결과를 모두 포함하고 있기 때문에 가능한 일입니다. 예제-1) CREATE TABLE tbl (i INT, j INT); CREATE INDEX idx ON tbl(i, j); SELECT j FROM tbl WHERE i > 0; 그렇다면 왜 커버링 인덱스라는 개념이 필요할까?, 우선 설명에 앞서 우선 CUBRID의 인덱스 구조에 대해 간단하게 설명하겠습니다. CU...
    Date2019.02.28 Category제품 여행 By정만영 Views1808 Votes0
    Read More
  9. CM을 통해 SQL을 분석해보자.

    SQL을 수행하다 보면 SLOW SQL이 많이 발생합니다. 이럴때, 해당 SQL의 실행계획을 확인 함으로써, 지연을 발생시키는 부분을 쉽게 찾을 수 있습니다. 1. SQL 서식화. - 보통 SQL을 LOG에서 copy 할경우 가시적으로 보기 힘든경우 사용합니다. 2. 질의 실행 계획보기. - 질의편집기에 SQL을 작성 후, 질의 실행계획보기를 통하여 해당 SQL의 실행계획을 확인 할 수 있습니다. 2.1 질의실행계획보기 --계속 - 질의 실행 계획보기를 실행 시, 질의 계획의 원본, 트리출력, 그래픽출력 등으로 쉽게 확인이 가능합니다. - 이글에서 주로 다룰 내용은 트리출력이며, 보다 사용자가 보기 편리한 구조로 이루어져 있습니다. - 해당 내용을 분석하면, olympic 테이블과 record 테이블은 서로 inner join으로 조인이 이루어 집니다. - olympic 테이블은 FULL SCAN이 일어났으며, 모두 디스크 io가 발생하였습니다. - record 테이블은 primary key(host_year)을 사용하여 인덱스 범위검색을 하였습니다. - 이때, olympic 테이블에서 추출한 레코드는 총 25개 이며, record 테이블에서는 2000개의 레코드를 추출하였습니다. - olympic 테이블에서의 전체 row는 25건이며, 페이지로는 1게 ...
    Date2019.01.01 Category제품 여행 By박동윤 Views1277 Votes0
    Read More
  10. No Image

    실패하지 않는 마이그레이션을 위해서 고려해야 될 사항

    실패하지 않는 마이그레이션을 위해서 고려해야 될 사항 클라우드 전환에 따라 기존 유지보수 비용이 높은 UNIX 체계에서 Linux 체계로 전환하면서 오픈소스 유형의 SW로 전환하는 사례가 많아졌다. 도입단가, 비용문제로 고객과 SW밴더간의 이견을 좁히지 못해서 대체 SW로 전환하는 사례도 있다. 그 이외에도 노후장비 교체시기에 SW까지 함께 교체하는 경우도 있는데 OS 및 WAS, 그리고 Database System과 같은 기업 서비스의 근간이 되는 Package SW들이 주 대상이 된다. 위 3가지 중에 대체 SW로 변환하는데 있어 어려움이 발생하는 영역으로 WAS 및 Database System 부분이 될 수 있는데 그 중에서도 Database System이 난위도가 높으며 성공여부를 가늠하는 핵심적인 부분이기도 하다. 다른 대체 SW로 전환하는 작업을 Win-Back 마이그레이션이라는 용어를 사용하기도 하는데 성공적으로 수행하기 위해서 꼼꼼하게 대비해야하는 사항들이 있다. 다수의 DBMS 전환작업을 해오면서 성공과 실패를 통해 경험한 내용을 기반으로 Win-Back 마이그레이션 프로젝트를 수행하는데 고려되어야 할 사항들에 대해서 공유하고자 한다. 1. 제품선정(RDB) DBA또는 그에 준하는 역할을...
    Date2018.12.31 Category나머지... By김창휘 Views7253 Votes0
    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