2장. 데이터 모델과 질의 언어

주요 내용

1. 데이터 저장과 질의를 위한 다양한 범용 데이터 모델
   • 관계형 모델(relational model)
   • 문서 모델(document model)
   • 그래프 기반 데이터 모델(graph-based data model)
2. 다양한 질의 언어와 사용 사례

 

데이터 모델

• 소프트웨어가 어떻게 작성됐는지 뿐만 아니라 해결하려는 문제를 어떻게 생각해야 하는지에 대해서도 영향을 미친다.
• 소프트웨어가 할 수 있는 일과 할 수 없는 일에 지대한 영향을 주므로 적합한 데이터 모델을 선택하는게 중요하다.

 

관계형 모델과 문서 모델

관계형 모델

• 데이터는 관계(relation)로 구성되고, 각 관계는 순서없는 튜플(tuple) 모음이다.
• SQL은 1970년 Edgar Codd가 제안한 관계형 모델을 기반으로 한 데이터 모델이다.
• 정규화된 구조로 데이터를 저장하고 질의할 필요가 있는 경우  관계형 데이터베이스 관리 시스템(RDBMS)과 SQL이 사용된다.

 

NoSQL(Not Only SQL)의 탄생

• 대규모 데이터셋이나 메우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성 필요
• 상용 데이터베이스 제품보다 무료 오픈소스 소프트웨어에 대한 선호도 확산
• 관계형 모델에서 지원하지 않는 특수 질의 동작
• 관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람

 

애플리케이션마다 요구사항이 다르기 때문에, 가까운 미래에는 관계형 데이터베이스가 폭넓은 다양함을 가진 비관계형 데이터스토어와 함께 사용될 것이다. 이런 개념을 다중 저장소 지속성(polyglot persistence)이라 한다.

 

객체 관계형 불일치

• 임피던스 불일치(impedance mismatch) : 데이터를 관계형 테이블에 저장하는 경우 애플리케이션 코드와 데이터베이스 모델 객체 사이에 거추장스러운 전환 계층이 필요
• ActiveRecord나 Hibernate 같은 객체 관계형 매핑(ORM) 프레임워크는 전환 계층에 필요한 상용구 코드(boilerplate code)의 양을 줄이지만 두 모델 간의 차이를 완벽히 숨기지 못한다.
• 일부 개발자는 JSON 모델이 애플리케이션 코드와 저장 계층 간 임피던스 불일치를 줄인다고 생각한다.
  • ex) one-to-many(일대다) 관계를 갖는 이력서를 표현하는 경우 관계형 모델보다 JSON 데이터 모델이 더 적합
  • JSON 표현은 다중 테이블 스키마보다 더 나은 지역성을 갖기 때문에, 질의 하나로 프로필 정보를 가져올 수 있다.

 

다대일 관계

• 데이터의 중복을 제거하는 일은 데이터베이스 정규화의 핵심 개념이다.
• 중복된 데이터를 정규화하려면 다대일(many-to-one) 관계가 필요하다.
• 관계형 데이터베이스에서는 조인이 쉽기 때문에 ID로 다른 테이블의 로우를 참조하는 방식이 일반적이다.
• 문서 데이터베이스에서는 일대다 트리 구조를 위해 조인이 필요하지 않다.(조인에 대한 지원이 보통 약하다.)
• 데이터베이스 자체가 조인을 지원하지 않으면 데이터베이스에 대한 다중 질의를 만들어서 애플리케이션 코드에서 조인을 흉내내야 한다.

 

다대다 관계

• 관계형 데이터베이스는 일상적으로 다대다 관계와 조인을 사용한다.
• 문서 데이터베이스와 NoSQL 이전에도 데이터베이스에서 다대다 관계를 표현하는 제일 좋은 방법에 대한 논쟁이 있었다.
• 1970년대 계층 모델은 문서 데이터베이스처럼 일대다 관계에서는 잘 동작하지만, 다대다 관계 표현이 어렵고 조인을 지원하지 않는다. 개발자는 (비정규화된) 데이터를 중복할지, 한 레코드와 다른 레코드의 참조를 수동으로 해결할지 결정해야 했다.
• 이때 제시된 해결책 두 가지가 관계형 모델과 네트워크 모델이다.

 

