[데이터 중심 애플리케이션 설계] 관계형 모델과 문서 모델

 

1) 서문

 

- 데이터 모델은 아마도 소프트웨어 개발에서 제일 중요한 부분일 것이다.

  왜냐하면 데이터 모델은 소프트웨어가 어떻게 작성됐느닞 뿐만 아니라 해결하려는 

  문제를 어떻게 생각해야 하는지에 대해서도 지대한 영향을 미치기 때문이다.

 

- 대부분의 애플리케이션은 하나의 데이터 모델을 다른 데이터 모델 위에 계층을 둬서 만든다.

  각 계층의 핵심적인 문제는 다음 하위 계층 관점에서 데이터 모델을 표현하는 방법이다.

  예를 들어 보자. 

 

(1) 애플리케이션 개발자는 현실(사람, 조직, 상품, 행동, 자금 흐름, 센서 등)을 보고 

     객체나 데이터 구조, 그리고 이러한 데이터 구조를 다루는 API를 모델링한다.

      이런 구조는 보통 애플리케이션에 특화돼 있다.

 

(2) 데이터 구조를 저장할 때는 JSON이나 XML 문서, 관계형 데이터베이스 테이블이나 

      그래프 모델 같은 범용 데이터 모델로 표현한다. 

 

(3) 데이터베이스 소프트웨어를 개발하는 엔지니어는 JSON/XML/관계형/그래프 데이터를

      메모리나 디스크 또는 네트워크 상의 바이트 단위로 표현하는 방법을 결정한다.

      이 표현은 다양한 방법으로 데이터를 질의, 탐색, 조작, 처리할 수 있게 한다.

 

(4) 더 낮은 수준에서 하드웨어 엔지니어는 전류, 빛의 파동, 자기장 등의 관점에서 

     바이트를 표현하는 방법을 알아냈다. 

 

- 복잡한 애플리케이션에서는 여러 API를 기반으로 만든 API처럼 중간 단계를 더 둘 수 있지만

  기본 개념은 여전히 동일하다. 각 계층은 명확한 데이터 모델을 제공해 하위 계층의 복잡성을 

   숨긴다. 이 추상화는 다른 그룹의 사람들(예를 들어 데이터베이스 벤더의 엔지니어와 

   데이터베이스를 사용하는 애플리케이션 개발자)이 효율적으로 함께 일할 수 있게끔 한다. 

 

- 다양한 유형의 데이터 모델이 있고, 각 데이터 모델은 사용 방법에 대한 가정을 나타낸다.

   어떤 종류의 사용법은 쉽고 어떤 동작은 지원하지 않는다.

   어떤 연산은 빠르지만 또 어떤 연산은 매우 느리게 작동한다.

   어떤 데이터 변환은 자연스럽지만 다른 어떤 데이터 변환은 부자연스럽다.

 

- 하나의 데이터 모델만을 완전히 익히는데도 많은 노력이 필요하다.

  (관계형 데이터 모델링 책이 얼마나 많은지 생각해보자)

  데이터 모델을 하나만 사용하고 내부 동작에 대한 걱정이 없을지라도 

  소프트웨어 작성은 그 자체로 충분히 어렵다. 

  그러나 데이터 모델은 그 위에서 소프트웨어가 할 수 있는 일과 

  할 수 없는 일에 지대한 영향을 주므로 애플리케이션에 적합한 데이터 모델을 선택하는

  작업은 상당히 중요하다. 

 

- 이번 장에서는 데이터 저장과 질의를 위한 다양한 범용 데이터 모델을 살펴본다. 

  특히 관계형 모델과 문서 모델, 그리고 몇 가지 그래프 기반 데이터 모델을 비교한다.

  또한, 다양한 질의 언어를 살펴보고 사용 사례도 비교한다.

  3장에서는 이런 데이터 모델이 실제로 어떻게 구현되는지 저장소 엔진의 동작 방식을 통해 설명하겠다.

 

 

