02장 데이터 모델과 질의언어

STUDY/Data Engineering

02장 데이터 모델과 질의언어

wonpick 2024. 2. 18. 18:52

데이터 중심 어플레케이션 설계 스터디를 진행하며 작성한 글 입니다.

스터디원: 7명
서적: 데이터 중심 어플리케이션 설계

서론

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

SW가 어떻게 작성됐는지 뿐만 아니라 해결하려는 문제를 어떻게 생각해야 하는지에 대해서도 영향을 미치기 때문이다.

대부분의 애플리케이션은 하나의 데이터 모델을 다른 데이터 모델 위에 계층을 둬서 만든다. (각 계층의 핵심 문제: 다음 하위 계층에서 데이터 모델 표현하는 방법)

애플리케이션 개발자는 현실(사람, 조직, 상품, 센서, 자금 흐름 등)을 보고 객체나 데이터 구조 그리고 이러한 데이터 구조를 다루는 API를 모델링한다.
데이터 구조를 저장할 때는 JSON, XML 문서. 관계형 데이터 베이스 테이블이나 그래프 모델 같은 범용 데이터 모델로 표현
……

각 계층은 명확한 데이터 모델을 제공해 하위 계층의 복잡성을 숨긴다. (ex - API : 여러 api 기반으로 만든 api처럼 중간 단계를 더 둘 수 있지만 기본 개념은 동일)

복잡성을 숨김으로써 다른 그룹의 사람들이 더 효율적으로 함께 이할 수 있게끔 한다.

애플리케이션이 어떤 데이터를 다루느냐에 따라 어떤 데이터 모델을 선택할지 결정된다. (소프트웨어가 할 수 있는 일과 할 수 없는 일에 영향을 주므로)

데이터 모델은 소프트웨어가 할 수 있는 일과 없는 일에 영향을 주므로 어플리케이션에 적합한 모델을 찾는 것이 중요하다.

데이터 모델링이란?

데이터를 생산하여 Database에 저장하기 위해 처리하는 과정

데이터 모델에는 그 객체가 다른 객체와 규칙을 대표하도록 설계되어야 하고 이 과정에서 데이터는 비즈니스 규칙, 규제 그리고 정부의 정책까지 데이터를 통해 표현할 수 있도록 한다(이러한 로직 들)

데이터 모델은 데이터의 설명과 의미 및 데이터의 일관성 제약 조건을 구성하는 추상 모델로 정의된다.

추상화: 현실 세계를 일정한 형식에 맞추어 표현한다.
단순화: 현실 세계를 약속된 규약이나 제한된 표기법과 언어로 표현한다
명확화: 누구나 이해가기 쉽게 애매모호함을 제거한다.

모델링의 3단계

개념적 모델링 → 논리적 모델링 → 물리적 모델링

개념적 모델링: 현실 세계의 데이터를 추상화하여 데이터로 표현하는 과정

Entity를 구성하고 그 entity 의 속성, 필드 등을 정의한다.

논리적 모델링: 논리적으로 데이터를 저장하기 위해 수립하는 단계

데이터의 구성 요소를 구조화 하고, 그들간의 관계를 정의한다.

물리적 모델링: 디스크에 데이터가 저장될 수 있도록 논리적 모델을 물리적 데이터 구조로 변환시키는 과정

DB에서 구현하기 위한 데이터 모델을 표현한다

1. 관계형 모델과 문서 모델(relational/document model)

관계형 모델을 기반으로 한 SQL이 오늘 날 가장 잘 알려져 있다.

RDB에서 데이터는 관계(relation)로 구성되고, 각 관계(relation)은 순서 없는 튜플(tuple)(SQL에서 로우(row))모음이다.
관계형 모델은 이론적 제안이었기 때문에 효율성에 많은 문제를 제기했었다.
- 하지만 관계형 데이터베이스 관리 시스템(relational database management system,RDBMS)와 SQL는 정규화된 구조로 데이터를 저장하고 질의를 수행할 필요가 있는 사람들이 대부분 선택하는 도구가 됐다.
관계형 데이터 베이스의 근원은 트랜잭션 처리나 일괄 처리 같은 비지니스 데이터 처리에 근원을 두고 있다.
수년 동안의 데이터 저장과 질의를 위한 접근 방식
- 1970-1980: 네트워크/계층 모델 < 관계형 모델
- 1980년 후반 1990초반: 객체 데이터
- 2000년대 초 : XML 데이터 (매우 적게 채택)
→ 오늘날 웹에서 보는 대부분의 서비스는 관계형 데이터 베이스 (ex-온라인 게시물, 토론, 소셜 네트워크, SaaS(software-as-a-service)생산성 애플리케이션 등)