네트워크 모델(코다실 모델)

• 네트워크 모델은 계층 모델을 일반화하고, 네트워크 모델에서 레코드는 다중 부모가 있을 수 있다.
• 다대일과 다대다 관계를 모델링할 수 있다.
• 레코드 간 연결은 외래 키보다는 프로그래밍 언어의 포인터와 비슷하고, 레코드에 접근하는 유일한 방법은 최상위 레코드(root record)에서부터 연속된 연결 경로를 따르는 것이다. 이를 접근 경로라 한다.
• 다대다 관계에서는 다양한 다른 경로가 같은 레코드로 이어질 수 있어서 다양한 접근 경로를 계속 추적해야 한다.
• 계층 모델과 네트워크 모델 모두, 원하는 데이터에 대한 경로가 없다면 어려운 상황에 놓이게 된다. 접근 경로를 변경할 수 있지만 아주 많은 수작업 데이터베이스 질의 코드를 살펴봐야 하고 새로운 접근 경로를 다루기 위해 재작성해야 하는 문제가 있다.

 

관계형 모델

•  관계(테이블)는 단순히 튜플(로우)의 컬렉션이 전부이다.
• 중첩 구조와 데이터를 보고 싶을 때 따라가야 할 복잡한 접근 경로가 없다.
• 임의 조건과 일치하는 테이블의 일부 또는 모든 로우를 선택해서 읽을 수 있고, 일부 컬럼을 키로 지정해 컬럼과 일치하는 특정 로우를 읽을 수 있다.
• 다른 테이블과의 외래 키 관계에 대해 신경쓰지 않고 임의 테이블에 새 로우를 삽입할 수 있다.
• 관계형 데이터베이스에서 질의 최적화기(query opimizer)는 질의의 어느 부분을 어떤 순서로 실행할지를 결정하고 사용할 색인을 자동으로 결정한다.(접근 경로)

 

문서 데이터베이스와의 비교

• 별도 테이블이 아닌 상위 레코드 내에 중첩된 레코드를 저장한다.
• 다대일과 다대다 관계를 표현할 때 관련 항목은 문서 참조라고 부르는 고유 식별자로 참조한다. 이 식별자는 조인이나 후속 질의를 사용해 읽기 시점에 확인한다.

 

관계형 데이터베이스와 오늘날의 문서 데이터베이스 선호 이유

• 문서 테이더 모델 : 스키마 유연성, 지역성에 기인한 더 나은 성능
• 관계형 모델 : 조인, 다대일, 다대다 관계 지원

 

문서 모델

• 애플리케이션에서 데이터가 문서와 비슷한 구조라면 문서 모델을 사용하는 것이 좋다.
• 제한 존재
  • 중첩 항목을 바로 참조할 수 없다. '사용자251의 직위 목록의 두 번째 항목'과 같이 표현해야 한다.
  • 조인 지원이 미흡하다.
  • 다대다 관계에서 훨씬 더 복잡한 애플리케이션 코드와 나쁜 성능으로 이어질 수 있다.
• 스키마 유연성
  • 종종 스키마리스(schemaless)로 불리지만 오해의 소지가 있다.
  • 데이터를 읽는 코드는 보통 구조의 유형을 어느 정도 가정한다. 즉 암묵적인 스키마가 있지만 데이터베이스는 이를 강요하지 않는다.
  • 정확한 용어로 읽기 스키마(데이터 구조는 암묵적이고 데이터를 읽을 때만 해석된다.)라고 한다.
  • 읽기 스키마 접근 방식은 컬렉션 안의 항목이 어떤 이유로 모두 동일한 구조가 아닐 때 유리하다.
  • 다른 여러 유형의 오브젝트가 있고 각 유형의 오브젝트별로 자체 테이블에 넣는 방법은 실용적이지 않다.
  • 사용자가 제어할 수 없고 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정된다.
