KR101160388B1 - 데이터베이스 관리 방법 및 시스템 - Google Patents

Abstract

특정 데이터가 선택되는 경우 해당 데이터의 선택과정과 해당 데이터의 조회수 갱신 과정을 동시에 수행할 수 있는 본 발명의 일 실시예에 따른 데이터베이스 관리 방법은 특정 테이블에 포함된 레코드의 인출요청 및 상기 레코드에 포함된 적어도 하나의 칼럼에 대한 갱신요청이 함께 정의된 질의문을 수신하여 분석하는 단계; 상기 분석된 질의문을 수행하기 위한 실행계획을 생성하는 단계; 및 상기 실행계획에 따라 상기 레코드의 인출 및 상기 적어도 하나의 칼럼에 대한 갱신을 수행함으로써 상기 실행계획을 실행하는 단계를 포함한다.

데이터베이스, DBMS, 질의문, 갱신, 칼럼

Description

데이터베이스 관리 방법 및 시스템{Method and System for Managing Database}

본 발명은 데이터베이스 관리 방법에 관한 것으로서, 보다 상세하게는 데이터베이스 관리 시스템을 이용하여 데이터베이스에 저장된 데이터를 효율적으로 갱신할 수 있는 데이터베이스 관리 방법 및 시스템에 관한 것이다.

데이터베이스 관리 시스템(Database Management System: DBMS, '이하 DBMS'라 함)은 방대한 양의 데이터가 저장되어 있는 데이터베이스를 관리하기 위한 시스템으로서, 대량의 정보들이 쉴새 없이 생성되고 있는 현 시대에 있어서 없어서는 안될 중요한 요소로 인식되고 있다.

이러한 DBMS에서는 모든 데이터를 테이블(Table) 형태로 데이터베이스에 저장하는데, 여기서 테이블이란 데이터베이스에서 데이터를 저장하는 기본구조를 말하며, 하나의 테이블은 하나 이상의 레코드(Record)들로 구성된다. 여기서, 레코드란 테이블의 한 행(Row)를 의미한다. 또한, 각 레코드는 하나 이상의 칼럼으로 구성되는데, 칼럼이란 테이블을 구성하는 실세계의 테이블 항목을 표현하는 이름을 가진 도메인(Domain)을 의미하는 것으로서, 어트리뷰트(Attribute) 또는 필 드(Field)라고도 한다.

이러한 DBMS는 외부로부터 특정 질의(Query)가 입력되는 경우, 입력된 질의에 따라 데이터베이스에 데이터를 선택, 삽입, 갱신, 삭제 등의 기능을 수행한다. 여기서 질의란 데이터베이스의 테이블에 저장되어 있는 데이터에 대한 어떠한 요구, 즉 데이터에 대한 어떠한 조작을 하기 원하는지를 기술한 것을 의미하는 것으로서, SQL(Structured Query Language)과 같은 언어를 이용하여 표현한다.

이러한, SQL문 중 가장 대표적인 질의는 선택(SELECT)문이다. 이러한 선택질의를 이용하여 테이블에 존재하는 데이터를 열람하거나, 데이터를 분석하여 데이터의 내용을 수정하거나, 여러 개의 테이블에 분산되어 저장되어 있는 데이터를 상호 참조하여 원하는 데이터를 열람할 수 있다.

예컨대, "SELECT content FROM board WHERE id=10"이라는 SQL 구문의 경우, "board"라는 테이블로부터 "id=10"을 만족하는 레코드를 선택할 것을 요구하는 요청을 의미한다.

상술한 DBMS가 게시판 서비스에 이용되는 경우, 사용자에 의해 특정 게시물이 선택되면 DBMS는 게시판 서비스 제공 서버로부터 해당 게시물의 요청을 위한 질의로 SELECT문과 해당 게시물의 조회수 증가 요청을 위한 UPDATA문을 전송 받게 되고, 이러한 질의에 따라 해당 게시물을 선택하고, 선택된 게시물의 조회수를 업데이트 한다.

즉, 종래에는 사용자에 의해 선택된 특정 게시물을 제공함에 있어서, 해당 게시물의 선택과정 및 조회수 증가 과정이 필수적으로 동반됨에도 불구하고, 이 두 과정이 별개의 질의문을 통해 수행되었으므로 시스템 운용의 효율성이 저하될 수 있다는 문제점이 있다.

또한, 종래의 DBMS의 경우, 특정 테이블에 포함된 레코드의 업데이트가 수행되고 있는 경우, 해당 레코드의 업데이트 수행을 위한 트랜잭션(Transaction)이 종료될 때까지 해당 레코드에 락(Lock)이 걸리게 되므로, 다른 선택질의 또는 업데이트 질의를 동시에 수행할 수 없게 되어, 데이터베이스 사용의 동시성이 떨어진다는 문제점이 있다.

또한, 종래의 DBMS의 경우, 특정 테이블에 포함된 레코드의 업데이트를 수행하는 경우, 업데이트가 수행될 때 마다 업데이트 결과를 테이블에 반영하였으므로, 업데이트 횟수가 많아지는 경우 시스템의 성능이 저하될 수 있다는 문제점이 있다.

본 발명은 상술한 문제점을 해결하기 위한 것으로서, 특정 데이터가 선택되는 경우 해당 데이터의 선택과정과 해당 데이터의 조회수 갱신 과정을 동시에 수행할 수 있는 데이터베이스 관리 방법 및 시스템을 제공하는 것을 기술적 과제로 한다.

또한, 본 발명은 특정 데이터의 갱신을 수행하는 경우, 해당 데이터의 락킹(Locking) 시간을 최소할 수 있는 데이터베이스 관리 방법 및 시스템을 제공하는 것을 다른 기술적 과제로 한다.

또한, 본 발명은 특정 데이터의 갱신이 수행되는 경우, 갱신결과들을 일정 주기로 반영할 수 있는 데이터베이스 관리 방법 및 시스템을 제공하는 것을 또 다른 기술적 과제로 한다.