1) NoSQL의 탄생

2010년대 NoSQL은 관계형 모델의 우위를 뒤집으려는 가장 최신 시도이다. NoSQL은 Not Only SQL로 재해석 된다.

NoSQL 데이터베이스를 채택 이유

대규모 데이터셋에서 매우 높은 쓰기 처리량 달성을 RDBMS보다 쉽게 할 수 있을만큼의 뛰어난 확장성.
상용 DB보다 무료 무료 오픈소스에 대한 선호도 확산
관계형 모델에서는 지원하지 않는 특수 질의
관계형에서 스키마 제한에 대한 불만, 동적이고 풍부한 데이터 모델에 대한 바람

애플리케이션은 저마다 요구사항이 달라 하나의 선택이 전체의 최적의 선택이 아닐 수 있다. 따라서 가까운 미래에는 RDBMS가 다양한 비관계형 데이터 스토어와 함께 사용될 것이다.

2) 객체 관계형 불일치

객체 지향 프로그래밍 (오늘날 대부분의 애플리케이션은 객체 지향 프로그래밍 언어로 개발 됨.) RDBMS에 저장하려면 애플리케이션 코드와 데이터베이스 모델 객채(테이블, 로우, 컬럼) 사이에 거추장스러운 전환 계층이 필요하다.

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

액티브레코드(ActiveRecord)나 하이버네이트(Hibernate) 같은 객체 관계형 맵핑(ORM) 프레임워크는 전환 계층에 필요한 상용구 코드(boilerplate code)의 양을 줄이지만 두 모델간 차이를 완벽히 숨길 수 없다.

예시) 관계형 스키마에서 이력서를 표현할 경우

대부분의 사람은 학력 기간과 연락처 정보등 하나 이상의 데이터를 담아야한다.
프로필 고유 식별자(user id), 다른 필드(first_name, last_name, 경력, 학력기간, 연락처 정보)
사용자와 이들 항목은 일대다(one-to-many)관계이며 이는 아래와 같은 다양한 방법으로 나타 낼 수 있다.
- 전통적인 SQL모델에서는 각 학력과 연락처등 정보를 개별 테이블에 넣고 외래키로 참조한다
- 이후 SQL마지막 버전에서는 구조화된 데이터 타입과 XML데이터에 대한 지원도 되었다.
- 마지막으로는, 직업 학력 연락처 정보를 JSON등으로 부호화해 텍스트 칼럼에 저장하여 애플리케이션이 해석하도록 하는 방식이다. -> but, 부호화된 칼럼의 값을 질의하는 DB는 사용할 수 없다.

위의 예인 이력서 같은 구조는 모든 내용을 갖추고 있는 문서라 JSON 표현에 매우 적합하다. 몽고DB, 리싱크DB, 카우치DB, 에스프레소 같은 문서 지향 DB는 JSON데이터 모델을 지원한다. 일부 개발자들은 JSON 모델이 임피던스 불일치를 줄인다고 생각하는데, 사실 JSON 자체가 가진 문제도 있다(이후 4장에서 설명). JSON식의 표현은 다중 테이블 스키마 보다 더 나은 지역성(locality)를 갖는다. 관계형 예제에서 다중 질의(각 테이블에 user_id로 질의)와 같은 복잡한 조인이 필요없다.

→ JSON 표현에서는 모든 관련 정보가 한 곳에 있기 때문에 질의 하나로 충분하다.

사실 이력서 상의 일대다 관계 데이터들은 TREE구조와 같은데, 이는 JSON 표현에서 명시적으로 드러나게 된다.

3) 다대일과 다대다 관계

앞선 예제에서 지역과 업계는 직접 입력받는 것이 아닌 region_id 와 industry_id를 사용했는데, 이렇게 표준 목록으로 드롭다운 리스트 형식으로 만든데에는 여러 장점이있다.

