NoSQL 데이터 모델링 1

NoSQL 데이터 모델링에서 데이터 모델과 모델링 절차에 대해서 이야기를 해보겠습니다.

최근 SNS, 빅데이터, 클라우드와 같이 트랜드와 같이 가는 기술 서비스에 대해서 관심이 많습니다.

사실 이런 최신 기술 트랜드라고 하는 것들이 나온지는 꽤 되었지만 RDBMS처럼 범용적으로 사용되고 있지는 않습니다.

이렇게 범용되지 않은 이유는 기존에 선점했던 관계지향형 데이터베이스(RDB)로 많은 사람들이 데이터 베이스를 만들기 시작해서 많은 서비스를 하는 프로그램을 만들었습니다.

이러한 이유로 RDBMS 전문가들이 생겨나게 되었고, 현재 사용되어지고 있기 때문이다.

NoSQL은 데이터베이스이기도 하지만 RDBMS와는 전혀 다른 성격을 가지고 있고, 접근 방식과 모델링 방식이 다르기 때문에 관계지향형 데이터베이스(RDBMS)를 먼저 배웠던 전문가들은 NoSQL에 대해서 접근하기에 개념적으로 힘든점이 많았기에 NoSQL이 활발한 활동이 진행되지 않았던 것입니다.

NoSQL은 데이터 모델에 따라서 성능이 많은 차이가 납니다. 이글에서는 NoSQL 데이터 모델링 기법에 대해서 소개하고자 합니다.

NoSQL 데이터 모델

데이터 모델링에 앞서서 NoSQL이 어떤 구조로 데이터를 저장하는 지 먼저 이해할 필요가 있습니다.

데이터 모델링은 패턴에 따라서 크게 3가지로 나뉠 수 있습니다.

1. Key/Value Store

2. Ordered Key/Value Store

3. Document Key/Value Store

로 1번 Key/Value Store를 기본 베이스로 시작해서 하나하나 특정한 기능을 하는 기능을 추가하는 형태입니다.

2번에는 Sorting을 활용해서 Ordered Key/Value를 활용할 수 있다는 장점을 보여줍니다.

3번에는 Key/Value의 저장을 Document를 이용해서 저장한다는 점에서 장점을 보여줍니다.

다음으로 하나하나씩 1번부터 3번까지 설명하겠습니다.

1. Key/Value Store

가장 기본적인 패턴으로 데이터베이스를 저장하는 unit으로써 많이 사용하고 있습니다.

대부분의 NoSQL은 다른 데이터 모델을 지원해도 기본적으로 Key/Value의 개념을 지원해줍니다.

Key/Value Store란, Unique한 Key에 하나의 Value를 가지고 있는 형태입니다. put(key, value) 로 데이터를 input하고, get(key)를 이용해서 데이터를 output합니다.

Value는 String이나 Integer와 같은 Primitive 타입이 될 수 있지만, 이 정도로는 우리가 일반적으로 사용하는 테이블 형태의 저장할 수 없기 때문에,

조금 더 확장된 개념을 사용하는데, Cloumn Family라는 개념을 사용합니다. Key에 연결된 Value를 (Column, Value) 조합으로 된 여러개의 필드를 갖습니다.

이 여러개의 필드들을 합쳐서 Column Family라고 합니다.

예를 들면, 어플리케이션 서비스를 가입했을 때, 사용자의 프로필정보를 저장한다고 생각하자.

사용자의 고유 ID를 Key라고 하면, 성별, 주소, 나이 들은 각각의 Column이 될 수 있습니다. 그리고 이 Column안에는 Value로 남자, 대구시, 24세와 같은 Input을 넣을 수 있습니다.

RDBMS와 비교를 해봤을 때, Key는 Primary Key로 만들 수 있고, Column은 일반 데이터를 저장할 필드라고 생각하시면 됩니다.

프로그램 Key/Value Store의 자료구조는 Map과 같습니다.

이 NoSQL의 데이터 모델링 패턴은 Oracle Coherence, Redis 등이 있습니다.

2. Ordered Key/Value Store

앞서 설명했듯이 Key/Value Store의 확장된 형태입니다.