상술한 목적을 달성하기 위한 본 발명의 일 측면에 따른 데이터베이스 관리 방법은 특정 테이블에 포함된 레코드의 인출요청 및 상기 레코드에 포함된 적어도 하나의 칼럼에 대한 갱신요청이 함께 정의된 질의문을 수신하여 분석하는 단계; 상기 분석된 질의문을 수행하기 위한 실행계획을 생성하는 단계; 및 상기 실행계획에 따라 상기 레코드의 인출 및 상기 적어도 하나의 칼럼에 대한 갱신을 수행함으로써 상기 실행계획을 실행하는 단계를 포함한다.

일 실시예에 있어서, 상기 질의문 분석단계는, 상기 수신된 질의문을 파싱하는 단계를 더 포함하고, 상기 실행계획 생성단계에서 상기 파싱된 질의문에 대해 실행계획을 생성하는 것을 특징으로 한다.

일 실시예에 있어서, 상기 레코드는 소정 게시판에 포함된 게시물이고, 상기 적어도 하나의 칼럼은 상기 게시물의 조회수가 기록된 칼럼을 포함하는 것을 특징으로 한다.

한편, 상기 실행계획 실행단계는, 상기 실행계획을 수행하기 위한 트랜잭션을 생성하는 단계; 상기 테이블로부터 상기 레코드를 인출하는 단계; 상기 인출된 레코드 중 갱신 요청된 상기 칼럼에 기록된 정보를 독출하는 단계; 독출된 상기 칼럼에 기록된 정보를 갱신하는 단계; 및 갱신완료를 통지함으로써 상기 트랜잭션을 종료하는 단계를 포함하는 것을 특징으로 한다. 또한, 상기 실행계획 실행단계는, 상기 칼럼에 기록된 정보 갱신단계 이전에, 서브 트랜잭션을 생성하는 단계를 더 포함하고, 상기 칼럼에 기록된 정보 갱신단계 이후에 상기 서브 트랜잭션을 종료하는 단계를 더 포함함으로써 상기 칼럼에 기록된 정보의 갱신이 상기 서브 트랜잭션 내에서 수행되는 것을 특징으로 한다. 이때, 상기 칼럼의 갱신을 위한 상기 서브 트랜잭션이 처리되는 시간 동안 상기 테이블 및 상기 레코드에 락(Lock)을 설정하는 것을 특징으로 한다.

또한, 상기 레코드 인출 단계에서, 상기 레코드는 순차 스캔 방법 또는 인덱스 스캔 방법 중 어느 하나를 이용하여 상기 레코드를 인출할 수 있으며, 상기 실행계획 실행단계에서, 상기 갱신 요청된 칼럼에 대한 인덱스가 존재하는 경우, 상기 칼럼에 기록된 정보의 갱신과 함께 상기 칼럼에 대한 인덱스를 갱신할 수 있다.

일 실시예에 있어서, 상기 실행계획 실행단계 이전에 상기 레코드의 식별자 및 칼럼의 식별자로 구성된 엔트리와 상기 엔트리에 포함된 칼럼 식별자에 상응하는 칼럼의 정보를 매칭시켜 메모리에 저장하는 단계를 더 포함하고, 상기 실행계획 실행단계는, 상기 칼럼에 대한 갱신 요청에 상응하여 상기 칼럼에 대한 갱신을 수행함에 있어서, 상기 갱신 요청된 칼럼에 대한 엔트리에 매칭되어 있는 칼럼 정보를 상기 메모리상에서 갱신하는 단계; 및 일정 조건이 만족되는 경우 상기 메모리상에 기록되어 있는 상기 칼럼 정보를 상기 테이블에 반영하는 단계를 포함할 수 있다.

이때, 상기 메모리상에 기록된 상기 칼럼 정보가 제1 기준치 이상인 경우 및 상기 메모리상에서 상기 칼럼 정보가 마지막으로 갱신된 시간으로부터 제2 기준치 이상의 시간이 경과한 경우 중 적어도 하나를 만족하는 경우 상기 칼럼 정보를 상기 테이블에 반영하는 것을 특징으로 한다.

상술한 목적을 달성하기 위한 본 발명의 다른 측면에 따른 데이터베이스 관리 시스템은 특정 테이블에 포함된 레코드의 인출요청 및 상기 레코드에 포함된 적어도 하나의 칼럼에 대한 갱신요청이 함께 정의된 질의문을 수신하여 분석하는 질의문 분석부; 상기 분석된 질의문을 수행하기 위한 실행계획을 생성하는 실행계획 생성부; 및 상기 실행계획에 따라 상기 레코드의 인출 및 상기 적어도 하나의 칼럼에 대한 갱신을 수행함으로써 상기 실행계획을 실행하는 실행계획 실행부를 포함하는 것을 특징으로 한다.

상술한 바와 같이 본 발명에 따르면, 특정 데이터가 선택되는 경우 해당 데이터의 선택과정과 해당 데이터의 조회수 갱신 과정을 동시에 수행함으로써 데이터의 처리 속도의 향상시킴으로써 사용자들의 편의성을 극대화할 수 있다는 효과가 있다.

또한, 본 발명에 따르면, 특정 데이터의 갱신을 수행하는 경우, 데이터의 갱신이 수행되는 서브 트랜잭션 내에서만 데이터에 대한 락이 설정되므로, 데이터에 대한 락킹(Locking) 시간을 감소시킬 수 있다는 효과가 있다.

또한, 본 발명에 따르면, 특정 데이터의 갱신이 수행되는 경우, 갱신결과가 발생할 때마다 데이터베이스에 반영하는 것이 아니라 일정 주기로 데이터베이스에 반영함으로써 데이터 입출력 횟수를 감소시킴으로써 시스템의 성능을 향상시킬 수 있다는 효과가 있다.

이하 첨부된 도면을 참조하여 본 발명의 실시예에 대해 상세히 설명한다.

도 1은 본 발명의 일 실시예에 따른 데이터베이스 관리 시스템의 개략적인 블록도이다.

