꼽행착오

데이터베이스 키의 개념과 종류

데이터베이스에서 키 (Key) 는 조건에 만족하는 튜플을 찾거나, 순서대로 정렬할 때 다른 튜플들과 구별할 수 있는 기준이 되는 속성이다.

하나의 릴레이션에는 수많은 튜플들이 존재한다. 고객 정보를 저장한 릴레이션에는 많은 고객들에 대한 튜플들이 존재하며, 각 튜플들 간에는 중복되는 속성값이 발생할 수 있다. 

예를 들어 이름, 나이, 사는 곳 등의 정보가 중복될 수 있는데, 이 때 각각의 고객(튜플)을 구분하기 위한 기준이 되는 속성이 필요하다. 이것을 우리는 "키" 라고 부르며, 하나의 속성 또는 여러 속성들의 집합으로 표현할 수 있다.

키의 종류로는 슈퍼키, 후보키, 기본키, 대체키, 외래키 가 있다.

최소성, 유일성

각각의 키에 대해 공부하기 전에, 최소성과 유일성이라는 개념에 대해 정리하고 넘어가려 한다.

유일성

유일성이란, 하나의 키값으로 튜플을 유일하게 식별할 수 있는 성질을 말한다. 위에서 언급했듯 여러 개의 튜플이 존재할 때 각각의 튜플을 서로 구분할 수 있는 속성이 존재해야 한다. 한 마디로 말하자면, 각각의 튜플은 유일해야 한다는 뜻이다. 예를 들어 어떤 릴레이션에 (주민번호, 나이, 사는 곳, 혈액형) 이라는 속성이 존재한다고 하자. 이 때 나이, 사는 곳, 혈액형 은 모두 충분히 중복될 수 있는 속성들이다. 하지만 주민번호는 모두 다르기 때문에 주민번호 속성에서 중복은 절대 발생할 수 없다. 이 릴레이션에서 키는 주민번호로 지정될 것이며, 이렇게 각각의 튜플을 구분할 수 있는 성질을 유일성이라고 표현한다.

최소성

최소성이란, 키를 구성하는 속성들 중 가장 최소로 필요한 속성들로만 키를 구성하는 성질을 말한다. 쉽게 말해, 키를 구성하고 있는 속성들이 진짜 각 튜플을 구분하는 데 꼭 필요한 속성들로만 구성되어 있는지를 의미한다. 예를 들어 위와 같이 (주민번호, 나이, 사는 곳, 혈액형) 릴레이션에서 (주민번호, 나이) 가 키로 지정이 되어 있다면, 당연히 이 키는 각 튜플을 구분할 수 있다. 주민번호와 나이가 모두 같은 사람은 세상에 존재하지 않기 때문에 그렇게 말할 수 있지만, 더 간단하게 주민번호가 중복되는 사람은 세상에 존재하지 않는다. 그렇기 때문에 (주민번호, 나이) 로 지정된 키는 최소성을 만족하지 않고 키에서 나이를 뺀 주민번호 만 키로 지정이 될 경우, 이 키는 최소성을 만족한다고 할 수 있다.

1. 슈퍼키 (Super Key) ; 유일성 O, 최소성 X

슈퍼키는 유일성의 특성을 만족하는 속성 또는 속성들의 집합을 의미한다.

키 값이 같은 튜플은 존재할 수 없다. 예를 들어 (고객 아이디) 의 경우 아이디가 같은 고객은 없기 때문에 슈퍼키가 될 수 있다. 하지만 (직업, 나이, 등급) 의 경우 나이, 직업, 등급이 같은 고객은 충분히 있을 수 있기 때문에 슈퍼키로 사용할 수 없다. 하지만 (고객 아이디, 직업, 나이, 등급) 의 경우는 고객 아이디가 각 튜플을 구분할 수 있는 속성이기 때문에 슈퍼키가 될 수 있다. 이처럼 슈퍼키는 유일성은 만족하지만 최소성은 만족하지 않는 키를 의미한다.

2. 후보키 (Candidate Key) ; 유일성 O, 최소성 O

