[DB] 분산환경에서 데이터 저장소 선택과 활용

RDBMS

장점

• Relation 기반
• 높은 신뢰성
• 비교적 높은 성능
• 비교적 다양한 기능
• 관리편의성

단점

• 단일 장비.. RDB 데이터가 많을 경우 확장성이 떨어짐

 

> 개선하기 위해 나온

NO SQL

장점

• 관계없는 데이터 처리에 최적화
• 높은 확장성을 가지는 경우 많음(여러 장비가 동시에 투입되는 것을 고려하고)
• Schemaless

단점 

• 제한적인 일관성
• Join, Transction 미지원
• 관리비용이 큰 경우 있음

 

데이터가 커지면

수직확장 = 장비증설

• 고비용
• 확장 시 서비스 중단(일부 중단 안 해도 되는 게 있으나 비싸)
• 확장 한계(슬롯에 꽂아)
• 관리 편의성

수평확장 = 분할(partitioning)/ 분산(distribution)

• 데이터 자체를 종류별로 쪼개서
• 다 다른 장비에 담음

 

분할

테이블 분할(수평/수직)

• 수평은 row단위로
• 수직은 column단위로

DB분할(테이블 위치 분산)

• 수평/수직으로 해결이 안될 때..

 

분산

분산 환경이란 무엇인가?

• 여러 대의 서버가 네트워크로 연결된 것(이중화)
• 분산 시 지연, 대역폭, 패킷 손실 있을 수 있음
  • 불일치 발생할 수도; 네트워크 이상일 수도 있고 장비 이상 혹은 공격받았을 때도 있음
• ACID 보장이 어렵다
  • 한 장비에 문제가 생겼을 경우 동기화가 불가할 때 데이터가 틀어질 수도 -> 따로 컨트롤 필요
• 데이터 복제(slave)
  • 무결성 보장이 어렵
• 디비가 나눠져 있으면 조인이 어렵다...

위치 분산(테이블을 쪼갠다)

디비를 먼저 쪼개고 그 디비를 다른 장비에

 

샤딩 sharding

• 수평분할을 이용한 분산
• 각 샤드는 테이블 별 동일한 스키마, 중복되지 않은 값을 가짐
• 샤드에 데이터를 나누는 기준이 필요 -> shared key

range shard

• 규칙을 정하고 범위를 나눠 분산(key 1~1000 / 1001 ~ 2000.... etc)
• 부하가 불균형
  • 범위별로 잘 쓰는 사람 안 쓰는 사람들이 있을 수 있는데 보통 이를 재배치해서 해소함
• 허나 재배치 기준을 잡기가 어려움 -> 잘 안 씀

modulus shard

• shard key를 해시(해시 함수가 mod)
• 부하가 비교적 균등
• 확장과 재배치 어려움

hash map shard

• 해시된 값을 기준으로 배치 룰을 별도로 만들어
• 부하가 비교적 균등
• 샤드별 비중도 지정 가능(3번 샤드가 성능이 좋으면 3번으로 더 가게 할 수 있음)
• 데이터 불균형 시 데이터 재배치 어려움
• 해쉬맵을 바꾼다고 해서 다시 재배치해야 하는데,, 그 비용이 큼

index shard

• 샤드 정보(사용자 위치)를 별도 저장소에 저장
• 신규 가입자 배치 조절 가능(3번에 더 가게 할 수 있음)
• 확장은 쉬우나 재배치 어려움(4번 추가 가능; 비중을 조절할 수 있음)
• 유저와 샤드를 매핑해 둠
• 샤드별로 카운드 둬서 가장 적은 카운트로 신규 이용자 받을 수

directory shard

• 샤딩을 위한 추상화된 서비스를 사용
• index shard와 유사

샤딩을 적용할 수 있는 경우

• 샤드 간 transaction/join이 발생하지 않는 데이터
• 데이터를 보는 관점이 하나인 데이터
  • 사용자의 입장? 사용자-구매내역- 연결된 데이터는 한 샤드에 
  • 판매자의 입장?
  • 해당 서비스의 주된 관점을 기준으로.. 샤딩
  • 주된 관점이 아닌 한 성능상 손해..
• 쓰기 부하 분산이 필요한 경우
  • 읽기 부하는 master-slave로 쉽게 분산 가능
  • 쓰기는 여러 군데에서 동시에서 쓰면 일관성 보장이 힘들어짐 그래서 일반적으로 쓰기 장비가 하나만 둠
  • 그 한 장비에서 쓰기가 엄청 많이 들어올 경우 테이블을 나눠놓으면 쓰기 부하가 분산됨