• 질의를 위한 데이터 지역성
  • 관련 데이터를 함께 그룹화하는 개념
  • 애플리케이션이 자주 전체 문서에 접근해야 할 때 저장소 지역성(storage locality)을 활용하면 성능 이점이 있다.
  • 지역성의 이점은 한 번에 해당 문서의 많은 부분을 필요로 하는 경우에만 적용된다. 데이터베이스는 대개 문서의 작은 부분에만 접근해도 전체 문서를 적재해야 하기에 큰 문서에서는 낭비일 수 있다.
  • 문서를 갱신할 때도 보통 전체 문서를 재작성해야 한다.
  • 부호화된 문서의 크기를 바꾸지 않는 수정은 쉽게 수행할 수 있다.
  • 일반적으로 문서를 아주 작게 유지하면서 문서의 크기가 증가하는 쓰기는 피하는걸 권장한다.

 

데이터를 위한 질의 언어

• 명령형 언어
  • 특정 순서로 특정 연산을 수행하게끔 컴퓨터에게 지시한다.
  • 명령어를 특정 순서로 수행하게끔 지정하기 때문에 다중 코어나 다중 장비에서 병렬 처리가 매우 어렵다.
• 선언형 질의 언어
  • SQL이나 관계 대수
  • 결과가 충족해야 하는 조건과 데이터를 어떻게 변환할지를 결정하기만 하면 된다. 어떤 색인과 어떤 조인 함수를 사용할지, 질의의 다양한 부분을 어떤 순서로 실행할지는 질의 최적화기가 결정한다.
  • 명령형 API보다 더 간결하고 쉽게 작업할 수 있다.
  • 데이터베이스 엔진의 상세 구현이 숨겨져 있어 질의를 변경하지 않고도 데이터베이스 시스템의 성능을 향상시킬 수 있다.
  • 병렬 실행에 적합하다. 결과의 패턴만 지정하기 때문에 병렬 실행으로 더 빨라질 가능성이 있다.

• 맵리듀스 질의
  • 많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델
  • 몽고DB와 카우치DB를 포함한 일부 NoSQL 데이터 저장소는 제한된 형태의 맵리듀스를 지원한다.
  • 선언형 질의 언어도 완전한 명령형 질의 API도 아닌 그 중간 정도에 있고, 질의 로직은 처리 프레임워크가 반복적으로 호출하는 조각 코드로 표현한다.
  • 상당히 저수준 프로그래밍 모델이다.
  • 연계된 자바스크립트 함수 두 개를 신중하게 작성해야 한다.

 

그래프형 데이터 모델

• 다대다 관계가 일반적일 때 사용한다.
• 그래프는 정점(vertex, 노드나 엔티티라고도 한다.)과 간선(edge, 관계나 호(arc)라고도 한다.)으로 이뤄진다.
• 예시
  • 소셜 그래프 : 정점은 사람이고 간선은 사람들이 서로 알고 있음을 나타낸다.
  • 웹 그래프 : 정점은 웹 페이지고 간선은 다른 페이지에 대한 HTML 링크를 나타낸다.
  • 도로나 철도 네트워크 : 정점은 교차로이고 간선은 교차로 간 도로나 철로 선을 나타낸다.
• 그래프는 동종 데이터에 국한되지 않는다.
• 그래프를 동종 데이터와 마찬가지 방식으로 사용하면 단일 데이터 저장소에 완전히 다른 유형의 객체를 일관성 있게 저장할 수 있는 강력한 방법을 제공한다.
  • ex) 페이스북은 다른 유형의 정점과 간선을 단일 그래프로 유지한다. 정점은 사람, 장소, 이벤트 등을 나타내고, 간선은 어떤 사람이 서로 친구인지 누가 이벤트에 참여했는지 등을 나타낸다.
• 종류
  • 모델 : 속성 그래프 모델(Neo4j, Titan, InfiniteGraph 등으로 구현), 트리플 저장소 모델(Datomic, Allegrograph 등으로 구현)
  • 그래프형 선언형 질의 언어 : 사이퍼(Cypher), 스파클(SPARQL), 데이터로그(Datalog)

 

속성 그래프 모델

 

정점 구성 요소

• 고유한 식별자
• 유출(outgoing) 간선 집합
• 유입(incoming) 간선 집합
• 속성 컬렉션(키-값 쌍)

 

간선의 구성 요소