후보키는 슈퍼키 중 최소성을 만족하는, 즉 유일성과 최소성을 모두 만족하는 속성 또는 속성들의 집합이다. 위의 슈퍼키에서 들었던 예시에서 (고객 아이디, 직업, 나이, 등급) 은 각 튜플을 유일하게 식별할 수 있으므로 유일성은 만족한다. 하지만 여기서 직업, 나이, 등급 정보가 굳이 필요할까? 이 속성들은 튜플 간에 중복되는 속성값을 가지고 있고, 이 속성들이 포함되어 있지 않은 (고객 아이디) 만으로도 튜플의 식별에는 전혀 문제가 되지 않는다. 그러므로 위의 키에서 직업, 나이, 등급을 제외한 (고객 아이디) 는 최소성을 만족하며 후보키가 될 수 있다.

3. 기본키 (Primary Key) ; 후보키 중 선택받은 키

이렇게 각 튜플을 구별할 수 있으며 유일성과 최소성을 모두 만족하는 후보키가 구해졌다. 후보키는 한 테이블 내에서 여러 개 존재할 수 있는데, 여기서 우리는 여러 후보키 중 하나를 택해 사용해야 하며 여기서 선택된 키가 기본키가 된다. 하지만 모든 후보키가 기본키가 되는 것은 아니고 기본키를 선택함에 있어서 다음의 기준을 통과해야 한다.

1. NULL 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적절하다.
2. 값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적절하다.
3. 단순한 후보키를 기본키로 선택한다.

속성

• NULL 값을 가질 수 없다. (개체 무결성의 첫번째 조건)
• 기본키로 정의된 속성에는 동일한 값이 중복되어 저장될 수 없다. (개체 무결성의 두번째 조건)

4. 대체키 (Alternate Key) ; 후보키 중 선택받지 못한 키

대체키는 기본키로 선택받지 못한 후보키들이다. 이름에서 알 수 있듯 대체키는 기본키를 대신할 수 있는 자격은 있지만, 3-1 ~ 3-3 의 조건에 부합하지 않아 기본키로 선택받지 못한 키들을 의미한다. 대체키는 '보조키' 라는 이름으로도 불린다.

5. 외래키 (Foreign Key) ; 다른 릴레이션의 기본키를 참조

외래키는 관계를 맺고 있는 릴레이션 R1, R2 에서 릴레이션 R1 이 참조하고 있는 릴레이션 R2 의 기본키와 같은 R1 릴레이션의 속성이다. 다시 말해 다른 릴레이션의 기본키를 그대로 참조하는 속성 또는 속성들의 집합이 외래키이다. 외래키는 릴레이션 간의 관계를 올바르게 표현하기 위해 필요하다.

속성

• 외래키로 지정되면 참조 테이블의 기본키에 없는 값은 입력이 불가하다. (참조 무결성 조건)

예를 들어, 다음과 같은 고객, 주문 릴레이션이 각각 있다고 하자.

• 고객 (고객 아이디, 고객 이름, 나이, 등급, 직업, 적립금)
• 주문 (주문번호, 주문 고객, 제품, 수량, 단가, 주문 일자)

위의 릴레이션에서 고객 릴레이션은 사이트에 가입한 고객에 대한 데이터를 가지고, 주문 릴레이션은 어떤 제품을 어떤 고객이 주문했는지에 대한 데이터를 다룬다. 주문 릴레이션에는 어떤 고객이 어떤 제품을 '언제, 얼마나, 얼마에' 에 대한 정보가 있을 것이다. 그리고 각 튜플을 구분할 수 있는 기본키(주문번호)가 있을 것이다.

여기서 주문 릴레이션은 고객의 정보를 모두 저장할 필요가 없다. 단지 고객 릴레이션에서 튜플을 구분할 수 있는 기본키가 되는 속성만을 가지고 있으면 된다. 이렇게 고객 릴레이션의 기본키(고객 아이디)를 참조하는 주문 릴레이션의 속성을 외래키(주문 고객)라 한다. 외래키는 관계를 맺은 릴레이션의 기본키를 참조하고 있으며, 이 때 중요한 점은 기본키와 기본키를 참조하는 외래키의 도메인 또한 반드시 같아야 한다는 것이다.

#Reference.

정규화 (Normalization)

1. 정규화란?