데이터베이스(110)에는 다양한 데이터들이 테이블 형식으로 저장되며, 상술한 바와 같이, 각 테이블은 하나 이상의 레코드로 구성되고, 각 레코드는 하나 이상의 칼럼으로 구성된다. 예컨대, 소정 게시판에 대한 게시물들이 저장된 데이터베이스인 경우, 테이블은 게시물들의 집합을 의미하고, 레코드는 각 게시물을 의미하며, 칼럼이란 게시물 식별자, 게시물의 작성자, 게시물의 조회수 등이 저장되는 영역을 의미한다.

데이터베이스 관리 시스템(100)은 데이터베이스(110)에 연결되어 데이터베이스(110)에 기록된 데이터를 갱신 또는 삭제하거나 데이터베이스(110)에 데이터를 추가 하는 등 데이터베이스(110)를 통합적으로 관리하는 기능을 수행하는 것으로서, 크게 질의문 분석부(120), 실행계획 생성부(130), 실행계획 실행부(140)를 포함한다.

질의문 분석부(120)는 데이터베이스 관리 시스템(100)과 연동되는 다양한 외부서버(미도시) 또는 관리자 단말기(미도시)로부터 데이터베이스(110)에 저장되어 있는 데이터들의 처리를 위한 질의문을 수신하고, 수신된 질의문을 분석한다.

이러한 질의문 분석부(120) 도 1에 도시된 바와 같이, 질의문 수신부(122), 파서(124)를 포함하며, 유효성 검증부(136)를 더 포함할 수 있다.

질의문 수신부(122)는 전술한 외부서버 또는 관리자 단말기로부터 질의문을 수신한다. 이때, 질의문 수신부(122)를 통해 수신되는 질의문은 SQL(Structured Query Language)과 같은 언어를 이용하여 작성될 수 있다.

일 실시예에 있어서, 질의문 수신부(110)는 데이터베이스(110)에 저장되어 있는 특정 레코드의 인출요청 및 해당 레코드의 칼럼에 대한 갱신 요청이 함께 정의되어 있는 질의문을 수신할 수 있다.

여기서, 레코드의 인출요청 및 해당 레코드에 포함되어 있는 칼럼 중 어느 하나에 대한 갱신 요청이 함께 정의되어 있는 질의문이란, 레코드가 게시물인 경우 데이터베이스(110)로부터 게시물의 인출이 요청되면 해당 게시물에 대한 조회수의 갱신이 필수적으로 동반되는 것에 착안하여 게시물의 인출 및 게시물 조회수의 갱신과정을 한번에 수행하기 위해 작성된 질의문을 의미하는 것으로서, 이러한 질의문을 SQL문으로 작성하는 경우 다음과 같다.

1) SELECT content, INCR(counter) FROM board

2) SELECT content, INCR(counter)+1 FROM board

3) SELECT content, FROM board WITH INCREMENT FOR counter

상술한 질의문은 특정 레코드의 인출을 정의하는 SELECT문으로써, "content"는 인출할 레코드를 의미하고, "counter"는 칼럼들 중 조회수가 기록된 칼럼을 의미하며, "board"는 해당 레코드가 기록된 테이블을 의미하고, "INCR()"은 SELECT문에서 조회수와 같은 특정 칼럼값을 증가시키기 위한 함수를 의미한다.

이하에서는 설명의 편의를 위해 갱신 요청된 칼럼이 조회수가 기록된 칼럼인 것으로 가정하여 설명하지만, 이러한 칼럼이 조회수가 기록된 칼럼에 한정되지 않다는 것은 당업자에게 자명한 사실이다.

파서(124)는 질의문 수신부(122)를 통해 수신된 질의문을 파싱하는 것으로서, 일 실시예에 있어서, 파서(124)는 질의문을 파싱함으로써 파스트리(Parse Tree)를 생성할 수 있다. 파서(124)는 파스트리를 생성함에 있어서, 여러 형태로 표현되어 있는 질의문을 하나의 구문형태로 변형한 후 변형된 구문에 대해 파스트리를 생성할 수 있다.

예컨대, 질의문 수신부(122)를 통해 상술한 1)에 기재된 SQL질의문이 수신되는 경우, 수신된 형태대로 파싱이 가능하지만, 2) 내지 3)에 기재된 SQOL문들이 수신되는 경우 파서(124)는 각 SQL문들을 다음과 같은 형태로 변환할 수 있다.

2) SELECT content, INCR(counter)+1 FROM board

---> SELECT content, counter +1, <INCR(counter)> FROM board

3) SELECT content, FROM board WITH INCREMENT FOR counter

---> SELECT content, <INCR(counter)> FROM board

여기서, <INCR(counter)>는 counter라는 칼럼은 질의문에 대한 결과에는 포함되지 않는 숨겨진 칼럼(Hidden column)이라는 것을 의미한다.

유효성 검증부(126)는 파서(124)에 의해 생성된 파스트리에 대한 의미검사를 수행하는 것으로서, 파스트리 상의 테이블이나 칼럼 등이 실제 존재하는 지 여부, 칼럼의 데이터 타입(Data Type)이 연산자와 호환되는지 여부 등을 검증한다.

일 실시예에 있어서, 수신된 질의문에 "INCR()"함수가 포함되어 있는 경우, 유효성 검증부(126)는 해당 함수의 인자인 칼럼이 대상 테이블에 포함되어 있는지 여부, 인자가 경로표현식인 경우 표현식에서 왼쪽 항목이 오른쪽 항목을 도메인으로 가지는지 여부, 및 인자의 데이터 타입이 정수형인지 여부 중 적어도 하나를 검증할 수 있다.

한편, 유효성 검증부(126)는 파스트리의 검증 과정에서, 수신된 질의문에 포함된 "INCR(counter)"라는 함수에 해당 함수의 처리를 위한 인자를 추가함으로써 "INCR(counter)"라는 함수를 "INCR(board, ID(counter))"라는 함수로 변형한다. 여기서, "board"는 board라는 테이블에 포함된 특정 레코드에 대한 식별자를 의미하는 것으로서 특정 레코드의 물리적인 위치를 나타내고, "ID(counter)"는 counter라는 칼럼에 대한 식별자를 의미하는 것으로서, 이러한 정보들은 특정 레코드 및 특정 레코드에서 해당 칼럼의 위치를 검색하는데 이용된다. 데이터베이스 관리 시스템(100)은 파스트리의 유효성 검증 없이 모든 파스트리에 대해 실행계획을 생성할 수도 있으므로, 이러한 유효성 검증부(126)는 선택적으로 포함될 수 있다.

