NoSQL 데이터 모델링 개념

데이터베이스를 사용할 때 가장 중요한 것은 역시 데이터 모델링이라고 할 수 있습니다. 데이터를 어떤 형태로 관리하고 적재할 것인지에 따라 성능이나 관리적인 측면에서 큰 차이가 날 수 있기 때문입니다. 기존의 RDBMS 방식과 NoSQL의 모델링 방법은 서로의 개념이 다른 만큼 큰 차이가 있습니다. 관계형 데이터베이스의 모델링은 주로 데이터들을 정규화(Normalization) 하는 방식으로 진행합니다. 반면에, NoSQL의 모델링은 비정규화(Denormalization)를 기본으로 가져갑니다. NoSQL의 데이터 모델링 개념과 기법, 예시를 보면서 알아보도록 할텐데 먼저 개념부터 알아보겠습니다.

NoSQL 데이터 모델링 개념

비정규화(Denormalization)와 함께 Aggregates, Application Side Join의 개념에 대해서 알아봅시다.

Denormalization (비정규화)

비정규화 = 데이터 중복 허용

이라고 말할 수 있습니다. RDB에서의 정규화는 데이터의 중복을 없애고 데이터의 정합성과 성질을 모아놨다고 한다면 비정규화는 그와 반대로 데이터의 중복을 허용하는 것을 의미합니다. 어떻게 질의할 것이냐가 아닌 어떻게 응답할 것인가, 어떤 데이터를 줄 것인가에 중점을 두기 때문에 비정규화를 통해 데이터를 모델링합니다.

비정규화로 인한 Trade-Off 발생

쿼리당 I/O or 쿼리 데이터 사이즈 VS 전체 데이터 사이즈

비정규화하면 모든 데이터를 한 곳에 모아놓고 쿼리를 수행하기 때문에, 쿼리 수행을 위한 I/O가 줄어 전체 성능을 향상시킬 수 있지만 중복이 허용되므로 전체 데이터 사이즈는 증가합니다.

쿼리 수행의 복잡도 VS 전체 데이터 사이즈

시스템과 데이터 사이즈가 큰 분산 환경에서 데이터 정규화 했을 때, 그 복잡도가 더욱 높아집니다. 비정규화를 하면 필요한 데이터들을 한 곳에 쿼리친화적인 구조로 쌓을 수 있기 때문에 전체적인 쿼리 프로세싱을 단순화하고 쿼리 실행 시간도 단축시킬 수 있습니다. 즉 복잡도가 낮아지는데 이와 상충하여 다른 Document나 Table에 중복되어 저장되기 때문에 전체 데이터 사이즈는 필연적으로 증가할 수 밖에 없습니다.

Aggregates

NoSQL은 스키마를 유연하게 다룰 수 있다는 것이 큰 특징입니다. 이러한 유연한 스키마 속성은 다양한 구조의 요소들을 가지고 있는 데이터 클래스를 구성할 수 있도록 합니다. 가령 List구조의 데이터가 있다고 가정했을 때, 한 List의 속성안에 또 다른 List를 중첩하여(Nested) 구성할 수 있습니다.

1. join 연산을 줄임

1:n 관계를 최소화하여 결과적으로 join 연산을 줄일 수 있습니다. join해서 가져와야 하는 데이터를 내부에서 조회 가능하기 때문입니다. 이로인해 수행시간 단축과 저렴한 비용의 대용량 데이터 지원이 가능하다는 효과가 있습니다.

2. 복잡하고 다양한 비즈니스 요소를 담을 수 있음

수많은 데이터가 쌓여있는 상태에서 스키마를 변경한다고 가정해봅시다. 기존의 RDBMS에서는 변경하는 비용이 많이 발생할 수 있습니다. 하지만 다양한 구조를 담을 수 있기 때문에 확장과 변동에 대해 유연하게 대처가 가능합니다.

아래 File에 관한 예를 들면,

3가지의 File을 정의한다고 했을 때, schema-less한 특성을 이용하면 이 데이터 모델을 하나의 테이블로 합칠 수가 있습니다. MP3 File, Photo File, Movie File은 각각 다른 종류이고 사용하는 데이터가 다르지만 결국 File이라는 공통된 속성에 해당하므로 id, size, name 등 공통된 필드를 중첩하여 정의할 수 있습니다.

Application Side Join

대체로 NoSQL은 join기능을 지원하지 않지만 필요하다면 Application 상에서 join을 사용할 수도 있습니다. 이런 경우는 비정규화, Aggregation을 수행해도 문제가 발생하는 경우인데, 불가피하게 join을 해야만 가능한 경우입니다.

1. N:M 관계인 경우

기본적인 1:N의 관계라면 필요없지만 N:M (다대다) 관계의 경우, 참조를 사용하기 때문에 join이 필요합니다. 

2. join 대상 데이터의 수시 변동

모델링을 할 때 이미 비정규화와 Aggregation을 통해 데이터의 중복을 여러 군데에서 허용했습니다. 때문에 만약에 데이터가 변경된다면 전부 찾아서 업데이트해야만 합니다. 이럴 경우 많은 비용이 발생할 수 밖에 없습니다. 이러한 경우를 방지하기 위해 변경이 잦은 데이터를 따로 추려 Application 상에서 join을 하는 것이 좋습니다.

예를 들어, 변경이 잦은 데이터를 TABLE1에서 별도로 관리하고 필요하면 get을 통해 가져와서 TABLE2의 데이터를 불러옵니다. 즉 join과 유사한 방법을 Application 로직 상에서 수행할 수 있습니다. 데이터가 변경될 경우 한 TABLE만 수정되기 때문에 문제를 해결할 수 있습니다.