정규화의 기본적인 목표는 테이블 간에 중복되는 데이터가 발생하지 않도록 하는 것이다. 중복된 데이터를 허용하지 않음으로써 데이터의 무결성을 유지할 수 있고, 이로 인해 데이터베이스 관리에 필요한 저장 공간을 축소시키는 효과가 있다.

데이터의 중복을 피하기 위해 데이터를 구조화하고, 그 과정에서 테이블을 더 작은 테이블로 분해하는데 이를 구조화하는 정규화 단계가 정의되어 있다.

제 1 정규화

제 1 정규화란, 테이블의 컬럼이 원자값 (Atomic Value) 를 갖도록 테이블을 분해하는 것이다. 예를 들어, 아래와 같이 고객의 취미를 저장한 테이블이 존재한다고 하자.

위 테이블에서 '추신수' 와 '박세리' 는 여러 개의 취미를 가지고 있어 제 1 정규형을 만족하지 못하고 있다. 이를 제 1 정규화를 통해 분해할 수 있는데, 제 1 정규화가 적용된 테이블은 다음과 같다.

제 2 정규화

제 2 정규화란, 제 1 정규화가 진행된 테이블에 대해 완전 함수 종속을 만족하도록 테이블을 분해하는 것이다. 여기서 완전 함수 종속이란 것은 기본키의 부분집합이 결정자가 되어선 안된다는 것을 말한다.

말이 조금 어려운데, 간단하게 얘기해서 어떤 테이블의 기본키가 두 개 이상의 컬럼으로 구성된 복합키일 때 기본키를 분해한 부분집합으로 인해 다른 컬럼의 값이 결정되어서는 안된다는 것이다. 예를 들어 다음의 테이블을 보면 조금 더 이해가 빠를 수 있다.

위 테이블에서 기본키는 {학생번호, 강좌이름} 의 복합키로 지정되어 있다. 그리고 {학생번호, 강좌이름} 의 기본키는 성적을 결정하고 있다. 그런데 여기서 강의실이라는 컬럼은 기본키의 부분집합인 {강좌이름} 에 의해 결정될 수 있다. 그렇기 때문에 위 테이블은 다음과 같이 기존의 테이블에서 강의실을 분해해 별도의 테이블을 관리해 제 2 정규형을 만족시킬 수 있다.

제 3 정규화

제 3 정규화란, 제 2 정규화를 진행한 테이블에 대해 이행적 종속이 없도록 테이블을 분해하는 것이다. 여기서 이행적 종속이란, A → B, B → C 가 성립할 때 A → C 가 성립하는 것을 의미한다.

예를 들어, 다음의 테이블을 살펴보자.

위 테이블에서 학생 번호는 강좌 이름을 결정하고 있고, 강좌 이름은 수강료를 결정한다. 결국, 학생 번호에 따라 수강료가 결정되므로 제 3 정규형을 만족하지 않는 테이블이다. 이를 제 3 정규형을 만족하도록 하기 위해서는, (학생 번호, 강좌 이름) 테이블과 (강좌이름, 수강료) 테이블로 분해할 필요가 있다.

이행적 종속을 제거하는 이유는 간단하다. 위의 테이블대로라면 학생번호가 501인 학생은 데이터베이스 강좌를 수강할 것이고 그 수강료로 20000 원을 지불하기로 되어 있다. 이 때, 이행적 종속이 테이블에 존재한다면 501 학생이 수강할 강좌를 스포츠경영학으로 변경할 경우, 스포츠경영학 강좌를 20000 원에 수강하게 된다. 물론 강좌가 변경됨에 따라 수강료 컬럼도 변경할 수 있지만, 한 컬럼의 데이터를 수정함으로 인해 다른 컬럼까지 같이 수정을 하게 되는 번거로움을 해결하기 위해 제 3 정규화를 진행하는 것이다.

즉, 학생 번호를 통해 강좌 이름을 참조하고, 강좌 이름으로 수강료를 참조하도록 테이블을 분해해야 하며 그 결과로 분해한 테이블은 다음과 같다.

BCNF 정규화

