SQL (RDBMS)과 NoSQL
SQL (RDBMS)
- 관계형 데이터베이스 관리 시스템(RDBMS)의 데이터 관리를 위해 설계된 프로그래밍 언어
- RDBMS는 NoSQL과 대비되어 DB를 구분지어 설명할 때 SQL DB로도 표현됨
RDBMS의 R은Relational의 약자로 RDBMS는 관계형 데이터베이스 관리 시스템을 의미
Database와 Management System이 같이 결합되서 데이터를 잘 관리하고 저장할 수 있도록 제공
즉, 관계형 데이터 모델을 기초로 두고 모든 데이터를 2차원 테이블 형태(Entity)로 표현하는 데이터베이스
관계형 데이터베이스(RDMBS)는 각각의 테이블이 다른 테이블들과 관계를 맺고 모여있는 집합체로 이해할 수 있음
또한 이러한 관계를 나타내기 위해 외래 키(foreign key)라는 것을 사용
이러한 테이블간의 관계에서 외래 키를 이용한 테이블 간 Join이 가능하다는 게 RDBMS의 가장 큰 특징
NoSQL
- Not only SQL, Non Relational Database SQL 등으로 불림
- 기존 정형화된 데이터 뿐 만 아니라 메신저 텍스트, 음성, 비정형화된 데이터도 저장하고 다뤄야 하는 수요가 생김
- RDBMS로만 빅데이터를 다룰 때 트래픽을 감당하기 어려워 졌고 이를 해결하기 위해 NoSQL이 등장
- 수평 확장과 고 가용성
- RDBMS가 클라이언트/서버 환경에 맞는 데이터 저장 기술이라면, NoSQL은 클라우드 환경에 보다 잘 맞는 기술
- 기존 관계형 DBMS가 갖고있는 특성 뿐만 아니라 다른 특성들을 부가적으로 지원
- 스키마 없음, 관계 없음
NoSQL 특징
-
NoSQL은 RDBMS와는 달리 데이터 간의 관계를 정의하지 않음
- 각 테이블 간의 관계를 정의하지도 않고 일반적으로 테이블 간의 Join도 불가능
-
RDBMS에 비해 훨씬 더 대용량의 데이터를 저장 가능
- 페타바이트급의 대용량 데이터를 저장할 수 있음
-
분산형 구조
- 분산형 구조를 통해 데이터를 여러 대의 서버에 분산해 저장
- 분산 시에 데이터를 상호 복제해 특정 서버에 장애가 발생했을 때에도 데이터 유실이나 서비스 중지가 없는 형태의 구조
-
고정되지 않은 테이블 스키마 (Schema-less)
- 테이블의 스키마가 유동적
- 키 부분의 타입은 공통이지만, 데이터를 저장하는 컬럼은 각기 다른 이름과 다른 데이터 타입을 갖는 것이 허용됨
- 읽기 작업보다 쓰기 작업이 더 빠르며, 일반적으로 RDBMS에 비해 쓰기와 읽기 성능이 빠름
NoSQL 종류
Key/Value Store
- key / Value 개념을 지원하며 Unique한 key에 하나의 Value를 가지고 있는 형태
- Column Family의 개념 사용 : key안에 (Column, Value) 조합으로 된 여러 개의 필드 사용
- Oracle Coherence, Redis
Document Key/Value Store
- key / Value store의 확장된 형태임, Value의 데이터 타입이 Document라는 타입 사용
- 복잡한 계층 구조 표현 가능
- Document 타입 : XML, JSON, YAML과 같이 구조화된 데이터 타입
- MongoDB, CounchDB, Riak ,Firebase Realtime Database
Wide Column Database
- Column-family Model 기반의 database
- Key-Value 구조는 동일하지만, 구조가 조금 다르며 key 또한 정렬된 순서로 저장되어있음
- 하나의 row는 rowkey라는 key를 갖고, 하나의 row에도 column-family 단위로 쪼개어 연관된 데이터를 관리한다. 이 column-family안에는 각각의 column-name과 value를 가진다.
- HBase, Hypertable 등
SQL VS NoSQL 비교
SQL | NoSQL | |
장점 | - 데이터 무결성 보장 (하위 ACID 참조) - 중복없는 데이터 - 명확한 스키마 |
- 스키마가 없어, 유연한 데이터 저장 - 데이터 분산에 용이하며, 성능향상으 루이한 수직 및 수평 확장 가능 |
단점 | - 스키마로 인해 데이터가 유연하지 못함 (스키마가 변경시 번거롭고 복잡) - 테이블 간 관계를 맺고 있어 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리가 만들어질 수 있음 - 성능 향상을 위해서는 서버의 성능을 향상 시켜야하는 Scale-up만을 지원 |
- 데이터 중복이 발생할 수 있으며, 중복된 데이터가 변경될 경우 수정을 모든 컬렉션에서 수행해야 함 - 스키마가 존재하지 않기에 명확한 데이터 구조를 보장하지 않으며 데이터 구조 결정이 어려울 수 있음 |
SQL VS NoSQL 용어 비교
SQL | MongoDB | DynamoDB | Cassandra | Couchbase |
테이블 | 컬렉션 | 테이블 | 테이블 | 데이터 버킷 |
열 | 문서 | 항목 | 열 | 문서 |
컬럼 | 필드 | 속성 | 컬럼 | 필드 |
기본 키 | ObjectId | 기본 키 | 기본 키 | 문서 ID |
인덱스 | 인덱스 | 보조 인덱스 | 인덱스 | 인덱스 |
보기 | 보기 | 글로벌 보조 인덱스 | 구체화된 보기 | 보기 |
중첩된 테이블 또는 객체 | 포함 문서 | 맵 | 맵 | 맵 |
배열 | 배열 | 목록 | 목록 | 목록 |
ACID와 BASE
ACID (RDBMS/SQL DB의 특징)
ACID(원자성, 일관성, 고립성, 지속성)는 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어이다. 짐 그레이는 1970년대 말에 신뢰할 수 있는 트랜잭션 시스템의 이러한 특성들을 정의하였으며 자동으로 이들을 수행하는 기술을 개발해 냈다.
1983년 안드레아스 로이테르(Andreas Reuter)와 테오 해르데르(Theo Härder)는 ACID라는 용어를 만들면서 이를 기술했다.[4]
데이터베이스에서 데이터에 대한 하나의 논리적 실행단계를 트랜잭션이라고 한다. 예를 들어, 은행에서의 계좌이체를 트랜잭션이라고 할 수 있는데, 계좌이체 자체의 구현은 내부적으로 여러 단계로 이루어질 수 있지만 전체적으로는 '송신자 계좌의 금액 감소', '수신자 계좌의 금액 증가'가 한 동작으로 이루어져야 하는 것을 의미한다.
- 원자성(Atomicity)은 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력이다. 예를 들어, 자금 이체는 성공할 수도 실패할 수도 있지만 보내는 쪽에서 돈을 빼 오는 작업만 성공하고 받는 쪽에 돈을 넣는 작업을 실패해서는 안된다. 원자성은 이와 같이 중간 단계까지 실행되고 실패하는 일이 없도록 하는 것이다.
- 일관성(Consistency)은 트랜잭션이 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 유지하는 것을 의미한다. 무결성 제약이 모든 계좌는 잔고가 있어야 한다면 이를 위반하는 트랜잭션은 중단된다.
- 독립성(Isolation)은 트랜잭션을 수행 시 다른 트랜잭션의 연산 작업이 끼어들지 못하도록 보장하는 것을 의미한다. 이것은 트랜잭션 밖에 있는 어떤 연산도 중간 단계의 데이터를 볼 수 없음을 의미한다. 은행 관리자는 이체 작업을 하는 도중에 쿼리를 실행하더라도 특정 계좌간 이체하는 양 쪽을 볼 수 없다. 공식적으로 고립성은 트랜잭션 실행내역은 연속적이어야 함을 의미한다. 성능관련 이유로 인해 이 특성은 가장 유연성 있는 제약 조건이다. 자세한 내용은 관련 문서를 참조해야 한다.
- 지속성(Durability)은 성공적으로 수행된 트랜잭션은 영원히 반영되어야 함을 의미한다. 시스템 문제, DB 일관성 체크 등을 하더라도 유지되어야 함을 의미한다. 전형적으로 모든 트랜잭션은 로그로 남고 시스템 장애 발생 전 상태로 되돌릴 수 있다. 트랜잭션은 로그에 모든 것이 저장된 후에만 commit 상태로 간주될 수 있다.
ACID는 RDBMS에서 매우 중요하게 생각하는 성질이라 할 수 있지만, NoSQL에서는 찾아보기 힘든 단어이다.
BASE (NoSQL DB의 특징)
성능과 가용성 등을 위해서 ACID의 C와 I의 속성을 포기하고 분산 시스템에 더 적합하다고 생각되는 성질을 정리한 것이 BASE이다.
- Basically Available : 분산시스템은 언제나 요청에 응답 할 수 있어야 한다. 하지만 언제나 올바른 응답을 보장해주지는 않는다.
- Soft-state : 분산시스템의 상태는 User가 별도로 유지하지 않으면 언제든지 변경될 수 있으며, 외부의 요청이 없더라도 언제든지 바뀔 수 있다는 의미이다. 또 다른 말로 사용자가 관리(refresh, modify)하지 않으면 Data가 expire 될 수도 있다.
- Eventually consistency : 지금 당장은 아니지만 언젠가는 Data가 일관성을 가진다. 일시적으로 일관성이 깨질수는 있지만 최종적으로는 일관성을 유지하는 특징을 의미한다. Update된 Data가 다른 Node들에게 전달되기 전까지 일시적으로 일관성이 깨지지만, 특정 시간이 지난후에 모든 Node들이 Update되면 다시 일관성을 유지 할 수 있게 된다.
'개발 > DB' 카테고리의 다른 글
Local Cache에 대하여 (Spring Cache, Caffeine/Ehcache, Redis Client-side caching..) (0) | 2022.09.01 |
---|---|
Index / Clustered Index vs NonClustered Index (0) | 2022.08.24 |
CAP 정리와 PACELC 정리 (0) | 2022.08.10 |
[Redis] Redis Cluster의 기초 (0) | 2022.06.21 |
Spring Data MongoDB Tailable Cursors (MongoDB 테일러 커서) (0) | 2021.01.11 |
댓글