2. Data Models and Query Languages

데이터 모델은 소프트웨어 개발에 중요하다. 데이터가 다음 아래 층에 대해 어떤 방식으로 표현되는가? 이에 대해 그에 최적인 자료 구조를 선택하거나, 일반적인 JSON/XML 문서로 표현해서 여러 방식으로 탐색/검색/조작/처리되고, 저층에서는 하드웨어에서 바이트가 어떻게 처리되는지를 생각할 수 있다. 중요한 것은 각 층은 아래 층의 복잡도를 은닉해 깔끔한 데이터 모델을 제공해야 한다는 것이다. 데이터 모델에는 여러 종류가 있고 그 특성은 다르다. 각각의 데이터 모델을 학습하는 것은 어렵다. 여기서는 여러 데이터 모델을 간략하게 알아볼 것이다.

Relational Model Versus Document Model

알려진 최고의 데이터 모델은 관계 모델에 기반한 SQL일 것이다. 이는 데이터 처리에 많이 쓰인다. 이외에도 네트워크 모델과 계층적 모델들이 있다. 컴퓨터들이 네트워크화되고 강력해짐에 따라 이들도 많이 쓰이고 있다.

The Birth of NoSQL

NoSQL은 SQL을 탈피하기 위한 움직임이었다. 이는 더 큰 확장성에 대한 요구, 무료 오픈 소스 소프트웨어에 대한 선호, 관계형 모델과 잘 맞지 않는 특수화된 쿼리 연산, 관계형 모델의 제한에 대한 극복 들로부터 유도되었다. 이에 대한 시도는 여러 시도가 있었다.

The Object-Relational Mismatch

많은 애플리케이션은 객체지향 프로그래밍 언어에 기반하는데 이로 인해 SQL에서는 애플리케이션 코드와 데이터베이스 모델간 부조화가 존재한다. JSON으로 인코딩하면 더 나은 경우도 있지만 그것은 국소성이 더 나은 것이고 항상 그런 것은 아니다.

Many-to-One and Many-to-Many Relationships

관계에는 다대일 관계와 다대다 관계가 있다. 이를 잘 구별하는 것이 중요하다. 데이터 중복으로 인한 오버헤드를 줄이는 것은 데이터베이스의 표준화의 핵심이다. 그러나 이는 다대일 관계를 필요로 하므로 문서 모델에는 적합치 않다. 데이터베이스가 조인을 지원하지 않으면 조인을 직접 흉내낼 수 있다.

Are Document Databases Repeating History?

데이터베이스를 어떻게 표현할 것인가에 대해서는 NoSQL 이전에도 많은 논란과 시도가 있었다. 관계형 모델, 네트워크 모델이 많이 쓰인다.

The network model

네트워크 모델은 계층화 모델을 일반화한 CODASYL 모델로부터 유래되었다. 이의 각 데이터는 접근 경로를 갖는다.

The relational model

이와 반대로 관계형 모델은 모든 데이터를 개방형으로 하여, 쿼리 최적화자가 쿼리의 어느 부분이 어느 순서로 실행될지를 결정한다. 이는 확장하기에도 쉽지만, 숙달되기는 어렵다.

Comparison to document databases

중첩된 기록을 저장하기에는 계층적 모델이 문서화된 데이터베이스보다 더 적합하다. 하지만 다대일/다대다 관계를 표현할 때에는 관계형 데이터베이스와 문서화 데이터베이스는 크게 다르지 않다.

Relational Versus Document Databases Today

관계형 데이터베이스와 문서화된 데이터베이스간 비교에는 여러 요소가 있다. 문서화 데이터베이스의 이점은 스키마 유연성, 더 좋은 성능, 일부 경우에 한해 더 좋은 표현력 등이 있다. 관계형 모델은 조인, 다대일/다대다 관계에 대한 더 좋은 표현 등의 이점이 있다.

Which data model leads to simpler application code?

데이터가 문서형이면 문서 모델을 쓰는 것이 좋다. 관련된 기법은 슈레딩으로, 문서를 복수의 표로 분할하는 것이다. 구조가 중첩될 경우에 이는 문제가 있을 수 있다. 조인에 대한 빈약한 지원은 문제가 될 수도 있다. 하지만 다대다 관계를 써야 한다면 문서 모델이 아니라 관계형 데이터베이스를 쓰는 것이 낫다. 어떤 모델이 애플리케이션 코드를 간소화시키는지는 상황에 따라 다르다.

Schema flexibility in the document model

많은 문서 데이터베이스는 특정 스키마를 강제하지 않는다. 그러나 이것은 스키마가 없다는 것이 아니라 데이터가 읽어질 때 스키마가 묵시적으로 정해진다는 것일 뿐이다. 이는 프로그래밍 언어에서 동적 타입 체킹과 비슷하다. 이에 반해 쓰기 시 스키마는 정적 타입 체킹과 비슷하다. 이는 데이터의 포맷을 바꿔야 하는 마이그레이션을 수행할 때 차이가 있을 수 있다. 데이터 형태가 불균질할 때 읽기 시 스키마는 이점이 있다.

Data locality for queries

쿼리에 대해서 같은 쿼리 내 데이터가 인접하면 데이터 국소성 면에서 이점을 갖는다. 이는 문서의 큰 부분을 동시에 필요로 할 때만 이점이 있다. 이는 문서 모델뿐만 아니라 다른 데이터베이스 모델에 대해서도 똑같이 해당되는 이야기이다.

