NoSQL 데이터 모델링

NoSQL 데이터 모델링

기존에 우리가 많이 사용하고 있는 RDMBS와 NoSQL은 전혀 다른 성격을 갖고 있고, 모델링 접근 방식 또한 다릅니다. 이 글에서는 먼저 NoSQL의 특징에 대해 알아보고, NoSQL의 데이터 모델링 패턴과 데이터 모델링 절차에 대해 알아보겠습니다.

1.1 NoSQL 특징

NoSQL은 RDBMS와 다른 형태의 데이터 저장 구조를 총칭합니다. NoSQL의 특징을 RDBMS와 비교하여 살펴보겠습니다.

1.1.1 RDBMS vs NoSQL 특징 비교

구분	RDBMS	NoSQL
데이터의 관계	Foreign Key 등을 이용하여 데이터의 관계를 정의한 후 JOIN 등의 관계형 연산을 수행	데이터 간의 관계를 정의하지 않음
확장성	데이터의 무결성 및 정합성 보장하기 위해 정규화된 데이터 모델을 사용하기 때문에 JOIN이 필요한 경우 확장성을 제약	데이터 모델 자체가 독립적으로 설계되어 있어 데이터를 여러 서버에 분산 시키는 것이 용이
스키마	스키마 변경에 따른 추가 작업이 필요함	유연한 스키마(Schema-less) 구조를 취함으로써 다양한 형태의 데이터를 저장할 수 있음

1.2 NoSQL 데이터 모델 구조

데이터 모델링을 하기 전에, 먼저 NoSQL이 어떤 구조로 데이터를 저장하는 지 이해할 필요가 있습니다. NoSQL의 데이터 모델 구조는 다음과 같이 구분될 수 있습니다.

1.2.1 Key/Value Store

Key/Value Store란, 고유한 Key에 하나의 Value를 가지고 있는 형태를 의미합니다. Put(key, value) 명령어를 이용하여 데이터를 input하고, get(key) 명령어를 이용하여 데이터를 output 합니다. 

이 형태의 데이터 모델을 사용하는 DB로는 Redis가 있습니다.

1.2.2 Column Family Store

Key/Value Store 방식에서는 하나의 Key에 하나의 Value만 저장할 수 있다는 한계점이 있습니다. 이러한 단점을 극복한 것은 Column Family Store 방식입니다. 하나의 Key에 여러 개의 Column을 저장하고, Column-Value의 묶음을 Column Family 라고 합니다.

1.2.3 Ordered Key/Value Store

Key/Value Store의 확장된 형태로서, 데이터를 저장하는 방식은 동일하지만 데이터가 내부적으로 Key를 기준으로 Sorting되어 저장되는 기능을 갖고 있습니다. NoSQL은 데이터를 정렬(Order By)해주는 기능을 제공하고 있기 않기 때문에, 데이터를 Sorting하여 활용할 수 있다는 점은 NoSQL의 성능을 향상 시킬 수 있습니다.

이 형태의 데이터 모델을 사용하는 DB로는 HBase, Cassandra 등이 있습니다.

1.2.4 Document Key/Value Store

Key/Value Store의 확장된 형태로 Key에 해당하는 Value 필드에 데이터를 저장하는 구조는 동일하지만, 저장되는 Value의 데이터 타입으로 Document라는 구조화된 데이터 타입(JSON, XML, YAML 등)을 사용하는 것을 특징으로 하고 있습니다. 이를 통해 복잡한 계층 구조 표현을 가능하게 하고, 제품에 따라서는 Sorting, Join, Grouping과 같은 RDBMS에서 제공하는 기능을 제공합니다.

이 형태의 데이터 모델을 사용하는 DB로는 MongoDB, CouchDB, Riak 등이 있습니다.

1.3 NoSQL 데이터 모델링 패턴

NoSQL 데이터 모델링을 할 때, 가장 기본적으로 사용되는 패턴으로는 다음 3가지가 있습니다.

1.3.1 Denormalization (비정규화)

Denormalization은 같은 데이터를 중복해서 저장하는 방식입니다. 비정규화를 하면 테이블간의 JOIN을 없앨 수 있습니다. NoSQL에서 두 테이블을 JOIN해서 데이터를 가져오는 로직을 구현하려면, 각각의 테이블에서 데이터를 가져와 어플리케이션에서 합쳐야 하기 때문에 2번의 IO가 발생하게 됩니다. 이 때, Denormalization을 적용하여 하나의 테이블에 JOIN될 데이터를 중복 저장하게 되면 1번의 IO로도 데이터를 가져올 수 있습니다.

Denormalization을 이용하여 중복을 허용했을 때의 장단점은 다음과 같습니다.

장점

· 쿼리 당 I/O 횟수 감소
· 쿼리 데이터 사이즈 감소
· 쿼리 수행 복잡도 감소

단점

· 전체 데이터 사이즈 증가
· 데이터 일관성 문제 발생 가능

1.3.2 Aggregation

