NoSql 데이터 모델링 개념
Denormalization
- 비정규화 = 데이터 중복 허용
- 쿼리 프로세싱을 간단하게 하거나 최적화하기 위해서, 사용자의 데이터를 특정한 데이터 모델에 맞추기 위해서
같은 데이터를 여러 도큐먼트나 테이블에 복제하여 중복하는 것을 허용함
- 비정규화로 인한 트레이드오프
- 쿼리당 I/O 또는 쿼리 데이터 사이즈 VS 전체 데이터 사이즈
- 쿼리 수행의 복잡도 VS 전체 데이터 사이즈
- 비정규화 시, 쿼리 수행을 위한 모든 데이터를 한 곳에 모아놓고 쿼리를 수행하기 때문에,
쿼리 수행을 위한 I/O 숫자를 줄여 전체 성능을 향상할 수 있다.
- 데이터 모델링 시점에서 데이터 정규화를 하거나
쿼리 실행 시점에서 데이터 간의 연속적인 JOIN은 쿼리 프로세스의 복잡도를 증가시킴
- 시스템과 데이터 사이즈가 큰 분산 환경에서는 그 복잡도가 더욱 높아짐
- 데이터 비정규화를 하면 쿼리에 필요한 모든 데이터를 한 곳에 쿼리-친화적인 구조로 모아놓을 수 있기에
전체적인 쿼리 프로세싱을 단순화하고 수행 시간 단축이 가능
- 해당 데이터는 다른 쿼리 수행을 위해 다른 도큐먼트나 테이블에 중복 저장되기 때문에
사이즈는 필연적으로 증가
Aggregates
- 유연한 스키마 속성은 복잡하고 다양한 구조의 내부 요소를 가지고 있는 데이터 클래스를 구성 가능하게 함
- 1:N 관계를 최소화하여 결과적으로 join 연산을 줄임
- 수행 시간 단축, 저렴한 비용의 대용량 데이터 지원
- 복잡하고 다양한 비즈니스 요소를 담을 수 있음
- 추후 확장성 및 변동성에 대한 유연한 대처 가능
- 대부분 NoSql 솔루션은 기본적으로 유연한 스키마를 제공
- NoSQL의 schema-less 특성을 이용하면, 데이터 모델을 하나의 테이블로 합칠 수 있음
공통 필드만 맞다면, 여러 테이블을 합칠 수 있음
Application Side Joins
- 대용량 데이터에 대해 빠른 응답 성능과 확장성, 가용성을 최우선 목적으로 하기에,
쿼리 타임 조인을 최대한 피하여 데이터 모델을 구성하는 것을 가정으로 함
- JOIN 대상 데이터에 대해 비정규화, 어그리게이션을 수행할 때 문제가 발생하는 경우
- JOIN 대상 데이터가 다대다(N:M) 관계를 가짐
- JOIN 대상 데이터의 수시 변동
- 대상 데이터가 수시로 변경되는 경우,
비정규화와 어그리게이션을 통해서 많은 ENTITY에 해당 데이터의 중복을 허용했기에
해당 데이터 업데이트 시 모두 찾아서 업데이트 - 추가 비용 발생
- 이런 경우, 차라리 변경이 잦은 데이터만을 추려내어 쿼리 타임 조인을 수행하는 것이 대안
- RDBMS를 사용하던가, NOSQL 사용하려면 APPLICATION 단에서 조인을 수행해라
주요 NOSQL 데이터 모델링 기법
General Modeling Techniques
- Atomic Aggregates
- Enumerable Keys
- Dimensionality Reduction
- Index Table
- Composite Key Index
- Aggregation With Composite Keys
- Inverted Search - Direct Aggregation
Composite Key
- 하나 이상의 필드를 deliminator를 이용하여 구분 지어 사용하는 방법
- Orderd KV Store의 경우에는 이를 이용하여 order by와 같은 Sorting / Grouping 구현 가능
- Nosql N개의 서버로 구성된 클러스터로 동작하고 데이터는 Key를 기준으로 N개의 서버에 나뉘어 저장
- Key를 선정할 때는 전체 서버에 걸쳐 부하가 골고루 분산될 수 있는 Key를 선정
Inverted Search Index
- value의 내용을 key로 하고, key의 내용을 value로 하는 패턴
- 검색 엔진에서 많이 사용
- 검색엔진은 사이트의 모든 페이지를 검색 로봇이 검색하여 문서 내의 단어를 색인 후 url에 맵핑하여 저장
- 검색은 단어를 key로 검색하므로, value에 검색 키워드들이 들어가 있을 경우 효과적인 검색 불가
- 검색 키워드를 키로 해서 url을 value로 하는 테이블을 다시 만든 다음,
검색 키워드로 검색을 하면 신속하게 검색 키워드를 가지고 있는 url을 찾아낼 수 있음
계층 데이터 구조 모델링 패턴
- NoSql은 다양한 데이터 모델이 있지만, 기본적으로 row, column을 가지고 있는 테이블 저장 구조를 가짐
- 애플리케이션 개발 중에는 이런 테이블 구조뿐만 아니라 Tree와 같은 계층형 데이터 구조를 저장해야 할 경우가 있는데, NoSql은 이러한 계층형 구조를 저장하는 것이 쉽지 않다.
- RDBMS의 경우에도 이런 계층형 구조를 저장하기 위해 많은 고민을 해왔기 때문에,
솔루션에서 기능 적으로 자체 지원하기도 하고 데이터 모델링을 통해 계층형 구조를 저장할 수 있음
- NoSql에서 계층형 구조를 저장하는 기법은 RDBMS에서 사용하는 기법들을 참고하여 구현했음
Tree Aggregation
- Tree 구조 자체를 하나의 Value에 저장하는 방식
- JSON이나 XML 등을 이용하여 트리 구조를 정의하고, value에 저장
- Tree 자체가 크지 않고, 변경이 많지 않을 경우에 적합
Materialized Path
- Tree 구조를 테이블에 저장할 때, root에서 부터 현재 노드까지의 전체적은 경로를 key로 저장하는 방법
- 구현에 드는 노력에 비해 매우 효율적인 방식
- Key에 대한 Search를 할 때 Regular Expression을 사용할 수 있으면 , 특정 노드의 하위 트리 등을 쿼리 해오는 기능 등 다양한 쿼리가 가능
NOSQL 데이터 모델링 예시
도메인 모델 파악
- 어떤 데이터 개체가 있는지, 개체 간의 관계 분석
- ERD를 그려 도식화
- RDBMS 모델링 접근 방법이긴 하지만, NoSql에서도 저장할 데이터를 명확하게 이해하기 위해 필수적임
쿼리 결과(데이터 출력 형태) 디자인
- 도메인 모델 기반으로 애플리케이션에서 쿼리가 수행되는 결괏값을 먼저 정함
- 출력 형식을 기반으로 필요한 쿼리 정의
- 출력 데이터를 기반으로 테이블 추출
패턴을 이용한 데이터 모델링
- NoSql은 Sorting, Grouping, Join 등의 연산을 제공하지 않기 때문에
Get / Put으로만 데이터를 처리할 수 있는 형태로 데이터 모델을 재정의
기능 최적화
- 첨부파일
- 포스팅에 의존적이며 변경이 적고, 개수가 많지 않기에 하나의 필드에 모아 저장하는 것이 나음
- 분류에 따른 포스팅 출력
- 현재는 포스팅 순서대로만 출력 가능
- 포스팅에 분류 필드를 별도로 넣고, 필드에 따라 where 문으로 select 할 수 있어야 함 (Secondary Index)
attach 컬럼 추가 후 , Attachment 테이블 삭제
NoSql 선정 및 테스트
- 모델링한 데이터 구조를 효과적으로 실행할 수 있는 NoSql 검토
- NoSql 특성 분석 및 부하 테스트, 안정성/확장성 테스트 수행
- 경우에 따라서는 여러 개의 NoSql을 복합적으로 사용
- 하나의 NoSql 만으로 모든 데이터를 처리하려 하지 말고, RDBMS와 혼용하거나 다른 NoSql과 연동하여 최적의 시스템 설계
선정된 NoSql에 최적화 및 하드웨어 디자인
- 선정된 NoSql에 적합하게 데이터 모델을 최적화
- 해당 NoSql에 맞는 애플리케이션 인터페이스 설계
- 구동시킬 하드웨어 디자인
- 반드시 데이터 모델과 내부 아키텍처를 제대로 파악하고, 그에 맞는 NoSql 선정
결론
- NoSql은 시스템 개발 시 , 데이터 모델링이 80% 이상을 차지함
- 선정한 NoSql과 애플리케이션 특성에 맞는 데이터 모델링에 집중