데이터를 저장하는 방식은 동일하나, 데이터가 내부적으로 Key를 기준으로 Sorting되어서 저장되어진다는 점이 다릅니다.

Sorting이 기능이 추가되어지면서, NoSQL에서는 상당한 성능개선을 해줄 수 있습니다.

NoSQL은 데이터를 Order By라는 기능을 제공하지 않기 때문에, 데이터를 Sorting하여 데이터를 활용할 수 있다라는 것이 성능에 대한 향상을 이끌 수 있습니다.

이 NoSQL의 데이터 모델링 패턴은 Apache의 Hbase, Cassandra 등이 있습니다.

3. Document Key/Value Store

2번과 마찬가지로 1번이 기본적인 베이스로 확장된 형태의 데이터 모델링 패턴입니다.

즉, Key/Value Store입니다. Key에 해당하는 Value 필드에 데이터를 저장하는 구조는 같으나,

저장되는 Value를 Document로 대신하여 JSON, XML, YAML과 같은 구조화된 데이터 타입으로 복잡한 계층으로 데이터를 저장할 수 있습니다.

추가적으로, Document Store 기반의 NoSQL은 제품에 따라 다르기는 하지만 추가적인 Sorting, Join, Grouping 과 같은 RDBMS 에서 제공하는 기능을 제공합니다.

이 NoSQL의 데이터 모델링 패턴은 MongoDB, CouchDB, Riak 등이 있습니다.

RDBMS와 NoSQL의 차이

NoSQL이 DBMS라고 생각해서 RDBMS와 비교했을 때 최소한 떨어지지않은 기능과 성능을 제공할 것이라는 생각을 많이 합니다.

하지만 이 것은 데이터 모델링이 잘되어서 활용이 잘 되었을 때 이야기지 오히려 더비효율적으로 사용되고 성능이 떨어지는 경우도 많습니다.

이런 단점이 발생하는 이유는 간단합니다. NoSQL에서 제공해주는 기능이 단순하다라는 이유입니다.

간단하게 설명하자면 NoSQL은 1) 데이터를 저장한다. 2) Key값에 대한 PUT/GET만 지원합니다.

나머지 RDBMS에서 사용하던 너무나 당연한 기능들이었던 

1) Sorting(데이터를 기준으로 정렬하는)

2) Join(의미있는 데이터를 합쳐서 사용하는)

3) Grouping(의미 있는 그룹별로 묶어서 데이터를 활용하는)

4) Range Query(원하는 범위내에 있는 데이터에 쿼리하는)

5) Index(데이터에 Index를 지정하여 성능을 높이는)

를 사용 못하는 부분들이 많기 때문에 NoSQL에서는 이 기능들과 같은 역할을 하는 것을 "NoSQL 데이터 모델링 패턴" 소개를 통해서 어떻게 구현할 수 있는 것인가를 알아 볼 것입니다.

NoSQL 데이터 모델링 시작하기

NoSQL 데이터 모델링은 NoSQL에 저장할 데이터들의 구조를 정의하는 작업입니다.

RDBMS로 표현하면, 테이블을 설계한다고 표현할 수 있습니다.

NoSQL은 우리가 이제까지 사용해왔던 RDBMS와 그 특성이 매우 다르기 때문에 접근 방법을 바꿔서 설계를 진행해야합니다.

NoSQL과 RDBMS의 데이터 모델링 차이

NoSQL을 사용해서 데이터 모델링을 하려면 기본의 RDBMS에서 가지고 있는 접근 방식 2가지를 바꾸어야합니다.

1) 개체 모델 지향 => 쿼리 결과 지향 모델링

:

RDBMS의 모델링 기법은

저장하고자하는 도메인 모델을 먼저 분석한 후에,

개체간의 관계(Relationship)를 식별하고,

테이블을 추출해내고,

테이블을 이용하여 쿼리를 구현하여,

쿼리를 요청하여 결과를 뽑아내는 방식입니다.

NoSQL의 경우에는 이 접근 방식을 역순으로 진행해야합니다.

RDBMS가 테이블=>쿼리

NoSQL은 도메인모델=>쿼리결과=>테이블

순서로 테이블을 디자인합니다.