대부분의 NoSQL에서는 기본적으로 ‘유연한 스키마(Schema-less)’를 제공합니다. 이 속성은 row의Key만 똑같다면 각각의 row들이 꼭 같은 컬럼을 가질 필요도 없고, 데이터 타입도 모두 달라도 된다는 것을 의미합니다.

 예를 들어, 파일 정보 저장 시스템이 있다고 할 때, 이 시스템은 파일에 대한 정보를 저장하고, 음악, 사진, 동영상 등의 파일의 종류에 따라 추가적인 메타 정보를 저장합니다. 이때의 개체관계도는 다음과 같습니다.

일반적인 용도의 파일 이외에 특수한 용도로 만들어진 MP3, 사진, 영화 파일들에 대한 예외 처리가 쉽지 않을 것입니다. 여기에 NoSQL의 Schema-less 속성을 적용하면 데이터 모델을 하나의 테이블로 합칠 수 있습니다.

이와 같이 1:N과 같은 복잡한 개체들의 관계를 손쉽게 하나의 테이블로 바꿀 수 있고, 이는 결과적으로 JOIN의 수를 줄여 쿼리 성능을 높일 수 있게 됩니다.

1.3.3 Application Side Join

NoSQL은 Join 기능을 제공하지 않기 때문에 Denormalization이나 Aggregation 등의 데이터 모델링 패턴을 이용하게 됩니다. 하지만, 이러한 패턴을 적용하더라도 어쩔 수 없이 Join 기능을 구현해야 하는 경우가 있습니다. 이 때는 NoSQL의 쿼리로는 불가능하고, NoSQL을 사용하는 client Application 단에서 Join 로직을 처리해줘야 합니다.

예를 들어, 2개의 테이블 TABLE 1, 2이 있고 TABLE 1의 컬럼 중 하나가 Foreign Key로서 TABLE 2의 데이터를 가리키고 있다고 할 때, Application Side Join을 수행하려면 TABLE 1에서 Primary Key로 한 row를 읽어온 후에, TABLE 2를 가리키는 컬럼의 값을 Key로 하여 다시 TABLE 2에서 쿼리를 해야 합니다.

이 방법은 Join이 필요한 테이블의 수 만큼 NoSQL로의 Request/Response IO가 발생하긴 하지만, Denormalization 등에 비해서 스토리지 사용량은 감소시킬 수 있습니다.

1.4 RDBMS와 NoSQL의 데이터 모델링 절차 비교

데이터 모델링이란, DB에 저장할 데이터들의 구조를 정의하는 작업을 의미합니다. NoSQL은 RDBMS와 특성이 매우 다르기 때문에 접근 방법을 바꿔 데이터 모델을 설계해야 합니다.

1.4.1 RDBMS 데이터 모델링 (개체 모델 지향)

RDBMS는 먼저 저장하고자 하는 도메인 모델을 분석합니다. 이를 통해 개체 간의 관계를 식별하여 테이블을 설계합니다. RDBMS는 다양하고 복잡한 쿼리를 지원하기 때문에 테이블을 디자인한 후에 필요한 데이터를 가져올 수 있도록 쿼리를 작성합니다. 테이블 설계 시 테이블간 데이터 중복을 최소한으로 하는 정규화된 테이블을 설계합니다.

1.4.2 NoSQL 데이터 모델링 (쿼리 결과 지향)

어플리케이션의 특징적인 데이터 접근 패턴에 따라 데이터 모델링을 실시합니다. NoSQL은 매우 단순한 쿼리만을 지원하기 때문에 어떤 쿼리 결과가 필요한 지 먼저 정의한 다음, 그 결과를 얻을 수 있도록 테이블을 디자인해야 합니다. 테이블(데이터 저장 모델) 설계 시 데이터가 두 개 이상의 테이블에 중복되게 저장하는 비정규화된 테이블을 설계해야 합니다.

1.5 NoSQL 데이터 모델링 절차

1.5.1 도메인 모델 파악

가장 먼저, 저장하고자 하는 도메인을 파악해야 합니다. 어떤 데이터 개체들이 있고 그 개체들간의 관계는 어떻게 되는지 등을 분석하고 ERD(개체관계도)를 그려서 도식화합니다. 이러한 방식이 RDBMS의 데이터 모델링 접근 방법이긴 하지만, NoSQL도 저장할 데이터에 대한 명확한 이해 없이는 제대로 된 데이터 모델이 나올 수 없을 것입니다.

이해를 돕기 위해 간단한 블로그 시스템을 예를 들어 설명하겠습니다. 

이 블로그 시스템은 사용자 아이디(userID)를 기반으로 블로그의 분류(Category)를 가지고 있고, 분류 별로 글을 작성할 수 있습니다. 또 글에 파일을 첨부(Attachment)할 수 있는 기능과 댓글(Comment)을 달 수 있는 기능이 있습니다.

1.5.2 쿼리 결과 (데이터 출력 형태) 디자인

다음으로 가장 중요한 과정인 ‘쿼리 결과 디자인’ 입니다. ‘도메인 모델’을 기반으로 어플리케이션에서 쿼리가 수행되는 결과 값을 먼저 정합니다. 기본적으로 게시물을 등록하는 블로그 시스템에서는 다음과 같은 기능들이 필요할 것입니다.