실행계획 생성부(130)는 유효성 검증부(126)에 의해 유효한 것으로 판단된 파스트리를 기반으로 요청된 레코드의 인출 및 레코드에 포함된 칼럼의 갱신을 위한 실행계획을 생성하여 후술할 메모리(160)에 저장한다. 여기서, 실행계획이란 특정 테이블로부터 레코드를 인출하는 방법, 결과 레코드 리스트, 갱신 요청된 칼럼에 대한 증가 연산 여부 등을 포함하는 자료구조를 의미한다.

일 실시예에 있어서 실행계획 생성부(130)는 요청된 레코드를 특정 테이블로 부터 인출하는 방법으로서, 순차 스캔 방법 및 인덱스 스캔 방법 중 어느 하나를 선택할 수 있다. 여기서, 순차 스캔 방법이란 특정 테이블에 포함된 레코드들을 순차적으로 스캔해 가면서 해당 레코드의 식별자를 가진 레코드를 인출하는 방법을 의미하고, 인덱스 스캔 방법이란 각 레코드의 식별자 별로 인덱스가 생성되어 있어, 이러한 인덱스만을 스캔함으로써 해당 레코드를 인출하는 방법을 의미한다.

실행계획 실행부(140)는 실행계획 생성부(130)에 의해 생성된 실행계획에 따라 특정 테이블로부터 해당 레코드를 인출하고, 갱신 요청된 칼럼의 물리적 위치에 상응하는 레코드 상의 칼럼에 기록된 칼럼값에 증가 연산을 수행함으로써 해당 칼럼값을 갱신한다.

구체적으로, 실행계획 실행부(140)는 실행계획 생성부(130)에 의해 생성된 실행계획을 실행하기 위한 트랜잭션을 생성함으로써 생성된 실행계획을 해당 트랜잭션 동안 처리한다. 여기서, 트랜잭션이란 하나의 논리적 작업 단위를 구성하는 것으로서, 하나 이상의 SQL문을 이용해서 정의된다. 이러한 트랜잭션의 사용으로 인해 데이터의 일치성과 데이터의 동시발생을 보장할 수 있게 된다.

실행계획 생성부(140)는 먼저 트랜잭션 내에서 특정 테이블로부터 해당 레코드를 인출하는 과정을 수행한다. 이때, 해당 레코드에 접근하기 위해 상술한 순차 스캔 방식 또는 인덱스 스캔 방식이 사용될 수 있다.

일 실시예에 있어서, 실행계획 생성부(140)는 레코드를 인출함에 있어서, 테이블의 스캔 시작과 함께 인출할 테이블에 대해서는 IS 락(Lock)을 설정하고, 해당 레코드에 대해서는 S 락(Lock)을 설정하며 이후, 테이블의 스캔 완료와 함께 설정 된 락들을 모두 해제한다.

한편, 실행계획 생성부(140)는, 갱신 요청된 칼럼의 물리적 위치에 상응하는 레코드 상의 칼럼에 기록된 칼럼값을 읽어 들여 증가시킨 후 갱신 레코드를 생성하고, 이를 원본 레코드에 오버래핑함으로써 해당 칼럼의 칼럼값을 갱신한다.

일 실시예에 있어서, 실행계획 생성부(140)는 해당 칼럼의 값을 갱신하기 위해 상술한 트랜잭션 내에서 별도의 트랜잭션인 서브 트랜잭션을 생성하고, 해당 칼럼값의 갱신이 서브 트랜잭션 내에서 수행되도록 할 수 있다. 이때, 실행계획 생성부(140)는 서브 트랜잭션의 생성과 함께 해당 레코드가 포함된 테이블에는 IX 락(Lock)를 설정하고, 해당 레코드에는 X 락(Lock)를 설정함으로써 해당 테이블 및 레코드에 대한 동시 접근을 차단하고, 서브 트랜잭션의 완료와 함께 설정된 모든 락들을 해제한다.

일반적으로 칼럼값을 갱신하고자 하는 경우, 칼럼값 갱신시점부터 해당 테이블 및 레코드에 락이 설정되고 갱신된 칼럼값을 데이터베이스에 반영하는 커밋(Commit)의 수행이 완료되어야만 설정된 락들이 해제되었으나, 본 발명의 경우, 칼럼값 갱신을 위해 트랜잭션 내에서 별도의 서브 트랜잭션을 생성하여 서브 트랜잭션 시작과 함께 해당 테이블 및 레코드에 락을 설정하고, 서브 트랜잭션의 종료와 함께 설정된 락이 모두 해제된다.

이러한 락킹 시간의 차이를 도식화하여 살펴보면 도 2와 같다. 도 2a에 도시된 바와 같이, 일반적인 방법에 따른 칼럼값 갱신 수행의 경우 칼럼값의 갱신 요청 이후부터 커밋이 완료되기까지의 구간(200)동안 데이터 접근의 차단을 위한 락 킹이 지속되지만, 본 발명의 경우 도 2b에 도시된 바와 같이, 칼럼값의 갱신 요청 이후부터 칼럼값 갱신 결과 통지까지의 구간(210), 즉 서브 트랜잭션의 처리 시간 동안만 데이터 접근의 차단을 위한 락킹이 지속됨을 알 수 있다.

따라서, 일반적인 방법에 따른 칼럼값 갱신의 경우, 칼럼값의 갱신 이후 커밋이 완료될 때까지 해당 테이블 및 레코드에 계속 락이 설정되어 있으므로 락킹(Locking) 시간이 길어져 데이터의 동시 처리성이 떨어지게 되나, 본 발명의 경우 칼럼값의 갱신이 완료되면 커밋이 완료되기 전이라도 설정된 락이 해제되므로 락킹 시간이 종래보다 종래 보다 짧아져 데이터의 동시 처리성이 향상된다.

