RDBMS(SQL DB)와 NoSQL DB
RDBMS는 relational database management system로 관계형 데이터베이스 관리 시스템이다.
NoSQL의 경우 비 관계형 데이터베이스 관리 시스템이다. 뭐 not only SQL 이니 no sql이니 뭐니 하는데 중요한것 같진 않고,
SQL(MySQL, Oracle...)은 RDMBS를 관리하기 위하여 설계된 언어이고, NoSQL은 RDB 형태가 아닌 다른 형태의 데이터 저장방식이다.
RDB는 정해진 데이터 스키마에 따라 DB 테이블에 레코드(row 혹은 tuple, 같은말) 형태로 저장하고, 데이터들이 관계를 통해 여러 테이블로 분산되어 저장된다.
(스키마는 DB 테이블의 설계 구조로 어떠한 데이터가 들어갈지 정의된 것을 말한다. 스키마에 맞춰 데이터가 입력되어야 함. 그리고 레코드는 1, sam, 32 // 각각 회원 번호, 이름, 나이 로 저장되었다고 할 때, 이 한 줄이 레코드. 이 레코들이 모여서 테이블. 회원번호, 이름, 나이 이런 카테고리들은 필드라고 한다.)
관계를 통한다는 것은 [1, sam, 32]이란 레코드가 있을 때, [sam, 어떤 글 제목, 어떤 글 내용]과 같은 레코드와 sam이라는 것으로 연결된다. 그래서 어떤 글의 작성자 sam의 회원번호는 1이고, 나이는 32라는 것까지 확인할 수 있는데, 저 두 레코드를 저장하고 있는 테이블이 서로 relate 되어 있기 때문이다.
아래 그림으로 예시를 더 들어보면, 홍길동 사원의 부서코드는 C100으로만 되어있다. 그럼에도 불구하고 홍길동 사원의 부서가 영업부라는 것을 알 수 있는 이유는 부서코드가 부서 테이블와 관계(relative) 되어 있기 때문이다.
이러한 RDB는 데이터 무결성(데이터가 완벽)이 보장되고, 정규화된(정형) 데이터 처리에 적합하다. 하지만, 대규모 확장이나 분산환경에는 부적합할 수도 있다.
빨간색 - 릴레이션 스키마/ 스키마 - 이 테이블에는 [사원코드, 사원명, 직급, 부서코드] 형태로 들어가야한다. 그리고 각 속성(필드, 열)들도 사원은 숫자, 사원명은 한글, 직급은 대리/과장/차장/부장..., 부서코드는 영문+숫자 형태로 들어가야되는 규칙이 적용되어 있는 것이고, 무엇하나 빠지거나 규칙을 어기면 안된다.
살구색 - 기본키 - 사원코드는 중복되지 않게 각 사원에게 지급된다. 이렇게 중복되지 않는 값들 중 대표 키로 설정해둔다.
(다시 한번 정리하면, 과장 이란 직급은 여러명이 있을 수 있지만, 사원코드 102는 김정만 만 있을 것이다. 특정 값으로 단 하나의 결과만 도출해낼 수 있는 값들 중 대표로 하나 정하는 것을 기본키(Primary key)라고 한다.
수퍼 키 - 특정 값으로 조회 했을 때 하나의 결과만 도출해낼 수 있는 값 인데, 값들이 조합으로 되어 있어도 된다.
[사원코드] - 수퍼 키, [사원코드, 사원명] - 수퍼키, [사원코드, 사원명, 직급] - 수퍼키, [직급, 부서코드] - 영업부에 여러 과장이 있을 수 있기 때문에 수퍼키가 안됨, [사원명, 직급] - 회사 내 같은 직급의 같은 이름의 사원들이 있을 수 있기 때문에 수퍼키가 안됨, [부서코드] - 수퍼 키, [부서명]-수퍼 키, [부서코드, 부서명] - 수퍼키
후보키- 수퍼키 중 최소한의 조합으로 된 것, [사원코드]- 수퍼키, [사원코드, 사원명] - 수퍼키 아님, [부서명]-수퍼 키, [부서코드, 부서명] - 수퍼키 아님,
기본 키 - 후보키들 중 메인, 레코드를 식별할 기준이 되는 키, 후보키들 중 기본 키가 되지 못한 것들은 대체 키라고 한다.
만약 사원 테이블에 사원코드가 없다면... 나이, 키, 체중, 성별, 고향, 입사년월일 속성등을 추가해서...
[사원명, 직급, 부서코드, 나이, 키, 체중, 성별, 고향. 입사년월일] 이렇게 묶는다면..이정도면 상식적으로 중복되지 않을 것이므로 이것을 기본키로 쓸 수 있다. 이런 것을 복합 키 라고 한다.
하늘색 - 외래키 - 다른 테이블의 기본 키와 연결 되어 있는 키. 사원 테이블에서 부서코드는 외래키이고, 부서 테이블에서는 부서코드가 기본키이다.
초록색 - 속성/어트리뷰트/필드/컬럼/열
보라색 - 도메인 - 하나의 속성이 취할 수 있는 동일한 유형의 값들의 집합
황토색 - 튜플/레코드/행/로우 - 한 줄 값들의 집합
노란색 - 릴레이션 인스턴스/인스턴스 - 릴레이션(테이블)에 스키마에 따라 저장된 값들의 집합
*RDB는 ACID 보장 => 중요한 트랜젝션을 처리하는 경우(절대 잘못된 정보 수정이 있어선 안되는 경우) RDB를 사용하는 것이 좋다.
ACID는
Atomicity(원자성) = 모든 작업이 반영되거나 그러지 않으면 모두 롤백 되는 것
Consistency(일관성) = 트랜잭션의 작업 처리 결과가 항상 일관성이 있어야한다는 것.
Isolation(고립성)=두 개 이상의 트랜젝션이 실행되고 있을 때, 어느 하나의 트랜잭션이 다른 트랜젝션 연산에 끼어들지 못함
Durability(영구성/내구성) = 한번 반영(커밋)된 트랜젝션은 영원히 적용된다는 특성
* 트랜젝션이란 DB 내에서 하나의 그룹으로 처리되어야하는 명령문들을 모아놓은 논리적인 단위
확장이 힘들다는 것은 RDB의 경우 확장을 위해서는 수직 확장(scale up)을 해야된다. 수직확장은 한계가 있을 수 밖에 없다. 물론 샤딩이라는 것을 통해 수평 확장(scale out)을 할 수 있지만, NoSQL에 비해 제한이 많거나 어렵다.
(Scale up - 컴퓨터의 성능 UPG, Scale out - 컴퓨터를 추가)
NoSQL은 스키마와 관계(relational)가 없다.(동적 스키마를 가진다고도 표현한다. 실제로 스키마가 없을 수도 있고...) Key-Value를 한쌍으로 Document 형태로 저장되며 다른 구조의 데이터를 같은 컬렉션에 추가가 가능하다.
* Document는 Record로 보면 되고, Collection은 Table로 보면 된다.
NoSQL은 기본적으로 수평적확장을 지원한다.(수직 확장은 당연히 되는것이고) 따라서 방대한 데이터 처리에 용이하다.
데이터 무결성, 정합성(데이터들이 일관되게 처리)을 보장하지는 않는다. 그래서 비정형, 반정형 데이터 처리에 적합하고 구조(스키마)를 알 수 없거나 데이터 양이 많거나 빠른 성능이 필요할 때 NoSQL이 적합하다.
근데 만약 데이터의 잦은 변경이 발생하면, NoSQL 보다는 RDB가 적합하다. RDB의 경우 한 테이블의 정보를 수정하기만 하면 관계된 테이블이 그 변경된 테이블 정보를 알 수 있지만,
NoSQL의 경우는 관계로 연결된 것이 아니라 컬렉션이나 도큐먼트가 복사된 경우라서 수정이 일어날 경우 복사된 데이터가 변경될 경우 여러 컬렉션 혹은 도큐먼트가 수정되어야 한다.
AWS에서 RDS와 Aurora(오로라)가 RDMBS에 속하고, DynamoDB가 Nosql에 해당하는 DB 시스템이다.