😊 Go to Learn이란?

K-devcon에서 주최하는 멘토링 프로그래밍으로 각 분야에서 전문가이신 멘토분들의 멘토링을 통하여 약 2-3달간 진행하는 프로그램입니다.

Go to Learn 1기 같은 경우 Flutter, Back-end, Full-stack, Writing 등 여러가지 주제가 담긴 멘토링 프로그램이 있었습니다.

그 중 Back-end를 중심으로 진행하는 DDIA 프로그램 같은 경우 데이터 중심 애플리케이션 설계라는 책을 매주 1장 씩 정독하고 요약하면서 괸련된 이야기를 논의하면서 진행하고 있습니다.

K-devcon 이란? : IT 정보를 공유하거나 위에서 설명한 Go to Learn 스터디 및 밋업을 개최하는 활동을 하고있는 IT 커뮤니티입니다.
K-devcon 홈페이지 바로가기

---

📖 2장 요약 및 정리

데이터 모델은 소프트웨어 내 문제를 어떻게 생각해야하는지 큰 영향을 미친다.
해당 장은 데이터 저장 및 질의를 위한 다양한 데이터 범용 모델을 설명하는 내용이 담겨있다.

데이터 베이스 시스템의 역사

계층 모델

IBM의 정보 관리 시스템에서 사용하기 시작한 데이터 모델이다.

• JSON 모델과 비슷하다. → 중첩된 레코드 트리로 표현
• 일대다 관계는 잘 표현한다.
• 다대다 같은 경우 지원하지 않아 레코드 참조를 수동으로 해야하는 단점이 존재한다.
  • 계층 모델의 한계를 해결하기 위하여 다양한 해결책이 등장하였다.
  • 네트워크 모델 / 관계형 모델

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

코다실 모델에서 표준화하였다.

• 계층 모델을 일반화
  • 모든 레코드는 정확히 하나의 부모가 있다.
  • 포인터 비슷한 방식으로 레코드간 연결
  • 따라서 다대일과 다대다 관계를 모델링 할 수 있다.

접근 경로 : 최상위 레코드에서부터 연속된 연결 경로를 따르는 방법

• 연결 목록의 순회와 같을 때 간단하게 실행이 되어진다.
• 레코드 목록을 반복해 접근 경로에 따라 커서를 움직여서 수행
• 매우 제한된 하드웨어 성능을 효율적으로 사용할 수 있었지만 코드가 복잡하고 유연하지 못하다.

관계형 모델

알려진 모든 데이터를 배치하는 것

• 단순히 튜플(로우)의 컬렉션이 전부이다.
• 접근 경로가 없다.
• 외래 키 관계에 대해 신경쓰지 않고 임의의 테이블에 새 로우 삽입이 가능

질의 최적화기가 자동으로 접근 경로를 만들기 때문에 따로 생각할 필요가 없다.

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

• 둘 다 고유한 식별자로 참조
  • 관계형 모델 : 외래 키
  • 문서 모델 : 문서 참조 (document reference) → 읽기 시점에 확인

관계형 모델 (Relational Model)

정리된 인터페이스 뒤로 구현 세부사항을 숨기는 것이 목표이다.

1960 - 1970년대의 비즈니스 데이터 처리에서 근원되었다.

• 다양한 목적으로 사용하기 시작하면서 본래의 영역을 넘어 다양한 사용 사례가 늘고 있다.
• 이후 네트워크 모델 & 계층 모델이 주요 대안으로 떠올랐었다.
• 최근에는 NoSQL이 대안으로 떠오르기 시작하였다. → 원인 : 다중 저장소 지속성의 개념의 등장

임피던스 불일치 : 애플리케이션과 데이터 베이스 모델 객체 간의 전환 계층이 필요함으로 인하여 등장하였다.

• 오늘날 대부분의 애플리케이션은 객체지향 프로그래밍 언어로 개발
• 일대다 (one-to-many)
  • 전통적인 테이블을 통하여 조회 혹은 JSON & XML를 부호화하여 나타낼 수 있다.
  • 트리 구조를 갖는다. → JSON 표현에서 명시적으로 표현된다.
• 다대다 (many-to-many)
  • 중복된 데이터를 정규화할려면 다대일(many-to-one)이 필요하다.
    • 관계형 모델에는 적합하나 문서 모델에는 적합하지 않다.
    • 관계형 같은 경우 조인이 쉽지만 문서형 모델 같은 경우 조인에 대한 지원이 약하기 때문이다.
    • 위를 해결하기 위하여 다중 질의를 활용한다. 다대다 (many-to-many)