한편, 실행계획 생성부(140)는 갱신 요청된 칼럼에 대한 인덱스가 존재하는 경우, 인덱스에 포함된 칼럼을 함께 갱신할 수 있다. 구체적으로, 실행계획 생성부(140)는 갱신 요청된 칼럼의 칼럼값이 갱신되고, 해당 칼럼에 대한 인덱스가 존재하는 경우 인덱스에서 해당 칼럼에 대한 이전 버전의 키(Key)를 삭제하고 새로운 버전의 키를 추가한다.

한편, 일 실시예에 있어서, 실행계획 생성부(140)는 칼럼값의 갱신에 관련된 정보를 로그형태로 저장할 수 있다. 이는 외부 서버 또는 관리자 단말기로부터 롤백(Rollback) 요청이 수신되는 경우, 갱신된 칼럼값을 갱신 이전의 칼럼값으로 되돌리기 위한 것으로서, 칼럼값이 갱신된 시간정보 및 갱신 이전의 칼럼값 등을 로그 형태로 저장한다.

실행계획 생성부(140)는 해당 레코드의 인출 및 해당 레코드에 포함된 칼럼의 갱신이 완료되면, 갱신된 결과를 데이터베이스(110)에 반영하기 위해 커 밋(Commit)을 수행함으로써 수신된 질의문 처리를 위한 트랜잭션을 종료한다.

상술한 실시예에 있어서는, 실행계획 생성부(140)가 해당 칼럼의 칼럼값 갱신이 완료되면 갱신 결과를 데이터베이스(110)에 직접 반영하는 것으로 기재하였지만, 변형된 실시예에 있어서는, 칼럼값 갱신이 완료되면 이를 메모리에 임시적으로 저장하였다가, 일정 조건이 만족되는 경우 그 결과를 한번에 데이터베이스(110)에 반영할 수 있을 것이다.

이는 게시물과 같은 레코드에 대한 조회가 집중되는 경우, 해당 게시물의 조회수와 같은 칼럼의 갱신 또한 빈번하게 되어 갱신결과를 매번 데이터베이스(110)에 반영하는 것은 시스템의 성능 저하를 유발할 수 있기 때문이다.

일 실시예에 있어서, 실행계획 생성부(140)는 후술할 메모리(160)에 저장된 칼럼값이 제1 기준치 이상이거나, 해당 칼럼값이 메모리(160)에 마지막으로 갱신된 시간으로부터 제2 기준치 이상의 시간이 경과했는지 여부를 판단하여 갱신된 칼럼값을 데이터베이스(110)에 반영할지를 결정할 수 있다.

이를 위해 데이터베이스 관리 시스템(100)은 레코드의 식별자 및 갱신 요청되는 칼럼의 식별자로 구성되는 엔트리를 생성 또는 삭제하고, 생성된 엔트리를 엔트리에 포함된 칼럼 식별자에 상응하는 칼럼값과 매칭시켜 메모리(160)에 저장하는 엔트리 관리부(150)를 더 포함하고, 메모리(160)에는 갱신 요청된 칼럼의 칼럼값이 엔트리 관리부(150)에 생성된 엔트리와 매칭되어 저장된다.

일 실시예에 있어서, 엔트리 관리부(150)는 해시 테이블을 생성하고, 레코드의 식별자와 갱신 요청된 칼럼의 식별자로 구성된 엔트리를 해시키로 하여, 각 해 시키마다 엔트리에 포함된 칼럼 식별자에 상응하는 칼럼값을 매칭시켜 저장할 수 있다.

실행계획 실행부(140)가 상술한 엔트리 관리부(150) 및 메모리(160)를 통해 갱신된 칼럼값을 메모리(160)에 저장하는 과정은 다음과 같다.

실행계획 실행부(140)는 특정 칼럼의 칼럼값에 대한 갱신 요청이 수신되면 메모리(160)에 갱신 요청된 칼럼의 식별자를 포함한 엔트리가 존재하는지 판단하여, 존재하지 않는 경우 엔트리 관리부(150)로 엔트리의 추가를 요청한다.

메모리(160)상에 해당 엔트리가 존재하거나, 엔트리 관리부(150)에 의해 엔트리가 추가되면, 실행계획 실행부(140)는 해당 엔트리에 매칭되어 있는 칼럼값에 대해 상술한 일정조건들이 만족되는지 여부를 판단하여 조건이 만족되는 경우, 해당 엔트리의 삭제를 요청하면서 해당 엔트리에 매칭되어 있는 칼럼값을 데이터베이스(110)에 반영한다.

일정조건이 만족되지 않는 경우 실행계획 실행부(140)는 엔트리에 매칭되어 있는 칼럼값을 메모리(160)상에 갱신함으로써 갱신요청을 처리한다.

한편, 엔트리 관리부(150)는 실행계획 실행부(140)에 의해 엔트리 추가가 요청된 경우, 메모리(160)상에 엔트리 추가가 가능한지 여부를 판단하여, 가능하지 않은 경우 메모리(160)상에 저장된 엔트리들 중 어느 하나를 삭제함으로써 새로운 엔트리를 추가할 수 있다.

이하, 도 3을 참조하여 본 발명의 일 실시예에 따른 데이터베이스 관리방법을 설명한다.

먼저, 외부서버 또는 관리자 단말기로부터 특정 테이블에 포함된 레코드의 인출요청 및 해당 레코드에 포함된 칼럼들 중 어느 하나에 대한 갱신 요청이 함께 정의되어 있는 질의문을 수신한다(제300단계). 일 실시예에 있어서, 이러한 질의문은 SQL(Structured Query Language)과 같은 언어를 이용하여 작성될 수 있다.