(1) 블로그 사용자의 포스팅 분류명들을 목록으로 출력합니다.
(2) 포스팅 출력화면에는 상단에 포스팅의 분류명과 제목을 출력하고, 다음으로 포스팅 날짜와 본문 내용을 출력합니다.
(3) 첨부파일의 업로드 날짜와 파일명을 출력하고, 파일에 대한 링크를 출력합니다.
(4) 댓글에는 작성일과 작성자 이름, 댓글 내용을 입력하고, 작성자 이름에는 이메일을 링크합니다.

이러한 기능들을 구현하기 위해 필요한 쿼리들을 정의하고 난 뒤, 해당 쿼리의 출력 데이터를 기반으로 한 테이블들은 다음과 같을 것입니다.

NoSQL 데이터 모델링은 도메인 모델을 중심으로 하는 것이 아니라, 이 어플리케이션의 데이터 출력 내용을 기반으로 하기 때문에 쿼리 결과 디자인 과정이 가장 중요합니다. 

1.5.3 패턴을 이용한 데이터 모델링

쿼리 결과 디자인을 바탕으로 NoSQL에 정의될 데이터 모델링을 실시합니다. NoSQL은 Sorting, Grouping, Join 등의 RDBMS의 기능을 제공하지 않기 때문에, 이를 배제하고 Put/Get 명령어로만 데이터를 가져올 수 있는 형태로 NoSQL 내의 테이블을 재 정의해야 합니다.

이 때, 위에서 설명한 여러 가지 NoSQL 데이터 모델링 패턴들이 적용됩니다. 그 중 가장 중요한 것이 바로 Denormalization입니다. 데이터를 가급적 중복으로 저장하여 한 번에 데이터를 읽어오는 횟수를 줄여야합니다.

위의 블로그 시스템 데이터를 일반적인 NoSQL 스타일로 바꾸면 다음과 같습니다.

Key를 구성할 때, Posting 테이블에서 Join을 없애기 위해서 userID와 postID를 ‘:’로 구분되는 deliminator로 하여 Key에 포함시켰습니다. 이렇게 했을 때 Ordered Key/Value Store의 경우에는 Key를 기반으로 Sorting을 하기 때문에 다음 2가지 기능을 사용할 수 있게 됩니다.

1) Sorting
postID를 순차적으로 증가시키게 되면, 같은 사용자의 글의 경우에는 정렬이 됩니다.

2) Grouping
포스팅을 출력하는 사용자에 대해서는 순차적으로 포스트를 출력하다가, 해당 사용자의 포스팅 데이터가 끝나면, Key의 앞부분인 userID가 다른 사용자ID로 바뀌기 때문에 where 문장 없이도 특정 사용자의 포스팅을 순차적으로 출력할 수 있습니다.

1.5.4 기능 최적화

Attachment 테이블의 경우, 포스팅이 되었을 때 레코드가 추가되며 변경이 거의 없습니다. 그리고 첨부파일의 수는 그리 많지 않기 때문에 하나의 필드에 모두 몰아서 저장할 수 있습니다. 이와 같이 하나의 필드에 여러 개의 데이터를 저장할 경우에는 Document Store을 고려해 볼 수 있을 것입니다.

또한 블로그 포스트, 첨부파일, 댓글은 정렬이 되어야 하기 때문에 Ordered Key 형태가 필요합니다. 지금까지의 데이터 모델은 포스팅이 된 순서대로만 출력한 형태인데, 분류 개념이 있기 때문에 분류에 따라서 포스팅을 출력하려면 분류 필드가 별도 필드로 들어가야 하고, 이 필드에 따라 where 문으로 select할 수 있는 기능이 있어야 합니다. RDBMS의 Index와 같은 이 개념을 NoSQL에서는 ‘Secondary Index’라고 합니다.

이런 옵션들을 적용해 보면 Posting 테이블은 아래와 같이 변경될 수 있습니다.

1.5.5 NoSQL 선정 및 테스트

그 다음으로는 모델링한 데이터 구조를 효과적으로 실행할 수 있는 NoSQL을 찾아야 합니다. NoSQL에 대한 구조 및 특성을 분석한 후에 실제로 부하 테스트, 안정성, 확정성 테스트를 거친 후에 가장 적절한 솔루션을 선택해야 합니다.

경우에 따라서는 여러 개의 NoSQL을 복합적으로 사용해야 할 경우도 있습니다. 또 하나의 NoSQL만으로 모든 데이터를 처리하지 말고, RDBMS와 혼용하거나 다른 NoSQL과 연동하여 최적의 시스템을 설계해야 합니다.

1.5.6 선정된 NoSQL에 데이터 모델 최적화 및 하드웨어 디자인

마지막으로 선정된 NoSQL을 기반으로 그에 적합하게 데이터 모델을 최적화해야 합니다. 그리고 이에 맞는 어플리케이션 인터페이스 설계와 구동시킬 하드웨어 디자인을 실시합니다.