Database 고르기

◼CheckList

1. 애플리케이션이 성숙했을 때 얼마나 많은 데이터를 저장할 것으로 예상되는가?

어느 정도의 데이터를 저장 할 것인가?

• 기가바이트 단위 이하 -> 모든 데이터베이스 가능
• 페타바이트 이상 -> '라이브' 데이터는 쿼리 속도를 위해 in-memory나 SSD 고려, 전체 데이터는 HDD로 보관 등의 구조 필요

2. 첨두 부하^[각주:1](peak load)에서 동시에 몇 명의 사용자를 처리할 것으로 예상되는가?

동시 사용자는 몇 명인가?

• 동시 사용자 부하 추정 필요
• 많은 데이터베이스가 확장 문제가 있다
• 예상치 못하거나 계절적인 부하를 위해 여러 서버로 확장 할 수 있는 옵션 필요
• 수동으로 샤딩 없이 수평적으로 확장이 가능한 데이터베이스는 적다

3. 애플리케이션에 필요한 가용성(availbility), 확장성(scalability), 지연 속도(latency), 처리량(throuput^[각주:2]), 데이터 일관성(data consistency)은 어느 정도인가?

• 확장성
  • 역사적으로 NoSQL이 SQL보다 확장성 우수(최근에는 SQL이 많이 근접)
  • 확장성이 좋으면 데이터베이스는 부하대비 처리량이 좋아져 동시 사용자 처리 가능
• 레이턴시
  • 데이터베이스의 응답시간, 어플리케이션 E2E 응답 시간 모두 포함
  • 모든 user 행위가 1초 미만의시간이 이상적
  • 단순한 트랜잭션이 100ms 미만 필요
  • 오래 걸리는 복잡한 쿼리는 백그라운드로 수행하여 응답시간 단축
• 일관성
  • SQL database에서는 모든 read가 최신 데이터가 반환 되지만 NoSQL은 아님

4. 데이터베이스 체계(schema)는 얼마나 자주 바뀔 것인가?

• 데이터베이스 체계가 크게 바뀔 가능성이 없다 + 레코드간에 일관된 유형 -> SQL
• 그 반대 -> NoSQL이 더 좋을 수

5. 사용자의 지리적 분포는 어떠한가?

• 빛의 속도 때문에 전 세계에 사용자가 퍼저 있다면 레이턴시 발생

6. 데이터의 ‘형태’는 무엇인가?

• SQL database
  • 엄격한 유형의 데이터를 테이블에 저장
  • 정의된 관계에 의존하여 index를 사용하여 쿼리 속도를 높이고 join을 사용하여 여러 테이블을 한번에 쿼리 가능
• document database
  • array와 embedded document를 사용하는 JSON 저장
• graph database

7. 애플리케이션은 OLTP, OLAP 중 어떤 것을, 또는 모두를 필요로 하는가?

OLTP? OLAP? HTAP?

• 어플리케이션이 트랜잭션, 분석 또는 다 필요한지 고민 필요
• 빠른 트랜잭션이 필요하면 빠른 쓰기 속도와 최소한의 index 가 필요
• 분석이 필요하면 빠른 읽기 속도와 많은 index 필요

8. 현실 속에서 기대하는 쓰기 대비 읽기의 비율은?

• 읽기가 빠른 데이터베이스 쓰기가 빠른 데이터베이스 존재
• 읽기 특화 어플리케이션은 보통 B-tree
• 쓰기 특화 어플리케이션은 보통 LSM(Long-Structed Merge)

9. 지리적 쿼리(Query) 또는 전체 텍스트 쿼리가 필요한가?

• 지리적 또는 기하학적 데이터
• 경계 안의 객체 또는 한위치의 주어진 거리안에서 객체를 찾기 위한 효율적인 쿼리 필요 시
• 지리 공간 index에는 R-tree가 많지만 다른 데이터 구조도 존재
• 공간 데이터를 지원하는 수십가지의 데이터베이스 대부분은 OGC(Open Geospatial Consortium) 표준을 지원

10. 선호하는 프로그래밍 언어는 무엇인가?

11. 예산이 있는가? 그렇다면 라이선스 및 지원 계약까지 포함시킬 수 있는가?

12. 데이터 저장소에 대한 법적 한계가 있는가?

• EU
  • 개인정보보호규정(GDPR) 이 프라이버시, 데이터 보호, 데이터 위치에 많은 영향을 끼친다
• 미국
  • 건강 보험 양도 및 책임에 관한 법(HIPAA)에서 의료정보를 규제
  • GLBA은 금융기관들이 고객의 개인정보를 처리하는 방식 규제
  • 캘리포니아에서는 새로운 소비자 개인정보 보호법(CCPA)가 프라이버시 권리 및 소비자 보호 강화

◼Database 종류