2) 관계형 모델과 문서 모델

- 오늘날 가장 잘 알려진 데이터 모델은 1970년 에드가 코드가 제안한 관계형 모델을 기반으로 한 SQL이다.

  데이터는 관계로 구성되고 각 관계는 순서 없는 튜플 모음이다.

  

- 관계형 모델은 이론적 제안이었고 당시 많은 사람은 관계형 모델을 효율적으로 구현할 수 있을지 의문을 제기했다.

  하지만 1980년대 중반에 관계형 데이터베이스 관리 시스템과 SQL은 정규화된 구조로 데이터를 저장하고

  질의할 필요가 있는 사람들 대부분이 선택하는 도구가 됐다.

  관계형 데이터베이스의 우위는 약 25~30년 정도 지속됐다. 

 

- 관계형 데이터베이스의 근원은 1960년대와 1970년대에 메인프레임 컴퓨터에서 수행된 비즈니스 데이터 처리에 있다.

  이 사용 사례는 보통 트랜잭션 처리(영업이나 은행 거래, 항공 예약, 창고에 재고 보관)와

  일괄 처리(고객 송장 작성, 급여 지불, 보고)로 오늘날의 관점에서는 일상적으로 수행되는 일이다.

 

- 당시 다른 데이터베이스를 사용하는 애플리케이션 개발자는 데이터베이스의 내부 표현에 대해

  많이 고민해야 했지만, 관계형 모델의 목표는 정리된 인터페이스 뒤로 구현 세부 사항을 숨기는 것이다. 

  

- 수년 동안 데이터 저장과 질의를 위해 많은 접근 방식이 경쟁했다. 

  1970년대와 1980년대 초반에는 네트워크 모델과 계층 모델이 주요 대안이었지만 결국 관계형 모델이 우위를 차지했다.

  객체 데이터베이스는 1980년대 후반과 1990년 초반에 나타났다가 다시 사라졌다.

  XML 데이터베이스는 2000년대 초반에 등장했지만, 매우 적게 채택됐다.

  관계형 모델의 경쟁자들은 당시에 대대적으로 과장 광고를 했지만, 얼마 가지 않았다. 

 

- 컴퓨터가 훨씬 더 강력해지고 네트워크화됨에 따라 컴퓨터를 점점 더 다양한 목적으로 사용하기 시작했다.

  놀랍게도 관계형 데이터베이스가 비즈니스 데이터 처리라는 본래 영역을 넘어 폭넓은 다양한 사용 사례에도

  보편화되는 것으로 나타났다.

  오늘날 웹에서 볼 수 있는 대부분의 서비스(예를 들어, 온라인 게시물, 토론, 소셜 네트워크, 전자 상거래, 게임, SaaS

  생산성 애플리케이션 등)는 여전히 관계형 데이터베이스를 통해 제공된다. 

 

 

3) NoSQL의 탄생

- 현재 2010년대에 NoSQL은 관계형 모델의 우위를 뒤집으려는 가장 최신 시도다. 

  "NoSQL"이라는 이름은 실제로 어떤 특정 기술을 참고한 것이 아니기에 적절하지 않다.

  원래 NoSQL은 2009년에 오픈소스, 분산 환경, 비관계형 데이터베이스 밋업(meetup)용 인기 트위터 해시태그였다.

  그럼에도 이 용어는 신경을 자극했고, 웹 스타트업 커뮤니티를 넘어 빠르게 확산됐다. 

  

- 지금은 인기 있는 여러 데이터베이스 시스템과 #NoSQL 해시태그가 연관돼 있다.

   그래서 NoSQL은 다시 거슬러 올라가 Not Only SQL로 재해석됐다.

 