Convergence of document and relational databases

시간에 따라 관계형과 문서형 데이터베이스는 서로 비슷해져가고 있다. 미래에는 이의 혼성이 주 모델이 될 것이다.

Query Languages for Data

SQL은 선언적 쿼리 언어고 IMS/CODASYL은 명령형 코드이다. 선언적 쿼리 언어에서는 데이터의 패턴을 특정해주기만 하면 된다. 또한, 데이터베이스 엔진의 세부 구현을 숨긴다. 또한 그 자체로 병렬화하기도 쉽다. 명령형 코드는 병렬화하기 어렵다.

Declarative Queries on the Web

명령형 쿼리문의 이점은 데이터베이스에만 한정된 것이 아니라 웹상에서도 이점이 있다.

MapReduce Querying

MapReduce는 여러 기기간 많은 양의 데이터를 처리하는 프로그래밍 모델이다. 이는 선언적 쿼리 언어도 아니고 완전한 명령형 API도 아니다. 쿼리의 논리는 코드 스니펫으로 표현되고, 이는 처리 프레임워크에 의해 연속적으로 호출된다. map과 reduce는 순수 함수여야만 한다. MapReduce는 여러 기기간 분산형 실행에 대해 꽤 저수준의 프로그래밍 모델이다. 단점은 두 JavaScript 함수를 주의 깊게 써야 한다는 것이다.

Graph-Like Data Models

다대다 관계가 데이터에 매우 보편적이면 그래프 모델을 쓰는 것이 좋다.

Property Graphs

그래프에서 정점은 고유한 식별자, 데이터, 나가는/들어오는 간선이 존재한다. 각 간선은 고유한 식별자, 시작/끝 정점, 간선의 종류, 데이터가 존재한다. 어느 정점간에도 연결이 가능해야 하며 각 정점에 대해 나가는/들어오는 간선을 쉽게 찾을 수 있어야 한다. 간선간에는 서로 다른 관계라면 다른 분류를 해서 데이터 모델을 깔끔하게 유지하는 것이 좋다. 그래프 구조는 데이터 모델링에 큰 유연성을 갖는다. 이는 확장성도 좋다.

The Cypher Query Language

Cypher는 특성 그래프에 대한 선언적 쿼리문이다.

Graph Queries in SQL

SQL에서도 그래프 구조를 쓸 수 있지만 좀 더 어렵다. 조인의 필요한 수를 미리 알 수 없기 때문이다.

Triple-Stores and SPARQL

3항-저장 모델은 모든 정보가 3항으로 저장된다.

The semantic web

시맨틱 웹은 2000년대 초에는 주목받았지만 요즘은 그렇지 않다.

The RDF data model

Turtle 언어는 자원 기술 프레임워크(RDF) 데이터 모델의 예이다.

The SPARQL query language

SPARQL은 3항 저장 모델에 대해 RDF 데이터 모델을 쓰는 쿼리 언어이다.

The Foundation: Datalog

Datalog은 SPARQL이나 Cypher보다 훨씬 오래되었다.

Summary

데이터 모델은 큰 주제로, 이 장에서는 여러 다른 모델을 빠르게 알아보았다. 역사적으로, 데이터는 하나의 큰 트리(계층적 모델)로 시작했으나, 이는 다대다 관계를 표현하기에 적합하지 않았으므로, 관계형 모델이 이를 해결하기 위해 개발되었다. 최근에, 개발자들은 어떤 애플리케이션들은 관계형 모델도 적합하지 않다는 것을 발견하였다. 비관계적 NoSQL 데이터베이스는 크게 2가지로 분화하였다:

  1. 문서화 데이터베이스. 데이터가 독립적 문서로 이루어져 있고 문서간 관계는 드문 경우.
  2. 그래프 데이터베이스. 모든 것이 모든 것과 잠재적으로 관계될 수 있는 데이터베이스.

3개의 모델 모두 많이 쓰이며, 관련 도메인에서 모두 좋다. 한 모델은 다른 모델에서 모방될 수 있으나 그 결과는 신통치 않다. 그래서 하나의 범용 시스템을 쓰는 것이 아니라 다른 목적에 대해 다른 시스템을 쓰는 것이다. 문서와 그래프 데이터베이스의 공통점은 저장하는 데이터의 스키마를 강제하지 않음으로써 요구 사항 변경을 쉽게 만든다는 것이다. 하지만, 데이터에는 특정한 구조가 여전히 존재한다: 그것이 명시적 (쓰기 시 강제)인가 묵시적(읽기 시 정해짐)인가 차이가 있을 뿐이다. 각 데이터 모델은 각 쿼리 언어나 프레임워크를 동반한다. SQL, MapReduce, MongoDB, Cypher, SPARQL, Datalog. 추가로 CSS, XSL/XPath는 데이터베이스 쿼리 언어는 아니지만 다른 흥미로운 부분들이다. 이외에도 다른 데이터 모델들이 있다.

  • 서열 유사도 검색을 수행하는 연구자들은 GenBank 등을 쓴다.
  • 입자 물리학자들은 수백 페타바이트에 대한 연산을 필요로 한다.
  • 완전 텍스트 검색은 위의 3개의 모델로 다뤄지지 않는 가장 널리 쓰이는 예일 것이다.

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중