[NoSQL] NoSQL을 사용하는 이유: RDBMS(SQL) VS NoSQL

💡 본 문서는 'NoSql을 사용하는 이유와 NoSQL의 종류 및 활용'에 대해 정리해놓은 글입니다.
프로젝트 내에서 RDB와 NoSql로 나눠서 사용하고 있었는데, 최근 들어 '왜 나누어 사용하고 있지?'라는 생각과 함께 NoSql에 관심이 가기 시작했습니다. 리서치하던 중 다양한 종류의 NoSQL이 있다는 것을 확인할 수 있었고 정보를 공유하고자 해당 글을 작성하였으니 참고 부탁드립니다. 

1. RDBMS의 한계: SQL

1.1 Relational DataBase(RDB) 란?

관계형 데이터 모델을 기초로 둔 데이터베이스로 데이터 간의 상관관계에서 개체 간의 관계를 2차원 테이블 형태로 표현합니다. 이를 관리하는 시스템을 Relational DataBase Management System(RDBMS)라 합니다.

1.2 RDB 특징 (feat. 트렌젝션)

RDB는 관계가 중요하기에 일련의 과정 중 일부만 성공하면 안되기에 모두 적용(Commit)되거나 모두 취소(Rollback)되어야 합니다. 따라서 여러 과정을 하나의 묶음인 '트렌젝션'이라는 단위를 통해 관리합니다.

이에 문제가 생길 경우 데이터의 부정합이 생길 수 있으며, 트렌젝션의 스케줄 관리를 잘 못하면 데드락에 빠질 수 있습니다.

• 트랜잭션에 대한 자세한 설명은 [DB] RDB 트랜잭션 (feat. 트랜잭션 격리 수준) 를 참고하시기 바랍니다.

1.3 RDB 장점 및 사용해야 하는 이유

대부분의 경우에 관계형 데이터베이스를 사용하는 것이 안정적입니다. 최근 NoSQL이 나오며 영역을 점점 잃고 있는데, 그래도 다음과 같은 장점이 있어 '명확한 스키마가 중요한 경우'나 '관계를 맺고 있는 데이터가 자주 변경되는 경우' 사용됩니다.

• 명확하게 정의된 스키마, 데이터 무결성 보장
• 관계는 각 데이터를 중복없이 한 번만 저장
• 데이터의 일관성을 보증할 수 있음
• 복잡한 형태의 쿼리도 가능(Join 등)

1.4 RDB 단점

• 스키마에 준수하지 않는 레코드는 추가할 수 없음
• 한 객체의 데이터를 여러개의 테이블로 나누어 표현해야하기에 설계 및 비용이 들어감(normalization)
• 칼럼을 자유롭게 추가하려면 테이블을 변경시키거나 새로운 테이블을 만들어야 함
• 관계를 맺고 있기 때문에, JOIN문이 많은 매우 복잡한 쿼리가 만들어질 수 있음
• 수평적 확장이 어렵고, 대체로 수직적 확장만 가능(즉 처리의 한계를 직면하게 됨)
• 대량의 데이터를 입력할 경우나 조회할 경우 성능이 저하 될 수 있고 Sharding과 Replication을 구축하는 비용이 큼

2. NoSQL을 사용하는 이유

2.1 NoSQL(Not only SQL)이란?

NoSQL 데이터베이스는 특정 데이터 모델에 대해 특정 목적에 맞추어 구축되는 데이터베이스로서 현대적인 애플리케이션 구축을 위한 유연한 스키마를 갖추고 있습니다. NoSQL 데이터베이스는 개발의 용이성, 기능성 및 확장성을 널리 인정받고 있습니다. 

2.2 NoSQL 데이터베이스의 작동 방식

NoSQL 데이터베이스에서는 데이터의 액세스 및 관리를 위해 다양한 데이터 모델을 사용합니다. 이러한 데이터베이스 유형은 큰 테이터 볼륨, 짧은 지연 시간과 유연한 데이터 모델이 필요한 애플리케이션에 최적화되었으며, 이는 다른 데이터베이스의 데이터 일관성 제약 일부를 완화함으로써 이루어집니다.

• SQL 데이터베이스에서의 관계는 기본 및 외래 키 제약 조건으로 정의됩니다. 또한 관계형 모델은 중복성을 줄이도록 정규화되고 일반적으로 저장에 최적화된 데이터베이스에서 데이터베이스가 테이블 사이에서 참조 무결성을 실현할 수 있도록 고안되었습니다.

• NoSQL 데이터베이스에는 보통 JSON 으로 단일 문서 내에 속성으로 저장됩니다. 이 모델에서 데이터는 직관적 개발과 수평 확장성에 최적화됩니다.

2.3 NoSQL 장점 및 사용해야 하는 이유

NoSQL 데이터베이스는 탁월한 사용자 경험을 제공하기 위하여 유연성과 확장성을 비롯해 고성능의 매우 기능적인 데이터베이스를 필요로 하는 모바일, 웹이나 게이밍과 같은 다양한 현대적인 애플리케이션에 적합합니다.

• 유연성 : 스키마 선언 없이 필드의 추가 및 삭제가 자유로운 Schema-less 구조
• 확장성 : 스케일 아웃(노드 추가, 파티셔닝 등)에 의한 서버 확장이 용이
• 고성능 : 대용량 데이터를 처리하는 성능이 뛰어남
• 가용성 : 여러 대의 백업 서버 구성이 가능하여 장애 발생 시에도 무중단 서비스가 가능(분할 용인)

2.4 NoSQL 단점

• 데이터베이스 일관성에 약함
• key값에 대한 입출력만 지원함
• 스키마가 정해져 있지 않아, 데이터에 대한 규격화가 되어 있지 않음
• 데이터 중복으로 인한 수정 작업의 느리고 번거로움

