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

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

조회 수 167 추천 수 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 커버링 인덱스(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의 인덱스 구조에 대해 간단하게 설명하겠습니다. CUBRID는 B+T...
    Date2019.02.28 Category제품 여행 By정만영 Views65
    Read More
  2. 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박동윤 Views138
    Read More
  3. 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김창휘 Views150
    Read More
  4. CMT(CUBRID Migration Tool) 활용

    CMT를 이용하여 데이터 마이그레이션 작업하면서 여러가지의 팁이 있겠지만 4단계에서 유용하게 사용할 수 있는 팁중 PK가 없는 테이블에 대해서 데이터 수행전에 PK 선택하거나 또는 테이블 생성 후 PK 컬럼을 추가하여 데이터 마이그레이션하면 되는 팁을 알려 드리겠습니다. 1) PK가 없는 테이블에 대해 이관전 PK 컬럼 선택 후 데이터를 이관하는 방법 2) PK가 없는 테이블 정보를 그대로 생성하고 데이터를 이관전에 seq 컬럼을 추가하여 그 컬럼에 대해 PK로 만들어 주므로 PK에 대한 재작업이 안해도 되는 방법 위 두가지를 병행하여 데이터 이관 작업을 진행하면 좀 더 쉽게 데이터 이관 작업을 할 수 있다. 1단계 - 원본과 대상 유형을 선택한다. - 다음버튼을 클릭한다. 2단계 - 편집버튼을 클릭하여 "원본 정보"를 등록하여 접속이 되는지 테스트버튼을 클릭하여 확인한다. (연결이름 : 임의로 작성, 호스트 주소 : IP주소, 연결 포트 : 사용하는 접속 포트, 데이터베이스 이름 : SERVICE_NAME, 사용자 이름 : 실제사용자ID, 비밀번호 : 실제비밀번호) - 테스트버튼을 클릭하여 접속이 안되는 경우는 연결포트 또는 데이터베이스 이름, 사용자이름, 비밀번호가 틀...
    Date2018.12.31 Category알려요~ By엄기호 Views111
    Read More
  5. No Image

    CUBRID 매니저 가져오기 마법사 유용한 팁!

    CUBRID 매니저 가져오기 마법사 유용한 팁! 다량의 데이터를 엑셀로 작성해서 넣는 경우가 많으실 텐데요 CUBRID 매니저에서 UI로 간단하고 쉽게 데이터를 넣을 수 있습니다. 바로 가져오기라는 기능인데요 가져오기는 스키마, 데이터를 파일로부터 데이터베이스 서버로 import를 하는 기능 입니다. (스키마는 SQL 파일만 지원하며, 데이터는 SQL, CSV, XLS, TXT를 지원합니다.) 가져오기 마법사는 아래의 3단계로 구성되어 있습니다. •가져오기 유형 선택 • 가져오기할 데이터 소스 및 옵션 선택 • 가져오기 옵션 확인 여기서 팁 한가지! XLSX 파일은 엑셀 2007부터 추가된 파일 포맷이며 CUBRID 매니저는 XLSX 파일을 지원하지 않으므로, XLSX 파일을 원본으로 하여 데이터 가져오기 작업을 수행하는 경우 정상적인 데이터 입력을 보장할 수 없습니다. 따라서, XLSX 파일은 "다른 이름으로 저장" 메뉴를 통해 반드시 XLS 파일로 변환한 후에 사용해야 합니다. 그리고 XLS 파일로 저장 시 파일 문자집합을 신경 써 주셔야 합니다. 엑셀 한글 버전에서는 따로 문자집합을 설정 안 할 경우 기본 인코딩이 EUC-KR로 되어 있어 파일의 문자집합 옵션을 맞지 않게 데이터를 가져오...
    Date2018.12.31 Category제품 여행 By강주원 Views64
    Read More
  6. Docker, Kubernetes 환경에서 CUBRID 컨테이너 서비스 해보기

    Docker, Kubernetes 환경에서 CUBRID 컨테이너 서비스 해보기 최근에 여러 기업에서 Docker, Kubernetes를 사용하여 컨테이너로 서비스 하는 사레들을 많이 보았습니다. CUBRID도 컨테이너로 만들어서 Docker, Kubernetes 환경에서 서비스 해보려고 합니다. Docker는 '가장 빨리 만나는 Docker: 클라우드 플랫폼 어디서나 빠르게 배포하고 실행할 수 있는 리눅스 기반 경량화 컨테이너'라는 책으로 처음 접하였습니다. 책을 구매해서 보는 것을 권장드리지만 'http://pyrasis.com/docker.html' 페이지에서 책의 내용을 공개하고 있습니다. 책이 너무 길다면 Slideshare, 'https://www.slideshare.net/pyrasis/docker-fordummies-44424016' 페이지에서 슬라이드로 요약된 내용을 볼 수 있습니다. Docker는 Docker라는 회사에서 OS에서 제공하는 가상화 기술을 사용하여 만든 오픈소스 Container 프로젝트의 결과물입니다. 컨테이너는 호스트에 게스트 환경을 구성한다는 점에서는 가상머신과 비슷하지만 OS를 별도로 설치해 줄 필요가 없고, 호스트와 동일한 성능을 낼 수 있다는 장점이 있습니다. 이외에도 여러가지 장점이 많지만 가장 큰 장점은 배포가 쉽다는 점이라고 생...
    Date2018.12.31 By주영진 Views239
    Read More
  7. No Image

    기술지원 중 자주받는 질문들을 살펴보자 !

    큐브리드 엔지니어로 기술지원을 수행하면서 자주 받는 질문들을 크게 10개 단락으로 나누어 모아 보았습니다. 큐브리드를 사용해주시는 많은 분들에게 작게나마 도움이 되기를 바라는 마음으로 작성해 보았습니다. 자세한 내용은 하단에 매뉴얼 링크를 달아 두었으니 참조 부탁 드립니다 1. DB 백업/복구 1) 백업 명령어를 알고 싶어요. ① $ cubrid backupdb -D <백업 경로> -z --no-check <DB명> 2) 증분 백업도 지원하나요? ① 큐브리드는 1차, 2차 증분 백업을 지원합니다. ② 증분 백업을 하기 위해서는 백업 옵션 중 -l 옵션을 사용하면 됩니다. 백업수준은 0,1,2 3가지로 나뉘어 지며 각각 전체 백업, 1차 증분 백업, 2차 증분 백업을 의미합니다. ③ 예시 : cubrid backupdb -D <백업 경로> -z --no-check -l 1 <DB명> 3) 복구는 어떻게 해야 하나요? ① $ cubrid restoredb -B <백업 파일 경로> <DB명> 4) 시점 복구도 지원하나요? ① 큐브리드는 어떠한 옵션도 지정되지 않은 경우 기본적으로 마지막 커밋 시점까지 데이터베이스가 복구됩니다. 시점 복구를 하기 위해서는 -d 옵션으로 시간을 지정할 수 있으나, 지정한 복구 시점까지 복구하기 위한 활성로그/보관 로그 ...
    Date2018.12.30 Category제품 여행 By허서진 Views112
    Read More
  8. DBMS? 힐끗 다른 쪽을 바라봤다

    시스템 소프트웨어 개발자로 딱 60살까지만 이런저런 시스템, 특히 대용량 데이터를 다루는 시스템을 직접 설계하고 만들어보고 싶은 마음은 지금도 여전하다. 그리고 그러한 미련에 들어온 DBMS 개발바닥이다. 원래 우직하니 한 우물만 파는 스타일은 아닌데.. 어찌어찌 하다보니 10년째 데이터 처리 엔진쪽으로만 일하고 있는 자신을 바라보며 기특하단 생각도 든다. 하지만 최신 유행하는 다른 분야로 발빠르게 움직이지 못한 것이 못내 아쉬울 때도 종종 있다. 이런 내 마음에는 아랑곳 없이 데이터환경이 휙휙 바뀌면서 하루가 멀다하고 새로운 모양의 시스템, DB들이 마구 쏟아져 나온다. 이런 추세속에서 여전한? 것들을 하고 있는 내 자신을 바라보고 있자면 old school에서 벗어나지 못하고 있는 듯 느껴져 왠지 마음이 급해진다. 이 글을 쓰고 있는 지금도 어디에선가는 새로운 DB(용어따지기 좋아하는 사람들을 위해 여기서 'DB'는 데이터베이스 자체가 아니라 DBMS혹은 DMS를 의미한다는 것을 밝힌다)가 글로벌 DB시장에 런칭하는 소리가 들리는 듯 하니 말이다. 그러나 이쪽 분야에서 일을 하면 할수록 데이터를 다루는 일에 신구라는 것이 없다는 생각이다. 다...
    Date2018.12.28 Category나머지... By조성룡 Views167
    Read More
  9. CUBRID 10의 새로운 기능 "문자열 압축"

    CUBRID 10은 새로운 기능이 추가 되었습니다. 그 중에서 문자열 압축기능이 추가되었습니다. 지금부터 문자열 압축 기능에 대해서 알아보도록 하겠습니다. 문자열 압축 기능은 아래의 표와 같습니다. CUBRID 문자열 압축은 255byte 이상에서만 실행되고, 압축이 효율적이지 않으면 압축을 실행하지 않습니다. 문자열 압축률이 얼마나 좋은지 테스트하기 위해서 문자열 압축 기능이 없는 CUBRID 9.3과 10.1에서 테스트 데이타 10만건을 입력하고, 테이블 크기를 확인하는 방법으로 진행하였습니다. “케이스 #1”은 중복 되지 않는 문자열 데이타를 입력하고 압축률을 확인하였고, “케이스 #2”는 중복 된 데이타를 입력하고 압축률을 확인하였습니다. 각 케이스별로 데이타 10만건을 생성한 방법은 아래 표와 같습니다. 먼저 테스트 데이타 1건을 입력하고, “insert 테이블 select ...” 구문에서 카탈로그 테이블과 카테시안 곱(Cartesian Product)을 활용하여 테스트 데이타를 생성하였습니다. 위 표의 SQL문으로 데이타 10만건을 입력하고 테이블 크기를 확인하였습다. 테이블 크기는 “show heap capacity of 테이블명;” 명령을 실행하고 Num_pages 값을 확인하였고, 결과는 아...
    Date2018.12.26 Category제품 여행 By권호일 Views60
    Read More
  10. GitHub Desktop을 활용한 소중한 소스 코드 관리

    1) 소중한 자신의 소스 코드가 손상 되거나 손실 되는 경우 2) 외부에서 자신의 소스 코드를 열람해야할 경우 3) 소스 코드의 변경 된 부분을 찾아야 하는 경우 소스 코드를 사용하다 보면 위와 같은 문제로 업무의 연속성이 끊어지는 경우가 발생 합니다. 이러한 문제를 GitHub Desktop을 통해 아주 간단하고 편리하게 사용 및 관리 하는 기능을 소개 하려 합니다. - 비용 : 무료 단, 소스 코드를 비공개하려면 과금 필요 - GUI 프로그램으로 git bash(커맨드 라인) 보다 편리하며, 손 쉽게 사용할 수 있습니다. [1 : GitHub 회원 가입] - 회원 가입 URL : https://github.com/ - IMAGE #1 GitHub 공식 홈페이지 접속 화면 사용할 정보 입력 : Username, Email, Password - IMAGE #2 STEP 1 : 계정 생성 동의 하기 - IMAGE #3 STEP 2 : 계정 유형 선택 - IMAGE #4 사용자 유형 선택 (Skip 해도 무관) - IMAGE #5, 6, 7 STEP 3단계 모두 마치면, Email 확인 후 계정 사용 가능 [2 : GitHub Desktop 설치] - 설치 URL : https://desktop.github.com/ - 지원 OS : Windows, OS X(MAC) - IMAGE #1 공식 홈페이지에서 GitHub Desktop 설치 파일을 받으 실 수 있습니다. (약 80MB) ...
    Date2018.12.03 Category나머지... By윤준수 Views574
    Read More
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 Next
/ 10

Contact Cubrid

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