관계형 데이터베이스(SQL)

• Mysql, Oracle, Mssql 같은 고전적인 데이터베이스

• 동일한 구조(릴레이션)의 관점에서 모든 데이터를 논리적으로 구성

• 선언적인 질의어를 통한 데이터 접근을 제공

• 응용 프로그램들은 데이터베이스 내의 레코드들의 어떠한 순서와도 무관하게 작성됨

• 사용자는 원하는 데이터(what)만 명시하고, 어떻게 이 데이터를 찾을 것인가(how)는 명시할 필요가 없음

• 관계 데이터 모델은 지금까지 제안된 데이터 모델들 중에서 가장 개념이 단순한 데이터 모델

• 관계 데이터 모델이 큰 성공을 거둔 요인

  • 바탕이 되는 데이터 구조로서 간단한 테이블(릴레이션)을 사용

  • 중첩된 복잡한 구조가 없음

  • 집합 위주로 데이터를 처리

  • 숙련되지 않은 사용자도 쉽게 이해할 수 있음

  • 표준 데이터베이스 응용에 대해 좋은 성능을 보임

• 특징

  • 바탕이 되는 데이터 구조로서 간단한 테이블(릴레이션)을 사용

  • 중첩된 복잡한 구조가 없음

  • 집합 위주로 데이터를 처리

  • 숙련되지 않은 사용자도 쉽게 이해할 수 있음

  • 표준 데이터베이스 응용에 대해 좋은 성능을 보임

• 장점

  • 데이터의 성능이 일반적으로 좋아 정렬, 탐색, 분류가 빠름

  • 신뢰성이 높아 데이터의 무결성을 보장

  • 정규화에 따른 갱신 비용을 최소화

• 단점

  • 기존에 작성된 스키마를 수정하기 어려움

  • 데이터베이스의 부하를 분석하기 어려움

  • 빅데이터를 처리하는데 매우 비효율적

• 기본 용어

• relation(릴레이션) : 2차원의 테이블(스프레드 시트(엑셀 시트)와 유사)

• record(레코드) : 릴레이션의 각 행

• tuple(튜플) : 레코드를 좀 더 공식적으로 부르는 용어 = 로우(row)

• attribute(속성) : 릴레이션에서 이름을 가진 하나의 열 = 컬럼(column) or 필드(field)

• 파일 시스템에는 레코드만 가진 파일 형태로 존재하지만 관계형 데이터베이스는 attribute, tuple을 가진 relation(테이블) 형태로 존재

• 도메인(domain)

  • 한 속성에 나타날 수 있는 값들의 집합

  • 각 속성의 도메인의 값들은 원자값

  • 프로그래밍 언어의 데이터 타입과 유사함

  • 동일한 도메인이 여러 속성에서 사용될 수 있음

  • 복잡 속성나 다치 애트리뷰트는 허용되지 않음

  • ex) EMPNAME의 도메인 정의

• 차수(degree)와 카디날리티(cardinality)

  • 차수 : 한 릴레이션에 들어 있는 속성들의 수(필드 수)

    • 유효한 릴레이션의 최소 차수는 1

      • 속성이 1개이상 있어야 릴레이션(테이블)이 됨

    • 릴레이션의 차수는 자주 바뀌지 않음

      • 보통 테이블 스키마는 자주 못바꿈
      • 스키마 변경시 전체 로우에 반영되어야 하기 때문에 처리가 중단됨

  • 카디날리티 : 릴레이션의 튜플(로우 수)

    • 유효한 릴레이션은 카디날리티 0을 가질 수 있음
    • 릴레이션의 카디날리티는 시간이 지남에 따라 계속해서 변함

비관계형 데이터베이스(NoSQL)

• NoSQL이라고도 부르며, Not Only SQL(SQL 뿐만이 아닌. 이라는 뜻)의 줄임말

• 즉, SQL뿐만 아니라 다른 여러 장점을 가지고 있다

• 기존의 관계형 데이터베이스의 한계를 뛰어넘기 위해 만들어진 새로운 형태의 데이터베이스라서, 관계형 데이터베이스보다 더 융통성 있는 데이터 모델을 사용

• 데이터의 저장 및 검색에 특화된 메커니즘을 제공함

• NoSQL은 분산 환경에서의 데이터 처리를 더욱 빠르게 함

• ex) MongoDB와 Redis,HBase, CouchDB

• 특징

  • 거대한 Map으로서 key-value 형식을 지원

  • 관계형 db와 달리 PK(주키),FK(외래키), JOIN 등 관계를 정의하지 않음

  • 스키마에 대한 정의 X

