Clustering (DB 서버에 대한 고민)
우선, STORAGE는 DB 저장소를 DB 서버는 DB 작업을 하는 서버를 의미한다.
👉목표
서버를 여러개 만들어 DB SERVER가 죽는 것을 방지하자
👉 종류
1. 하나의 큰 STORAGE 안에 2 ACTIVE SERVER : 처리 속도는 더 빠르지만 병목현상 있을 수 있음
2. 하나의 큰 STORAGE 안에 ACTIVE-STANDBY : 하나는 대기 상태로 두어 병목현상 X
REPLICATION (DB 손실에 대한 고민)
👉 목표
실제 데이터가 저장되는 저장소도 복제하여, 저장된 데이터 손실을 방지하자
👉 특징
- MASTER-SLAVE 구조로 MASTER로 들어온 데이터를 SLAVE로 동기화하여 데이터를 백업
- MASTER는 수정, 삽입, 삭제 역할
- SLAVE는 조회용으로 사용
Replication에 대한 구체적인 내용은 아래 글 참고
https://yubi5050.tistory.com/195
SHARDING (DB 검색 효율에 대한 고민, 과도한 트래픽 고민)
👉 목표
- DB 테이블을 나누어 데이터가 너무 많아서 검색이 느린것을 해결해보자
- DB 부하가 심해지면 애초에 샤딩으로 데이터를 분리하여 저장하여 해결하자
👉 설계 간 주요 고려사항
- 분산되는 DB DATA를 어떻게 잘 분산 저장할 것인가
- 분산되는 DB DATA를 어떻게 잘 읽을 것인가
👉 특징
- 나눠지는 DB 각각을 SHARD라고 하며, SHARD KEY에 따라 SHARD를 선택함
- SHARD KEY 결정 방식에 따라 SHARDING 방법이 나뉨
- 아래 종류 1과 종류 2는 nosql 저장방식에 더 어울리고, 종류 3은 rdb에 좀더 어울림
👉 종류
1. hash sharding (id%4)
- 4는 shard 갯수
- 구현이 간단하지만 만약에 shard 확장시 hashing 함수가 달라져야 하므로 기존에 저장된 데이터의 정합성이 깨짐
- 공간에 대한 효율을 고려 하지 않는다.
2. dynamic sharding
- locator service를 두어 id range에 따라서 sharding 하는 방식
- 확장에 유연하지만, locator service를 거쳐야 shard가 정해지므로 의존적임
3. entity group
- shard 각각 마다 관련된 rdb table row들을 모아두는 방식
- 단일 shard 내에선 쿼리가 효율적이지만, 데이터간 강한 응집도를 가짐
- 단점은 다른 shard의 entity와 연관이 되는 쿼리의 경우 비효율적임
'DB > 이론' 카테고리의 다른 글
[MQ] 메시지 지향 미들웨어 (by. RabbitMQ, Redis) (0) | 2022.11.26 |
---|---|
[Cache] Memcached vs Redis 차이 (2) | 2022.11.22 |
[DB] Replication 이란? (Feat. Mysql, Mongo) (0) | 2022.10.03 |
[DB] Index란? (0) | 2022.08.11 |
[DB] Transaction 격리 수준 종류 (Isolation Level) (0) | 2022.08.10 |