여기서, 레코드의 인출요청 및 해당 레코드에 포함되어 있는 칼럼들 중 어느 하나에 대한 갱신 요청이 함께 정의되어 있는 질의문이란, 상술한 바와 같이, 레코드가 게시물인 경우 데이터베이스로부터 게시물의 인출이 요청되면 해당 게시물에 대한 조회수의 갱신이 필수적으로 동반되는 것에 착안하여 게시물의 인출 및 게시물 조회수의 갱신과정을 한번에 수행하기 위해 작성된 질의문을 의미한다.

다음으로, 수신된 질의문을 파싱하여 파스트리(Parse Tree)를 생성한다(제310단계). 일 실시예에 있어서, 파스트리를 생성함에 있어서, 수신된 질의문이 여러 형태로 표현되어 있는 경우, 수신된 질의문을 하나의 구문형태로 변형한 후 변형된 구문에 대해 파스트리를 생성할 수 있다.

이후, 생성된 파스트리에 대한 의미검사를 수행함으로써 파스트리에 대한 유효성을 검증한다(제320단계). 파스트리에 대한 의미검사란 파스트리 상에 표현된 테이블이나 칼럼 등이 실제 존재하는 지 여부, 칼럼의 데이터 타입(Data Type)이 연산자와 호환되는지 여부 등을 검증하는 것을 말한다. 일 실시예에 있어서, 수신된 질의문에 "INCR()"함수가 포함되어 있는 경우, 해당 함수의 인자인 칼럼이 대상 테이블에 포함되어 있는지 여부, 인자가 경로표현식인 경우 표현식에서 왼쪽 항목이 오른쪽 항목을 도메인으로 가지는지 여부, 및 인자의 데이터 타입이 정수형인지 여부 중 적어도 하나를 검증할 수 있다.

한편, 파스트리의 유효성을 검증함에 있어서, 수신된 질의문에 포함된 "INCR(counter)"라는 함수의 처리를 위한 인자를 "INCR(counter)"함수에 추가함으로써 "INCR(counter)"라는 함수를 "INCR(board, ID(counter))"라는 함수로 변형한다. 여기서, "board"는 board라는 테이블에 포함된 특정 레코드에 대한 식별자를 의미하고, "ID(counter)"는 counter라는 칼럼에 대한 식별자를 의미한다. 상술한 바와 같이, 이러한 유효성 검증 과정은 선택적으로 포함될 수 있을 것이다.

다음으로, 파스트리의 유효성 검증결과 수신된 질의문에 대한 파스트리가 유효한 것으로 판단된 경우, 해당 파스트리를 기반으로 요청된 레코드의 인출 및 레코드에 포함된 칼럼의 갱신을 위한 실행계획을 생성한다(제330단계). 여기서, 실행계획이란 특정 테이블로부터 레코드를 인출하는 방법, 결과 레코드 리스트, 갱신 요청된 칼럼에 대한 증가 연산 여부 등을 포함하는 자료구조를 의미한다.

이후, 생성된 실행계획에 따라 특정 테이블로부터 해당 레코드를 인출하고, 해당 레코드의 칼럼들 중 갱신 요청된 칼럼의 칼럼값을 갱신함으로써 실행계획을 실행한다(제340단계).

실행계획을 실행하는 과정을 도 4를 참조하여 보다 상세하게 설명한다.

먼저, 실행계획이 생성되면, 생성된 실행계획에 따라 해당 질의문을 처리하기 위한 트랜잭션을 생성한다(제400단계). 즉, 해당 레코드의 인출 및 해당 레코드에 포함된 칼럼들 중 어느 하나의 칼럼에 대한 갱신을 생성된 트랜잭션 동안 처리하는 것이다. 트랜잭션에 대한 설명은 실행계획 생성부에 대한 설명에서 상세히 기재하였으므로 구체적인 설명은 생략하기로 한다.

이후, 생성된 트랜잭션 내에서 레코드 인출 요청을 처리하기 위해 테이블로부터 해당 레코드를 인출한다(제410단계). 일 실시예에 있어서, 테이블 상에서 해당 레코드에 접근하기 위해 상술한 순차 스캔 방식 또는 인덱스 스캔 방식이 사용될 수 있다.

이때, 테이블의 스캔 시작과 함께 인출할 테이블에 대해서 IS 락(Lock)을 설정하고, 해당 레코드에 대해서 S 락(Lock)을 설정하고, 테이블 스캔의 완료와 함께 설정된 락을 해제한다.

다음으로, 갱신 요청된 칼럼의 칼럼값을 갱신하기 위해 서브 트랜잭션을 생성한다(제420단계). 즉, 트랜잭션 내에서 별도의 트랜잭션인 서브 트랜잭션을 생성함으로써 칼럼값의 갱신은 서브 트랜잭션 내에서 수행되도록 하는 것이다. 이때, 데이터의 동시 접근을 차단하기 위해, 서브 트랜잭션의 생성과 함께 해당 레코드가 포함된 테이블에는 IX 락(Lock)를 설정하고, 해당 레코드에는 X 락(Lock)를 설정한다.

이후, 서브 트랜잭션 내에서 갱신 요청된 칼럼의 칼럼값을 갱신한다(제430단계). 구체적으로, 갱신 요청된 칼럼의 물리적 위치에 상응하는 레코드 상의 칼럼에 기록된 칼럼값을 읽어 들여 증가시킨 후 갱신 레코드를 생성하고, 이를 원본 레코드에 오버래핑함으로써 해당 칼럼의 칼럼값을 갱신한다.

한편, 갱신 요청된 칼럼의 칼럼값이 갱신되는 경우, 외부 서버 또는 관리자 단말기로부터 롤백(Rollback) 요청이 수신에 대비하여 칼럼값이 갱신된 시간정보 및 갱신 이전의 칼럼값 등을 로그 형태로 데이터베이스에 저장할 수 있다.

이후, 칼럼값이 갱신이 완료되면, 서브 트랜잭션을 종료시키면서 설정되어있던 모든 락을 해제하고(제440단계), 갱신된 결과를 데이터베이스(110)에 반영하기 위해 커밋(Commit)을 요청하고(제450단계), 요청된 커밋이 완료되면, 질의문 처리를 위한 트랜잭션을 종료한다(제460단계).