프로필간 일관된 스타일의 철자 & 모호함 회피, 현지화 지원 , 갱신의 편의성, 더 나은 검색

ID나 텍스트 문자열의 저장 여부는 중복의 문제이다.

ID를 사용하는 경우 (자선 활동이라는 단어처럼) 의미 있는 정보는 한 곳에만 저장하고 그것을 참조하는 모든 것은 ID를 사용한다.
텍스트를 직접 저장한다면 그것을 사용하는 모든 레코드에서 사람을 의미하는 정보를 중복 저장하게 된다.

→ ID 장점: 중복 제거, 변경 용이

중복된 데이터를 정규화 하려면 다대일 관계가 필요하지만, 문서 모델에서 다대일 관계는 적합하지 않다. 따라서 데이터 베이스에 대한 다중 질의를 만들어서 애플리케이션 코드에서 조인을 흉내내야 하기에 어렵다.

4) 문서 데이터베이스는 역사를 반복하고 있나??

RDBMS는 일상적으로 다대다 관계와 조인을 사용하지만 문서형 DB와 NOSQL은 DB에서 다대다(Many-to-Many) 관계 표현의 가장 좋은 방법에 대한 논쟁을 펼치고 있다.

1970년대 비지니스 데이터 처리를 위해 IBM의 정보 관리 시스템을 데이터베이스로 가장 많이 사용했는데, 이는 계층 모델이라 부르는 상당히 간단한 모델을 사용했다. 계층 모델은 오늘날 사용하는 JSON 모델과 놀랍도록 비슷하며, 모든 데이터를 레코드 내에 중첩된 레코드 트리로 표현한다.

하지만 계층 모델 역시 다대다 관계 표현이 어려워 오늘날과 똑같은 고민했고, 이런 계층 모델의 한계를 해결하기 위해 관계형 모델과 네트워크 모델이 나타나게 되었다.

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

코다실 모델 (Conference on Data System Language,CODASYL)

코다실 모델이라고 부르기도한다. 계층 모델을 일반화한 모델로, 계층 모델의 트리 구조에서는 모든 레코드는 정확하게 하나의 부모가 존재하는데, 네트워크 모델에서는 다중 부모가 존재가능하다. 레코드에 접근하는 유일한 방법은 최상위 레코드에서부터 연속된 연결 경로를 따르는 방법으로, 이를 접근 경로 라고 하며, 외래키(foreign key)보다는 프로그래밍 언어의 포인터와 더 비슷하다. (삽입시 조인 수행)

네트워크 모델의 “접근 경로는 없다”

없다기 보다는 질의 최적화(Query Optimizer)가 자동으로 대신 만드는 것

만약 레코드가 다중 부모를 가진다면 애플리케이션 코드는 다양한 관계를 모두 추적해야하며, 이런 수동 접근 경로 선택은 데이터베이스 질의와 갱신을 위한 코드가 복잡하고 유연하지 못하다. M:N을 구현하면 마치 N차원 공간 항해랑 같기 때문에, 접근 경로를 수정할 수 있지만 많은 수작업 질의코드를 살펴봐야하고 재작성 하는 등 매우 어려운 일이다.

관계형 모델

대조적으로 관계형 모델이 하는 일은 알려준 모든 데이터를 배치하는 것으로, 단순히 튜플의 컬렉션이 전부이다. 다른 테이블과의 관계를 신경쓰지 않고 새 로우를 삽입할 수 도 있다. 이런 RDB에서 query optimizer는 질의의 어느 부분을 어떤 순서로 실행할지 결정하고 사용할 색인을 자동 결정한다. 이 선택이 바로 실제 “접근 경로”인 것. 하지만 개발자가 아니라 query optimizer기가 자동으로 만드므로 개발자가 고려할 필요가 없다.
→ index를 변경하면 옵티마이저가 자동으로 적합한 방법을 선택하니 새로운 기능을 추가하는 것이 훨씬 쉽다
(범용 최적화기 사용시 모든 애플리케이션이 혜택)

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

문서 데이터베이스는 상위 레코드 내에 중첩된 레코드를 저장한다는 측면에서 계층 모델로 되돌아갔다. 하지만 다대일과 다대다를 표현할때 RDB와 근본적으로 다르지 않았으며, 관계형 모델에서 외래키가 문서 모델에서의 문서 참조(document reference)와 같다.

