데이터베이스란?
- 여러 사람에 의해 공유되어 사용될 목적으로 통합하여 관리되는 데이터의 집합
- 자료항목의 중복을 없애고 자료를 구조화하여 저장함으로써 자료 검색과 갱신의 효율을 높인 것
DBMS란?
- 데이터베이스를 관리하는 시스템
- 데이터베이스를 정의하고 질의어 SQL를 지원하는 등의 작업을 함
- 관계형 데이터베이스 RDBMS
- 데이터를 단순한 표(Relation)로 표현하는 형식의 데이터베이스
- 정형화된 데이터 항목들의 집합
- 비관계형 데이터베이스 NoSQL
- 시대가 변화하면서 데이터가 점점 편화함<- 빅데이터 등장(3V - Volume, Velocity, Variety)
- 새로운 형태의 데이터 저장 기술이 필요
- 기존의 RDBMS의 한계를 극복하기 위해 만들어진 새로운 형태의 DBMS
RDBMS의 한계
- 스키마 문제
- 빅데이터를 RDB의 스키마에 맞춰 변경해서 넣으려면 매우 긴 시간의 down time이 발생
- 스케일업의 한계
- RDBMS는 스케일 아웃을 위해 설계되지 않음(스케일 업, Scale Up)
- 관계 모델과 트랜잭션의 연산, 일관성, 속성을 유지하면서 분산환경(스케일 아웃, Scale Out)에서 RDBMS를 조작하는 것은 어려움
RDBMS , NoSQL 비교
- 데이터 구조는 위와 같이 다르고
- 확장성 측면은 RDBMS에 비해 NoSQL이 더 좋다.
트랜잭션 성질 비교
- 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질
- RDBMS는 ACID , NoSQL은 CAP theorem
ACID
- 예시 : 돈 송금 명령 -> 내 계좌(-) -> 상대 계좌 (+) -> 전산상에 기록 -> 하나의 트랜잭션
- 원자성 Atomicity
- 부분적으로 실행되다가 중단되는 것을 방지하는 성질
- 정상적으로 송금이 되었으면 전상상에 기록이 되고, 아니면 처리되기 이전의 상태로 돌아가야 함.
- 일관성 Consistency
- 데이터는 항상 일관성 있는 상태를 유지해야 하고 데이터의 조작 후에도 무결성을 해치지 말아야 한다
- 송금이 완료되었으면, 계산에 대한 값이 제대로 보장이 되어야 함
- 고립성 Isolation
- 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미
- 송금이 수행 중일 때, 은행이 나에게 이자를 주는 트랜잭션이 수행되려면 송금 트랜잭션이 완수되고 수행해야 함
- 지속성 Durability
- 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미
- 송금(트랜잭션)이 한번 끝났으면 계속 유지되어야 함.
CAP theorem
- 가용성 Availability
- 어떤 일이 발생하더라도 서비스가 가능
- 일관성 Consistency
- 데이터가 하나의 노드에 기록될 때마다 이 데이터는 쓰기가 '성공'으로 간주되기 전에 시스템의 다른 모든 노드로 즉시 전달되거나 복제
- 파티션 허용 Partition tolerance
- 시스템의 노드 간에 다수의 통신 단절에도 불구하고 클러스터가 계속해서 작동해야 함을 의미
- 수평적 확장(Scale Out)을 가능하게 함
- 서버 한대 더 배치해서 데이터베이스를 확장할 수 있음
- CP 데이터베이스
- 가용성을 희생하면서 일관성과 파티션 허용을 제공
- 두 노드 간에 파티션이 발생하면, 시스템은 파티션이 해결될 때까지 일관되지 않은 노드를 종료(사용 불가능 하도록)
- AP 데이터 베이스
- 일관성을 희생하면서 가용성과 파티션 허용을 제공
- 파티션을 통해 모든 노드를 사용할 수 있지만, 노드 오류 시 다른 데이터보다 이전 버전의 데이터를 리턴
- 파티션이 해결되면, 일반적으로 시스템의 모든 불일 치를 복구하기 위해 노드를 재동기화
- CA 데이터베이스
- 모든 노드에서 일관성과 가용성을 제공
- 시스템에 있는 두 노드 사이에 파티션이 있는 경우 이를 수행할 수 없으므로, 결함 허용을 제공할 수 없음.
NoSQL의 데이터 모델
- 데이터베이스 구조를 명시하기 위한 개념들의 집합
- RDB는 릴레이션 형이니까 column이 있으면 데이터를 row로 관리한다. <- table 형태
- MongoDB 같은 NOSQL은 데이터를 key: value 값으로 다룸 <- JSON 형태, object 형
- 칼럼형 : 데이터로 key : value 쌍이 매칭되는 구조임.
- Key-Value store(모델)
- Document Store
- Column Family Store
- Graph Store
키- 값 모델
- 관계형 데이터베이스는 데이터 구조를 '잘 정의된 데이터 유형이 있는 필드를 포함하는 일련의 테이블'로 정의함
- 대조적으로, 키-값 시스템은 스키마가 존재하지 않으므로 이는 상당한 유연성을 제공함
- 대표적으로 Redis(인메모리), Oracle Coherence 등
- 장점 : 매우 간단함
- 단점 : 쓰기 연산에 유리하나 조건 읽기에는 불리함
문서형 모델
- 문서형 모델이란 키- 값 모델의 집합으로 중괄호를 통해서 하나의 문서처럼 저장하는 형태
- 데이터를 따로 매핑하지 않고 집어넣으면 알아서 잘 저장되므로 편리함
- 그러나 데이터를 가공함에 있어서 어려움을 겪을 수 있음
- 대표적으로 MongoDB, CouchDB, Riak
- 장점
- 문서들은 서로 독립적인 단위
- 스키마로부터 자유롭기 때문에 구조화되지 않은 데이터들도 쉽게 저장할 수 있음
- 단점
- 통계, 연산 등의 분야보다 갱신, 삽입, 조회의 용도가 효율이 좋음
- Join이 안되므로 미리 embedding 시켜야 함. : $lookup 함수로 Join과 유사한 능력을 수행할 순 있음.
칼럼형 모델
- 데이터의 저장을 열(Column) 단위로 처리하는 모델
- 특정 쿼리에 대해서는 행(Row)의 모든 데이터가 필요하지 않으므로 분석을 위해 사용하기 좋음
- 열 단위의 값은 데이터가 유사할 가능성이 높으므로 높은 압축률을 얻을 수 있음
- 대표적으로 SimpleDB, BigTable
- 장점
- 집계 연산에 유리함
- 단점
- 행을 조회하는 경우 비효율적
그래프형 모드
- 노드, 에지 및 속성을 사용하여 데이터를 표시하고 저장하는 모델
- 노드는 rdbms의 레코드, 행 또는 문서형 모델의 문서와 거의 동일함
- 에지는 노드 사이의 관계를 나타내는 선을 의미함
- 대표적으로 Soones, AllegroGraph, neo4j
- 장점
- 노드 간 관계 표현이 명확함
- 노드 간 관계 쿼리 수행 능력이 빠름
- 단점
- 그래프형 구조의 이유로 통계적 질의에는 부적합
'Back > MongoDB' 카테고리의 다른 글
MongoDB와 Python 연동하기 (0) | 2023.05.18 |
---|---|
Mongo DB 실습 - 3 (0) | 2023.05.18 |
Mongo DB 이론 - 2 (0) | 2023.05.17 |
Mongo DB 실습 - 2 (0) | 2023.05.17 |
Mongo DB 실습 - 1 (0) | 2023.05.17 |