BCNF 정규화란, 제 3 정규화를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록 테이블을 분해하는 것이다. 여기서 결정자란, A → B 를 만족하는 A 를 의미한다. 예를 들어, 다음과 같이 특강 수강 정보에 대한 테이블이 있다고 하자.

위의 테이블에서 기본키는 {학생번호, 특강이름} 이다. 그리고 기본키 {학생번호, 특강이름} 은 교수를 결정하고 있다. 또한 여기서 교수는 특강 이름을 결정한다.

여기서 문제는, 교수가 특강이름을 결정하는 결정자이지만 후보키는 아니라는 점이다. 그렇기 때문에 BCNF 정규형을 만족시키기 위해서는 위의 테이블을 분해해야 하고 다음과 같이 특강 신청 테이블과 특강 교수 테이블로 분해하면 BCNF 정규형을 만족시킬 수 있다.

#Reference.

DB Index

1. 인덱스란?

인덱스란, 주기적인 쓰기 작업과 저장 공간을 활용해 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조이다. 책을 예로 들었을 때, 우리가 원하는 내용을 찾기 위해 책의 모든 내용을 뒤져보는 것은 오랜 시간이 걸리는 비효율적인 일이다. 그렇기 때문에 책의 맨 앞이나 맨 뒤에 색인이라는 항목을 추가하는데, 데이터베이스에서 인덱스란 책에서의 색인과 같다.

데이터베이스에서도 원하는 데이터를 찾기 위해 테이블의 모든 데이터를 탐색하면 시간이 오래 걸리기 때문에 데이터와 데이터의 위치를 포함한 자료구조를 생성해 빠르게 조회할 수 있도록 한다.

위의 그림과 같이, 유저가 쿼리를 날렸을 때 인덱스를 통해 찾고자 하는 데이터의 위치를 확인하고 그 데이터를 사용자에게 전달한다. 인덱스를 활용하면 데이터를 조회하는 SELECT 외에도 UPDATE 나 DELETE 의 성능에도 영향을 미친다. 그 이유는 해당 연산을 수행하기 위해 대상을 먼저 조회해야 하기 때문이다.

만약 인덱스를 사용하지 않은 컬럼을 조회해야 하는 상황에는 전체를 탐색하는 Full Scan 을 수행해야 한다. Full Scan 은 전체를 비교해 탐색하기 때문에 당연히 처리 속도가 떨어질 수밖에 없다.

2. 인덱스의 관리

DBMS 는 인덱스를 항상 최신 정렬된 상태로 유지해야 원하는 값을 빠르게 탐색할 수 있다. 그렇기 때문에 인덱스가 적용된 컬럼에 INSERT, UPDATE, DELETE 가 수행되면 각각 다음의 연산을 추가적으로 수행해야 하며 그에 따른 오버헤드가 발생한다.

• INSERT : 새로운 데이터에 대한 인덱스 추가
• UPDATE : 기존의 인덱스를 '사용하지 않음' 처리하고 갱신된 데이터에 대한 인덱스 추가
• DELETE : 삭제하는 데이터의 인덱스를 '사용하지 않음' 처리

3. 인덱스 사용의 장점과 단점

장점

• 테이블을 조회하는 속도를 향상시킬 수 있다.
• 전반적인 시스템의 부하를 줄일 수 있다.

단점

• 인덱스를 관리하기 위해 추가적인 저장공간이 필요하다.
• 데이터 관리 외에 인덱스 관리를 위한 추가적인 작업이 필요하다.
• 인덱스를 잘못 사용하는 경우 오히려 성능이 저하될 수 있다.

만약 CREATE, UPDATE, DELETE 가 빈번한 컬럼에 인덱스를 걸게 되면 인덱스의 크기가 비대해져 성능이 오히려 저하되는 역효과가 발생할 수 있다. 그러한 이유 중 하나는 UPDATE 와 DELETE 연산 때문인데, 앞서 언급한 대로 UPDATE 와 DELETE 는 기존의 인덱스를 삭제하는 것이 아니라 '사용하지 않음' 처리를 한다. 만약 어떤 테이블에 UPDATE 와 DELETE 가 빈번하게 발생한다면 실제 데이터는 10만 건인데 인덱스는 100만 건이 넘어가게 되는 등, SQL 문 처리 시 비대해진 인덱스로 인해 성능이 오히려 떨어지게 된다.