RDBMS의 경우, 여러가지 최적화된 기능으로 테이블을 가지고 자유롭게 쿼리 결과를 뽑아 낼 수 있지만,

NoSQL의 경우, 복잡한 쿼리 기능이 없기 때문에, 반대로 도메인 모델에서 어떤 쿼리 결과가 필요한지 정의한 후에,

이 쿼리 결과를 얻기 위한 데이터 저장 모델을 역순으로 디자인합니다.

2) 정규화 => 비정규화(DeNormalization)

:

RDBMS 모델링에서는 데이터의 일관성과 도메인 모델과의 일치성을 위해서 데이터 모델을 정규화합니다.

그 중에서도 같은 데이터가 두 개이상 테이블에 중복되게 저장되는 경우를 제거하는 과정도 있습니다.

NoSQL는 반대의 접근 방법이 필요합니다. 쿼리의 효율성을 위해서 데이터를 정규화하지 않고, 의도적으로 중복된 데이터를 저장하여 사용하는 비정규화된 데이터 모델 설계 방식으로 접근을 해야합니다.

NoSQL 데이터 모델링 절차

이제는 RDBMS와 NoSQL의 두가지 결정적인 차이를 인식하고 , NoSQL 기반의 데이터 모델링 절차를 알아보겠습니다.

1, 도메인 모델 파악

RDBMS는 일단,

저장하고자하는 도메인을 파악합니다.

어떤 데이터 개체가 있는지 개체간의 관계는 어떻게 되는지 등을 분석하고,

ERD를 그려서 도식화 합니다. 이러한 방식으로 데이터를 모델링합니다.

이제까지 이야기를 한 바에 따르면 RDBMS와 반대되는 관점으로 가져가라는 식의 이야기를 많이 했는데,

설계를 할 때, 그 설계의 절차에 대해서 반대의 관점에서 보는 것이지, 이해의 관점에서는 그렇지 않습니다.

일단은 설계하기 전 단계에서 이해를 확실하게 할 수 있어야합니다. 그래야 좋은 모델이 나올 수 있습니다.

다음은 간단한 블로그 시스템의 데이터 도메인 모델입니다.

블로그 시스템은 사용자 ID기반으로 블로그를 분류하고 ,

분류별로 글을 작성할 수 있으며,

글에 파일을 첨부할 수 있고,

댓글을 달 수 있는 블로그입니다.

검색이나 페이징과 같은 다른 차원의 구조와 알고리즘을 더해야하는 경우는 여기서 제외하고 위의 4단계를 구성한 다이어그램을 구할 수 있습니다.

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

다음으로 가장 중요한 과정인 쿼리 결과를 중심 자료로 해서 만드는 쿼리 결과 디자인입니다.

"도메인 모델"을 기반으로 애플리케이션에 의해서 쿼리되는 결과값을 먼저 정해야합니다. 

앞에서 예를 든 블로그의 시스템을 예시로 보겠습니다.

1) 사용자의 포스팅에 대해 필요한 분류명들을 목록식으로 출력합니다.

2) 포스팅 출력 화면에서 상단에, 포스팅의 분류명과 제목을 출력하고 다음에는 포스팅 날짜, 본문 내용을 출력한다.

3) 다음에는 첨부파일들을 출력하는데 , 첨부파일 업로드 날짜와 파일명을 차례대로 출력하고, 파일에 대한 링크를 출력한다.

4) 마지막으로 댓글을 출력하는데, 댓글에는 작성일과, 작성자 이름과 댓글 내용을 출력하고, 작성자 이름에는 이메일을 링크한다.

즉 쉽게 이야기 하면, 필요한 기능별로 분류명을 만들고, 예를 들면, 포스팅 기능 분류

분류명이 만들어진 해당 기능에 대해서 어떤 내용인지에 대해서 예를 들면, 포스팅 제목, 포스팅 날짜, 본문 내용, 첨부파일, 댓글과 같은 내용을 쓰고,

그 내용에 대해서 어떤 변수가 필요한지에 대해서 그 내용 밑에 쓰도록 합니다.

이제 다음으로 이 출력이 된 형식을 기반으로, 어떤 쿼리가 필요한지를 정의해보겠습니다.

