RDBMS와 NoSQL

1. RDBMS

• 데이터는 정해진 데이터 스카마에 따라 테이블에 저장되고 관계를 통해 여러 테이블에 분산된다.
• 스카마를 준수하지 않은 레코드는 테이블에 추가할 수 없다.
• 데이터의 중복을 피하기 위해 관계를 이용한다. 하나의 테이블에서 중복 없이 하나의 데이터만을 관리하기 때문에 다른 테이블에서 부정확한 데이터를 다룰 위험이 없어진다.
• ACID 특징을 가진다.
• mySQL

 

1) 장점

• 명확하게 정의된 스키마로 데이터 무결성을 보장한다.
• 관계를 통해 분산 저장하기 때문에 각 데이터를 중복 없이 한 번만 저장한다.

 

2) 단점

• 유연하지 않다. 데이터 스키마를 사전에 계획하고 알려야 해서 나중에 수정하기 힘들다.
• 관계를 맺고 있어서 조인문이 많은 복잡한 쿼리가 만들어질 수 있다.

 

3) 언제 사용?

• 관계를 맺고 있는 데이터가 자주 변경되는 애플리케이션
• 변경될 여지가 없고 명확한 스키마가 사용자와 데이터에게 중요한 경우

 

2. NoSQL(Not Only SQL)

• 관계형 데이터 모델을 지양하며 대량의 분산된 데이터를 저장하고 조회하는데 특화되어있으며 스키마 없이 동작한다.
• 레코드를 문서(documents)라고 부른다.
• 문서를 RDB처럼 여러 테이블에 나눠 담지 않고 관련 데이터를 동일한 컬렉션에 넣는다. 따라서 여러 테이블에 조인할 필요가 없이 이미 필요한 모든 것을 갖춘 문서를 작성한다.
• 다른 구조의 데이터를 같은 컬렉션에 추가 가능하다.
• Redis, MongoDB

 

1) CAP 이론

• 일관성(Consistency): 다중 클라이언트에서 같은 시간에 조회하는 데이터는 항상 동일한 데이터임을 보증한다.
• 가용성(Availability): 모든 클라이언트의 읽기와 쓰기 요청에 대하여 항상 응답이 가능하다. 즉, 특정 노드가 장애가 나도 서비스가 가능해야 한다.
• 네트워크 분할 허용성(Partition tolerance): 지역적으로 분할된 네트워크 환경에서 동작하는 시스템에서 두 지역 간의 네트워크가 단절되거나 네트워크 데이터의 유실이 일어나더라도 각 지역 내의 시스템은 정상적으로 동작해야 한다.

 

2) 장점

• 스키마가 없어서 유연하다. 언제든지 저장된 데이터를 조정하고 새로운 필드 추가가 가능하다.
• 데이터는 애플리케이션이 필요로 하는 형식으로 저장되어 데이터를 읽어오는 속도가 빨라진다.

 

3) 단점

• 유연성으로 인해 데이터 구조 결정을 미루게 될 수 있다.
• 데이터 중복을 계속 업데이트해야 한다.
• 데이터가 여러 컬렉션에 중복되어 있기 때문에 데이터 수정 시 모든 컬렉션을 수행해야 한다.

 

4) 언제 사용?

• 정확한 데이터 구조를 알 수 없거나 변경, 확장될 수 있는 경우
• 읽기를 자주 하지만 데이터 변경은 자주 없는 경우