관계형 데이터베이스와 문서 데이터베이스

각 데이터베이스 간 강점

• 문서 데이터베이스 : 스키마 유연성 / 지역성에 기인한 성능
• 관계형 데이터베이스 : 조인, 다대일, 다대다 지원

간결성

• 데이터 항목 간에 존재하는 관계 유형에 따라 다르기 때문에 어느 모델이 간단한지 정할 수 없다.
  • 문서 데이터베이스 : 문서와 비슷한 구조
  • 관계형 데이터베이스 : 다대다 관계 / 상호 연결이 많은 데이터

스키마 유연성

• JSON (문서, 관계형) : 문서의 데이터에 어떤 스키마를 강요하지 않는다.
• XML (관계형) : 선택적으로 스키마 유효성 검사를 포함할 수 있다.
• 스키마리스(schemaless) → 암묵적인 스키마가 있지만 이를 강요하지 않는다.
  • 읽기 스키마
• 접근 방식 간의 차이
  • 문서 데이터베이스 : 예전 문서를 읽은 경우를 처리하는 코드만 있으면 된다.
  • 정적 타입의 데이터베이스 : 마이그레이션을 수행해야한다.

데이터 지역성

• 저장소 지역성 : 애플리케이션이 자주 전체 문서에 접근해야할 때 위를 활용하면 성능 이점이 있다.
  • 한 번에 해당 문서의 많은 부분을 필요로 하는 경우에 적용
  • 이러한 이유로 일반적으로 문서를 아주 작게 유지하면서 문서의 크기가 증가하는 쓰기를 피하라고 권장
• 관계형 데이터베이스의 지역성
  • 다중 테이블 색인 클러스터 테이블 → 오라클
  • 칼럼 패밀리 개념 → 카산드라, HBase (빅테이블 데이터 모델)

문서 데이터베이스와 관계형 데이터베이스의 통합

• 시간이 지남에 따라 서로 점점 비슷해지고 있다.
  • XML를 지원하기 떄문에 문서 내부에서 색인하고 질의하는 기능이 포함
  • 문서 데이터베이스를 사용할 때 매우 비슷한 데이터 모델을 사용할 수 있다.
• 각 데이터 모델이 서로 부족한 부분을 보완해 나가고 있는 중이다.

질의 언어

선언형 질의 언어

SQL와 같은 관계형 모델에서 사용하는 질의 언어이다.

• 방법이 아니라 알고자하는 조건과 데이터를 어떻게 변환할지 지정한다.
• 명령형 API보다 더 간결하고 쉽게 작업할 수 있다는 이점이 있다.
• 병렬 실행에 적합하다. → 다중 코어와 다중 장비에서 병렬 처리가 명령형 보다 적합
• 데이터베이스 뿐만 아니라 웹 환경에서도 활용된다.

명령형 코드

IMS, 코다실에서 데이터베이스에 질의하는 언어이다.

• 일반적으로 많이 사용하는 프로그래밍 언어 또한 명령형 코드로 사용한다.
• 특정 순서로 특정 연산을 수행하게 끔 컴퓨터에게 지시한다.

맵리듀스(MapReduce) 질의

많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델 → 몽고 DB / 카우치 DB

• 선언형과 명령형의 중간에 정도에 해당이 된다.
• map과 reduce 함수를 기반으로 한다.
  • 두 함수는 순수(pure) 함수여야한다. → 입력으로 전달된 데이터만 사용 / 부수 효과가 없어야 함
  • 사용성 문제
    • 연계된 자바스크립트 함수 두개를 신중히 작성해야한다. → 집계 파이프라인의 선연형 질의언어 지원

그래프형 모델 (Graph Model)

데이터가 다대다 관계가 일반적인 경우 데이터 간 연결이 복잡해질수록 그래프로 데이터를 모델링

속성 그래프 모델

네이포제이, 타이탄, 인피니티그래프로 구현 됨

• 요소
  • 정점 : 고유한 식별자 / 유출 간선 집합 / 유입 간선 집합 / 속성 컬렉션
  • 간선 : 고유한 식별자 / 간선의 시작과 끝 (정점) / 관계 유형을 설정하는 레이블 / 속성 컬렉션
  • 정점이 주어지면 정점의 유입과 유출 간선을 찾을 수 있고 그래프를 순회할 수 있다.
    • 일련의 정점에 따라 앞뒤 방향으로 순회
  • 서로 다른 레이블을 사용하면 다른 유형의 정보를 저장하면서 데이터 모델을 깔끔하게 유지
