MongoDB::NoSQL?

업무를 진행하기 위해서 어쩌다 보니 NOSQL에 대해서 공부해야할 일이 생겼다.

 

이리 저리 구글링을 통해 알아본 결과

 

NOSQL이란, SQL을 사용하는 RDBMS와는 다르게 SQL을 사용하지 않고 DB작업을 할 수 있으며, 이름처럼 NOSQL이 SQL을 사용하지 않는다는게 아니라 Not Only SQL로 SQL을 굳이 사용하지 않아도 사용할수 있다는 것을 의미하며 SQL을 사용할 수도 있는 DB이다. 또한 정통적인 관계형 데이터베이스모델보다 덜 제한적인 일관성 모델을 이용하는 어쩌고 저쩌고 스키마 관계 개념이 없어서 스키마에 맞출 필요가 없어 데이터를 좀 더 자유롭게 관리할 수 있으며 수평적 확장이 쉽고 실시간 처리나 대용량 빅 데이터 처리에서 많이 사용되는 모델이다. 덕분에 어쩌고 저쩌고 자시고

 

 

온통 알아들을 수 없는 소리 뿐이다. 이런 이론적인 내용은 백날봐도 이해가 되지 않는다. 

실제 코드나 데이터 형태, 검색 결과 등을 봐야 이해가 빠를 것 같은데 온통 이런 글 뿐이다.

 

공부도 할겸, 나중에 또 찾기 귀찮기 때문에 내가 게시해봐야겠다.

 

 

---

일단 NOSQL을 공부하겠다는건 RDBMS의 기본적인 내용은 안다는 것으로 전제로 하겠다.

 

NOSQL의 반대 SQL이 RDBMS를 의미하는 이유는

RDBMS를 이용하기 사용되는 언어가 SQL이라서 

SQL이 RDBMS와 동의어 처럼 사용되는 것처럼 보인다.

 

대표적인 특징들 위주로 살펴보자

---

- 스키마가 없다.

Table (3 col / 2 row)

일단 우리가 익숙한 RDBMS를 보자 

표 자체, 속성, 데이터 들을 각각 Table, Column, Row 라고 한다. 표 한칸은 Filed.

 

새로운 사람 "민수"를 추가하려고 하는 경우

모르는 사람이 보아도 나이와 거주지를 같이 입력해 주어야 한다는 것을 알 수 있다. 또한

 

민수 | 컴퓨터 공학과 | minsu@email 

 

이러한 데이터가 추가되기 힘들다는 것은 아마 예상 했을 것이다.

 

왜?

 

이름 | 나이  | 거주지      

라는 스키마에 맞지 않으니까

*굳이 데이터를 넣고 싶다면 스키마 자체를 수정하면 되긴 하겠다.

 

그러나 NOSQL DB에서는 스키마가 정해져 있지 않기 때문에 충분히 가능한 일이다.

 

NOSQL에도 다양한 저장방식이 존재하나 그 중 하나인 Doucument DB를 기준으로 보겠다

 

저장을 하게 되면

Collection ( 3 Document )

Json 형식으로 데이터를 저장하기 때문에 위와 같이 저장이 되겠다.

( Json 형식이란 쉽게말해서 Key:Value 데이터쌍을 쉼표로 구분하여 나열한 데이터 쯤 되겠다. )

 

표 자체와 데이터는 각각 Collection, Document 라고 부르며 굳이 비교를 해보자면

• Table - Collection
• Row - Document
• Column - X

이렇게 볼 수 있지 않을까 싶다.

 

하여튼 이렇게 스키마가 정해져 있지 않다면 데이터를 추가할 때, 데이터가 손실되거나

스키마를 수정하는 등의 추가적인 연산을 하지 않아도 되기 때문에 매우 효율적이라고 한다.

 

---

 - 조인이 없다

 

RDBMS에서 R이 Relation의 R인 것처럼 데이터들 간의 관계를 중요하게 생각한다.

 

이러한 관계가 왜 나왔냐 다음을 보자

 

같은 거주지에 따라서 같은 지역번호가 중복되서 저장되었다. 

 

이렇게 저장된 데이터는 부정확하게 다루어질 수 있는데 한 행의 지역번호만 수정하는 경우

같은 거주지에 살더라도 지역번호가 달라지는 현상이 발생할 수 있기 때문이다.

 

이러한 점을 해결하기 위해서 문제를 야기할 수 있는 중복을 최소화하고자 정규화를 하며

정규화를 통해 나누어진 테이블들은 관계(Join)를 형성하게 된다.

 

곧 "JOIN -> 관계 -> 정규화 -> 중복 방지" 라고 볼 수 있겠다.

 

 

반면 NOSQL에서는 Join이 없다.

애초에 정해진 스키마가 없기에 관계를 정의하기가 어렵고, 구현할 수는 있는데 별로 많이 사용되지 않는다고 한다.

 

그럼 이러한 경우 어떻게 하는가

 

데이터를 직접 복제하여 Collection에 속하게 만든다.

 

혹은 필요한 데이터만을 포함시키는 것도 가능하겠다.

 

스키마가 정의되어 있지 않기 때문에 데이터를 자유롭게 활용할 수 있다.

 

이때 데이터는 복제가 되는 것이기 때문에 특정 Collection에서 데이터를 수정해도 다른 Collection에서는 반영이 되지 않기 때문에 해당 데이터를 사용하는 모든 Collection에서 수정 작업을 수행하여야 한다는 단점이 존재한다.

 

그러나 Join을 사용하지 않고 필요한 데이터가 한 Collection에 존재하기 때문에

데이터를 검색할 때에는 매우 빠른 속도를 보이며, 이를 수행할 쿼리문도 매우 간단해진다.

 

- SQL
SELECT R2.지역번호
FROM R1
JOIN R2 
ON R1.거주지 = R2.거주지;
WHERE R1.이름='철수'

- NOSQL
db.users.find({이름:'철수'},{지역번호:1,_id:0})

철수의 지역번호를 조회하는 쿼리문이 상당히 간단해진것을 볼 수 있다.

---

 - 분산처리

 

애초에 NOSQL자체가 RDBMS의 몇가지 한계점을 해결하기 위해 탄생되었기 때문에

 

분산처리 또한 시스템내에서 자동으로 지원해준다. 애초에 NOSQL의 목적 자체가 분산처리가 용이한 DB 이기도 하다.

 

따라서 분산처리기능을 기본으로 제공하기 때문에 분산 시스템에서 제공하기 힘든 트랜잭션과 JOIN이 제공되지 않는다고 한다.

 

---

 - 결론

 

사실 시작은 거창했으나 결말이 어설프다.

 

이건 이거고 저건 저건데 그냥 다 섞어서 용도에 맞게 쓴다고 한다.

 

사실 로직적으로? 데이터 구조적으로? 좀 세부한 차이를 알고 싶었는데 못찾겠다.

 

잘 모르겠다. 그냥 그렇다더라...