• 종류

  1) 문서형(Document) 데이터베이스

  • 데이터를 테이블이 아닌 문서처럼 저장하는 데이터베이스

  • 파일 시스템이랑 비슷하지만 데이터 탐색은 ManageMent System이 대신 해주기 때문에 다름

  • 많은 문서형 데이터베이스에서 JSON과 유사한 형식의 데이터를 문서화하여 저장

  • 각각의 문서는 하나의 속성에 대한 데이터를 가지고 있고, 컬렉션이라고 하는 그룹으로 묶어서 관리

  • 대표적인 문서형 데이터베이스에는 MongoDB가 존재

  2) Key-Value 타입

  • 속성을 Key-Value의 쌍으로 나타내는 데이터를 배열의 형태로 저장

  • 여기서 Key는 속성 이름을 뜻하고, Value는 속성에 연결된 데이터 값을 의미

    • key : PK 같은 어떤 데이터를 찾을 수 있는 인덱스 같은 역할

  • 간단하게 저장하기 때문에 데이터 생성, 삭제 속도가 빠름

  • Redis, Dynamo 등이 대표적인 Key-Value 형식의 데이터베이스

  3) Wide-Column Store 데이터베이스

  • 데이터베이스의 열(column)에 대한 데이터를 집중적으로 관리하는 데이터베이스

  • 각 열에는 key-value 형식으로 데이터가 저장되고, 컬럼 패밀리(column families)라고 하는 열의 집합체 단위로 데이터 처리 가능

  • 하나의 행에 많은 열을 포함할 수 있어서 유연성을 높음

  • 데이터 처리에 필요한 열을 유연하게 선택할 수 있다는 점에서 규모가 큰 데이터 분석에 주로 사용되는 데이터베이스 형식

  • 대표적인 wide-column 데이터베이스에는 Cassandra, HBase가 존재

  4) 그래프(Graph) 데이터베이스

  • 자료구조의 그래프와 비슷한 형식으로 데이터 간의 관계를 구성하는 데이터베이스

  • 노드(nodes)에 속성별(entities)로 데이터를 저장

  • 각 노드간 관계는 선(edge)으로 표현

  • 대표적인 그래프 데이터베이스에는 Neo4J,InfiniteGraph가 존재

• 장점

  • 대용량 데이터 처리를 하는데 효율적

  • 읽기 작업보다 쓰기 작업이 더 빠르고 관계형 데이터베이스에 비해 쓰기와 읽기 성능이 빠름

  • 데이터 모델링이 유연함

  • 뛰어난 확장성으로 검색에 유리

  • 최적화된 키 값 저장 기법을 사용하여 응답속도나 처리효율 등에서 성능이 뛰어남

    • 일반적으로 Join을 하지 않는다면 검색에 유리

  • 복잡한 데이터 구조를 표현할 수 있음

• 단점

  • 쿼리 처리시 데이터를 파싱 후 연산을 해야해서 큰 크기의 document를 다룰 때는 성능이 저하

---

SQL Vs NoSQL

• NoSQL 기반의 비관계형 데이터베이스가 확장성이나 속도면에서 더 뛰어남

• 차원으로 구조화된 SQL 기반의 데이터베이스가 더 좋은 성능을 보여주는 서비스도 많음

1. SQL 사용이 적합한 경우

1) 데이터베이스의 ACID 성질을 준수해야 하는 경우

• ACID는 Atomicity(원자성), Consistency(일관성), Isolation(격리성), Durability(지속성)를 의미

  • Atomicity(원자성) : 수정이 발생하더라도 하나가 원자적으로 유지됨

  • 각 단어는 데이터베이스에서 실행되는 하나의 트랜잭션(Transaction)에 의한 상태의 변화를 수행하는 과정에서, 안전성을 보장하기 위해 필요한 성질

  • 트랜잭션(Transaction) 이란 데이터베이스를 수정하는 하나의 작업묶음단위 (ex. 출금)

• SQL을 사용하면 데이터베이스와 상호 작용하는 방식을 정확하게 규정할 수 있기 때문에, 데이터베이스에서 데이터를 처리할 때 발생할 수 있는 예외적인 상황을 줄이고, 데이터베이스의 무결성을 보호할 수 있음

• 전자 상거래를 비롯한 모든 금융 서비스를 위한 소프트웨어 개발 에서는 반드시 데이터베이스의 ACID 성질을 준수해야 함

• 그래서 이런 경우에는 일반적으로 SQL을 이용한 관계형 데이터베이스를 사용

2) 소프트웨어에 사용되는 데이터가 구조적이고 일관적인 경우(=> 스키마)

• 소프트웨어(프로젝트)의 규모가 많은 서버를 필요로 하지 않고 일관된 데이터를 사용하는 경우, 관계형 데이터베이스를 사용하는 경우가 많음

• 다양한 데이터 유형과 높은 트래픽을 지원하도록 설계된 NoSQL 데이터베이스를 사용해야만 하는 이유가 없기 때문에

2. NoSQL 사용이 적합한 경우

1) 데이터의 구조가 거의 또는 전혀 없는 대용량의 데이터를 저장하는 경우

• 대부분의 NoSQL 데이터베이스는 저장할 수 있는 데이터의 유형에 제한 X

• 필요에 따라, 언제든지 데이터의 새 유형을 추가 가능

• 소프트웨어 개발에 정형화 되지 않은 많은 양의 데이터가 필요한 경우, NoSQL을 적용하는 것이 더 효율적

2) 클라우드 컴퓨팅 및 저장공간을 최대한 활용하는 경우

• 클라우드 기반으로 데이터베이스 저장소를 구축하면, 저렴한 비용의 솔루션을 제공받을 수 있음

• 소프트웨어에 데이터베이스의 확장성이 중요하다면, 별다른 번거로움 없이 확장할 수 있는 NoSQL 데이터베이스를 사용하는 것이 좋음

3) 빠르게 서비스를 구축하는 과정에서 데이터 구조를 자주 업데이트 하는 경우

• NoSQL 데이터베이스의 경우 스키마를 미리 준비할 필요가 없기 때문에 빠르게 개발하는 과정에 매우 유리

  • 시장에 빠르게 프로토타입을 출시해야 하는 경우가 이에 해당

• 소프트웨어 버전별로 많은 다운타임(데이터베이스 서버를 오프라인으로 전환하여 데이터 처리를 진행하는 작업 시간) 없이 데이터 구조를 자주 업데이트 해야하는 경우, 스키마를 매번 수정해야 하는 관계형 데이터베이스 보다 NoSQL 기반의 비관계형 데이터베이스를 사용하는 게 더 적합!