2.5 NoSQL 사용 시 효율적인 상황

• 아주 낮은 응답 지연시간(latency) 필요
  • 데이터에 대한 캐시가 필요한 경우
  • 배열 형식의 데이터를 고속으로 처리할 필요가 있는 경우
• 정확한 데이터 구조를 알 수 없거나 변경 / 확장 될 수 있는 경우
• 데이터(JSON, YAML, XML등)를 직렬화나 역직렬화 해야할 경우
• 읽기(read)처리를 자주하지만, 데이터를 자주 변경(update)하지 않는 경우 (즉, 한번의 변경으로 수십 개의 문서를 업데이트 할 필요가 없는 경우)

 

3. SQL vs NoSQL 비교

수 십 년간, 애플리케이션 개발을 위해 가장 많이 사용된 데이터 모델은 Oracle, DB2, SQL Server, MySQL, PostgreSQL과 같은 관계형 데이터베이스에서 사용하는 관계형 데이터 모델이었습니다. 2000년대 중반에서 말에 이르러서야 다른 데이터 모델들이 채택되고 사용되는 현상이 눈에 띄기 시작했습니다. 이러한 새로운 데이터베이스와 데이터 모델 등급을 차별화하고 분류하기 위해 "NoSQL"이란 용어가 만들어졌습니다. 흔히 "NoSQL"이란 용어는 "비관계형"과 같은 의미로 사용됩니다.

3.1 SQL vs NoSQL 비교

	SQL 데이터베이스	NoSQL 데이터베이스
중점사항	- 데이터 일관성을 위한 트랜잭션의 안전한 수행	- 서비스 가용성과 데이터 처리 성능 향상
최적의 워크로드 (적합 업무)	무결성 및 일관성 중시 - 데이터 무결성 및 일관성이 중요한 트랜잭션 업무 - 온라인에서 다양한 집계 및 통계를 분석하는 업무 - 복잡한 계산 및 실시간 데이터 정합성이 필요한 업무	성능 및 가용성 중시 - 오프라인에서 정형 및 비정형 데이터 분석 업무 - 초당 동시 처리가 중요한 업무(낮은 지연시간) - 로그 및 이력 등의 단순 기록형 업무
데이터 모델	- 엔티티 및 엔티티 간의 관계를 정의함(참조 무결성) - 엔티티 정의 시 정규화에 의한 설계가 중요함 - 테이블, 칼럼 등 DB 요소에 대한 스키마를 엄격히 관리함	- 서비스에 맞는 DB 선택이 중요함(키-값, 문서, 그래프 등) - 반정규화에 의한 설계를 기본으로 함 - 비정형화 스키마 구조로 미리 스키마를 선언하지 않음
속성	ACID (Atomicity, Consistency, Isolation, Durability)  Atomicity: 트랜잭션은 최소의 업무 단위를 완벽하게 실행하거나 혹은 전혀 실행하지 않아야 함. Consistency: 트랜잭션이 커밋되면 데이터가 데이터베이스 스키마를 준수해야 함 Isolation: 실행 중인 트랜젝션의 중간에 다른 트랜젝션이 접근할 수 없음 Durability: 예기치 못한 시스템 장애시 마지막으로 상태로 복구함.	BASE (Basically Available, Soft State, Eventually Consistent) Basically Available: Master 서버에 장애 발생 시에도 여러 Slave 서버로 인해 무중단 서비스가 가능함(가용성) Soft State: 외부의 개입이 없어도 정보가 변경될 수 있으며, 일관성(Consistency)이 유지되지 않는 경우 일관성을 위해 데이터를 자동으로 수정 가능함 Eventually Consistent: (장애 발생시)일시적으로 일관적이지 않은 상태가 되어도 일정 시간 후 일관적인 상태가 되어야한다는 의미
성능	- 성능 향상을 위해서 최적화 작업이 필요함	- 클러스터 크기, 네트워크 및 애플리케이션에 의해 성능이 결정
인터페이스	- SQL을 통해서만 데이터 저장 및 검색이 가능함	- 쿼리 외 다양한 API를 통한 데이터 저장 및 검색이 가능함 - 파티션 키를 사용하면 앱에서 키-값, 열 세트 또는 일련의 앱 객체 및 속성을 포함하는 반정형 문서를 검색가능
장점	- 데이터 중복 배제로 데이터 이상 발생 및 용량 증가를 최소화함	- 쿼리 프로세싱이 단순화 되어 대용량 데이터 처리 성능이 향상
단점	- 조인이 복잡한 경우 쿼리 프로세싱도 복잡해져 성능이 저하됨	- 데이터 중복에 의해 데이터 일관성이 저하되고 용량이 증가함
확장	- 일반적으로 하드웨어의 계산 성능을 높이거나 읽기 전용 워크로드의 복제물을 추가함으로써 확장됨	- 일반적으로 거의 무제한적인 범위에서 일관된 성능을 제공하는 처리량 제고를 위해 분산형 아키텍처를 사용해 액세스 패턴이 확장 가능함

 

참고

• [AWS] NoSQL이란?: https://aws.amazon.com/ko/nosql/
• [Wiki] NoSQL: https://ko.wikipedia.org/wiki/NoSQL
• [TIBCO] 인메모리 데이터베이스란 무엇입니까?: https://www.tibco.com/ko/reference-center/what-is-an-in-memory-database 
• [mongoDB] What is MongoDB?: https://www.mongodb.com/docs/manual/
• [Oracle] 관계형 데이터베이스(RDBMS)란?: https://www.oracle.com/kr/database/what-is-a-relational-database/
• mongoDB Story 1: mongoDB 정의와 NoSQL: https://meetup.toast.com/posts/274