5) 관계형 데이터베이스와 오늘날의 문서 데이터베이스

관계형(RDB) 선호 : 조인, 다대다(M:1N), 다대일(M:1) 관계 지원하면서 문서 데이터 모델에 대항
문서 데이터(document) 모델 선호 : 스키마 유연성, 지역성에 기인한 더 나은 선택 때문

어떤 데이터 모델이 애플리케이션 코드를 더 간단하게 할까?

애플리케이션 데이터가 문서와 비슷한 구조라면 문서 모델을 사용하는 것이 좋다. 관계형 모델은 문서와 비슷한 구조를 여러 테이블로 나누어 찢기(shredding) 때문에 복잡한 애플리케이션 코드를 발생시킨다.

But, 문서 모델은 중첩항목을 바로 참조할 수 없고, 미흡한 조인 지원은 때떄로 문제가 된다(때로는 아닐 수 있음). 다대다 관계를 사용하면 문서 모델의 매력은 떨어지는것이 대표적인 문제다.

결론 : 일반적으로 어떤 데이터 모델이 코드를 더 간단하게 만드는지 말할수 없음. (데이터 유형에 따라 다름!)

문서 모델에서의 스키마 유연성

문서 데이터베이스는 종종 스키마리스(schemaless)로 불리지만, 이는 오해의 소지가 있는 표현이며, 데이터를 읽는 코드는 보통 구조의 유형을 어느정도 가정한다. 즉 쓰기 스키마말고 읽기 스키마 인것이다.

쓰기 스키마와 읽기 스키마
쓰기 스키마(schema-on-write) : RDB의 전통적인 접근 방식
- 스키마는 명시적으로 DB는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장한다
- 정적 타임 확인과 유사하다
읽기 스키마(schema-on-read) : 문서 모델
- 데이터 주고는 암묵적으로 읽을때만 해석이 된다.
- 프로그래밍 언어에서 동작 타입 확인과 유사하다

2. 데이터를 위한 질의 언어

선언형 질의언어 (SQL, 관계대수)
- 결과가 충족해야하는 조건 + 데이터를 어떻게 변환할지 지정 (정렬, 그룹화, 집계, ..)
- 어떻게 실행할지는 Optimizer(쿼리 최적화)의 몫
명령형 코드 (IBM, 코다실(네트워크 모델))
- 특정 순서로 특정 연산을 수행하게끔 컴퓨터에게 지시
- 목표를 달성하기 위한 방법
선언형의 장점
- 선언형은 명령형에 비해 더 간결하고 쉬운 작업
  - 데이터베이스 엔진의 상세 구현이 숨겨져 있어 질의를 변경하지 않고도 성능을 향상 시킬 수 있음
  - 기능적으로 더 제한적 ↔ 자동 최적화
- 종종 병렬 작업에 적합 (순서 의존 x)
  - 결과를 결정하기 위한 알고리즘이 아니라 패턴만 지정하기 때문

웹에서의 선언형 질의

CSS, XSL (선언형) vs JS의 코어 DOM API (명령형)

선언형의 장점은 DB에만 국한되지 않는다.
예) CSS를 사용하여 선택자에 특정 디자인(패턴)을 일괄 적용할 수 있으며 이는 선언형 방식이다.

명령형의 단점 예) JS에서 DOM API를 사용하여 구현 → 문제사항 2가지

새로운 API 개발 시 코드를 재작성 필요 (선언형인 CSS의 경우 호환성을 깨뜨리지 않음)
클래스 삭제 감지가 되지 않아, 특정 작업이 수행되면 전체 페이지가 로딩될때까지 유지된다. (선언형인 CSS는 자동으로 감지해서 삭제되자마자 같이 삭제한다)

결론 → 웹에서도 명령형 DOM API보다 선언형 CSS를 더 추천하는 것처럼, DB에서도 선언형 질의언어 SQL 등등이 명령형 질의 API보다 더욱 추천된다.

맵리듀스 질의 (MapReduce)

맵리듀스(MapReduce)란?

많은 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델
구글에 의해 널리 알려졌다.

NOSQL 데이터 저장소

제한된 형태인 맵리듀스를 지원
이 매커니즘은 많은 문서를 대상으로읽기 전용(read-only)질의를 수행할 때 사용
예) MongoDB, CouchDB 등등

