[DBMS] 데이터베이스(Database) 종류와 장/단점 (계층형/네트워크형/SQL/NoSQL)

데이터베이스(database)는 '작성된  목록으로써 여러 응용 시스템들의 통합된 정보들을 저장하여 운영할 수 있는 공용 데이터들의 묶음'저렇게 위키에 정의가 되어있다. 

쉽게 말하면 데이터베이스는 정보를 수집하고 보관하기 위한 시스템으로 우리가 흔히 프로그래밍의 언어를 배울때 항상 배우는 파일 입출력 (File I/O)보다 향상되게 데이터를 접근하고 관리할 수 있다. 

데이터베이스의 종류는 다양하다 1) 계층형 데이터베이스, 2) 네트워크형 데이터베이스, 3) 관계형 데이터 베이스, 그리고 4) NoSQL 데이터베이스가 있다. 

• 1) 계층형 데이터 베이스는 데이터의 관계를 트리 구조로 정의하고, 부모, 자식 형태를 갖는 구조이다. 풀어서 말하면 상위에 레코드가 복수의 하위 레코드를 갖는 구조이다. 하지만 데이터의 중복이 문제가 생긴다. 

• 2) 네트워크형 데이터베이스는 계층형 데이터의 데이터 중복 문제를 해했고, 레코드간의 다양한 관계를 그물처럼 갖는 구조이다. 하지만 복잡한 구조 때문에 추후에 구조를 변경한다면 많은 어려움이 따른다. 

• 3) 관계형 데이터베이스는 우리가 흔히 표현하는 행(Column), 열(Record)로 구성된Table간의 관계를 나타낼때 사용한다. 우리는 이렇게 표현된 데이터를  SQL(Structured Query Language)을 사용하여 데이터 관리 및 접근을 한다.

• 4) NoSQL 데이터베이스는 관계형 데이터베이스보다 덜 제한적인 일관성 모델을 이용한다. 키(key)와 값(value)형태로 저장되고, 키를 사용해 데이터 관리 및 접근을 한다.

우리가 흔히 사용하는 관계형 데이터베이스 (SQL)과 NoSQL 데이터베이스에 대해서 자세하게 알아 보겠다.  

• 관계형 데이터베이스 (SQL)
• 장점
• 다양한 용도로 사용이 가능하고, 일반적으로 높은 성능을 보여주고 있다 (범용적 / 고성능)
• 데이터의 일관성을 보증한다.
• 정규화에 따른 갱신 비용 최소화
• 단점
• 대량의 데이터 입력 처리
• 갱신이 발생한 테이블의 인덱스 생성 및 스키마 변경
• 컬럼의 확장의 어려움
• 단순히 빠른 결과
• 주요 제품 종류
• Oracle / Oracle
• MS-SQL Server / Microsoft
• MySQL / Oracle (SunMicroSystems)
• DB2 / IBM
• Infomix / IBM
• Sybase / Sybase
• Derby / APache
• SQLite / Opensource
• NoSQL 데이터베이스
• SQL을 사용하지 않는다는 의미로, Not Only SQL (SQL이 필요 없다는 의미가 아니고, 개선/ 보안의 의미)
• Non-Relational Operational Database SQL (관계형 데이터베이스가 아니다.) 
• NoSQL의 장점
• 대용량 데이터
• 데이터 분산 처리
• Cloud Computing
• 빠른 읽기/쓰기 속도
• 유연한 데이터 모델링
• NoSQL의 종류
• key / value
• 휘발성/영속성
• Memchached, Tokyo Tyrant, Flare, Roma, Redis
• Document
• 스키마 정의 없음
• MongoDB, CouchDB
• Big Table(Column 형) DB
• 뛰어난 확장성, 검색에 유리
• Hbase, Casandara, Hypertable
  

  우리가 흔히 사용하는 SQL 데이터베이스와 NoSQL의 데이터베이스는 언제 어떻게 사용하느냐가 굉장한 성능에 영향을 준다. 데이터 사이에 관계가 존재하면 SQL 데이터베이스를 사용하고, 데이터 사이에 관계가 필요 없으면 NoSQL 데이터베이스를 사용하면 된다. (너무 당연한 말이지 암... 이름이 저런디)

  내 경험을 바탕으로 한다면, SNS를 개발할때 User, Feed, Comment 등 다양한 데이터가 존재하고, 데이터 사이에 관계가 존재하기 때문에 SQL을 사용하면 보다 빠르게 데이터를 접근 할 수 있다. 만약 이 내용을 NoSQL로 구현을 했다면 모든 내용을 하나의 Document로 저장하면 되겠지만, 그렇게되면 데이터의 중복이 엄청나기 때문에 올바르지 못하다. 데이터 중복을 피하기 위해 만약 User, Feed, Comment 등의 값들을 각각 key-value로 저장하고 있다면, 데이터 접근 후 하나의 객체로 만드는 과정의 비용이 상당할 것이다. 생각만해도 클라이언트가 답답해 하는 소리가 들린다. 

  하지만 인터넷에 있는 기사를 긁어오는 스크랩 코드를 구현했다면 url + @로 key, 하나의 페이지를 value로 저장한다면 빠르고 쉽게 저장/접근이 가능하다. 이럴때는 NoSQL이 적절하지 않을까 싶다. 

  본 내용은 나의 경험과 생각이다. 더 좋은 아이디어와 틀린점이 있으면 댓글로 토론을 해봅시다.