• 데이터 크기나 사용량이 편중되지 않은 경우
  • 특정 데이터가 엄청 커지면 부적합...

샤딩을 적용하기 어려운 경우

• 샤드 간 transaction이 빈번할 때
• 데이터를 보는 관점이 여러 개인 데이터
• 여러 샤드와 공통으로 관계를 맺는 데이터
• 특정 부분만 access가 집중되는 데이터

 

읽기 복제(replica)

• 동일 스키마, 동일 데이터의 복제본(전체/부분)
• 읽기 부하 분산 가능(slave에서 조회 시)
• 쉽고 간단하게 증설 가능
• 디비보다 캐시가 더 빠르다!

 

NOSQL

1. 확장성/가용성

• 모든 데이터가 RDB수준(ACID)으로 필요하지 않을 때
• 신뢰성을 희생해서라도 확장성/가용성 증대

2. 다양한 데이터 형태

• 관계가 필요 없는 데이터
  • 세션정보
  • key-value type
  • document, json
  • column store

3. 스키마 없음; 스키마가 필요한 경우에만 지정 가능(스키마 수정이 빈번할 경우)

4. 트랜잭션 없음; 약하게...

5. 조인 없음; 지원을 해도 제한이 있음

6. 제한된 액션(기본적인 CRUD +..)

7. 인덱스가 기존 디비보다 다양치 못함(미약)

 

mongoDB

• document store / json 타입 저장
• 장애가 발생해도 쉽게
• dba 관리 힘들어(성능 향상이 힘들어)
• 범용성 지향(인덱스 있고 조인도 힘들지만 되고 트랜잭션도 강화 중)
• 개발 편의성 좋음
• schemaless 데이터가 많을 경우 / json
• 트랜젝션이 별로 없으면 유리

단점

• 최소 권장 3대 ~ 권장 세팅 5대
• 장비의 비용이 듦..
• 초기부터 늘려서 사용해야.. 더 비쌀 수도 있음

 

카프카

• 실시간으로 기록 스트림을 게시, 구독, 저장 및 처리할 수 있는 분산형 데이터 스트리밍 플랫폼
• 데이터의 송신보장
• 분산 시스템으로 온라인 상태에서 간단하게 중개인 추가 가능
• 병렬로 처리하기 위해 파티션으로 나눠서 처리
• 파티션을 복제 - 다른 서버/노드가 장애 발생 서버의 역할을 대신 고속성을 유지하면서 데이터의 송신 보장이 가능

 

분산의 타이밍

• 서비스 시작 전 - 저장소 선택 기준
• 성능 한계 도달 전 - 확장

저장소 선택 기준

1. 데이터의 크기: 얼마나 큰/많은 데이터

2. 데이터 온도: 얼마나 자주 액세스

3. 데이터 타입: 어떤 형태(key-value, document....)

4. 일관성: ACID

5. 부하 특성: 언제 얼마나 CRUD 부하가 발생하는가(read/write)

확장은 언제?

• 개별 장비의 한계에 도달할 때 -> 키워야..
• 증설보다 확장이 유리할 때

확장 방법

• 샤드 - 어떻게 나눌지 미리 결정(초기에 같이 고민; 샤드가 가능하도록 디비 구성; 쓰기 분산 고민스러우면 초기에 샤드를 고려해)
• 읽기 복제본 추가(중간 확장 시 가장 쉬움, 이중화가 되어 있기 때문에 어느 정도 되어 있음)
• 디비 분산

 

보관기간은 기획자와 선상의해야 하며

파티셔닝 요청 시 기준이 되는 컬럼은 Datetime으로 하는 게 좋다..

timestamp는 2038년까진가 한계가 있는 값..

아카이브 저장소 - 백업용 디비; 안쓰는 디스크에 데이터 몰아둠.. 근데 쓰기만하고 읽지는 않더라..

 

샤딩 반영 시 관점이 다른 데이터를 가져올 때

1. common db 방식: 샤드에 갱신한 정보를 common db에도 업데이트; 다양한 관점에서 조회 가능

2. 캐시: 주요한 걸 캐시에 올려두고 상세는 별도로 조회해서 조합

3. 순환조회: 전체 샤드를 대상으로 조회하고 조합함.. 성능이 구려 서비스에 적용하진 않고 보통 통계 등에 사용

---

참고: 샤딩 vs 수평 파티셔닝

https://develaniper-devpage.tistory.com/100

[DataBase] 5. 파티셔닝/ 샤딩