Index 의 효율적인 사용

1. 인덱스의 특징

인덱스는 WHERE 절에서 효과가 있다.

인덱스는 SELECT - FROM - WHERE 절 중 WHERE 절에 사용할 컬럼에 대한 효율화라 볼 수 있다. WHERE 절을 사용하지 않고 인덱스가 걸린 컬럼을 조회하는 것은 인덱스가 성능에 아무런 영향을 주지 못한다.

예를 들어, '학생' 테이블에 학번, 이름, 전화번호 가 있다고 가정해보자. 인덱스는 학번과 전화번호에 걸려 있다. 다음 중 인덱스가 영향을 주는 쿼리는 어떤 것이 있을까?

1. SELECT '학번' FROM '학생';
2. SELECT '전화번호' FROM '학생' WHERE '이름' = '김철수';
3. SELECT * FROM '학생' WHERE '학번' = 1;

정답은 당연히 3번이다. 1번은 WHERE 절을 사용하지 않아 인덱스가 영향을 주지 않고, 2번은 WHERE 절을 사용했지만 해당 절에서 사용한 컬럼이 인덱스가 적용되지 않은 컬럼이기 때문에 영향을 주지 않는다.

무조건 많이 설정하면 성능이 좋아질까?

인덱스는 테이블마다 하나 혹은 여러 개의 컬럼에 대해 설정할 수 있다. 단일 인덱스를 여러 개 생성할 수도 있고, 여러 컬럼을 묶어 복합 인덱스를 설정할 수도 있다.

그러나 무조건 인덱스를 많이 설정하는 것이 검색 속도를 향상시키는 데 도움을 주지 않는다. 인덱스는 데이터베이스의 저장 공간을 사용해 테이블 형태로 저장되므로 개수와 저장 공간은 비례한다.

따라서, 조회 시 자주 사용하고 고유한 값 위주로 인덱스를 설정하는 것이 성능에 도움이 된다.

DML (Data Manipulation Language) 각각에 어떤 영향을 미칠까?

SELECT 쿼리는 성능이 눈에 띄게 향상되지만 INSERT, UPDATE, DELETE 쿼리에서는 때에 따라 다르다.

• UPDATE, DELETE 는 WHERE 절에 잘 설정된 인덱스로 조건을 붙여주면 조회할 때 성능에 영향을 준다.
  (수정, 삭제할 데이터를 조회할 때의 속도가 빨라지는 것이지, 수정 자체의 속도가 빨라지는 것이 아니다.)
• INSERT 의 경우는, 새로운 데이터가 추가되면서 기존 인덱스 페이지에 저장되어 있던 탐색 위치가 수정되어야 하므로 효율이 좋지 않다.

즉, 인덱스는 원하는 데이터를 빠르게 찾을 때 빛을 발한다.

어떤 컬럼에 인덱스를 설정하는 게 좋을까?

테이블의 목적 등에 따라 인덱스의 개수는 달라질 수 있지만 일반적으로 한 테이블 당 3~5 개 정도의 인덱스가 적당하다. 인덱스는 컬럼을 정해 설정하는 것이므로 후보 컬럼의 특징을 잘 파악해야 한다. 아래 4가지 기준을 잘 고려하면 효율적으로 인덱스를 설정할 수 있다.

• 카디널리티 (Cardinality)
• 선택도 (Selectivity)
• 활용도
• 중복도

카디널리티 (Cardinality)

카디널리티가 높을수록 인덱스 설정에 좋은 컬럼이다.

(= 한 칼럼이 갖고 있는 값의 중복 정도가 낮을수록 좋다.)

카디널리티는 컬럼에 사용되는 값의 다양성 정도, 즉 중복 수치를 나타내는 지표이다. 후보 컬럼에 따라 상대적으로 중복 정도가 낮다, 혹은 높다로 표현한다.

예를 들어, 10개의 행을 갖는 '학생' 테이블에 학번과 이름 컬럼이 있다고 하자. 학번은 학생마다 고유하게 부여받는 값이므로 10개의 값 모두가 고유한 값이다. 이름은 동명이인이 있을 수 있으니 1 ~ 10 의 카디널리티 값을 갖는다. 즉, 상대적으로 학번이 이름에 비해 카디널리티 값이 높으므로 인덱스로 설정하기에 알맞다.

