관계형 데이터베이스와 NOSQL 비교

핵심내용

 

데이터베이스는 일종의 창고라고 볼 수 있다. 그리고, 이 창고에는 데이터들이 저장되어 있고 저장되어 있는 데이터들이 모여 데이터의 집합을 이룬다. 어떤 물품(데이터)를 저장할지에 따라 사용하는 창고(DB)의 종류가 달라지고 이는 관리자가 결정한다. 오늘은 이 창고들 중 관계형 데이터베이스와 NoSQL을 비교해보려 한다.

 

관계형 데이터베이스

https://www.c-sharpcorner.com/article/what-is-the-most-popular-database-in-the-world/

데이터베이스계의 주류는 뭐니뭐니해도 관계형 데이터베이스이다. 위 통계를 살펴보면 가장 인기있는 데이터베이스 5개중 4개가 관계형 데이터베이스이다(Oracle, MySQL, SQL Server, PostgreSQL). 

 

관계형 데이터베이스에서 "관계"란 동일한 속성을 가지고 있는 데이터들의 집합이라고 할 수 있다. 예를 들어, 아래 표를 살펴보자. 

번호	이름	성별
1	송중기	남자
2	이성민	남자

첫 번째 줄과 두 번째 줄 모두 각각 번호/이름/성별 세 가지의 동일한 속성을 가지고 있다. 이 줄을 레코드 혹은 튜플이라고 하는데, 이 레코드 들이 모여 관계를 이룬다. 

 

번호	이름	출연작
1	송중기	태양의후예
2	이성민	미생
3	송중기	빈센조

위의 표에서 3개의 레코드들은 모두 번호/이름/출연작이라는 동일한 속성을 가지고 관계를 이루고 있다. 또한, 상기한 두 표는 "이름"이라는 속성으로 관계를 이루고 있다.

 

이처럼 관계형 데이터베이스의 데이터들은 속성을 기반으로 정형화 되어 있다. 즉, 데이터의 형태가 정해져 있다는 의미이다. 예를 들어, 위의 표의 레코드는 번호/이름/출연작 세 가지의 속성을 가질 수 있다. 

 

관계형 데이터베이스가 가지는 가장 큰 장점은 데이터가 가질 수 있는 정확성과 일관성이다. 아래 표를 살펴보자.

번호	이름	출연작
1	송중기	태양의후예
2	이성민	미생
3	송중기	세탁기?

출연작이라는 속성에 갑자기 이상한 녀석이 생겼다(절대, 지금 빨래 돌리고 있어서 그런거 아님). 왜 이상하다고 하는가? 출연작에 해당하는 값만 레코드에 기록되어야 하는데, 가전제품이 기록되었기 때문이다. 이러한 현상에 대해 유식한 말로 도메인 무결성을 위배했다고 표현할 수 있다. 이외에도 여러 무결성 조건들이 있다. 이처럼 관계형 데이터베이스가 가진 "무결성"은 데이터의 정확성과 일관성을 담보해준다. 

 

무결성을 일종의 완벽주의로 생각해보자. 완벽주의가 얼마나 사람을 피말리게 하는지 생각해보면, 그만큼 관계형 데이터베이스가 원칙으로 삼고있는 무결성이 얼마나 큰 강점인지 알 수 있을 것이다.

 

NoSQL

 

앞서 설명한 관계형 데이터베이스는 SQL이라는 언어를 사용하여 조작한다. 이외의 다른 종류의 데이터베이스들은 SQL말고 도 다른 방법으로도 데이터를 저장할 수 있다는 "Not Only SQL"을 줄여 NoSQL이라고 부른다. 

 

관계형 데이터베이스의 주요한 단점으로 확장성을 많이들 언급한다. 확장성에는 두 가지 방향이 있다. 첫 번째는 수직적 확장이다. 레코드를 추가하는 것으로 생각할 수 있다.

 

두번째는 수평적 확장이다. 가장 간단하게는 속성을 추가하는 것을 생각해볼 수 있다.

 

