[21일] 데이터 베이스

Tony Lee·2023년 5월 8일
0

데브코스

목록 보기
5/5

OLTP: online transaction processing, 프로덕션 데이터베이스

  • mysql, postgres, oracle

  • 속도에 집중

  • 백엔드, 프론트가 주로 사용

  • 프로덕션 데이터이기 때문에 여기에 큰 쿼리를 날리면, 전체 프로덕트의 속도가 느려짐

    OLAP: Online Analytical processing, 데이터 웨어하우스

  • redshift, snowflake, bigquery, hive

  • 처리 데이터 크기에 집중, 프로덕션 데이터베이스를 복사해서 웨어하우스에 저장

  • 데이터팀이 주로 사용

SQL의 단점

구조화된 데이터를 다루는데 최적화가 되어있음

정규식 표현을 통해 비구조화딘 데이터를 어느정도 다루는 것은 가능하나 제약이 심함
많은 관계형 데이터베이스들이 플랫한 구조만 지원함 (no nested like JSON)

  • 구글 빅쿼리는 nested structure를 지원함
    비구조화딘 데이터를 다루는데 Spark, Hadppop과 같은 분산 컴퓨팅 환경이 필요해짐
  • SQL만으로는 비구조화 데이터를 처리하지 못함
    관계형 데이터베이스마다 SQL문법이 조금씩 상이

Star Schema

데이터를 논리적 단위로 나눠 저장하고 필요시 조인. 스토리지 낭비가 덜하고 업데이트가 쉬움

Denomalizerd schema

모든 데이터를 한 개의 테이블에 저장하여 별도의 조인이 필요 없는 형태
스토리지를 더 사용하지만, 조인이 필요 없기에 빠른 계산이 가능

데이터 웨어하우스란? 회사에 필요한 모든 데이터를 저장

여전히 SQL기반의 관계형 데이터베이스
프로덕션 데이터베이스와는 별도

고객이 아닌 내부 직원을 위한 데이터베이스
처리속도가 아닌 처리 데이터의 크기가 더 중요해짐

데이터 웨어하우스 외부에 존재하는 데이터를 읽어서 데이터 웨어하우스로 저장해주는 작업을 ETL 혹은 데이터 파이프라인이라고 부름

Redshift

OLAP이기 때문에 응답속도가 빠르지 않기 때문에 프로덕션 데이터베이스로 사용불가

Columnar storage

  • 컬럼별 압축이 가능
  • 컬럼을 추가하거나 삭제하는 것이 아주 빠름
  • 벌크 업데이트 지원
  • 고정 용량/비용 SQL 엔진
  • 다른 데이터 웨어하스처럼 priamry key uniqueness를 보장하지 않음
    - 프로덕션 데이터베이스들은 보장함
profile
Striving to have a positive impact on the community

0개의 댓글