- 데이터베이스의 원칙
- 데이터베이스의 종류 및 특징
- Row-Oriented vs Column-Oriented
- CAP Theorem
- 서비스에 적합한 DB 선택
- 언제 MySQL을 사용한 것인가?
데이터베이스의 원칙
-
무결성
데이터가 정확하고 일관성 있어야 하며 오류가 없어야 함.
하지만 일관성의 경우 서비스의 방향에 따라 타협할 수도 있음.
정의된 규칙과 제약 조건을 준수해야 함.<strong vs eventual의 예시>
ㅇ Strong Consistency (강력한 일관성) - 은행계좌 잔액관리
1번 계좌에서 빠져나간 돈은 2번 계좌에 꼭 들어가야 함.ㅇ Eventual Consistency (최종적 일관성) - 소셜미디어 게시물
모든 서버 간에 즉각적인 일관성이 필요하진 않음.
유저가 올린 게시물이 즉각 동기화되지 않더라도 일정한 시간 안에 동기화됨.
이는 대규모 분산 시스템에서 성능과 응답 시간을 향상시키는 데 도움이 됨.정리하면, Strong Consistency는 데이터의 엄격한 일관성을 유지하고
동시성을 제한하기 때문에 대규모 분산 시스템에서는 추가 오버헤드를 유발할 수 있음.
Eventual Consistency는 대규모 분산 시스템에서 성능 향상을 꾀할 수 있지만
일시적인 데이터 일관성이 떨어질 수 있음.
-
안전성
데이터베이스에서 안전성은 보안과 접근 제어를 의미함.
민감 정보를 저장하므로 악의적인 사용자로부터 보호되어야 함.
고장이 잘 나지 않아야 하고 장애 방지, 복구 대책이 있어야 함. -
확장성
더 많은 데이터, 더 많은 작업을 처리할 수 있음.
수평 확장 - scale out(샤딩, 클러스터링),
수직 확장 - scale up(하드웨어 업그레이드)와 같은 방식으로 구현 가능함.<예시>
ㅇ 대규모 데이터 처리 - scale out
여러 서버를 활용해 데이터 처리 능력 확장할 수 있음.ㅇ Stateless 어플리케이션 - scale out
서버에 상태를 저장하지 않음.
그렇기 때문에 scale out 시 서버 상태를 복제할 필요가 없음.
-> 복잡성이 낮음.
-> 비용이 덜 들어감. 복제 안 하니까.
-> 유연해짐. 상태 유지 안 하니까 서버 추가나 제거가 용이함.ㅇ Memory-intensive - scale up
메모리 인텐시브는 메모리 사용량이 많은 애플리케이션을 의미함.
일반적으로 cpu 사용량이 많지 않음. 스케일 업이 좀더 쉽게 성능 향상 가능함.
성능을 올리면 장애율이 낮아지기 때문에 단일 서버 장애로 인한 손실을 어느 정도 예방할 수 있음.ㅇ CPU-bound - scale up
많은 계산을 필요로 하는 cpu 처리 능력이 필요하므로 스케일 업이 유리함.ㅇ CDN - scale out
전세계 서버에 캐시를 제공해야 하므로 스케일 아웃이 유리함.ㅇ 모노리식 서버 - scale up
단일 서버, 노드를 사용하므로 스케일 업을 해야 함.
RDBMS / NoSQL(key-value, graph, document)
-
rdbms
관계형 데이터베이스.
테이블로 이루어져 있고 각 테이블은 레코드와 칼럼으로 구성돼 있음.
테이블의 구조, 데이터 유형, 제약 조건을 명시한 스키마가 있음.
Oracle, MySQL, PostgreSQL, MariaDB 등이 있음. -
NoSQL
비정형, 반정형 데이터를 처리할 수 있음.
스키마가 자유로워서 데이터 모델링이 유연함.
대부분 분산 시스템에 많이 쓰이며, 여러 서버에 데이터를 분산해서 확장성을 제공함.ㅇ Redis(key-value)
In-memory 데이터 스토어로 데이터를 빠르게 읽고 쓸 수 있음.
주로 캐싱이나 세션 관리쪽에 사용됨.ㅇ DynamoDB(key-value)
아마존(AWS)의 NoSQL 서비스로 고가용성, 확장성을 제공함.
주로 웹 애플리케이션이나 모바일 앱에 사용됨.ㅇ Neo4j(graph)
데이터를 노드와 관계의 집합으로 모델링함.
데이터 간의 관계와 연결을 중심으로 데이터를 저장, 검색, 쿼리하기에 적합함.
사이퍼 쿼리라는 걸 사용한다고 함.ㅇ MongoDB(document)
문서 지향 데이터베이스로 json과 비슷한 형태인 bson 형태로 데이터를 저장함.
NoSQL답게 스키마가 유연하고 대규모 시스템에 많이 사용됨.
Row-Oriented vs Column-Oriented
행 지향 데이터베이스와 열 지향 데이터베이스를 말함.
데이터를 저장하고 처리하는 방식에 차이가 있음.
-
Row-Oriented
행 단위로 데이터를 저장함.
즉, 하나의 레코드에 해당하는 데이터를 연속적으로 저장함.
하나의 레코드에 다양한 컬럼의 데이터들이 존재하게 됨.
연속된 메모리 공간에 저장되고 같은 레코드의 데이터들은 인접하게 저장됨.
데이터 조회 시 전체 레코드를 읽는 게 보편적이고, 특정 컬럼에 대한 접근은 느릴 수 있음.
레코드에 대한 읽기, 쓰기 능력이 빠름.
주로 트랜잭션 처리에 사용됨. -
Column-Oriented
컬럼 단위로 데이터를 저장하는 방식을 말하며,
같은 컬럼에는 같은 유형의 데이터가 연속적으로 저장됨.
이 때문에 데이터 압축과 해제가 효과적으로 수행됨.
특정 컬럼에 대한 연산, 예를 들면 집계함수 같은 걸 빠르게 할 수 있음.
또 필요한 컬럼만 읽을 수 있음.
다만 레코드에 대한 쿼리 작업은 느릴 수 있음.
데이터 분석이나 머신러닝에 주로 쓰임.
CAP Theorem
CAP 이론은 분산 데이터베이스 시스템의 설계와 특징을 이해하는 데 중요한 개념 중 하나다.
CAP은 일관성, 가용성, 분할 내성을 나타내는 영어 단어의 약자를 나타낸다.
-
Consistency(일관성)
데이터가 일관적으로 표시돼야 함. -
Availability(가용성)
모든 요청은 응답을 받을 수 있어야 함.
시스템은 항상 동작하고 있어야 함. -
Partition Tolerance(분할 내성)
분산 환경에서 발생하는 네트워크 문제에 대한 내성을 나타냄.
네트워크 분할이나 노드 간 통신 장애가 있을 때에도
시스템은 여전히 동작 중이어야 함.
CAP 이론은 세 가지 중 두 가지만 동시에 보장되는 것을 말함.
(CA, CP, AP)
CA는 일관성 있고 가용성 있지만 분할 내성이 없기 때문에 분산 시스템에서 쓰이지 않고,
CP는 일관성 있고 분할 내성이 있지만 가용성은 부분적으로 상실되는데,
대부분의 분산 시스템에서 사용됨.
AP는 가용성도 높고 분할 내성도 있지만 일관성이 부족한데,
대부분의 NoSQL이 이에 해당함.
서비스에 적합한 DB 선택
분산 처리가 많은 환경에 MySQL을 쓴다거나
일관성이 보장돼야 하는 서비스에 NoSQL을 쓴다면
문제가 생기거나 엄청난 비효율이 발생함.
서비스에 적합한 데이터베이스를 선택할 수 있어야 함.
언제 MySQL을 사용할 것인가?
- E-commerce
서비스가 작을 때 무료이니까 사용해 볼 수 있음. - 분산 시스템
관계를 갖는 특성상 분산이 안 되기 때문에 분산 시스템에는 사용 불가. - 그래프 기반 데이터도 사용이 적합하지 않음.
공통 컬럼이 있나도 찾아봐야 하고 불편함이 있음
또 조인이 너무 많아짐.
조인이 많아진다는 건 비용이 많이 들어가고 성능 저하가 생긴다는 걸 의미함. - 대용량 실시간 분석에는 Column-Oriented가 이점이 있을 수 있지만,
Row-Oriented는 어려울 수 있음.
그리고 대용량 분산 시스템은 대부분 NoSQL을 사용함.
