데이터베이스

DB로도 리다이렉트되는데 독일철도(Deutsche Bahn)를 찾아오신 분들은 여기로
소리크기의 단위인 데시벨 [math]dB[/math] 을 찾아오신 분들은 여기로

DataBase 혹은 DB, db

1 개요

인터넷과 더불어 정보화사회를 가능하게 하는 양대 축 중 하나
당신이 접속한 문서들의 집합

여러 사람에 의해 공유되어 사용될 목적으로 통합하여 관리되는 데이터의 집합을 말하는 개념이다. 줄여서 DB라고도 하며, 특정 다수의 이용자들에게 필요한 정보를 제공한다든지 조직 내에서 필요로 하는 정보를 체계적으로 축적하여 그 조직 내의 이용자에게 필요한 정보를 제공하는 정보 서비스 기관의 심장부에 해당된다.

일반적으로 응용 프로그램과는 별개의 미들웨어를 통해서 관리된다. 데이터베이스 자체만으로는 거의 아무 것도 못하기 때문에 그걸 관리하는 시스템과 통합돼 제공되며 따라서 정확한 명칭은 데이터베이스 관리 시스템(DBMS)이 된다. 데이터베이스만 제공되는 건 CSV같이 아주 단순한 데이터에 국한되는데 이걸 직접 사용하는 경우는 많지 않고 이런 데이터를 RAW데이터로 간주해 다른 DBMS시스템에 적재하고 사용하는 게 일반적이다.

관계형 데이터 베이스(RDBMS)가 가장 널리 쓰이고 있다. 그리고 이 관계형 데이터베이스를 이용하기 위한 표준 언어가 만들어져 있는데 그것이 SQL이다. 구조화 질의 언어(Structured Query Language)의 약자. 예전에는 데이터베이스가 관계형 데이터베이스의 대명사처럼 여겨졌으나 요즘에는 다른 형태의 데이터베이스도 많이 나와있다. 가히 데이터베이스 춘추전국시대. 이런 비-관계형 데이터베이스는 NoSQL이라 불린다. SQL을 사용하지 않는 데이터베이스라는 다소 장난스런 표현. 물론 정식 명칭은 각자 가지고 있다. 객체형, 문서형, 컬럼형 등등.

관계형 데이터 베이스를 이용하기 위해 만들어진 SQL 문은 배워 두면 여러모로 쓸 데가 많다. 컴퓨터로 하는 일에서 대부분을 차지하는 작업은 바로 정렬과 탐색인데 이 두 작업을 가장 전문적으로 처리하는 건 데이터베이스이다. 컴퓨터로 계산을 하는 경우는 의외로 정렬과 탐색에 비하면 비중이 낮은 편이다.

간혹 무겁게 DB까지 돌리지 말고 파일로 하나하나 저장해놓으면 DB보다 훨씬 간편하지 않냐는 사람도 있다. 하지만 파일의 경우 간단한 작업을 할 때는 DB에 비해서 간단하고 오버헤드도 적은 편이나, 게시판을 만드는 등의 작업을 할 경우 DB에 비해서 훨씬 밀린다. 인덱싱, 멀티 스레드 작업으로 인해 파일에 비해 더 빠르고, 파일에서 몇 줄으로 처리해야 할 일들을 DB에선 단 한 줄만으로도 처리할 수가 있어서 본격적인 작업을 하려면 DB를 사용하는 것을 권한다.

2 데이터베이스의 특징

  • 자기기술성 : 파일 시스템과 구별되는 특징. DBMS가 데이터의 삽입 및 삭제를 데이터/구조적 종속 없이 가능케 해준다.
  • 프로그램과 데이터의 격리 : 단일한 응용 프로그램 내에서 데이터를 개별적으로 관리하는 방식은 데이터 저장 구조 등이 변경되면 응용 프로그램도 수정되어야 한다. 하지만 데이터베이스는 자기기술성을 가지므로 저장 구조 등을 수정하는 것이 응용 프로그램에 영향을 미치지 않는다.
  • 추상화 : 복잡한 데이터베이스의 구조에 대한 정보를 감추고, 각 사용자에게 뷰를 제공한다.
  • 특정 적용 업무나 응용 시스템이 아닌 동시에 복수의 적용 업무나 응용 시스템에 대한 데이터의 공급 기지로서 공유할 필요가 있는 데이터를 보관·관리한다. 즉, 다수의 사용자에게 동시 접근을 허용한다. 동시성제어 항목 참고.
  • 데이터의 특성, 실체 상호 간의 의미 관계와 형식 관계를 기술한 개념적인 구조에 따라서 편성된 데이터의 집합이다.
  • 동일한 내용의 데이터가 중복되어 있지 않아야 하고, 다양한 접근 방식이 마련되어 있어야 하며, 검색이나 갱신이 효율적으로 이루어질 수 있도록 해야 한다.
  • RAM,ROM같은 주기억장치가 아닌 컴퓨터에서 사용할 수 있는 보조기억장치에 저장된다.[1]