• 고유한 식별자
• 간선이 시작하는 정점(꼬리 정점)
• 간선이 끝나는 정점(머리 정점)
• 두 정잠 간 관계 유형을 설명하는 레이블
• 속성 컬렉션(키-값 쌍)

 

중요한 특징

• 정점은 다른 정점과 간선으로 연결된다. 특정 유형과 관련 여부를 제한하는 스키마는 없다.
• 정점이 주어지면 정점의 유입과 유출 간선을 효율적으로 찾을 수 있고 그래프를 순회할 수 있다. 즉 일련의 정점을 따라 앞뒤 방향으로 순회한다.
• 다른 유형의 관계에 서로 다른 레이블을 사용하면 단일 그래프에 다른 유형의 정보를 저장하면서도 데이터 모델을 깔끔하게 유지할 수 있다.

그래프는 발전성이 좋아서 애플리케이션에 기능을 추가하는 경우 애플리케이션의 데이터 구조 변경을 수용하게끔 그래프를 쉽게 확장할 수 있다.

 

 

사이퍼 질의 언어

사이퍼(Cypher)는 속성 그래프를 위한 선언형 질의 언어로, 네오포제이(Neo4j) 그래프 데이터베이스용으로 만들어졌다. 

 

SQL의 그래프 질의

재귀 공통 테이블식(recursive common table expression)(WITH RECURSIVE문)을 사용해서 표현할 수 있다.

 

트리플 저장소와 스파클

 

트리플 저장소에서는 모든 정보를 주어(subject), 서술어(predicate), 목적어(object)처럼 매우 간단한 세 부분 구문(three-part statements) 형식으로 저장한다.

 

주어

• 그래프의 정점

목적어

• 문자열이나 숫자 같은 원시 데이터타입의 값. 이 경우 트리플의 서술어와 목적어는 주어 정점에서 속성의 키, 값과 동등하다.
• 그래프의 다른 정점. 이 경우 서술어는 그래프의 간선이고 주어는 꼬리 정점이며 목적어는 머리 정점이다.

 

시멘틱 웹

RDF 데이터 모델

 

스파클 질의 언어

스파클(SPARQL)은 RDF 데이터 모델을 사용한 트리플 저장소 질의 언어다. 사이퍼보다 먼저 만들었고 사이퍼의 패턴 매칭을 스파클에서 차용했기 때문에 둘은 매우 유사해 보인다.

 

초석:데이터로그

스파클이나 사이퍼보다 훨씬 오래된 언어로, 서술어(주어, 목적어)로 작성한다.

사이퍼와 스파클과 비교했을 때, 두 가지 방식은 SELECT로 바로 질의하는 반면 데이터로그는 단계를 나눠 한 번에 조금씩 질의로 나아간다.

 

정리

	관계형 모델	문서 모델	그래프 모델
데이터 구조	테이블(행과 열)	계층적 문서 (JSON, XML 등)	노드와 엣지 (vertex-edge)
스키마	엄격한 스키마 (정의 필요)	유연한 스키마 (동적 구조 가능)	유연한 구조 (관계 중심)
질의 언어	SQL (표준화됨)	자체 API 또는 확장된 SQL	그래프 질의 언어 (Cypher, Gremlin 등)
관계 표현	외래 키 (JOIN 사용)	중첩 문서 또는 참조	직접적인 엣지로 관계 표현
중첩 구조 지원	지원 안 됨 (정규화 필요)	자연스럽게 지원	가능 (노드/엣지 구조에서 표현)
확장성 (수평 확장)	어렵지만 가능 (Sharding 복잡)	비교적 쉬움	어렵거나 제한적
일관성 모델	강한 일관성 (트랜잭션 지원)	보통 약한 일관성 (시스템에 따라 다름)	다양함 (ACID 또는 eventual)
적합한 사용 사례	전통적인 비즈니스 앱, 금융, ERP	콘텐츠 관리, 제품 카탈로그	소셜 네트워크, 추천 시스템, 사기 탐지
장점	성숙한 기술, 표준화된 도구 및 언어	유연성, 개발 편의성	복잡한 관계 표현에 적합
단점	스키마 변경 어려움, 복잡한 JOIN	중복 데이터, JOIN 비효율	대규모 확장이 어려움, 복잡도 증가