Google Cloud Associate 강의 요약: Database

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