- NoSQL 데이터베이스를 채택한 데는 다음과 같은 다양한 원동력이 있다.

  (1) 대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성의 필요

  (2) 상용 데이터베이스 제품보다 무료 오픈소스 소프트웨어에 대한 선호도 확산

  (3) 관계형 모델에서 지원하지 않는 특수 질의 동작

  (4) 관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람

 

- 애플리케이션은 저마다 요구사항이 다르다. 한 사용 사례에 맞는 최적의 기술 선택은 또 다른 사용 사례에 맞는

  최적의 선택과는 다를 수 있다. 그러므로 가까운 미래에는 관계형 데이터베이스 폭넓은 다양함을 가진 

  비관계형 데이터스토어와 함께 사용될 것이다.

  이런 개념을 종종 다중 저장소 지속성(polyglot persistence)이라 한다. 

 

 

4) 객체 관계형 불일치

- 오늘날 대부분의 애플리케이션은 객체지향 프로그래밍 언어로 개발한다.

  이는 SQL 데이터 모델을 향한 공통된 비판을 불러온다. 

  데이터를 관계형 테이블에 저장하려면 애플리케이션 코드와 데이터베이스 모델 객체(테이블, 로우, 칼럼)

  사이에 거추장스러운 전환 계층이 필요하다.

  이런 모델 사이의 분리를 종종 임피던스 불일치(impedance mismatch)라고 부른다.

 

- 액티브레코드(ActiveRecord)나 하이버네이트(Hibernate) 같은 객체 관계형 매핑(ORM) 프레임워크는

  전환 계층에 필요한 상용구 코드(boilerplate code)의 양을 줄이지만,

  두 모델 간의 차이를 완벽히 숨길 수 없다. 

 

- 예를 들어 그림 2-1은 관계형 스키마에서 이력서(링크트인 프로파일)를 어떻게 표현하는지 보여준다.

   프로필 전체는 고유 식별자인 user_id로 식별한다.

   first_name과 last_name 같은 필드는 사용자마다 정확하게 하나씩 있어 users 테이블의 칼럼으로

  모델링할 수 있다.

  하지만 대부분의 사람들은 경력(직위)에 넣을 직업이 하나 이상이며 학력 기간과 연락처 정보도 다양하다.

  사용자와 이들 항목은 일대다(one-to-many) 관계다.

  이 관계는 다양한 방법으로 나타낼 수 있다.

 

 

- 이력서 같은 데이터 구조는 모든 내용을 갖추고 있는 문서라서 JSON 표현에 매우 적합하다.

  예제 2-1을 보자. JSON은 XML보다 훨씬 더 간단해 매력적이다. 

  몽고DB(MongoDB), 리싱크DB(RethinkDB), 카우치DB(CouchDB)와 에스프레스(Espresso) 같은 

  문서 지향(document-oriented) 데이터베이스는 JSON 데이터 모델을 지원한다. 

 

- 일부 개발자는 JSON 모델이 애플리케이션 코드와 저장 계층 간 임피던스 불일치를 줄인다고 생각한다.

   4장에서 설명하겠지만 데이터 부호화 형식으로서 JSON이 가진 문제도 있다.

   스키마의 부족을 장점으로 종종 인용하기도 하는데, 이에 대해서는 39쪽의 '문서 모델에서의 스키마 유연성'

   에서 설명하겠다.

 

- JSON 표현은 그림 2-1의 다중 테이블(multi-table) 스키마보다 더 나은 지역성(locality)을 갖는다.

  관계형 예제에서 프로필을 가져오려면 다중 질의를 수행하거나 users 테이블과 그 하위 테이블 간에

  난잡한 다중 조인을 수행해야 한다. JSON 표현에서는 모든 관련 정보가 한 곳에 있어 질의 하나로 충분하다.

 

- 사용자 프로필에서 사용자에서 직위, 학력 기록, 연락처 정보로 대응되는 일대다 관계는 의미상

  데이터 트리 구조와 같다. 이 트리 구조는 JSON 표현에서 명시적으로 드러난다.