MongoDB의 맵리듀스 (MongoDB의 모델 사용법)

선언형 질의도 완전한 명령형 질의API도 아닌 그 중간
- 맵리듀스는 여러 FP(Functional Programming) 언어에 map (collect) & reduce (fold/inject) 함수 기반
  - 단, 순수 함수 (pure function) 여야함 (side-effect X)
  - 임의 순서로 실행 가능, 재실행 가능
- 집계 파이프라인(aggregation pipeline) → 선언형 질의 언어 지원
  - SQL의 부분집합과 유사하지만 JSON 기반 구문
  - 맵리듀스 함수 작성의 어려움 해소를 위함
  - 선언형 질의 언어는 질의 최적화(Optimizer)가 질의 성능을 높일 수 있는 기회를 제공

맵리듀스 (low-level) vs SQL (high-level) 반대 개념이 아님.
분산 SQL 구현도 가능하고, MR 사용한/사용하지 않은 구현 모두 O
질의 중간에 자바스크립트 사용/확장 가능 (MR, 일부 SQL)

3. 그래프형 데이터 모델

1:N (트리구조), 레코드간 관계 X →문서모델
N:1, N:M 관계 →관계형 모델
복잡한 N:M 관계 → 그래프형 모델

다대다 관계가 일반적일 경우, 또 데이터 간 연결이 더 복잡해지면 그래프로 데이터를 모델링 하기 시작하는 편이 더 자연스럽다

그래프는 정점(vertax)과 간선(edge)로 이루어지는데, 동종 데이터에 국한 되지 않는다

ex) 페이스북의 정점은 사람, 장소, 체크인, 코멘트 등 여러가지가 될 수 있음

그래프에서 데이터를 구조화하고 질의하는 몇가지 방법과 언어를 설명할 것

속성 그래프

속성 그래프의 특징은 다음과 같다.

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

결론 → 그래프는 데이터 모델링을 위한 많은 유연성을 제공한다.

기능 추가시 쉬운 확장
구조 다르거나 데이터 입도(granularity)가 달라도 됨

*데이터 입도: 데이터가 얼마나 자세히 분할되었는가

사이퍼 질의 언어

사이퍼(Cypher)
- 속성 그래프를 위한 **선언형** 질의 언어
- Neo4j 그래프 DB용으로 만들어 졌다.

사이퍼 질의 언어의 장점
선언형 질의 언어는 질의를 작성 시 수행에 대해 자세히 지정 X
→ 질의 최적화기가 가장 효율적이라고 예측한 전략을 자동으로 선택하기 때문

SQL의 그래프 질의 언어

그래프를 관계형 구조로 넣어도 SQL을 사용하여 질의할 수 있을까?
정답 → 할 수 있지만 어렵다. 관계형을 그래프로 표현할 수 있으며, 그래프도 관계형으로 표현할 수 있지만 후자는 어렵다.
이유 → 그래프 질의에서는 찾고자 하는 정점을 찾기 전 가변적인 간선을 순회해야 하고, 미리 조인 수를 고정할 수 없기 때문 (관계형은 질의에 필요한 조인 미리 파악 가능하다.) 반면에! 사이퍼에서는 매우 간결히 표시 가능하다.

재귀 공통 테이블 식 (recursive common table expression)

WITH RECURSIVE 문
1999 이후, 관계형 DB에서도 가변 순회 경로에 대한 질의 표현 가능
하지만! 문법이 사이퍼에 비해 어렵다.

트리플 저장소와 스파클

트리플 저장소 모델은 속성 그래프 모델과 거의 동등하다.

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

시맨틱 웹

트리플 저장소 데이터 모델은 시맨틱 웹과 완전 독립적이지만, 많은 사람들이 이 둘은 밀접한 관계가 있다고 생각한다. 시맨틱 웹은 웹 사이트는 사람이 이미 읽을 수 있는 정보를 게시하고 있으니, 컴퓨터가 읽게끔 기계가 판독 가능한 데이터로도 정보를 게시하자는 생각이다. 하지만 현실에 실현된 흔적이 없으며, 부정적 견해를 보이는 사람이 많다

RDF 데이터 모델 (자원 기술 프레임워크 (RDF, Resource Description Framework))