3 종류

3.1 관계형(Relational)

데이터베이스계의 주류. 아직도 주류의 자리에서 내려오지 않고 있다. 데이터를 컬럼(Column)과 로우(Row)라는 일종의 표 형태로 저장한다. 데이터의 종속성은 관계(Relation)으로 표현한다.

한 테이블에 있는 모든 로우는 같은 길이의 컬럼을 가지고 있으며 이 컬럼의 구조와 데이터의 관계가 테이블 스키마(Schema)로 사전 정의된다.

역사가 오래된 만큼 가장 신뢰성이 높고 데이터의 분류, 정렬, 탐색 속도가 빠르다. SQL은 고도로 정교한 검색 쿼리를 제공하며 상상하는 거의 모든 방식으로 데이터를 다룰 수 있게 해 준다. 또한 트랜젝션(Transaction) 지원이 매우 강력하여 신경만 제대로 써주면 데이터가 안 들어가는 경우는 있어도 잘못 들어가는 경우는 없다. 예를 들어 금융거래시 구매자 통장에서 돈이 빠져나가고 뒤이어 판매자 통장에 돈이 들어와야 거래가 정상적으로 끝나게 되는데 만약 판매자 통장을 관리하던 컴퓨터가 맛이 갔다고 한다면 RDBMS는 트랜젝션 롤백을 통해 구매자 통장의 잔금을 원상복구 시키면서 거래를 취소한다. 여기선 간단하게 설명했지만 현실에서는 네트워크 이상, 데이터 비트 오염, 하드디스크 이상, 동시성 문제 등 데이터 무결성을 보장하기 위해 넘어야 할 산이 많다. 근데 이 모든 상황을 다 고려해서 그 어떤 상황에서도 데이터 무결성을 '보장'하는 게 RDBMS의 특징이다. 다른 타입의 DBMS는 이정도의 데이터 무결성을 보장하지 못한다! 한마디로 없는 돈이 허공에서 솟아날 수도 있고 있던 돈이 증발할 수도 있다.

그러나 스키마를 수정하기가 어렵고, 데이터가 2차원 표형태로만 출력되기 때문에 트리 구조로 조직화되는 '객체'들과 궁합이 잘 안맞는 게 문제다. 이 문제는 ORM(Object-Relation Mapping)기법으로 땜빵하고는 있으나 밑에 설명하는 객체형, 문서형 DB가 더 객체 친화적이므로 신규 프로젝트를 시작하는 경우라면 ORM과 객체형 DB사이에서 잘 저울질해보자.

다만 DBMS가 부하분산이 잘 안된다. 읽기 작업은 분산이 되지만 쓰기 작업을 분산하려면 고도의 기술력에 더해 전략까지 필요하다.

3.2 키-값형(KV store)

모든 데이터를 키(Key)와 값(Value)의 쌍으로 매핑한다. Key를 어떻게 인덱싱했느냐에 따라 다르지만 보통 특정 값 하나를 찾아내는 데에는 가장 뛰어난 성능을 보인다. 하지만 데이터를 그룹화하고 정렬하는 기능은 없다시피하다. 대신 RDBMS에 비해 가볍고, 빠르고, 다루기 쉽다.

언뜻 보면 1차원 데이터만 다룰 수 있을 것 같이 생겼지만 Value에 넣을 수 있는 값이 자기 자신의 Key를 포함하여 Any object이기 때문에(크기 제한은 있을 수 있다) 대부분의 데이터를 다룰 수 있다. 물론 다른 DBMS는 이런 데이터 조직화를 도와주는 각종 도구를 제공하므로 2차원 이상 데이터는 KV store 말고 다른 걸 찾아보는 게 좋다.

