SQL vs NoSQL
한마디 버전 한국어 : SQL은 Foreign Key등을 이용하여 같이 관계를 정의하고, NoSQL은 데이터 간의 관계를 정의하지 않습는다. 이것은 가장 큰 차이점 중 하나입니다. 관계형 데이터베이스는 데이터 관계형으로 결합하며, NoSQL은 각 테이블을 하나의 데이터셋, 그 자체로 간주한다. 영어 : SQL defines relationships using like Foreign Key, and NoSQL does not define relationships between data. This is one of the biggest differences. Relational databases joins data relational, and NoSQL consider each table as a single data set, itself. |
1. NoSQL DB
NoSQL은 기존 SQL 서버의 복잡성과 용량을 해결하기 위해 탄생했기 때문에 데이터 용량이 더 큰 경향이 있습니다. SQL은 고정된 스키마를 가지고 있고 NoSQL은 유연한 스키마를 가지고 있으며, SQL 데이터베이스에는 특정 유형의 데이터만 넣을 수 있고, NoSQL에는 그런 개념이 없습니다. 아무거나 다 때려 넣을 수 있..;; ㅎㅎ
| Type | NoSQL DB |
| Key-Value Cache | Apache Ignite, Couchbase, Coherence, eXtreme Scale, Hazelcast, Infinispan, Memcached, Redis, Velocity |
| Key-Value Store | ArangoDB, Aerospike, Couchbase, Redis |
| Key-Value Store (Eventually-Consistent) | Oracle NoSQL Database, Dynamo, Riak, Voldemort |
| Key-Value Store (Ordered) | FoundationDB, InfinityDB, LMDB, MemcacheDB |
| Tuple Store | Apache River, GigaSpaces |
| Object Database | Objectivity/DB, Perst, ZopeDB |
| Document Store | ArangoDB, BaseX, Clusterpoint, Couchbase, CouchDB, DocumentDB, eXist-db, IBM Domino, MarkLogic, MongoDB, Qizx, RethinkDB, Elasticsearch |
| Wide Column Store | Amazon DynamoDB, Bigtable, Cassandra, Scylla, HBase, Hypertable |
| Native Multi-model Database | ArangoDB, Cosmos DB, OrientDB, MarkLogic |
NoSQL 데이터베이스는 관계형 데이터베이스에 사용되는 테이블 관계 이외의 방법으로 모델링된 데이터의 저장 및 검색 메커니즘을 제공합니다. NoSQL 데이터베이스는 빅데이터 및 실시간 웹 애플리케이션에서 점점 더 많이 사용되고 있으며. SQL과 어깨를 나란히 하고 SQL과 비슷한 쿼리를 지원한다는 것을 강조하기 위해 "Not Only SQL(NoSQL)"라고도 불린다.
이 접근방식의 동기에는 설계의 단순성, 시스템 클러스터에 대한 단순한 "수평적" 확장(관계형 데이터베이스의 문제)에 능하며, NoSQL 데이터베이스에서 사용하는 데이터 구조(예: 키 값, 와이드 칼럼, 그래프 또는 문서)는 관계형 데이터베이스와는 기본적으로 달라서 일부 작업들은 더 빠르게 처리합니다.
2. NoSQL 단점
대부분의 NoSQL DB는 데이터베이스 일관성이 약합니다. 이 일관성을 가용성, 분할용인(partition tolerance), 속도와 맞바꾸었습니다. 이미 사용하고 있는 SQL 쿼리 언어와 시스템을 바꿔야하는 엄청난 수고들도 진입장벽을 높이고 있습니다.
대부분의 NoSQL 스토어는 진정한 ACID 트랜잭션이 부족하지만, 일부 데이터베이스는 이러한 트랜잭션을 설계의 중심으로 만들어져 있습니다.
** ACID :
ACID(원자성, 일관성, 고립성, 지속성)는 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어 (Atomicity, Consistency, Isolation, Durability)
3. SQL DB
이미 잘 알고 계실 것이라 생각됩니다.
관계형 데이터베이스(RDB)는 테이블, 레코드 및 열(컬럼) 별로 구성된 다중 데이터 세트의 집합이며, RDB는 데이터베이스 테이블 간에 잘 정의된 관계를 확립하여, 그 테이블 간의 관계를 이용하여 정보를 더 효율적으로 전달하고 공유 합니다. 이것을 이용하여 데이터 검색, 삽입, 삭제 등이 용이합니다.
RDB는 데이터베이스 상호 작용을 위한 쉬운 프로그래밍 인터페이스를 제공하는 표준 사용자 애플리케이션인 구조화된 쿼리 언어(SQL)를 사용 합니다. RDB는 데이터 세트 매핑의 수학적 함수 개념에서 파생되었으며 Edgar. F. Codd. 에 의해 개발되었죠.
DB는 다양한 방법으로 데이터를 정리한다. (아래)
- One to One Relationship: 1:1관계
- One to Many Relationship: 1:Many 관계
- Many to One Relationship: Many:1 관계
- Many to Many Relationship: Many:Many 관계
하나의 테이블에 정보를 다 때려넣는 NoSQL과 달리, 아래 관계로 테이블을 관계를 각각 정립하여 테이블을 나누어 서로 조인해서 반환하는 형식입니다.
아래는 RDB 랭킹 입니다. (2020년 3월)
앗, 오해를 막기위해 성능 랭킹은 아닙니다. 인기도 랭킹입니다.(출처: db-engins.com)
딩그르르는 Django로 되어 있습니다. Django는 PostgreSQL(4위)를 추천하고, 더 많은 기능이 있지만, 딩그르르는 MySQL로 되어있습니다. 순전히 익숙함의 문제입니다. 참고로, MySQL과 PostreSQL은 둘다 매우 훌륭한 데이터베이스라고 생각합니다.
4. SQL 단점:
NoSQL이 나올만큼, 많은 단점이 존재 합니다만, 아래 단점이 대표적입니다.
- SQL은 스키마가 사전에 계획되어 있기때문에, 그대로만 데이터가 들어가야 합니다. 내가 넣고 싶은데로 넣을 수가 없어요. 그래서 유연하지 못합니다(NoSQL과 반대, NoSQL은 스키마가 없음)
- 데이터가 여러 테이블로 분산되어 있기떄문에 Join을 이용하여야 합니다.
- 수평적 확장이 어렵습니다. 이는 NoSQL이냐 SQL이냐의 문제는 아니고 BASE vs ACID의 문제입니다. 하지만 클러스터를 이용하여 읽기용 추가노드 등을 도입할 순 있습니다.(쓰기용 노드는 힘듭니다.. ㅜㅜ)
**수직적확장 : 서버의 사양을 올리는 확장
**수평적확장 : 여러 대의 서버를 두어 성능을 올리는 확장
5. 요약본
| SQL | NoSQL |
| 관계형 데이터베이스 관리 시스템 | 분산형 데이터베이스 관리 시스템 |
| 수직적 확장 | 수평적 확장 |
| 스키마에 의해 선정의 되어 있음 | 스키마가 없거나 다이나믹함(유연함) |
| 견고하고 단단함! 부하를 잘 견딤 | SQL보다 일반적으로 빠른 경향이 있음 |
| 역사가 깊은만큼 설치/설정이 쉬워 시간이 절약됨 | 처음 모델링 자체가 요구되지 않아서 시간이 절약됨 |
| 꾸준한 속도를 보여줌 | 때때로 응답속도가 느릴 수 있음 |
| 여러 테이블을 조인하는 등 복잡한 쿼리 사용가능 | 테이블간 관계가 없어복잡한 쿼리사용이 부적합함 |
6. 알겠습니다. 그래서 뭘 언제 사용해야 하나요?
SQL를 사용해야 할 경우:
- 복잡한 쿼리나 리포트를 만들어내야 하는 경우
- 높은 부하가 예상될 경우(딴딴함!)
- 데이터가 크게 쌓이게 될 여지가 별로 없는 경우(정말 데이터가 많으면 압도적으로 NoSQL이 빠름)
크게 = 수억개~ (사실 10억도 괜찮긴 한데..)
NoSQL을 사용해야 할 경우
- 지속적으로 새로운 기능들이 추가되고 변경되어 데이터셋을 사전정의하기 힘든경우
- 데이터 정합성이나 일관성이 최고 우선순위가 아닌경우
- 데이터가 너무너무 많을 경우
하지만, 요즘엔 둘다 사용한다는 사실! 두개의 장점을 모두 살려보아요. (Django도 가능합니다!)