RDF는 서로 다른 웹 사이트가 일관된 형식으로 데이터를 게시하기 위한 방법 제안

스파클 질의 언어 (SPARQL, SPARQL Protocol And RDF Query Language)

스파클(SPARQL)은 RDF 데이터 모델을 사용한 트리플 저장소 선언형 질의 언어
사이퍼와 유사하지만 사이퍼보다 스파클을 사용하면 때로 질의문이 더 간결해진다.

그래프 데이터베이스 vs 네트워크 모델

스키마
- 코다실 : 다른 레코드 타입, 중첩가능 레코드 타입 지정하는 스키마 존재
- 그래프 : 제한 x → 유연성이 더 크다.
접근 방식
- 코다실 : 접근 경로 중 하나를 탐색해야 특정 레코드에 도달 가능
- 그래프 : 고유 ID로 정점 직접 참조 / 색인으로 빠르게 찾기
정렬
- 코다실 : 레코드 하위 항목은 정렬된 집합 (신규 삽입시 위치 고려)
- 그래프 : 정점 & 간선 정렬 x. 질의 시에만 결과 정렬
질의
- 코다실 : 명령형 질의 사용. 스키마 변경 시 질의 쉽게 손상
- 그래프 : 대부분 고수준 선언형 질의언어 사용. (명령형도 가능은 o)

초석: 데이터로그 (Datalog)

데이터로그 (Datalog)

스파클이나 사이퍼보다 훨씬 오래된 언어로 이후의 질의 언어의 기반이 되는 초석을 제공하기에 중요하다.
데이터로그의 데이터 모델은 트리플 저장소 모델과 유사하지만, 조금 더 일반화 됐다.
- (주어, 서술어, 목적어)로 트리플을 작성하는 대신 서술어(주어, 목적어)로 작성한다.
- 서술어(predicate) (주어(subject), 목적어(object))

대체 가능
- Data Lake (HDFS) → AWS S3
- Hive → Amazon Athena
- Hadoop → AWS EMR

기타

대체 가능
- Data Lake (HDFS) → AWS S3
- Hive → Amazon Athena
- Hadoop → AWS EMR
https://velog.io/@_ted_0527_/TIL-데이터-사이언스-3#빅데이터의-왕-hadoop

	RDB	NoSQL	DWH (Data Warehouse)	Data Lake	데이터마트
			“지금” 데이터를 가장 빠르게 분석 여러가지 저장소로부터 가져온 정보가 통합되기 때문에 데이터 창고라는 의미에서 데이터 웨어하우스. 데이터 웨어하우스는 비지니스 의사결정을 지원할 수 있는 분석작업을 목적으로 데이터를 구성하며, 주로 정형 데이터를 기반으로 하기 때문에 관계형 db엮어서 사용한다.	“미래"에 이용할 데이터를 모으기	데이터 마트는 정형화된 데이터를 저장하고 분석할 수 있는 데이터베이스 데이터 웨어하우스에서 각 분석 목적에 맞는 데이터들을 따로 빼 놓은 저장소가 데이터 마트. → 단일 또는 몇 개의 소스, 또는 데이터 웨어하우스에 이미 수집된 데이터의 일부 데이터 웨어하우스가 정형 데이터를 저장하고 있기 때문에 데이터 마트 역시 정형 데이터를 다루는 관계형 데이터 베이스를 사용한다.
OSS/서비스	Oracle MySQL PostgreSQL	Elasticsearch Cassandra Redis snowflake HIVE (배치쿼리 엔진) Amazon Redshift	Bigquery, Showflake, Redshift(PostgreSQL기반), Hadoop +Hive/Presto +ORC/Parquet	Hadoop HDFS Amazon S3
목적	트랜잭션(OLTP)	특정 실적 중시	분석(OLAP)	데이터저장
데이터 구조	정형화	반정형화	정형화 반정형화	정형화,비정형화,반구조화
스키마	고정 스키마	가변 스키마	고정 스키마 일부 경우 데이터 웨어하우스를 구현하기 전 설계되며 분석과 동시에 작성 가능 ( 스키마-온-라이트 또는 스키마-온-리드)	스키마리스(데이터 카탈로그) 분석 시에 작성됨( 스키마-온-리드)

→참고: https://aws.amazon.com/ko/compare/the-difference-between-a-data-warehouse-data-lake-and-data-mart/