선택도 (Selectivity)

선택도가 낮을수록 인덱스 설정에 좋은 컬럼이다.

5 ~ 10% 가 일반적으로 적당하다.

선택도는 데이터에서 특정 값을 얼마나 잘 선택할 수 있는지에 대한 지표이다. 선택도는 다음과 같이 계산할 수 있다.

선택도 (Selectivity) 
    = 컬럼의 특정 값의 row 수 / 테이블의 총 row 수 * 100
    = 컬럼의 값들의 평균 row 수 / 테이블의 총 row 수 * 100

예를 들어, 10개 행을 갖는 '학생' 테이블에 학번, 이름, 성별 컬럼이 있다고 하자. 학번은 고유하고, 이름은 동명이인이 2명씩 존재하고, 성별은 남녀 의 비율이 5:5 이다.

• 학번의 선택도 = 1 / 10 * 100 = 10% (동일한 학번이 존재하지 않으므로 어떤 값의 row 수는 모두 1)
• 이름의 선택도 = 2 / 10 * 100 = 20% (두 명마다 같은 이름을 가지므로 값들의 평균 row 수는 2)
• 성별의 선택도 = 5 / 10 * 100 = 50% (10명 중 5명이 남자, 5명이 여자로 특정 값의 row 수가 모두 5)

즉, 선택도는 특정 필드값을 지정했을 때 선택되는 레코드 수를 테이블 전체의 레코드 수로 나눈 비율이다.

활용도

활용도가 높을수록 인덱스 설정에 좋은 컬럼이다.

활용도는 해당 컬럼이 실제 작업에서 얼마나 활용되는지에 대한 값이다. 수동 쿼리 조회, 로직과 서비스에서 쿼리를 날릴 때 WHERE 절에서 자주 활용되는지를 통해 판단할 수 있다.

중복도

중복도가 없을수록 인덱스 설정에 좋은 컬럼이다.

중복도는 중복되는 인덱스 여부가 있는지에 대한 값이다. 인덱스 성능에 대한 고려 없이 마구잡이로 설정하거나, 다른 부서 / 다른 작업자의 분리된 요청으로 같은 컬럼에 대해 인덱스가 중복으로 생성된 경우를 볼 수 있다.

인덱스도 테이블 형태로 생성되므로, 속성을 가지고 그 속성을 컬럼으로 관리한다. 이 속성이 다를 때 같은 컬럼이라 할지라도 중복으로 인덱스 설정이 가능하다. 같은 컬럼에 대해 중복 인덱스 설정이 되어있다 하더라도 SQL 자체 연산이 빠른 쪽으로 데이터를 조회하지만, 인덱스도 결국 메모리의 일부를 사용하기 때문에 필요없는 항목은 삭제하는 것이 좋을 것이다.

인덱스를 설정할 때 고려해야 할 특징들을 위와 같이 정리했지만, 실제로 인덱스를 효율적으로 적용하는 것은 어떤 데이터를 다루느냐, 그 데이터가 어떤 특징을 가지고 있느냐를 추가적으로 고려해야 하기 때문에 위의 수치만을 가지고 절대적으로 판단할 수 있는 것은 아닌 것 같다.

인덱스의 자료구조

인덱스를 구현하기 위해 여러 자료구조를 사용할 수 있다. 아래에서는 가장 대표적인 해시 테이블과 B+Tree 에 대해 설명하겠다.

1. 해시 테이블 (Hash Table)

해시 테이블은 (Key, Value) 형태로 데이터를 저장하는 자료구조 중 하나로 빠른 데이터 검색이 필요할 때 유용하다. 해시 테이블은 Key 값을 이용해 고유한 Index 값을 생성하고 그 Index 에 데이터를 저장하거나 Index 에 저장된 값을 꺼내오는 구조이다.

해시 테이블 기반의 DB Index 는 (데이터=컬럼의 값, 데이터의 위치) 를 (Key, Value) 로 사용해 컬럼의 값으로 생성된 해시를 통해 인덱스를 구현했다. 해시 테이블의 탐색 시간복잡도는 O(1) 이며 매우 빠른 검색을 지원한다.