Database Type	Use Case	AWS Service
Relational	전통적인 어플리케이션, e-commerce, OLTP 트랜잭션	- Aurora - RDS
Key-value	높은 트래픽이 있는 어플리케이션, e-commerce, gaming, 금융거래	- DynamoDB - Keyspace
Document	컨텐츠 다루는 곳, 카탈로그들, 유저 프로필	- Document
OLAP	전통적인 데이터 웨어하우스, SaaS	- Athena - Redshift
In-memory	캐싱, 세션, 리더보드, 지리적인 어플리케이션	- Elasticache - MemoryDB for Redis
Search	로깅, 개인화 검색	- OpenSearch
Graph	Fraud detection(이상 거래 탐지), SNS, 유저 프로필	- Neptune
Ledger	시스템 기록, 서플라이 체인, 등록, 뱅킹 트랜잭션	- QLDB
Time series	IoT, DevOps, 텔레메트리	- Timestream

RDBMS(관계형 데이터베이스 관리 시스템)

오라클, mysql, ms server, postgresql

• 장점
  • 고도로 정형화 된 데이터 처리에 뛰어남
  • ACID 트랜잭션 지원
  • 데이터 저장 및 검색은 SQL로 쉽게 처리
  • 기존의 데이터 수정 없이 데이터 추가가 간단해 구조를 빠르게 확장 할 수 있다
  • 계층화된 접근이 필요한 어플리케이션에 적합
    • 어떤 사용자 타입이 접근이 가능하거나 수정이 가능한지 설정 가능
• 단점
  • 비정형 데이터 처리 한계
  • 테이블로부터 떼어낸 데이터를 가독성이 높은 것으로 재 조립해야 하고 이것은 속도에 영향을 준다
  • 고정된 스키마(schema)는 변화에 유연하게 대응하기 어려움
  • 관계형 데이터베이스는 구성과 확장에 비용이 많이 드는 경향
  • 수평으로 확장 하려면 sharding이 필요하고 ACID를 유지하면서 sharding은 까다로운 작업
• 적합한 케이스
  • data integrity가 중요한 상황
  • ex) 재무, 보안, 개인 건강 정보 등 고도로 정형화된 데이터

Document Database

mongodb, couchbase

• 데이터를 JSON, BSON, XML등으로 저장하는 비관계형 데이터 베이스
• 유연한 스키마
• SQL과 달리 구조를 강제하지 않음
• 문서에 원하는 어떤 데이터도 넣을 수 있다.
• 강점
  • 매우 유연한 데이터 베이스
  • 반정형, 비정형 데이터 처리에 적합
  • 어떤 유형의 데이터가 들어올지 미리 알수 없는 경우에 적합
  • 사용자는 모든 문서에 영향을 주지 않고 특정 문서에 원하는 구조 생성 가능
  • 스키마는 중단 시간 없이 수정이 가능하여 가용성이 높음
  • 빠르고 효율적으로 수평 확장이 용이(수평 확장에 필요한 샤딩이 RDBMS보다 훨씬 직관적)
  • 작성 속도 역시 전반적으로 빠름
• 약점
  • 유연성을 위해 ACID를 희생
  • 질의가 한 문서 내에서만 가능, 여러 문서에 걸쳐서는 불가능
• 적합한 케이스
  • 비정형, 반정형 데이터가 있는 경우
  • 심도 있는 데이터 분석, 빠른 프로토 타입 작업에 적합

key-value database

redis, memcached

• 각 값이 특정 키와 연관된 일종의 비관계형 데이터베이스
• associative array라고도 부름
• key: 512mb의 어떠한 binary sequnce라도 될 수 있다.
• value: blob으로 저장되지만 미리 정의한 스키마는 불필요
• 장점
  • 뛰어난 유연성
  • 광범위한 유형의 데이터 쉽게 처리 가능
  • key는 index 검색이나 join없이 바로 추출 되기 때문에 성능에 이점
  • 코드를 다시 작성하지 않고도 한 시스템에서 다른 시스템으로 이동 가능
  • 뛰어난 수평 확장성
  • 전체적인 낮은 운영 비용
• 약점
  • 값 질의 불가능(블롭으로 저장 되어 있어 블롭으로만 반환되기 때문)
  • 값의 일부를 편집하기 어려움
  • 모든 객체를 key-value형태로 모델화 하기 어려움
• 적합한 케이스
  • 비정형 데이터 작업이 많은 경우
  • ex) 추천, 사용자 프로필 및 설정, 상품 사용기, 블로그 댓글 등
  • 대규모 세션 관리, 자주 접근하지만 자주 업데이트되지 않는 데이터에 적합

wide-column databae

cassandra, HBase

