이번 포스팅에는
관계형 데이터 베이스(Relational Database)인 SQL 과
비관계형 데이터 베이스(Non-relational Database) 인 NOSQL의
차이점과 장단점을 다루고 있습니다.
정리는 모든것의 기초이다.-- 에드먼드 버크
[ Introduction ]
웹 어플리케이션을 개발을 시작하면,
어떤 데이터베이스를 선택할지 고민하게 되는 순간이 오게됩니다.
마치 밀린일을 하나씩 하다, 정신을 차려보면 어느새 책상위에 문서더미가
쌓여있는것을 발견하고 나름의 규칙에 맞게끔 정리하는 것처럼
데이터를 어떻게 저장하고 관리할지는 매우 중요한 문제입니다.
일반적으로 Spring에서 개발을 할때는 MySQL을,
Node.js에서는 MongoDB 를 주로 사용하지만,
이는 프레임워크에 따라 함께 결정되는 것은 아닙니다.
따라서 프로젝트를 진행하기에 앞서 적절한 데이터베이스를 선택해야하고,
이에 대하여 알아보도록 하겠습니다.
0. SQL (Structured Query Language)
SQL은 관계형 데이터 베이스(RDB)로써 이를 사용하면
RDBMS에 데이터를 저장,수정,삭제 및 검색할 수 있습니다.
데이터는 테이블에 레코드로 저장되며, 각 테이블마다 명확하게 정의된 구조가 있습니다.
해당 구조는 필드의 이름과 데이터 유형으로 정의됩니다.
이러한 구조와 제약조건에 대한 정확한 명세를 스키마라고 합니다.
따라서 스키마를 준수하지 않은 레코드는 테이블에 추가할 수 없습니다.
다시말해, 스키마를 수정하지 않는 이상 정해진 구조에 맞는 레코드만 추가가 가능한것이
관계형 데이터베이스의 큰 특징중 하나라고 할 수 있겠습니다.
또한, 데이터의 중복을 피하기위해 아래의 그림과 같이 해당 관계를 이용합니다.
- RDB의 특징
-
테이블(Table)마다 스키마(Schema)를 정의해야 한다.
-
데이터는 정해진 데이터 스키마에 따라 테이블에 저장된다.
-
데이터는 관계를 통해 여러 테이블에 분산된다.
-
데이터 타입과 제약(Constraint)를 통해서 데이터의 정확성을 보장합니다.
-
성능을 높이려면 하드웨어(H/W)를 고성능으로 교체해줘야 합니다. (Scale Up)
-
고성능 하드웨어는 Cost가 많이 발생하기때문에, RDB의 성능을 높이거나 확장하는데
제약이 있게되고 이로인해 확장성에 좋지않습니다.
1. NOSQL (Non - Structured Query Language or Not Only SQL )
NOSQL은 기존의 전통적인 RDB 보다 일관성을 좀 더 내려놓고, 확장성을 더 높여 데이터의 저장,수정,삭제,조회를 위한 메커니즘을 제공하기 위해 등장하였습니다.
따라서 NOSQL은 스키마도 존재하지 않고 관계도 없는 것이 특징입니다.
SQL에서 레코드에 해당하는 개념을 문서(document)로 저장합니다. 따라서 문서형 데이터베이스에 해당합니다.
- Non-RDB의 특징
-
RDB의 확장성의 제약을 해결하기 위해 등장하였습니다.
-
분산 컴퓨팅을 이용하여 상대적으로 더 낮은 cost로 DB의 성능을 끌어 올릴 수 있습니다.(Scale Out)
-
스키마 없이 동작하며, 관계도 없기에 하나의 거대한 단일 테이블로 구성됩니다.
-
NOSQL의 방식으로는 key-value, Document, Column-family, Graph가 있습니다.
-
구조에 대한 정의를 변경할 필요가 없어 필드를 추가하는 것이 자유롭습니다.
-
복잡한 SQL 쿼리문을 사용하지 않습니다.
-
빅데이터(구조 변경이 용이, 정형-반정형 데이터의 혼재, 추가/수정/삭제가 더 빈번함, 정확성보다는 데이터의 양이 중요) 처리에 주로 사용됩니다.
2. 아니 그래서 알겠고 어떤게 더좋은건데?
죄송하지만 정답은 없습니다😂
어떤 DB가 더 탁월하고 더 좋다기 보다는 둘다 훌륭한 솔루션이기에
상황에 맞게 적합한 DB를 사용하는 것이 중요합니다.
따라서 두 DB의 장단점을 비교해보며 어떤상황에 어떤 DB가 적합한지 알아보겠습니다.
SQL의 장단점
🟢 명확하게 정의된 스키마를 통해 데이터의 무결성을 확보할 수 있습니다.
🟢 관계는 각 데이터를 중복없이 한번만 저장하게 해줍니다.
🔴 제약관계로 인해 데이터의 관계가 종속적이라 유연하지 못합니다.( 데이터 스키마를 사전에 계획하고 추후 수정이 번거롭습니다.)
🔴 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있습니다.
🔴 대체로 수직적 확장만 가능하며 확장에 있어 비용문제가 발생할 수 있습니다.
NoSQL의 장단점
🟢 스키마가 없어서 유연합니다. 언제든지 저장된 데이터를 조정하고 새로운 필드를 추가할 수 있습니다.
🟢 데이터를 읽어오는 속도가 빨라지고, 애플리케이션이 필요로 하는 형식에따라 자유로운 방식으로 저장됩니다. (비정형 데이터 또한 저장가능)
🟢 수직 및 수평 확장이 가능해서 애플리케이션이 발생시키는 모든 읽기/쓰기 요청처리가 가능합니다.
🔴 유연성으로 인해 데이터 구조 결정이 미뤄질 수 있습니다.
🔴 데이터 중복을 계속 업데이트 해주어야 합니다.
🔴 데이터가 여러 컬랙션에 중복되어 있기 때문에 수정시 모든 컬랙션에서 수정을 해줘야 합니다.
(SQL에서는 중복 데이터가 없으므로 한번의 삭제 쿼리문 만으로 해결할 수 있음)
3. 아니 그래서 진짜 알겠고 어떤걸 써야하는데?
Using SQL DB is Better !!
🔵 관계를 맺고 있는 데이터가 자주 변경되는 어플리케이션의 경우
🔵 변경될 여지가 없고, 명확한 스키마가 사용자와 데이터에게 중요한 경우
Using NoSQL DB is Better !!
🟡 정확한 데이터 구조를 알 수 없거나 변경/확장 될 수 있는 경우
🟡 읽기를 자주 하지만, 데이터 변경은 자주 없는 경우
🟡 데이터 베이스를 수평으로 확장해야 하는 경우 (막대한 양의 데이터를 다뤄야 하는 경우)
[ Conclusion ]
RDB와 Non-RDB가 왜 등장했는지를 생각해보면 어떤 상황에 어떤 DB를
사용하는지 좀 더 명확하게 판단할 수 있을것입니다.
TMT방식으로 RDB와 Non-RDB의 역사를 곱씹어보며 포스팅을 마무리하겠습니다.
Once upon a time~
초기의 데이터 베이스 시스템은 1970대에 에드거 F.커드가 RDB를 제안하기 전까지 플랫파일, 계층형, 네트워크 데이터 관리시스템이 존재했고 이들의 단점은 데이터 베이스 구조가 바뀔때 프로그램도 변경해야한다는 것이었습니다.
So ~
이는 DB 논리구조가 테이프나 디스크에 물리적으로 데이터가 저장되는 방식이 "독립적이지 못했기" 때문입니다. 구조적 독립성을 보장해주는 것이 RDB의 주요 개선점중 하나입니다.
But ~
이러한 RDB는 웹의 출현과 함께 점점 문제가 생기게 됩니다. 큰 규모의 데이터와 사용자를 대상으로 하려면 대용량 데이터의 읽기/쓰기 작업, 빠른 응답시간, 높은 가용성 이 지원되어야 했으며 이런 요구사항을 충족시키기위해 NoSQL이 출현하게됩니다.
Lastly ~
전자상거래와 소셜미디어의 기하급수적인 성장은 확장성이 좋고 저비용에 유연하며 높은 가용성을 지닌 DBMS의 출현을 이끌어냈습니다. NoSQL은 고비용문제와 구현상의 어려움을 해결해 주었습니다. 하지만 앞에서도 말했듯이 Non-RDB가 RDB를 대체할 가능성은 낮습니다. 두 시스템은 서로 보완하고 장점을 흡수해나가면서 점점 복잡해지고 요구사항이 많아지는 애플리케이션에 적응해 나갈 것입니다.
좋은글 감사합니다~