상술한 실시예에 있어서는, 갱신 요청된 칼럼의 갱신 결과를 데이터베이스에 직접 반영하는 것으로 기재하였지만, 시스템의 성능 저하를 방지하기 위해, 칼럼값 갱신이 완료되는 경우, 갱신 결과를 메모리에 임시적으로 저장한 후 일정 조건이 만족되는 경우 그 결과를 한번에 데이터베이스에 반영할 수 있을 것이다.

이하에서는 갱신 결과를 메모리에 임시적으로 저장한 후 일정조건이 만족되는 경우 갱신 결과를 데이터베이스에 반영하는 방법을 도 5를 참조하여 구체적으로 설명한다.

먼저 특정 테이블에 포함된 레코드의 식별자와 해당 레코드에 포함된 칼럼의 식별자를 하나의 쌍으로 하여 엔트리를 구성하고(제500단계), 엔트리와 해당 엔트리에 포함된 칼럼의 식별자에 해당하는 칼럼값을 해시 테이블을 이용하여 저장한다(제510단계).

이후, 특정 레코드에 포함된 칼럼들 중 어느 하나에 대한 갱신 요청이 수신되면(제520단계), 메모리상에 해당 칼럼의 식별자를 포함하는 엔트리가 존재하는지 여부를 판단한다(제530단계).

판단결과, 해당 엔트리가 존재하지 않는 경우 메모리상에 엔트리의 추가가 가능한지를 판단하여(제540단계), 추가가 가능한 경우 엔트리를 추가하고(제542단계), 추가가 가능하지 않은 경우 메모리상에 저장된 엔트리들 중 어느 하나를 삭제한 후(제544단계), 해당 엔트리를 추가한다(제542단계).

한편, 제530단계의 판단결과 해당 엔트리가 존재하거나, 제542단계의 결과 해당 엔트리가 추가된 경우, 해당 엔트리에 매칭되어 있는 칼럼값에 대해 소정 조건들이 만족되는지 여부를 판단한다(제550단계). 일 실시예에 있어서, 소정 조건이란 해당 엔트리에 매칭되어 있는 칼럼값이 제1 기준치 이상인지 여부 또는 해당 엔트리에 매칭된 칼럼값이 메모리상에서 마지막으로 갱신된 시간으로부터 제2 기준치 이상의 시간이 경과했는지 여부 중 어느 하나를 의미한다.

판단결과, 소정 조건이 만족되는 경우, 해당 엔트리를 삭제한 후(제560단계), 삭제된 엔트리에 매칭되어 있던 칼럼값을 갱신하여 데이터베이스에 직접 반영한다(제570단계).

한편, 소정조건이 만족되지 않는 경우 해당 엔트리에 매칭되어 있는 칼럼값을 메모리상에서 갱신함으로써 갱신요청을 처리한다(제580단계).

상술한 실시예에 있어서는, 소정 조건을 만족하는지 여부를 먼저 판단한 후 칼럼값 갱신을 수행하는 것으로 기재하였지만, 변형된 실시예에 있어서는, 먼저 칼럼값을 갱신한 후 갱신된 칼럼값이 소정 조건을 만족하는지 여부를 판단할 수도 있을 것이다.

또한, 상술한 실시예에 있어서는, 특정 레코드 및 칼럼에 대한 엔트리를 미리 생성하는 것으로 기재하였지만, 변형된 실시예에 있어서는 이러한 엔트리를 미 리 생성하는 것이 아니라, 특정 칼럼에 대한 갱신 요청이 수신되는 경우 해당 칼럼이 포함된 레코드 및 해당 칼럼에 대한 엔트리를 생성하여 해당 칼럼의 칼럼값과 매칭시켜 저장할 수도 있을 것이다.

상술한 데이터베이스 관리 방법은 다양한 컴퓨터 수단을 이용하여 수행될 수 있는 프로그램 형태로도 구현될 수 있는데, 이때 데이터베이스 관리 방법을 수행하기 위한 프로그램은 하드 디스크, CD-ROM, DVD, 롬(ROM), 램, 또는 플래시 메모리와 같은 컴퓨터로 판독할 수 있는 기록 매체에 저장된다.

본 발명이 속하는 기술분야의 당업자는 본 발명이 그 기술적 사상이나 필수적 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다.

그러므로, 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구범위에 의하여 나타내어지며, 특허청구범위의 의미 및 범위 그리고 그 등가 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

도 1은 본 발명의 일 실시예에 따른 데이터베이스 관리 시스템의 개략적인 블록도.

도 2는 일반적인 칼럼 갱신 요청 처리시의 락킹 시간과 본 발명의 일 실시예에 따른 칼럼 갱신 요청 처리시의 락킹 시간을 비교하여 보여주는 도면.

도 3은 본 발명의 일 실시예에 따른 데이터베이스 관리 방법을 보여주는 플로우차트.

도 4는 도 3에 도시된 실행계획 실행과정을 상세하게 보여주는 플로우차트.

도 5는 본 발명의 다른 실시예에 따른 데이터베이스 관리 방법을 보여주는 도면.

<도면의 주요 부분에 대한 부호의 설명>

100: 데이터베이스 관리 시스템 110: 데이터베이스

120: 질의문 분석부 130: 실행계획 생성부

140: 실행계획 실행부 150: 엔트리 관리부

160: 메모리

Claims (25)

1. 파서, 실행계획 생성부 및 실행계획 실행부를 포함하는 데이터베이스 관리 시스템에서 수행되는 데이터베이스 관리 방법에 있어서,

   상기 파서가 특정 테이블에 포함된 레코드의 인출요청 및 상기 레코드에 포함된 적어도 하나의 칼럼에 대한 갱신요청이 함께 정의된 질의문을 수신하여 파싱하는 단계;

   상기 실행계획 생성부가 상기 파싱된 질의문을 수행하기 위한 실행계획을 생성하는 단계; 및

   상기 실행계획 실행부가 상기 실행계획에 따라 상기 레코드의 인출 및 상기 적어도 하나의 칼럼에 대한 갱신을 수행함으로써 상기 실행계획을 실행하는 단계

   를 포함하고,

   상기 실행계획은,

   테이블로부터 레코드를 인출하는 방법, 결과 레코드 리스트, 갱신 요청된 칼럼에 대한 증가 연산 여부에 대한 정보 중 적어도 하나를 포함하는 자료구조인 것을 특징으로 하는 데이터베이스 관리 방법.