대략적으로 4개의 쿼리가 필요합니다. 4개의 쿼리를 살펴보면

1번 쿼리) 일단, 전체 분류명을 가져오는 쿼리입니다.

2번 쿼리) 그리고 포스팅의 내용인 분류, 제목, 날짜, 본문에 대해서 출력합니다.

3번 쿼리) userID, postID 를 이용해서 해당하는 첨부 파일을 출력합니다.

4번 쿼리) userID, postID를 이용해서 댓글을 출력합니다.

다음은 1번부터 4번까지 쿼리에 맞게 그림으로 잘 나타낸 것입니다.

위와 같이 애플리케이션의 출력형태에 따라서 데이터를 정리할 수 있습니다.

NoSQL의 데이터 모델링은 도메인 모델을 중심으로 하는 것이 아니고,

애플리케이션의 데이터 출력 내용을 기반으로 하기때문에 위와 같은 구조가 나오게 됩니다.

쉽게 이야기 하면 NoSQL을 이용한 구조를 만드는 방식은 어플리케이션을 다 만들고 나서 어플리케이션에서 요구하는 내용으로 설계를 합니다.

3. 패턴을 이용한 데이터 모델링

어플리케이션 데이터의 출력 내용을 디자인 했으면 이제 이 내용을 가지고 NoSQL에 정의될 데이터 모델링을 들어간다.

NoSQL은 Sorting, Grouping, Join 등과 같은 RDBMS에서 제공하는 기능이 없기 때문에,

PUT/GET으로만 데이터를 가지고 올 수 있는 형태로 데이터 모델 즉, NoSQL 내의 테이블을 재정의 해야합니다.

여기서 테이블을 재정의하는 과정에서 가장 중요한 것은 Demoralization입니다.

데이터를 가급적 중복으로 저장해서 한번에 데이터를 읽어오는 횟수를 줄이도록 합니다.

Document를 통째로 데이터를 가져오는 데이터모델의 특성상 I/O가 엄청나게 부담되기 때문에 한 번에 저장할 때 Document에 다 넣고,

한번에 불러오는 게 I/O도 줄이고 좋은 방법입니다.

Key 부분을 주목해 볼 필요가 있습니다. Join이 없는 것을 대체하기 위해서 Posting에서 userID나 postID를 ':'로 구분하여 Key에 동시에 포함시켜버렸습니다.

또한 Join 연산을 대체하고 나서 다른 이유가 있습니다.

Ordered Key Value Store 패턴을 보면 Key를 기반으로 소팅하기 때문에,

첫 번째로, postId를 Sequential 하게 증가 시켜 나가면, 같은 사용자의 글은 순서대로 되어서 Sorting이 가능합니다.

두 번째로, Grouping으로 포스팅을 출력하는 사용자에 대해서 posting을 전부 출력나가면, 순차적으로 post가 출력되고,

해당 사용자의 포스팅 데이터가 끝이나면, Key의 userID가 다른 사용자ID로 바뀌기 때문에 where문장이 없어도, 특정 사용자의 포스팅을 순차적으로 출력할 수 있다.

뒤에서 설명한 데이터 모델링 패턴에 Enumerable Key와 Composite Key Index 패턴을 참고하면 된다.

4. 최적화를 위해 필요한 기능들을 리스팅

지금까지 NoSQL 디자인이 어느정도 되었습니다. 이제는 NoSQL의 특성을 반영하여 조금 더 디테일한 디자인을 할 수 있습니다.

다시 애플리케이션 및 데이터의 특성을 살펴보겠습니다.

첨부 파일(Attachment)의 경우에는 포스팅이 작성되었을 때 레코드가 추가되며, 변경이 거의 없다.

그리고 첨부파일의 수는 그리 많지 않기 때문에, 하나의 필드에 모두 몰아서 저장할 수 있다.

이렇게 하나의 필드에 여러개의 데이터를 저장할 경우에는 Document Store을 고려해 볼 수 있다.

그리고 앞에서도 언급했지만 블로그 포스트, 첨부파일, 댓글은 Sorting되어야 하기에 Ordered Key 형태가 필요합니다.

