CS 내용 요약, 지식/Google Cloud Associate

Google Cloud Associate 강의 요약: Database

걍판자 2025. 1. 11. 04:15
반응형

Database 관련 문제 상황

만약 데이터베이스가 다운된다면 발생하는 문제

  1. 접근 안되는 문제
  2. 데이터들 날라가는 문제
  • 해결책1 snapshot: 매 시간마다 snapshot을 찍어 다른 데이터 센터에 저장하기
    • 그렇다면 데이터들 날라가지 않게는 할 수 있지만 1번 접근 문제와, 스냅샷을 찍을때 느려지는 3번 문제가 추가로 발생함
  • 해결책2 standby: 복사본인 standby database를 만들어 놓고, 장애때 돌리면 3가지 문제 다 해결됨

availability, durablity, Consistency

  • availability 가용성 : 내가 원할때 얼마나 빠르게 접근할 수 있는가
    • 다양한 zones와 regions에 배포할 수록 가용성 높아짐
  • durability 내구성: 오랜 시간이 지날때 얼마정도의 파일이 손상되지 않고 유지되는가?
    • standby, snapshot, transaction,logs, replica 등을 다양한 zones과 regions 추가 보관
  • consistency 일관성: 여러 DB instance에서 동시에 업데이트 되는가?
    • Strong consistency: 모든 복제로 즉시 업데이트 됨. 이로 인해 느려질 수 있음. 은행거래가 대표적
    • Eventual consistency: 비동기적이라 약간의 시간이 걸림. 그 시간 사이에 값 차이가 일어날 수 있고, 확장성이 무결성보다 중요할때 쓰임. 소셜미디어 포스트가 대표적인 예임
    • Read-after-Write Consistency: 삽입 수정이 곧바로 일어나야 함. 복제속도는 느린만큼 접근은 빠름.

RTO와 RPO

  • RTO(Recovery Time Objective): 최대 장애 시간 (다운되었을때 복구되는 시간)
  • RPO(Recovery Point Objective): 최대 데이터 손실 주기 (백업주기)

일반적으로 RTO가 RPO보다 더 큼

시나리오 Solution
RTO와 RPO 둘다 엄청 작아야함 Hot standby 방식: 자동으로 데이터 동기화 하고 실패시 자동으로 standby로 연결되게 함
RTO는 좀 걸려도 괜찮지만 RPO는 작아야함 Warm standby: 자동으로 데이터는 동기화되게 하되 스탠바이 자체의 인프라는 작게하다가 문제 발생하면 scale up해서 사용
RTO는 오래걸려도 괜찮으나 RPO는 작아야함 snapshot이나 transaction logs 방식 사용
둘다 상관 X 그냥 아예 새로운 서버로 생성해 조치

데이터베이스를 reporting 하고 analytics 하는 응용 프로그램을 얹으면 좋음.(이런 application들은 읽기 전용임) 근데 이런거 얹으면 성능 느려질 수 있는데, CPU와 memory를 키우든 database cluster를 만들든 복제본을 따로 두어 그것만 읽게 하든 할 수 있음. 읽기전용 복제본 따로 두어 읽게 하는 것을 추천

Realtional Databases

  • 가장 많이 쓰였고 유명함.
    • 사전에 정의된 엄격한 테이블과 스키마 가짐
    • 트랜잭션이 강력하여 금융거래에 쓰임
    • OLTP(online transaction processing),
      • 많은 사용자가 작은 양의 transaction 가질때.
      • ERP,CRM, E-커머스, 은행 앱 등에서 쓰이며 MySQL, Oracle, SQL 서버가 그 언어이다.
      • 구글에서는 SQL을 기반으로 한 Cloud SQL과 대용량을 처리하는 Cloud Spanner를 제공한다.
    • OLAP(online analytics processing)
      • 정말 방대한 양의 데이터를 유저에게 허용하여 분석하게 해줄때. 데이터 분석창고 같은것이 그 예시이다.
      • GCP에서는 BigQuery가 그 예시이다.
    • OLTP와 OLAP는 비슷하나 데이터 저장방식이 다르다.
    • OLTP는 행단위로 저장되기에 transaction이 작은게 효율적이다.
    • OLAP는 열단위로 저장되기에 압축도가 높고, 각 속성끼리 노드 형태로 연결되어 있다. 복잡한 쿼리일 경우 실행이 효율적이다.

NoSQL Databases

  • 관계형인 SQL 뿐만 아니라 NoSQL의 유연한 스키마를 통해 수직적인 scale의 perabyte 단위를 다룰 수도 있음 .
  • 일반적으로 확장성, 대용량과 고성능을 얻고, strong consistency 기능을 포기함
  • 구글에서는 Cloud Firestore(Datastore)과 Bigtable이 있음.
    • Datastore
      • DataStore은 서버가 없는 NoSQL 로 ACID 트랜잭션, SQL 같은 쿼리, index를 제공함.
      • 트랜잭션한 모바일 웹 어플리케이션을 위해 만들어짐
      • 나중 버젼에 strong consisteny와 moblie web cilent library가 추가됨
    • Bigtable
      • 규모의 확장성에 기반을 둔 수직 database임
      • 서버 인스턴스가 있어야 함
      • 10TB에서 페라바이트 이상일때 권장함
      • 대용량 분석과 workload에서 사용 권장
      • transactional workloads 에는 적합하지 않음. multi-row transaction 제공 안하고, singe-low transaction만 제공하기 때문

In-Memory DB

  • 디스크에서 찾는것보다 메모리에서 찾는게 더 빠름
  • in-memory DB는 지속적인 데이터를 메모리에 저장해 적은 지연율
  • GCP에서는 memory Store 가 있음
  • 캐시, 세션, 리더보드 등을 처리할때 쓰임

시나리오

  • Q: 테이블 구조로 빠르게 스키마 만들고 싶어요
  • A: Datastore/Firestore 쓰세요
  • Q: 적은 용량으로 비관계형 DB를 쓰고 싶어요
  • A: Datastore 쓰세요.
  • Q: 미리 짜둔 스키마로 트랜잭션하고, global 하여 초당 수백만개의 트랜잭션을 처리했으면 해요.
  • A: CloudSpanner 쓰세요.
  • Q: Transactional local DB를 초당 수천개씩 처리하고 싶어요.
  • A: Cloud SQL
  • Q: 웹의 캐시 데이터
  • A: memorystore 쓰세요.
  • Q: 페라바이트 단위로 데이터 분석을 처리하고 싶어요.
  • A: BIgQuery 쓰세요.
  • Q: 엄청난 볼륨의 실시간 IOT 스트리밍 데이터
  • A: BigTable
반응형
저작자표시 비영리 변경금지