웹 캐시나 세션 데이터, 쇼핑몰의 장바구니 데이터 등을 담는 데에 최적인 DB여서 이쪽으로 활용을 많이 한다. 그 외에 KV store는 데이터베이스의 크기가 상대적으로 작아 메모리에 통째로 올려놓고 구동하는 것도 쉽기 때문에 인-메모리 데이터베이스로 많이 사용된다. 인-메모리 데이터베이스는 그 특성상 매우 고속으로 동작하는 대신 데이터의 안정성을 전혀 보장하지 않는데 장바구니 같은 건 날아가도 상관없는 데이터이면서 반응이 즉시 와야 하는 성격이라 주로 선택된다. KV store로 세션을 처리하는 웹 서버도 하드디스크에 부담을 상당히 덜어주면서 반응이 아주 빠르다. 그러니까 일종의 '임시 데이터' 저장소로서의 입지를 굳게 다지고 있다.

3.3 객체형(Object)

프로그래밍 언어에서 객체지향의 개념이 포함되었듯이, 관계형 데이터베이스 이후, 데이터베이스에서도 객체지향을 구현한 것이 바로 객체형 데이터베이스이다. 이러한 DBMS를 ODBMS라고 한다.

다만, 데이터베이스 분야에서는 ODBMS가 주류가 되지는 못했는데, 이유는 쿼리 사용이 복잡해지기 때문이다. 다른 형태의 DBMS가 도태된 이유와 같은 것. 때문에 아직까지도 RDBMS 방식이 널리 사용되고 있다.

3.4 문서형(Document)

MongoDB의 방식. 위의 객체형과 비슷하다. 문서의 구조를 나타내는 스키마가 필수가 아닌 것이 특징이다.
스키마가 없기 때문에 인덱스 필드를 제외하고(인덱스를 해제하는 건 가능하다) 필드를 마음대로 넣거나 뺄 수 있다. 기존 데이터에 해당 필드가 있든 없든 상관없고 그런 데이터를 상대로도 조회, 그룹핑 등의 작업이 가능하다.

객체 지향 프로그래밍이 주류인 현재, 데이터를 따로 매핑할 필요 없이 그냥 집어넣으면 알아서 잘 저장되는 객체형, 문서형 데이터베이스가 주목받고 있다.

그러나 저장한 상태 그대로의 문서를 뽑아내는 게 아니라 뭔가 데이터를 가공하려고 하면 잘 되지 않는다. 예를 들어 Group by나 Join 쿼리 등. 또한 데이터를 지속적으로 '쌓아 올리는' 응용(예를 들어 금융거래 기록 저장)에서는 성능이 상당히 떨어진다. 이런 건 RDBMS가 가장 잘 하는 분야.

데이터의 스키마가 자주 바뀌고 데이터가 다계층의 객체 형태이면서 대부분의 업무가 갱신, 삽입(문서단위), 조회에 집중돼있고 통계 연산에 쓰일 일이 많지 않은 곳에서 사용하기 좋다. 통계 연산이 가끔 필요한 곳에서는 필요한 데이터를 추출해 RDBMS에 옮기고 SQL로 처리한다. 아니면 DBMS에서 자체 제공하는 map/reduce 연산을 쓰던지.

한마디로 바인더 서류철과 비슷한 성격을 가졌다. 바인더철에 추가로 종이를 꽂거나(삽입), 꽂힌 종이를 다른 걸로 갈아넣거나(갱신), 종이를 찾거나(조회) 하는 일에는 뛰어나지만 한 종이 안에 적힌 데이터가 계속 늘어나거나(추가), 여러 종이에 걸쳐 있는 어떤 값을 다 더하거나(통계) 하는 일에는 취약하다. RDBMS는 여기서 '종이'에 해당하는 놈이 무한한 두루마리와 같아서 데이터의 추가 작업이나 특정 필드를 대상으로 한 통계 및 그룹화 작업이 쉽다. 대신 RDBMS는 2차원을 넘어가는 데이터(트리 구조 데이터 등)를 저장할 때 두루마리를 여러 개 준비해야 하는 게 단점이다. 중간에 형식이 다른 데이터를 끼워넣는 건 불가능하고. 문서형 DB는 종이 하나에 모든 관련 데이터를 다 담아두므로 다른 종이에 무슨 데이터가 어떻게 저장되든 상관하지 않는다. 조회를 위한 인덱스만 하나 이상 있으면 OK.