• 데이터 모델링을 위한 많은 유연성을 제공한다.
• 사이퍼 (Cypher) 질의 언어
  • 속성 그래프를 위한 선언형 질의 언어이다.

  🤔 그래프 데이터를 관계형 구조로 넣은 후 SQL를 사용해 질의 할 수 있을까?

  • 질의에 필요한 조인을 미리 알고 있다. → 미리 조인 수를 고정 할 수 없다.
  • 가변 순회 경로에 대한 질의 개념 → 재귀 공통 테이블 식을 활용 WITH RECURSIVE

트리플 저장소 모델

데이토믹, 알레그로그래프 등으로 구현 됨

• 모든 정보를 주어, 서술어, 목적어처럼 매우 간단한 세 부분 구문 형식으로 저장한다.
  • 주어 : 그래프와 정점
  • 목적어 : 문자열과 숫자 같은 윈시 데이터타입의 값 / 그래프의 다른 정점
• 시맨틱 웹
  • 트리플 저장소 모델과 시멘틱 웹과는 독립적이다.
• RDF 데이터 모델
  • RDF 데이터를 사람이 읽을 수 있는 형식으로 표현 → 터틀 언어
  • 한눈에 쉽게 보기 위하여 터틀 / N3 형식을 선호한다.
• 스파클 질의 언어 (SPARQL)
  • RDF 데이터 모델을 사용한 트리플 저장소 질의 언어
  • 사이퍼와 매우 유사하다. → 패턴 매칭을 스파클에서 차용

네트워크 모델과의 비교

• 다른 레코드 타입과 중첩 가능한 레코드 타입을 지정하는 스키마가 없다.
  • 변화하는 요구사항을 쉽게 적용하는 유연성을 지님
• 고유 ID를 가지고 임의 정점을 직접 참조하거나 색인을 사용
• 하위 항목이 정렬된 코다실과 다르게 그래프 같은 경우 정점과 간선이 정렬되지 않는다.
• 그래프 데이터베이스는 명령형 질의 언어가 아닌 선언형 질의 언어를 사용한다.

데이터로그 (Datalog)

질의 언어의 기반이 되는 초석을 제공한 언어이다.

• 서술어(주어, 목적어)로 작성한다.
• 새로운 서술어를 데이터베이스에 전달하는 규칙을 정의한다.

---

😉 필자의 생각

2장을 읽기 전 데이터 모델 같은 경우 SQL와 같은 관계형 데이터 혹은 NoSQL 정도 알고 있었던 상태였다. 2장 내 특히 데이터 모델 같은 경우 어떠한 상태로 등장하게 되었는지 그리고 이러한 특징 및 문제점이 무엇인지 다양하게 설명해주었던 내용이 주류였다.

데이터 모델에 대하여 읽어보면서 그래프형, 문서형와 같은 NoSQL & 문서형 데이터 모델 안에서 다양한 데이터의 종류가 있다는 것을 알게 되었다.

또한 각 문서형에 따른 질의 언어가 있었는데 초창기에는 프로그래밍 언어와 유사하였고 간결하게 변화시킨게 지금 쓰는 데이터베이스 언어라는 사실을 알게 되었다.

위에서 언급하였지만 그래프 자료구조를 활용한 그래프 데이터 모델를 위 장을 읽고 나서 처음 알게 되었다. 그래서 위와 관련된 논의점이 생각이 났었다.

그래프 데이터 모델이 활용된 애플리케이션에 활용한 사례를 알고 싶다.
필자의 경우 데이터 간 연결이 복잡하므로 대규모 트래픽 및 데이터에 사용 되지 않을까 생각이 든다.

위와 같은 논의점을 이번 스터디에서 물어본 결과 대표적으로 페이스북,드라이브(클라우드 파일), 리눅스 파일시스템 등에서 활용 되어진다고 한다. 요즘에는 AI분야 내에서도 MML 레이블에서 벡터 DB를 저장하기 위해 그래프 데이터 모델을 활용하는 경우도 있다고 한다.

마지막으로 개발 업무가 비즈니스 데이터 처리를 다루고 있기 때문에 왜 관계형 데이터 처리를 애용했는지 알 수 있게 되었다. 그리고 프로젝트 내 XML를 사용하여 문서에서 저장 된 데이터 질의 언어를 사용한 구조도 떠올랐다.