현재 데이터 모델은 포스팅이 포스트된 순서대로만 출력하는 형태인데,

분류개념이 있기 때문에, 분류에 따라서 포스팅을 출력하려면 분류필드를 별도 필드로 들어가야하고, 이 필드에 따라 where문으로 select할 수 있어야 합니다.

그렇게 하기 위해서는 RDBMS의 Index와 같은 개념이 필요한데 이러한 기능을 NoSQL에서는 Secondary Index라고 합니다.

쉽게 정리하자면 Attachment의 테이블을 차라리 Posting 테이블의 attachment라는 document 데이터 타입을 적용한 정보로 저장을 하자는 것입니다.

그리고, categoryID의 값은 Secondary Index로 사용해서 인덱싱을 하자는 것입니다.

NoSQL 제품들은 Key-Value Store, Oredered Key-Value Store, Document Store 방식의 데이터 모델 패턴이 존재되지만,

세세한 기능부터 처리하는 방식은 조금씩 매우 다르다. 그래서 세세한 부분을 다 고려해서 기능별로 서버에 미치는 영향을 판단해봐야하는데,

그러한 Reference가 많지 않은게 현실이다. 그렇기 때문에 설계하는데에 많은 에로사항들이 존재하지만,

분명 데이터베이스의 이점이 있다면 찾아가면서 구현해야하는 몫이 개발자에게는 따른다.

5. 후보 NoSQL 선정 및 테스트

앞에서 언급한 바와 같이, 모델링한 데이터 구조를 효과적으로 실행할 수 있는 NoSQL을 찾아야합니다.

이는, NoSQL에 대한 구조 및 특성을 분석하고 실제로 부하테스트, 안정성, 확장성 테스트를 거친 후에, 가장 적절한 솔루션을 선택해야합니다.

경우에 따라서는 하나의 NoSQL을 사용하는 것이 아니라 여러가지의 NoSQL을 복합적으로 사용하는 경우도 있습니다.

저 같은 경우에는 서버의 중심이 되는 NoSQL 같은 경우에는 MongoDB를 사용하고 있고, 자잘한 기능들을 지원하는 보조 서버로는 AWS의 DynamoDB를 활용해서,

현재 서비스를 하고 있는 중입니다.

트위터나 페이스북과 같은 대규모의 서비스들은 하나의 NoSQL만을 사용하지않고 데이터의 성격과 업무의 목적에 맞는 다수의 NoSQL을 선정하여 사용합니다.

6. 선택한 NoSQL에 만들어진 데이터 모델을 최적화하고 하드웨어 디자인

마지막으로 선택한 NoSQL을 기반으로 다시 데이터 모델을 최적화 하고, 이에 맞는 애플리케이션 인터페티스 설계와 하드웨어에 대한 디자인을 진행합니다.

이상으로, NoSQL의 데이터 모델링 절차에 대해서 알아보았다.

RDBMS가 데이터 자체의 관계를 중시하기에 데이터에서 모든 모델링이 된다고 하면,

NoSQL은 애플리케이션이 출력하고자 하는 데이터 출력 내용에 따라서 데이터 모델링이 완성된다.

즉, RDBMS-데이터중심, NoSQL-애플리케이션의 요구되는 것. 두가지의 모델링 방식은 역순이라고 표현하는게 맞다.

NoSQL은 신 기술 분야이고, 오픈 소스 진영에서 주를 이루고 있기에 기술 지원이 힘들다.

외국에서는 NoSQL에 대해서 유상으로 기술 지원을 해주는 업체들이 있기는 한데, 외국 엔지니어를 부르는데에 국내에서는 한계가 있다.

NoSQL에 대한 서적도 그리 많지 않은 편이기 때문에 공부하기도 어렵다.

해외에서는 이러한 NoSQL류를 쓰는 업체들은 스스로 내부 개발자들이 역량을 키워서 공부하고, 테스트해서 내재화된 기술을 기반으로 NoSQL을 운용한다.

NoSQL의 도입은 기업의 기술 내재화 관점에서 도입을 고려하는 게 좋다.

*Reference

1. NoSQL 데이타 모델링 #1-데이타모델과, 모델링 절차 - http://bcho.tistory.com/665