3.5 컬럼형(Column)

Map/reduce에 특화된 DB. Hadoop이 컬럼형 DB이다.
디스크에조차 다 담지 못할 정도의 거대한 데이터를 다루는 게 특기이다. 다만 데이터 검색용으로 사용하기보다는 데이터의 통계 처리용으로 주로 사용된다.

NoSQL의 범람을 알리는 신호탄 같은 역할을 했기에 초반에 반짝 유행을 탔으나 이놈은 사용하기가 더럽게 어렵다. 일단 설계 사상 자체가 초대형 빅 데이터를 다루는 데 치중해있어서 최소 12대 이상의 컴퓨터로 클러스터 머신을 구성해야 하고[2](한 대로 돌릴 수 있긴 한데 그럴거면 RDBMS가 훨씬 고성능이다) 그걸 관리하기 위해서는 데이터베이스 뿐만 아니라 네트워크와 하드웨어에 대한 심도깊은 이해가 필요해서 지금은 인기가 많이 식었다. 디스크 하나에 다 못담을만큼 대용량 데이터면 적어도 테라바이트급 데이터라는건데 그만한 데이터를 처리할 만큼 거대한 조직은 은행이나 대형 쇼핑몰(아마존등), 검색엔진 회사(구글등) 정도를 제외하면 거의 없다. 저 Hadoop이라는 놈도 태생은 구글의 빅테이블이다.

어지간한 대기업 레벨이 아니고서야 컬럼형 데이터베이스를 고려해야 할 정도로 대량의 데이터가 매일같이 쏟아지진 않을 것이다. 게다가 저게 시스템 구축하기가 너무 힘들기 때문에 정 쓰고 싶다면 학습 목적이 아닌 한에야 클라우드 컴퓨팅 서비스로 제공하고 있는 걸 가져다 쓰는 게 좋다.

4 DB 에러

각종 정보를 저장하는 데이터베이스(DataBase)의 약자가 DB 이기 때문에, 많은 곳에서 두부라는 애칭으로 불린다.
게임의 경우 게임의 실행파일을 제외한 그 나머지들, 책방이라면 책의 목록을 정리해 둔 PC, 웹사이트라면 회원정보나 게시물의 내용을 모두 저장해둔 서버 등, 뭔가를 운영하고 실행하기 위해 필수불가결한 존재이다. 그러나...

파일:Attachment/두부/동음이의어/c0027899 479ac2ab233a1.jpg
누르고 싶다

이와 같이 웹 사이트를 이용하는 도중 갑자기 접속이 안되면서, 이 메세지와 함께(예시 화면은 제로보드 DB 접속 에러화면) 마왕으로 각성하는 경우가 있다.

웹 사이트와 마찬가지로 게임이나 유틸리티와 같이 컴퓨터에 설치되는 프로그램들도 자신의 DB에 이상이 생기면 에러메세지와 함께 작동불능이 되지만, 이 경우 이용자 개인의 불편사항에 머무르는 편이기 때문에 웹 사이트 서버의 DB 에러와 같이 여러 사람이 동시에 겪을 정도의 파괴력이 나오지 않아 마왕이라고 일컬어지는 일은 별로 없다.

디시에서도 실세갤의 판단 여부를 가늠할 때 두부에러가 얼마나 자주 일어나느냐에 따라 결정하던 시절이 있었다. 스갤은 실제로 명경기나 그에 준하는 사건이 터질 때 수시로 두부 에러를 일으켰다. 최근에는 서버 증설&이지디씨 무력화&갤 인구감소 등의 이유로 웬만해선 두부 에러를 보기 어렵다.

5 함께 보기

  1. ↑ 빠른 처리를 위해서 RAM에 올려서 돌리는 경우도 있다. 당연하지만 변경 사항을 보조기억장치에 저장하지 못한 상태에서 서버 전원이 나가면 변경사항은 개발살이 난다.
  2. ↑ 출처: [1]