관계형 데이터베이스의 경우, 수직적 확장은 용이하나 수평적 확장은 힘들다. 그 이유는 정형화된 "관계"가 가지는 값비싼 비용 때문이다. 관계를 재설정하기 위해서는 많은 노력이 들어간다. 왜냐하면, 특정 속성을 추가하거나 삭제하거는 경우 기존의 다른 관계들 간의 연관성을 모두 고려해야 하기 때문이다.

 

반대로, NoSQL의 경우 수평적 확장에 용이하다. 왜냐하면, 데이터베이스 내의 데이터 들 간의 관계를 규정할 필요가 없기 때문이다. NoSQL의 데이터 들은 그 자체로서 존재한다. 

 

가장, 단순한 형태의 NoSQL인 상품 코드를 기준으로 상품을 저장하는 Key-Value 저장소를 예시로 들어보자. 

Key	Value
2349349	갤럭시 버즈 프로
12393912	아이폰 14
3320402	갤럭시 S22

 

여기서, Value에는 "속성"의 의미가 없다. 그렇기 때문에 아래와 같은 표현도 가능하다.

Key	Value
2349349	갤럭시 버즈 프로
12393912	아이폰 14
3320402	{     상품명: 갤럭시22     가격: 1,000,000 }

왜냐하면, 각 레코드 들이 동일한 속성으로 관계를 가질 필요가 없기 때문이다. 이와 같은 특징 때문에 NoSQL에서는 수평적 확장이 가능하다.

 

Mongo DB(Document Database)

 

Key-Value 저장소에서 Value를 Document로 바꿔주면 Document DB가 된다. 여기서 Document란 JSON 형태의 데이터를 의미한다. Mongo DB공홈에서는 이를 BSON(binary representation of JSON)이라고 표기하고 있다.

https://www.mysoftkey.com/mongodb/what-is-document-in-mongodb/

그리고, 이러한 Documents들의 집합을 Collection이라고 하는데 관계형 데이터베이스의 표(테이블)에 해당한다.

 

수평적 확장이 용이한 NoSQL 답게 Document또한, 스키마에서 자유롭다. 공홈의 예시를 이용해 테스트해보자.

https://www.mongodb.com/docs/manual/tutorial/query-documents/

db.inventory.insertMany([
   { item: "journal", qty: 25, size: { h: 14, w: 21, uom: "cm" }, status: "A" },
   { item: "notebook", qty: 50, size: { h: 8.5, w: 11, uom: "in" }, status: "A" },
   { item: "paper", qty: 100, size: { h: 8.5, w: 11, uom: "in" }, status: "D" },
   { item: "planner", qty: 75, size: { h: 22.85, w: 30, uom: "cm" }, status: "D" },
   { item: "postcard", qty: 45, size: { h: 10, w: 15.25, uom: "cm" }, status: "A" }
]);

 

구조만 살펴보자. item/qty/size/status 와 같은 속성들이 규칙적으로 할당되어 있는 것 같다.

db.inventory.insertMany([
   { item: "journal", quote: "오늘 먹을 치킨을 내일로 미루지말라", qty: 25, size: { h: 14, w: 21, uom: "cm" }, status: "A" },
   { item: "notebook", qty: 50, size: { h: 8.5, w: 11, uom: "in" }, status: "A" },
   { item: "paper", qty: 100, size: { h: 8.5, w: 11, uom: "in" }, status: "D" },
   { item: "planner", qty: 75, size: { h: 22.85, w: 30, uom: "cm" }, status: "D" },
   { item: "postcard", qty: 45, size: { h: 10, w: 15.25, uom: "cm" }, status: "A" }
]);

 

하지만, 위와 같이 quote라는 필드를 Document에 추가해도 아무런 에러가 발생하지 않는다. 왜냐하면, 스키마의 제약이 없기 때문이다.

이로 인해, 조회할 때 RDB 처럼 복잡한 Join을 하지 않아도 된다. 왜냐하면, 다 때려 박을 수 있기 때문. 이상, 관계형 데이터베이스와 NoSQL에 대해 비교해봤다.