Goal
- NoSQL를 사용하는 이유를 이해한다.
- NoSQL과 RDB(관계형 데이터 베이스)의 차이를 이해한다.
NoSQL이란 ?
Not only SQL 혹은 Non-Relational Operational Database 약자로 비관계형 데이터베이스를 지칭한다.
등장 배경
NoSQL은 점점 빅데이터의 등장(모바일, 웹 시장의 데이터)으로 인해 데이터와 트래픽이 기하급수적으로 증가함에 따라 RDBMS에 단점인 성능을 향상시키기 위해서는 장비가 좋아야 하는 Scale-Up의 특징이 비용을 기하급수적으로 증가시키기 때문에 데이터 일관성은 포기하되 비용을 고려하여 여러 대의 데이터에 분산하여 저장하는 Scale-Out을 목표로 등장하였다.
이 다양한 형태의 저장기술은 RDBMS 스키마에 맞추어 데이터를 관리해야 된다는 한계를 극복하고 수평적 확장성(Scale-out)을 쉽게 할 수 있다는 장점을 가지고 있습니다.
즉,
- 기존의 RDBMS가 Consistency와 Availability에 중점을 두었다면 NoSQL은 Scalability와 Availability에 중점
특징
- NoSQL에서는 RDBMS와는 달리 테이블 간 관계를 정의하지 않는다. (비관계형)
- 관계를 정의하지 않아 일반적으로 테이블 간 Join 불가능
- RDBMS에 비해 대용량 데이터 저장 가능
- 주로 빅데이터, 분산 환경 시스템에서 대용량 데이터 처리에 적합
- 분산형 구조로 설계
- 여러 곳의 서버에 데이터를 분산 저장 하여 서버에 장애 발생시, 데이터 유실 혹은 서비스 중지 발생을 예방하기 위함
- 느슨한 스키마 제공 (고정되어 있지 않은 테이블)
- 테이블(컬렉션)의 스키마가 유동적이고 데이터를 저장하는 컬럼이 각기 다른 이름과 다른 데이터 타입을 갖는 것이 허용됨
저장 기술
- Key-Value Database
- Key와 Value의 쌍으로 저장된다. Key는 Value에 접근하기 위한 용도로 사용됨.
- 값은 어떠한 형태의 데이터라도 담을 수 있다. 심지어는 이미지나 비디오도 가능
- 질의 속도가 빠르다 = 검색 최적화
- Redis, Riak, Amazon Dynamo DB 등이 있다.
- Document Database
- Key와Document의 형태로 저장된다. Key-Value 모델과 다른 점이라면 Value가 계층적인 형태인 도큐먼트로 저장된다는 것이다. 객체지향에서의 객체와 유사하며, 이들은 하나의 단위로 취급되어 저장된다. 다시 말해 하나의 객체를 여러 개의 테이블에 나눠 저장할 필요가 없어진다는 뜻
- 객체를 Document의 형태로 바로 저장이 가능하기에 객체-관계 매핑이 필요가 없다.
- 검색에 최적화
- 쿼리가 달라 쿼리가 번거로움
- 질의 결과는 JSON이나 xml 형태로 출력
- MongoDB, CouthDB
- Wide Column Database
- Column-family Model 기반의 Database이며 키에서 필드를 결정한다
- 키는 Row(키 값)와 Column-family, Column-name을 가진다. 연관된 데이터들은 같은 Column-family 안에 속해 있으며, 각자의 Column-name을 가진다
- 관계형 모델로 비유하자면 어트리뷰트가 계층적인 구조를 가지고 있음
- 이렇게 저장된 데이터는 하나의 커다란 테이블로 표현이 가능
- 질의는 Row, Column-family, Column-name을 통해 수행된다.
- HBase, Hypertable
- Column-family Model 기반의 Database이며 키에서 필드를 결정한다
- Graph Database
- 데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장
- 데이터 간의 관계가 탐색의 키일 경우에 적합
- 페이스북이나 트위터 같은 소셜 네트워크에서(내 친구의 친구를 찾는 질의 등) 적합
- 연관된 데이터를 추천해주는 추천 엔진이나 패턴 인식 등의 데이터베이스로도 적합
- Neo4J
- 데이터를 Node와 Edge, Property와 함께 그래프 구조를 사용하여 데이터를 표현하고 저장
NoSQL vs RDBMS
NoSQL
장점
- NoSQL에서는 스키마가 없기 때문에 유연하며 자유로운 데이터 구조를 가질 수 있다
- 언제든 저장된 데이터를 조정하고 새로운 필드를 추가 가능
- 데이터 분산이 용이하며 성능 향상을 위한 Saclue-up 뿐만이 아닌 Scale-out 또한 가능
- 빅데이터 처리에 용이하다
단점
- 데이터 중복이 발생할 수 있으며 중복된 데이터가 변경 될 경우 수정을 모든 컬렉션에서 수행을 해야한다
- 스키마가 존재하지 않기에 명확한 데이터 구조를 보장하지 않으며 데이터 구조 결정가 어려울 수 있다
- 많은 인덱스를 사용하려면 충분한 메모리가 필요하다.
데이터 일관성이 항상 보장되지 않는다.
사용 권장 시점
- 문서나 JSON과 같은 비정형 데이터에 더 효과적
- 정확한 데이터 구조를 알 수 없고 데이터가 변경/확장이 될 수 있는 경우
- Update가 많이 이루어지지 않는 시스템
- 중복이 발생할 가능성 때문, 데이터 변경시 모든 컬렉션에서 수정 해야하는 번거로움 때문
- 막대한 데이터를 저장해야 해서 Database를 Scale-Out를 해야 되는 시스템
RDBMS
장점
- 정해진 스키마에 따라 데이터를 저장하여야 하므로 명확한 데이터 구조를 보장하고 있다.
- 또한 관계는 각 데이터를 중복없이 한 번만 저장할 수 있다.
단점
- 테이블간테이블 간 관계를 맺고 있어 시스템이 커질 경우 JOIN문이 많은 복잡한 쿼리가 만들어질 수 있다.
- 성능 향상을 위해서는 서버의 성능을 향상 시켜야하는 Scale-up만을 지원합니다. 이로 인해 비용이 기하급수적으로 늘어날 수 있다.
- 스키마로 인해 데이터가 유연하지 못하다. 나중에 스키마가 변경 될 경우 번거롭고 어려울 뿐 아니라 전체 시스템을 중단해야 한다.
사용 권장 시점
- SQL 데이터베이스는 다중 행 트랜잭션에 더 효과적
- 데이터 구조가 명확하며 변경 될 여지가 없으며 명확한 스키마가 중요한 경우
- 중복된 데이터가 없어(데이터 무결성) 변경이 용이하기 때문에 관계를 맺고 있는 데이터가 자주 변경이 이루어지는 시스템
참고
https://www.integrate.io/ko/blog/the-sql-vs-nosql-difference-ko/
https://khj93.tistory.com/entry/Database-RDBMS%EC%99%80-NOSQL-%EC%B0%A8%EC%9D%B4%EC%A0%90
'DB' 카테고리의 다른 글
[Database] DML, DCL, DDL, TCL (0) | 2023.08.16 |
---|