2000년대 초중반으로 넘어오면서, 인터넷을 사용자가 폭발적으로 늘어나기 시작합니다. 사용자가 폭발적으로 늘어나면서 high-throughput과 low-latency를 요구하는 DB의 수요가 높아졌습니다. 또한 예상할 수 없는 비정형 데이터가 증가하면서 스키마가 유연한 DB의 수요가 높아졌습니다.

유연한 스키마
sql에서 테이블(=nosql에서의 컬렉션)을 생성할 경우 해당 테이블의 데이터 구조를 미리 정의해야합니다.

create table student(
	id INT PRIMARY KEY,
	name VARCHAR(20),
)

Copy

반면 NoSQL에서 컬렉션을 정의할 때 스키마를 정의하지 않아도 됩니다.

db.createCollection("student")
Copy

컬렉션의 데이터 구조가 결정되는 시점은 데이터를 삽입할 때입니다.

db.student.insertOne({name:"hanju"})
Copy

같은 컬렉션이라고 같은 구조의 데이터만 넣을 필요 없이, 저장되는 데이터 형식에 맞춰서 저장할 수 있습니다.
(json 형태로 데이터를 저장하기 때문)

db.student.insertOne({
	name:"hanju",
	address:{
		country: "Korea",
		state: "Seoul"
	}
	certificate: ["AWS solution Architect", "HAST Lv3"]
	
	})

Copy

parameter로 검색하는 과정 역시 json을 활용하기 때문에 유연합니다.

db.student.find({name"hanju"})
Copy

중복 허용 join 회피
join을 할 필요없이 하나의 doc 조회만으로 관련된 데이터를 전부 조회할 수 있습니다. 하지만 application 레벨에서 중복된 데이터들이 업데이트될 때마다 모두 최신 데이터를 유지하게끔 로직을 잘 작성해야합니다.

scale out에 유연하다.
NoSQL은 서버 여러대로 하나의 클러스터를 구성하여 사용할 수 있습니다. 애초에 저장될 때 중복을 허용하는 (=join이 잘 일어나지 않는) 방향으로 하나의 doc안에 모든 정보를 때려넣다보니, 분산하여 저장하더라도 하나의 doc만 어떻게 잘 찾아오면 해결할 수 있기 때문에 여러대의 db로 나누어서 관리해도 좋습니다.

RDB의 경우 데이터를 분산하여 저장하게 될 경우 join시에 문제가 발생합니다. 하나의 비즈니스 로직을 처리할 때 여러 개의 테이블 정보가 필요하다고 가정해보겠습니다. 여러 개의 테이블은 여러개의 DB에 분산되어 저장되어 있습니다. 비즈니스 로직을 처리하기 위해서는 여러개의 테이블을 참조해야하고 이는 여러대의 db를 계속 반복해서 조회해야합니다.