하지만 DB 인덱스에서 해시 테이블이 사용되는 경우는 매우 제한적인데, 그러한 이유는 해시 연산이 등호 연산에만 특화되었기 때문이다. 해시 함수는 값이 1이라도 달라지면 완전히 다른 해시 값을 생성하는데, 이러한 특성으로 인해 부등호 연산이 자주 사용되는 데이터베이스 검색에 해시 테이블이 적합하지 않다.

예를 들어, "나는" 으로 시작하는 모든 데이터를 검색하기 위한 쿼리문은 인덱스의 혜택을 전혀 받을 수 없게 된다. 이러한 이유로 데이터베이스의 인덱스 저장을 위한 자료구조로는 B+Tree 가 많이 사용되고 있다.

2. B+Tree

B+Tree 는 DB 의 인덱스를 위해 자식 노드가 2개 이상인 B-Tree 를 개선한 자료구조이다. B+Tree 는 모든 노드에 데이터를 저장한 B-Tree 와는 다른 특성을 가지고 있다.

• 리프 노드 (데이터 노드) 만 인덱스와 함께 데이터 (Value) 를 저장하고, 나머지 노드 (인덱스 노드) 들은 데이터를 위한 인덱스 (Key) 만을 갖는다.
• 리프 노드들은 Linked List 로 연결되어 있다.
• 데이터 노드의 크기는 인덱스 노드의 크기와 같지 않아도 된다.

데이터베이스의 인덱스 컬럼은 부등호를 이용한 순차 검색 연산이 자주 발생될 수 있다. 이러한 이유로 B-Tree 의 리프 노드들을 Linked List 로 연결해 순차검색을 용이하게 하는 등 B-Tree 를 인덱스에 맞게 최적화했다. (물론 Best Case 에 대해, 리프 노드까지 가지 않고 데이터를 탐색할 수 있는 B-Tree 에 비해 무조건 리프 노드까지 탐색해야 데이터를 찾을 수 있다는 단점도 존재한다.)

이러한 이유로, 비록 B+Tree 는 O(logn) 의 시간복잡도를 갖지만 해시테이블보다 인덱싱에 적합한 자료구조로 사용되고 있다.

아래 그림은 InnoDB 에서 사용된 B+Tree 의 구조이다.

InnoDB 의 B+Tree 는 일반적인 구조보다 더욱 복잡하게 구현이 되어있다. InnoDB 에서는 같은 레벨의 노드끼리는 Linked List 가 아닌 Double Linked List 로 연결이 되어있고, 부모 노드와 자식 노드들은 Singly Linked List 로 연결되어있다.

#Reference.

Features Added in MySQL 8.0

• Data Dictionary
  https://dev.mysql.com/doc/refman/8.0/en/data-dictionary.html

• Atomic DDL
  https://dev.mysql.com/doc/refman/8.0/en/atomic-ddl.html

• 보안 및 계정 관리
• 자원 관리
• 테이블 암호화 관리
• InnoDB
• JSON
• Data Type Support
• Optimizer

Reference.

[MySQL 8.0 Ref] https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-additions

관계형 데이터베이스 (RDB ; Relational DataBase)

글을 적기에 앞서 우선, RDB 가 무엇인지부터 얘기해 보려고 한다. RDB 란 Relational DataBase 즉, 관계형 데이터 모델에 기초를 둔 데이터베이스이다. 여기서 관계형 데이터 모델이란, 자료를 2차원 구조의 테이블 형태로 표현하는 것을 말한다.

간단한 예로, 학생들의 정보를 저장한다고 할 때 다음과 같이 표현을 할 수 있다.

이러한 관계형 데이터 모델에서 사용되는 용어는 다음과 같다.

- 릴레이션 (Relation) : 데이터들을 2차원 테이블의 구조로 저장한 것.

- 속성 (Attribute) : 릴레이션의 열(=Column), 개체를 구성하는 속성들.

- 튜플 (Tuple) : 릴레이션의 행(=Row), 속성들의 집합이며 레코드(Record) 라고도 부름.

