데이터베이스의 종류

RDB

• 개념
  • 데이터를 row와 column으로 이루어진 table의 형태의 데이터를 저장
  • 데이터가 테이블(table)에 레코드(record)로 저장되며, 각 테이블에는 명확한 구조(structure)가 존재하여 스키마를 준수하지 않는 레코드 추가할 수 없음
  • SQL(Structured Query Language)을 사용해서 데이터를 관리 및 접근함 (읽기/쓰기/수정)
• 장점
  • 데이터의 분류, 정렬, 탐색 속도가 빠름
  • 신뢰성이 높고 데이터의 무결성을 보장
  • 관계를 통해 각 데이터를 중복없이 한 번만 저장함
  • 데이터베이스를 추가하기 전에 유효성 검사를 통해 데이터 품질을 향상시킬 수 있음
  • VIEW를 이용한 보안 설정이 가능하기 때문에 허가받지 않는 사용자들로부터 데이터의 조회/변경/삭제 방지 가능
• 단점
  • 기존에 작성된 스키마의 수정이 어려움
  • 관계를 맺고 있기 때문에 복잡한 JOIN 쿼리를 사용해야 함
  • 데이터베이스의 부하 분석이 어려움
  • 수평적 확장이 어렵고 대체로 수직적 확장만 가능하여 데이터 처리량 성장에 한계가 있음
• 예시
  • Oracle, DB2, SQL Server, MySQL, PostgreSQL

NoSQL

• 개념
  • NoSQL(Not Only SQL) 이라고도 부름
  • 관계형 데이터베이스의 한계를 극복하기 위해 만들어진 새로운 형태의 데이터베이스로, 융통성있는 데이터 모델을 사용
  • 데이터의 저장 및 검색에 특화된 메커니즘 제공
  • 분산환경에서 데이터 처리를 더욱 빠르게 하기 위해 개발됨
• 장점
  • 스키마가 없어 유연성이 높음 (저장한 데이터를 조정하거나 새로운 필드 추가 가능)
  • 한 테이블에 모든 것을 갖춘 문서를 만들어 복잡한 조인문으로 작업할 필요가 없음
  • 자주 바뀌지 않는 데이터인 경우 편리, 애플리케이션에 필요한 형식으로 저장되어 데이터 읽는 속도가 빠름
  • 수직 및 수평 확장이 가능하므로 데이터베이스가 애플리케이션에서 발생시키는 모든 읽기/쓰기 요청의 처리가 가능
• 단점
  • 문서 저장이 단위 요소 수준에서 세밀한 보안을 제공하지 않음
  • NoSQL마다 쿼리 언어가 다른 경우가 많아 이식성이 낮음
  • 조인이 없어 컬렉션마다 데이터를 복제하여 각 컬렉션 일부분에 속하는 데이터를 생성함 > 데이터의 업데이트가 필요한 경우 특정 데이터를 함께 사용하는 모든 컬렉션에서 수행되도록 주의 필요
• 분류
  • Key-Value
    • key-value pair로 데이터를 저장
    • key는 unique identifier로도 사용됨
    • 값은 어떠한 형태의 데이터라도 담을 수 있음 (이미지, 비디오 등 가능)
    • Redis, Memcached 등이 해당
    • 활용
      • 간단한 데이터모델을 대상으로 데이터를 자주 읽고 쓰는 경우에 적합
      • 성능 향상을 위해 관계형 데이터베이스에서 데이터 캐싱
      • 모바일 애플리케이션용 사용자 데이터 정보와 구성정보 저장
      • 이미지와 오디오 파일 같은 대용량 객체 저장
  • Graph
    • 데이터를 graph의 형태로 저장
    • 각 항목이 node로 이루어져있고, node간의 관계는 edge를 사용해서 나타냄
    • Neo4j, OrientDB등이 해당
    • 활용
      • SNS등 서로 관계가 복잡한 상황에서 자주 사용됨 (링크드인 - 1촌, 2촌)
  • Document
    • key와 Document의 형태로 저장 (Key-Value 모델과 다른 점: Value가 계층적 형태인 도큐먼트로 저장)
    • row, column과 같은 구조는 없고 일반적으로 JSON 또는 XML 형태로 데이터를 저장
    • 값을 저장하기 전에 schema를 정의하지 않으며, 문서를 추가하면 schema가 됨
    • 각 문서 별로 다른 필드를 가질 수 있기 때문에 애플리케이션에서 데이터 입력 과정에서 컬럼과 필드의 관리를 해주어야함
    • 데이터베이스별로 데이터를 조작할 수 있는 언어가 따로 있음 (Xquery나 다른 도큐먼트 질의 언어)
    • MongoDB, CassandraDB, MarkLogic 등이 해당
    • 활용
      • 블로그 포스트와 같이 형식이 자유로워야 할 때 사용
      • 대용량 데이터를 읽고 쓰는 웹사이트용 백엔드 지원
      • 제품처럼 다양한 속성이 있는 데이터 관리
      • 다양한 유형의 메타데이터 추적
  • Column-family
    • 키는 Row(키 값)와 Column-family, Column-name을 가짐
    • 미리 정의된 스키마를 사용하지 않으므로 컬럼 추가 가능
    • 연관된 데이터들은 같은 Column-family 안에 속해 있으며, 각자의 Column-name을 가짐
    • 이렇게 저장된 데이터는 하나의 커다란 테이블로 표현이 가능
    • Schema-less이긴 하지만 새로운 필드를 만드는 데 드는 비용이 크기 때문에 사실상 결정된 스키마를 변경하는 것이 어려움
    • 컬럼-패밀리 모델은 클러스터링이 쉽게 이뤄지며, Time stamp가 존재해 값이 수정된 히스토리를 알 수 있음
    • 값들은 일련의 바이너리 데이터로 존재하기 때문에 어떤 형태의 데이터라도 저장될 수 있음
    • Blob 단위의 쿼리가 불가능하며, Row와 Column의 초기 디자인이 중요 (테이블 간 조인을 지원하지 않음)
    • 질의는 Row, Column-family, Column-name을 통해 수행
    • HBase, Cassandra, Hypertable 등이 해당
    • 활용
      • 여러 대로 구성된 클러스터에서 운영 (단일서버로 운영해도 될 만큼 데이터가 적다면 document나 key-value DB가 유리함)
      • 쓰기 작업이 많은 경우
      • 복제본 데이터가 단기적으로 불일치하더라도 큰 문제가 없는 경우
      • 동적 필드를 처리하는 경우

RDB vs NoSQL

• 관계형 데이터베이스는 관련 데이터를 동일한 테이블에 동일한 구조로 저장해야함 vs 비관계형 데이터베이스도 관련 데이터를 동일한 컬렉션에 넣으나, 다른 구조의 데이터를 같은 컬렉션에 추가 가능
• 관계형 데이터베이스 사용이 유리한 경우 :
  • 어플리케이션의 여러 부분에서 관련 데이터가 비교적 자주 변경되는 경우
• 비관계형 데이터베이스 사용이 유리한 경우 :
  • 정확한 데이터 요구사항을 알 수 없는 경우
  • 읽기 처리를 자주 하고, 관계를 맺고 있는 데이터가 자주 변경되지 않는 경우
  • 데이터베이스를 수평으로 확장해야 하는 경우 (대량의 데이터를 다뤄야 하는 경우, 읽기/쓰기 처리량이 큰 경우)