• 확장 가능 기록 저장소
• 동적인 컬럼 지향 비관계형 데이터 베이스
• key-value database로 보는 경우도 있지만 관계형 데이터베이스 속성도 존재
• 스키마 대신 keyspace 개념 사용, keyspace는 칼럼 집합을 포괄
• 테이블과 비슷하지만 구조면에서 더 유연
• 각 칼럼 군에는 열이 구별된 여러개의 행이 존재
• 각 행은 똑같은 갯수나 유형의 열을 갖고있을 필요 없음
• timestamp를 통해 가장 최근 버전의 데이터를 판별
• 강점
  • 관계형, 비관계형 데이터베이스의 장점 모두 갖고 있다.
  • 다른 비관계형 데이터베이스보다 정형 데이터 및 반정형 데이터 처리에 능하고 업데이트도 쉬움
  • 관계형 데이터베이스보다 수평 확정성이 더 크고 속도가 빠름
  • 대규모 데이터 집합을 간단하게 탐색 가능
  • 집계 질의에 특히 능함
• 약점
  • 소규모로 사용할 때 많은 비용
  • 한꺼번에 업데이트 하는 것은 쉽지만 개별 기록을 업로드하고 업데이트에느 ㄴ어려움
  • 트랜잭션을 처리할 때 관계형 데이터베이스보다 느리다
• 적합한 케이스
  • 속도가 중요한 빅데이터 분석
  • 빅데이터에 대한 데이터 웨어하우스 작업
  • 일반적인 트랜잭션 응용프로그램에 좋은 도구가 아님

distributed relational database

• 1980년대 부터 써온 RDBMS는 흔히 중앙 처리 장치나 단일 서버에서 실행
  • 처리 대이터양이나 실행 속도 개선을 위해 Scale up에 의존
  • 가용성 개선을 위한 수동 전환 기능으로 hot backup server와 active 서버를 active-passive 클러스터에 함께 배치
  • 공유 스토리지를 이용하는 것이 일반적
• NoSQL과 달리 분산된 서버에도 일관성이 희생 되지않는 데이터 베이스(Scale out이 가능한 database)
• ex
  • AWS RDS, AWS aurora
  • Azure SQL database
  • ClustrixDB
  • CockroachDB
  • Google cloud spanner

◼Uber

postgres에서 mysql로 변경

• postgresql 한계
  • write에 효율적이지 못한 아키텍처
  • 비효율적인 data replication
  • table corruption 문제
  • 부족한 replica MVCC 지원
  • 새로운 버전 업그레이드 어려움
• mysql 장점
  • MySQL은 concurrent한 연결을 thread로 처리 하기 때문에 process를 사용하는 postgresql보다 오버헤드가 적다
  • buffer pool에서 postgres는 내부적으로 cache를 사용하는데 작다. 반면 InnoDB는 자체적인 LRU를 구현하여 커스텀이 가능했다.
  • 여러개의 다른 replication mode를 제공한다.
  • postgres처럼 InnoDB도 MVCC 같은 특징을 제공한다

◼Discord

cassandra 선택 이유 mondoDB를 사용하고 있었지만 sharding이 복잡했고 안정성이 없다고 판단

올바른 Database 고르기

데이터 베이스를 고르기 전에 read/write 페턴 확인하여 현재 문제 진단

• read가 극단적으로 랜덤이었고 read/write비율이 대략 50/50
• voice chat이 많은 방은 message를 보내지 않았고 적은 양의 message여도 cache가 축출되는 문제를 발생 시킴
• private text가 많은 방은 어마어마한 message를 보낸다. 보통 100명 미만의 구성원들이고 필요한건 최신 데이터 인데 cache에 없을 가능성이 있음
• 큰 public한 방에서는 어마어마한 messag가 발생되고 읽기와 쓰기가 빈번하기때문에 모두 cache에 있을 가능성이 있음
• 랜덤 읽기 기능 추가 예정

requirements

• Lineaer scalability : 나중에 솔류션을 고민해야 하거나 수동으로 다시 shard해야 하는 경우 원치 않는다
• Automatic failover: 밤에도 일하고 싶지 않기 때문에 가능한한 스스로 회복이 가능한 데이터베이스
• Low maintanance: 한번 만들때만 작업하고 데이터가 늘어나면 node만 추가해주면 가능한 구조
• Proven to work: 새로운 시도도 좋지만 너무 새로운건 부담스러움
• Predictable performance: 응답이 80ms가 넘으면 알림을 주고 있다 그리고 redis나 memcache같은 cache를 쓰고 싶지 않다
• Not a blob store: 매초 수천의 message를 써야 할때 지속적으로 blob을 역직렬화 하고 붙이는 것은 좋지 않다
• Open source: 타사의 존망에 의존하고 싶지 않다

---

Reference

• [IoT 데이터 처리의 모든 것-③] 시계열 데이터베이스 출현
• DynamoDB에 대해서 알아보자 - 1
• ‘질문 12개로 구성한’ 데이터베이스 선택 가이드
• RDB부터 검색엔진까지··· 내게 꼭 맞는 DB 고르기
• RDBMS·NoSQL 장점만 모았다··· '분산 관계형' 데이터베이스 5종
• How Discord Stores Billions of Messages
• Why Uber Engineering Switched from Postgres to MySQL
• The Case for Purpose-Build Databases

1. 일정 기간 동안 가장 높은 부하 [본문으로]
2. Bandwidth vs. Throughput [본문으로]