- 차수 (Degree) : 릴레이션을 구성하는 속성 수(열의 개수)

- 카디널리티 (Cardinality) : 릴레이션에 입력된 튜플의 수

RDBMS 는 이런 RDB 를 관리하기 위한 소프트웨어라 정의할 수 있다. SQL 이라는 구조화된 질의어를 사용해 RDB 를 생성하고, 관리할 수 있는데 대표적으로 MySQL, Oracle DB, Maria DB 등이 있다.

MySQL

우선, MySQL 은 세계적으로 널리 사용되는 오픈 소스 DBMS 이다. 오픈 소스이기 때문에 무료로 사용이 가능하고, 다양한 운영체제에서 여러 가지의 프로그래밍 언어와 사용할 수 있다. 널리 알려진 표준 SQL 형식을 사용하며 크기가 큰 데이터의 집합도 빠르고 효과적으로 처리가 가능하다.

MySQL 은 CLI 를 통해 사용할 수도 있고, MySQL 에서 공식적으로 개발/지원하는 MySQL Workbench 를 사용해 GUI 를 활용할 수도 있다.

Oracle DB

Oracle DB 는 오라클 사의 관계형 데이터베이스 관리 시스템의 이름이다. 현재 유닉스 환경에서 가장 널리 사용되는 RDBMS 라고 한다. 검색이나 업데이트를 위한 언어로 SQL 과 PL/SQL 을 지원한다.

* PL/SQL 은 오라클 DB 에서 SQL 언어를 확장하기 위해 사용하는 컴퓨터 프로그래밍 언어 중 하나이다. 주로 자료 내부에서 SQL 명령문만으로 처리하기에 복잡한 자료의 저장이나 프로지서 / 트리거 등을 작성하는 데 쓰인다고 한다. 

MySQL vs. Oracle DB

MySQL 과 Oracle DB 중 무엇을 사용할 것인가?

오라클은 일반적으로 충분히 큰 예산과 복잡한 비즈니스적 요구, 기업 고객을 위해 설계되었다. 반면, MySQL 은 가장 일반적으로 데이터베이스 기반 웹 사이트나 Non-Critical 애플리케이션을 위해 사용되는 저가의 데이터베이스이다.

Oracle DB 의 특징

오라클 DB 의 특징은 아래와 같이 크게 5가지로 표현할 수 있다.

• Oracle Management Server
  • 오라클 DB 는 중앙 집중 방식으로 Administration Monitoring 이 가능하고, Multiple Database 를 튜닝할 수 있다.
  • 다른 Admin User 들과 공유가 가능하다.
• Oracle Change Manager
  • 변경 Plan 을 작성하고 실제로 구현하기 전에, 변경 사항의 효과를 볼 수 있다.
  • 생산 시스템을 방해하지 않는다.
• Administrative Alerts
  • 오류 발생 시 오라클은 이메일이나 설정되어 있는 계정으로 연락을 줄 수 있다.
  • 경고는 예정된 정지 시간동안 차단될 수 있다.
• Capacity Planning
  • 업그레이드 관리자의 계획을 돕기 위해 사용 패턴의 추적이 가능하다.
  • 병목 현상을 쉽게 파악할 수 있다.
• Query Optimizer
  • 쿼리 최적화 프로그램으로 오라클은 SQL 문을 실행하는 가장 효율적인 방법을 선택한다.
  • Cost 비용의 최소화를 위해 테이블 / 인덱스를 분석한다.

MySQL 의 특징

MySQL 의 특징은 다음과 같다.

• 사용이 타 RDBMS 에 비해 쉽다.
• 무료로 사용 가능한 GUI Tool 이 많다.
• Device 에 적은 Overhead 가 가해진다.
• 버전이 업그레이드됨에 따라 고급 기능을 지원하기 시작했다.

MySQL 과 Oracle DB 는 목적에 맞게 적절한 사용이 필요할 것으로 보인다. 작은 프로젝트나 데이터를 많이 저장하지 않는 시스템의 경우는 MySQL 을 사용하는 편이 좋을 수 있고, 데이터의 사용량이 매우 많고 고도화된 시스템의 경우에는 Oracle DB 를 사용하는 편이 좋을 것으로 생각된다.