2. 삭제
3. 제1항에 있어서, 상기 레코드는 소정 게시판에 포함된 게시물이고, 상기 적어도 하나의 칼럼은 상기 게시물의 조회수가 기록된 칼럼을 포함하는 것을 특징으로 하는 데이터베이스 관리 방법.
4. 삭제
5. 삭제
6. 삭제
7. 삭제
8. 제1항에 있어서, 상기 실행계획 실행단계에서, 상기 실행계획 실행부가

   상기 갱신 요청된 칼럼에 대한 인덱스가 존재하는 경우, 상기 칼럼에 기록된 정보의 갱신과 함께 상기 칼럼에 대한 인덱스를 갱신하는 것을 특징으로 하는 데이터베이스 관리 방법.
9. 삭제
10. 삭제
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 제1항, 제3항 및 제8항 중 어느 하나의 항에 기재된 방법을 수행하기 위한 프로그램이 기록된 기록매체.
16. 특정 테이블에 포함된 레코드의 인출요청 및 상기 레코드에 포함된 적어도 하나의 칼럼에 대한 갱신요청이 함께 정의된 질의문을 수신하여 파싱하는 파서;

    상기 파싱된 질의문을 수행하기 위한 실행계획을 생성하는 실행계획 생성부; 및

    상기 실행계획에 따라 상기 레코드의 인출 및 상기 적어도 하나의 칼럼에 대한 갱신을 수행함으로써 상기 실행계획을 실행하는 실행계획 실행부를 포함하고,

    상기 실행계획은,

    테이블로부터 레코드를 인출하는 방법, 결과 레코드 리스트, 갱신 요청된 칼럼에 대한 증가 연산 여부에 대한 정보 중 적어도 하나를 포함하는 자료구조인 것을 특징으로 하는 데이터베이스 관리 시스템.
17. 삭제
18. 제16항에 있어서,

    상기 실행계획 실행부는 상기 실행계획을 수행하기 위한 트랜잭션을 생성하고, 상기 트랜잭션 내에서 상기 테이블로부터 상기 레코드를 인출하며, 상기 인출된 레코드 중 갱신 요청된 상기 칼럼에 기록된 정보를 독출하고, 독출된 상기 칼럼에 기록된 정보를 갱신하는 것을 특징으로 하는 데이터베이스 관리 시스템.
19. 제18항에 있어서,

    상기 실행계획 실행부는, 상기 트랜잭션 처리 중 상기 칼럼에 기록된 정보 갱신을 수행하기 위한 서브 트랜잭션을 생성하고, 상기 칼럼에 기록된 정보의 갱신은 상기 서브 트랜잭션 내에서 수행하는 것을 특징으로 하는 데이터베이스 관리 시스템.
20. 제19항에 있어서,

    상기 실행계획 실행부는 상기 서브 트랜잭션이 처리되는 시간 동안 상기 테이블 및 상기 레코드에 락(Lock)을 설정하는 것을 특징으로 하는 데이터베이스 관리 시스템.
21. 제16항에 있어서,

    상기 레코드의 식별자 및 상기 칼럼의 식별자로 구성된 엔트리와 상기 엔트리에 포함된 칼럼 식별자에 상응하는 칼럼의 정보를 매칭시켜 메모리에 저장하는 엔트리 관리부를 더 포함하고,

    상기 실행계획 실행부는, 상기 칼럼에 대한 갱신 요청에 상응하여 상기 칼럼을 갱신하는 경우, 상기 메모리 상에서 상기 갱신 요청된 칼럼에 대한 엔트리에 매칭되어 있는 칼럼 정보를 갱신하고, 일정 조건이 만족되는 경우 상기 메모리상에 기록되어 있는 상기 칼럼 정보를 상기 테이블에 반영하는 것을 특징으로 하는 데이터베이스 관리 시스템.
22. 제21항에 있어서,

    상기 실행계획 실행부는 상기 메모리상에 기록된 상기 칼럼 정보가 제1 기준치 이상인 경우 및 상기 메모리상에서 상기 칼럼 정보가 마지막으로 갱신된 시간으로부터 제2 기준치 이상의 시간이 경과한 경우 중 적어도 하나를 만족하는 경우 상기 칼럼 정보를 상기 테이블에 반영하는 것을 특징으로 하는 데이터베이스 관리 시 스템.
23. 제21항에 있어서,

    상기 엔트리 관리부는 해시 테이블을 이용하여 상기 엔트리 및 상기 칼럼 정보를 상기 메모리에 저장하는 것을 특징으로 하는 데이터베이스 관리 시스템.
24. 제21항에 있어서,

    상기 실행계획 실행부는 상기 갱신 요청된 칼럼에 대한 엔트리의 존재여부를 판단하여, 상기 갱신 요청된 칼럼에 대한 엔트리가 존재하지 않는 경우 상기 엔트리 관리부로 갱신 요청된 칼럼에 대한 엔트리 추가를 요청하고,

    상기 엔트리 관리부는 상기 엔트리 추가 요청에 상응하여 상기 갱신 요청된 칼럼에 대한 엔트리를 추가하는 것을 특징으로 하는 데이터베이스 관리 시스템.
25. 제24항에 있어서,

    상기 엔트리 관리부는 상기 실행계획 실행부로부터 상기 엔트리 추가 요청이 수신되면, 상기 메모리에 상기 엔트리의 추가 가능 여부를 판단하여, 추가 가능하지 않은 경우 상기 메모리에 저장되어 있는 엔트리들 중 어느 하나의 엔트리를 삭제한 후 상기 갱신 요청된 칼럼에 대한 엔트리를 추가하는 것을 특징으로 하는 데이터베이스 관리 시스템.

Images