안녕하세요 성조입니다.
Data를 관리하기 위해서 DBMS를 사용하게 되는데 그중에서 SQL과(관계형 데이터베이스인 RDBMS) NoSQL의 특징들과 차이점을 정리하고자 포스팅을 진행했습니다.
개인적으로 학습을 진행하고 포스팅한 것이므로 100% 객관적이라고 판단하기 어려운 부분이 있습니다.
INDEX
1. SQL의 특징과 장단점
2. NoSQL의 특징과 장단점
3. SQL과 NoSQL의 차이점
SQL의 특징과 장단점
SQL(Structured Query Language)이란?
SQL은 IBM에서 1970년대 초에 도널드 D. 챔벌린과 레이먼드 F. 보이스가 처음 개발했으며, 실험용 RBDMMS인 SYSTEM R의 인터페이스가 기원이다. 관계형 데이터베이스에 대한 질의어 표준이다.(정형화된 언어)
Structured Query Language: SQL은 약자로 데이터를 다루기 DDL, DML, DCL, TCL 등의 명령문을 조작 및 정의하고 액세스를 하는 특수 목적을 가진 프로그래밍 언어이다.
SQL의 특징
● SQL은 수많은 RDBMS의 표준으로 채택되어 있다. 즉, RDBMS는 SQL 표준을 따라 맞춰서 개발을 진행한다. 하지만 대표적인 DBMS인 오라클, MySQL 등이 미국의 ANSI SQL이라는 표준 SQL을 잘 따르지는 않는다. 그래도 대체적으로 많은 수의 데이터베이스 관련 프로그램들은 SQL을 표준으로 채택하고 개발을 진행하고 있다.
● SQL은 이식성이 좋기 때문에 운영체제에 상관없이 데스크톱, 휴대용 장비 등에서 각각 사용되고 있던 DBMS을 타 시스템으로 이식하는데 별문제 없이 이식할 수 있다.
● SQL은 비 절차식 데이터 접근 언어이다.
⇒ 즉, 기존 프로그래밍 언어 중 C언어를 예로 들면 [소스파일] -> [컴파일러] -> [오브젝트 파일] -> [링커] -> [실행 파일] -> [실행] 구조라면 SQL은 질의문을 통해서 바로 원하는 결과를 얻어내는 언어이다.
● SQL은 레코드보다는 레코드 집합에 대한 연산을 주로 수행한다.
● SQL은 대표적으로 관계 사상(Relation Mapping)을 기초로 한 언어이다.
⇒ 관계 사상이란 input 릴레이션과 output을 릴레이션으로 매핑하는 관계형 언어이다. 여기서 말하는 관계 대수란 집합론과 1차 논리에 기반하여 관계(표)로 표현된 데이터를 취급하는 대수적인 연산 체계이다.
즉, 정리하면 관계 대수를 활용하여 input 릴레이션과 output 릴레이션을 매핑하여 원하는 구조로 특정 지을 수 있는 관계 사상을 의미한다.
● SQL은 client / server 구조를 지원한다.
예시로 평소 플랫폼 서비스에서 필터를 사용하는 경우나 조회수, 추천수 등 별로 볼 수 있는 경우 사용자가 원하는 키워드를 선택하고 검색하는 것이 client 단계이며, 출력되면서 나오는 과정까지 응답의 과정을 server에서 처리해 주는 것이다.
SQL의 장점과 단점
장점
- 엄격한 스키마를 제공하기 때문에 명확한 결과를 데이터베이스에 저장하게 되므로 큰 규모를 구축할 때 좋다.
- 큰 규모를 구축할 때 관계 사상 형태로 데이터를 매핑하여 정의하기 때문에 필요한 값들을 적재적소에 맞게 배치하면서 데이터의 중복성을 최소화하여 스키마에 맞춰서 값들을 대입할 수 있다. 즉, 중복성을 최소화하고 무결성을 유지하는데 도움 된다.
- SQL이 사용된 지 오래됐음에도 꾸준히 버전 업그레이드를 진행하고 있으며, 커뮤니티를 통해서나 인터넷에서 참조되는 스키마 형태들이 많이 존재한다.
- SQL은 Multi-Thread 방식을 지원한다.
- 데이터베이스 트랜잭션인 ACID를 지원하여 안전하게 수행된다.
단점
- RDBMS SQL에서는 엄격한 스키마를 제공하기 때문에 설계 이후에 원하는 데이터가 추가적으로 생기는 경우 원하는 부분만 수정하기 어려운 부분이 있다. 그리고 Database 설계를 전체 다 수정해야 하는 경우 설계 복잡도가 매우 높아질 수 있어서 수정이 어려운 경우가 발생할 가능성도 존재한다. 즉, SQL은 NoSQL보다 유연하지 못하고, 확장하기 어려운 부분이 있다.
- 수직적 확장은 가능하나 수평적 확장은 어렵다. 즉, 현재까지 나온 기술력 이상의 성능을 내기 어려움이 있는 것이다.
- SQL은 빅데이터 처리에 비용이 많이 소모되므로 어려움이 있다.
- 관계 매핑을 기본으로 하기 때문에 join을 통해서 얻어야 하는 결괏값들이 있는 경우 물고 물리는 복잡한 쿼리문이 발생할 수 있다.
수직적 확장은 서버가 기존보다 더 많은 자원을 처리하기 위해서 성능을 올리는 확장의 개념이다.
수평적 확장은 여러 대의 서버 컴퓨터를 가지고 성능을 향상시키는 방법인데 현재까지 나온 컴퓨팅 성능보다 더 높은 성능을 낼 수 있게 해주는 장점이 존재하는 방법이다.
NoSQL의 특징과 장단점
NoSQL(non SQL OR non relational)이란?
1998년 카를로 스트로찌(Carlo Strozzi)는 기존 RDBMS에서 채택하던 표준 SQL 인터페이스를 채용하지 않고, 자신의 경량 오픈 소스(Open Source) 관계형 데이터베이스를 NoSQL이라 명명하면서 처음으로 시작했다. 하지만 카를로 스트로찌의 홈페이지에 접속하면 1991년 3월 "Operator-Stream Paradigm"을 기반으로 작업을 했다는 얘기를 보면 기존보다는 조금 더 빠른 기간에 설계가 진행됐음을 알 수 있다. 또한 카를로 스트로찌는 본인의 홈페이지에 no sequel(노시퀄)이라고 부르는 것이 더 올바른 표현이라고 생각한다고 기재했다.
NoSQL의 시작은 2009년 초에 요한 오스칼손(Johan Oskarsson)와 그의 소속인 라스트 FM의 동료들이 오픈 소스 분산 데이터베이스를 NoSQL로 부르는 것이 본격적으로 진행되면서 시작됐다.
NoSQL는 기존 SQL와 다르게 릴레이션 형태가 아니므로 정형 데이터가 아닌 비정형 데이터를 처리할 수 있는 메커니즘을 제공하며, 스키마를 가지고 있지 않기 때문에 유연한 확장을 지원한다. Not Only SQL이라고도 부르며 SQL 외에도 데이터를 저장할 수 있는 다양한 방법들이 있다는 것이 NoSQL의 모토이다.
NoSQL의 특징
기존 SQL과 다르게 NoSQL은 스키마를 정의하지 않고, 필요한 값들을 정의하여 사용하는 것이 가장 큰 특징이다.
크게 4가지 모델로 나뉘며, 다음의 성능표와 이론을 가지고 있다.
데이터 모델 | 성능 | 확장성 | 유연성 | 복잡성 | 기능 |
Key-value(키-값) | 높음 | 높음 | 높음 | 없음 | 가변적 (없음) |
Document(도큐먼트 지향) | 높음 | 가변적 (높음) | 높음 | 낮음 | 가변적 (낮음) |
Column-family(컬럼 지향) | 높음 | 높음 | 준수 | 낮음 | 최소 |
Graph(그래프 데이터베이스) | 가변적 | 가변적 | 높음 | 높음 | 그래프 이론 |
● Key- value
Key-value는 해시 테이블을 사용하여 키와 값을 한 쌍으로 저장하는 방식이며, 키와 값이 알려지지 않은 경우에 적합한 모델이다.
Key-value는 분할성이 큰 모델이며, 비교적 가장 단순한 NoSQL 모델이라서 타 유형의 데이터베이스로 어려운 범위까지 수평 확장을 진행할 수 있는데 그로 인해서 IOT서비스와 같은 사례에는 키-값 데이터 모델이 조금 더 적합하다는 모델로 평가된다.
간단한 API만을 제공하기 때문에 배우기는 쉽지 put, get, delete의 질의문만 제공하므로 값의 내용을 사용한 쿼리가 불가능하다는 단점이 존재한다. 그래도 간단한 API를 제공하는 만큼 질의 속도가 빠른 편임을 인지하는 것이 좋을 것 같다.
Key-value 모델을 사용하는 NoSQL 데이터베이스로는 Memcached, Riak, Redis, Amazon Dynamo DB, LevelDB 등이 있다.
● Document
Key-value와 다르게 Key와 Document의 형태로 저장하는 방식이다. 키-값과 동일하게 키를 가지고 있지만. 다른 점으로는 키-문서 형태를 가진다는 것이다. 문서 형식은 다른 모델들을 포함하는 상위 집합이다.
Document는 키와 값을 1:1 매핑하는 것이 아닌 JSON(JavaScript Object Notation) 형태의 객체와 비슷한 형태로 저장이 가능하다. 일반적으로 사용되는 숫자, 문자열, 배열, 불리언, 객체 등의 유형을 저장할 수 있으며, 하나의 객체를 여러 개의 테이블에 저장할 필요가 없어진다.
키-값을 저장하는 것이 1:1 느낌이라면 Document는 JSON 형태로 저장하기 때문에 1:n의 데이터 형태로 저장을 진행할 수 있다.
수평적 확장이 좋은 모델이라서 대용량 데이터를 읽고 쓰기에도 좋은 모델이다.
카탈로그 정보를 효율적, 효과적으로 저장할 수 있는데 이 카탈로그는 인터넷 전자 상거래 시스템, SNS 플랫폼에서 데이터를 얻을 때 유용하다.
Document 방식은 개발자가 원하는 기능들을 만들 때 효율적으로 빠르게 만들어내기 좋은 직관적인 데이터 모델이다.
Document 모델을 사용하는 NoSQL 데이터베이스로는 MongoDB, CouchDB, MarkLogic 등이 있다.
● Column-family OR Wide Column
집합 - 지향 모델로 위의 두개가 Key-value, Document를 활용해서 작업을 진행했다면 Document는 대량의 읽고, 쓰기가 장점이라면 Column-family 모델은 대용량 데이터를 저장하는 것이 장점이며, 쿼리 패턴을 예측할 수 있는 모델이다. 또한 IOT의 데이터와 사용자 프로필 데이터를 저장하는데 자주 사용된다.
또한 기존에 Value, Document를 이용하여 값을 저장했다면 Column-family 모델은 키에서 필드를 결정하게 된다. Colunm에 여러 개의 값을 저장할 수 있는데 다.
질의는 Row, Column-famliy, Column-name을 통해서 수행된다.
Column-family 모델을 사용하는 NoSQL 데이터베이스로는 HBase, Cassandra, Hypertable 등이 있다.
● Graph
그래프 모델은 노드와 엣지에 데이터를 저장하는 형태이다. 노드에는 일반적으로 객체에 대한 정보가 저장되며, 엣지에는 노드 간의 관계에 대한 정보들이 저장된다.
자주 사용되는 모델로는 소셜 네트워크, 사기 탐지, 지식 그래프, 권장 엔진과 같은 패턴들을 찾는 그래프가 존재한다.
Graph 모델을 사용하는 NoSQL 데이터베이스로는 Neo4j와 Giraph가 있다.
NoSQL의 장점과 단점
장점
- 빅데이터를 기존 SQL에 비해서 더 작은 비용으로 처리할 수 있다.
- 유연성, 확장성, 고성능, 고기능성이 존재한다.
- 수평적 확장(Scale-out)이 가능하며, 이로 인하여 수직적 확장(Scale-up)에 비해서 비용 절감된다.
- 스키마를 정의하지 않고 사용할 수 있다.
- 지속적으로 기능이 추가되면서 변동이 심한 경우 사용하지 좋다.
- 데이터 구조가 단순하고 양이 많을 때 사용하기 좋다.
- 데이터베이스의 데이터가 정합성과 일관성이 우선순위가 아닌 확장성, 유연성 등의 특징이 우선순위인 경우 사용하기 좋다.
- 정확한 데이터 구조를 알 수 없는 상태에서 변경이나 확장될 가능성이 존재할 때 사용하면 좋다.
- 빠르게 개발을 진행해야 하는 경우 적합하다.
- 쿼리의 성능이 빠르다.
단점
- NoSQL은 관계가 정의되지 않는 모델이라서 Join을 사용할 수 없다.
- 스키마를 정의하지 않았기 때문에 데이터 중복이 발생하여 중복성 최소화를 만족시키기 어려울 가능성이 있다.
- 명확한 데이터 구조를 가지기 어려울 수 있다.
- 구현 난이도가 매우 높을 수 있다.
- 복잡하고 동적인 쿼리를 다루기 어렵기 때문에 데이터 구조가 복잡한 경우 SQL이 더 적합하다는 평가가 많이 존재한다.
SQL과 NoSQL의 차이점
설명 | SQL | NoSQL 데이터베이스 |
개발 역사 | 1970년대에 처음 개발되었으며, 데이터의 중복성 최소화에 중점을 두고 개발됐다. | 2009년대 초반에 요한 오스칼 손, 라스트 FM에서 언급되면서 시작했고, 확장에 중점을 둔 애자일 방식의 구동되는 방향으로 개발됐다. |
대표적인 시스템 | Oracle, MySQL, Microsoft SQL Server, PostgreSQL | Amazon Dynamo DB, Redis, MongoDB, Couch DB, HBase, Cassandra, Neo4j |
데이터 저장 형태 | 행과 열이 고정된 테이블 형태로 데이터가 저장된다. | 키-값, JSON 문서 형태, 키-값, 와이드 열 - 행과 동적 열이 있는 테이블 형태, 노드와 엣지로 이뤄진 형태 |
주요 목적 | 범용(일반적)으로 사용된다. | 범용으로 사용되며, 빅데이터와 같은 대용량 데이터를 처리할 때 또는 쿼리 패턴을 갖는 대용량 데이터, 서로 연결된 데이터끼리의 관계 분석과 탐색을 진행할 때, 단순 조회 쿼리를 진행할 때 사용된다. |
확장 방법 (스케일링, Scale-up, Scale-out) |
수직적 확장(Scale-up) 기존 컴퓨터 보다 더 좋은 컴퓨터 한 대를 업그레이드하여 성능을 올린다. |
수평적 확장 (Scale-out) 기존 컴퓨터와 동일한 성능의 컴퓨터도 사용 가능하며, 여러 대의 컴퓨터를 하나로 합쳐서 사용하는 원리이다. |
스키마 (Schemas) |
스키마가 존재하며, 엄격한 스키마 구조를 가지기 때문에 데이터에 대한 중복성 최소화와 무결성에 대해서 초점이 맞춰진 데이터베이스이다. | 스키마 구조가 따로 없는 유연한 구조를 가진다. 그렇기 때문에 확장성이 기존 관계형 데이터베이스보다 좋다. |
다중 트랜잭션 ACID (Multi-Record ACID Transactions) |
기본적으로 ACID을 지원한다. | 대부분 다중 레코드 ACID 트랜잭션을 지원하지 않지만 MongoDB와 같이 특정 데이터베이스에서 기능을 지원한다. |
조인(Joins) | 자유롭게 사용 가능하며, 대부분 필수적으로 사용된다. | 기본 NoSQL은 join기능을 제공하지 않지만 Redis, MongoDB등의 데이터베이스는 join 기능을 지원한다. 하지만 직접 매핑을 초점으로 이뤄내기 때문에 대체적으로 사용되지는 않는다. |
데이터 - 객체 매핑 (Data to Object Mapping) |
관계형 데이터베이스는 ORM을 통하여 객체-릴레이션 매핑을 필요로 한다. | ORM이 필요하지 않은 모델이다. 프로그래밍 언어에 맞게 데이터 구조를 직접 매핑되는 형태이다. |
참조 자료들을 기반으로 학습하고 정리한 내용입니다.
올바르지 못한 정보를 포함하고 있거나 오타가 있는 경우 등 관련 내용을 댓글로 남겨주시면 감사드리겠습니다!
다음 포스팅 때 뵙겠습니다!
- 참조 자료 -
https://www.mongodb.com/scale/nosql-vs-relational-databases
https://www.mongodb.com/ko-kr/compare/mongodb-mysql
https://ko.wikipedia.org/wiki/NoSQL
https://www.oracle.com/kr/database/what-is-a-relational-database/
https://ko.wikipedia.org/wiki/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4
https://www.oracle.com/kr/database/what-is-database/
http://www.ktword.co.kr/test/view/view.php?m_temp1=282
https://ko.wikipedia.org/wiki/%EA%B4%80%EA%B3%84%EB%8C%80%EC%88%98
https://ko.wikipedia.org/wiki/ACID
https://aws.amazon.com/ko/nosql/
https://www.mongodb.com/ko-kr/nosql-explained
http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page
https://web.archive.org/web/20110716174012/http://blog.sym-link.com/2009/05/12/nosql_2009.html
https://www.mongodb.com/ko-kr/nosql-explained/nosql-vs-sql
'Database > Database' 카테고리의 다른 글
[Database] 정규화란? (0) | 2022.04.28 |
---|---|
[Database] DML(Data Manipulation Language)이란? (Lightly) (0) | 2022.04.26 |
[Database] 함수적 종속성 FD (Funcional Dependency) (2) | 2022.04.04 |
[Project]pet and pet, Database[MySQL], schema (0) | 2022.03.05 |
[파이널 프로젝트] pet and pet erd (2) | 2022.02.26 |