DevOps Day 17 (3.29) 데이터베이스_데이터 파티셔닝 + 캐시

대용량의 데이터 – 파티셔닝
데이터셋이 매우 크거나, 쿼리 처리량이 매우 높아 복제하는 것만으로는 부족할 수 있는 문제가 있을 경우 데이터베이스를 파티션이라는 작은 단위로 쪼개서 활용하는 방법이 있습니다. 샤딩 (sharding)이라고도 표현합니다.

 

파티셔닝의 목적
데이터 파티셔닝을 필요로 하는 주된 이유는 확장성 때문입니다. 데이터베이스가 확장되면서 점점 대용량의 데이터베이스가 되고, 그러한 환경에 맞게 프로세스를 처리할 필요성이 생기기 때문입니다.

쓸림현상 (Skewed) 방지를 위한 시도
- 일반적으로 파티셔닝과 복제(Replica)는 함께 사용됩니다. 파티션 내부를 더 자세히 살펴보면 각 파티션의 복사본을 여러 노드에 저장하고 있는 것을 알 수 있습니다. 이러한 방식을 사용하는 이유는 요청의 쏠림현상(skewed)을 방지하기 위해서입니다.
- 데이터를 분산시켰음에도 불구하고, 특정 패턴을 가진 요청에 의해서 한 곳으로 요청이 쏠리는 현상(skewed)이 발생할 수 있습니다. 이러한 문제를 피하기 위해서 파티션을 구성할때는 데이터의 쿼리(질의) 부하를 노드 사이에 고르게 분산시킬 수 있도록 전략적으로 배치해야 합니다.

고른 분포를 위한 전략
1. 첫번째 방법은 레코드를 할당할 노드를 무작위로 선택하는 것입니다
2. 키 범위를 기준으로 한 파티셔닝을 진행하는 것입니다
3. 키의 해시값 기준 파티셔닝입니다

 

동일 데이터의 잦은 조회 – 캐시
캐시(Cache)는 임시로 복제된 데이터를 저장하는 장소로 사용자가 더 효율적이고 빠르게 원하는 데이터에 접근할 수 있도록 하기위해 설정됩니다.

 

개시 사용의 장점
데이터 베이스는 기본적으로 속도 보다는 데이터의 저장과 안정성에 초점을 맞추게 됩니다. 캐시의 경우에는 임시로 데이터가 저장되는 장소이기 때문에, 저장의 기능보다는 정보를 제공하는 처리 속도에 더 집중 할 수 있습니다(인 메모리 캐시).

 

비용감소
캐시를 사용하게 됨으로서 원본 데이터베이스에 대한 쿼리 수를 줄이고, 데이터베이스 자체를 스케일링 할 필요성을 낮추면, 성능 향상과 더불어 비용을 절감하는 효과를 낼 수 있습니다.

 

캐시 타입
Cache-aside : 애플리케이션을 설계할 때 캐시 보관 패턴을 사용합니다. 데이터가 캐시에 존재하지 않는다면 데이터베이스에 직접 연결하도록 코드를 구성합니다.

 

Read-through/Write-through Cache
- Read-through/Write-through 캐시 모두 데이터베이스와 일렬로 배치되며, 애플리케이션은 뒤에 있는 데이터베이스가 아닌 캐시를 주 데이터 저장소처럼 취급합니다.
- Read-through를 통해서 애플리케이션이 데이터를 읽으려 한다면, 최초 데이터를 로드할 때만 캐시가 데이터베이스에 접근합니다.
- Write-through를 통해서 에플리케이션에서 쓰기 요청이 발생한다면, 우선적으로 캐시에 데이터를 추가한 뒤 데이터베이스에도 데이터를 추가하게 됩니다.

 

Write-behind/write-back Cache
Write-behind(back) 방식을 사용하면, 애플리케이션은 일단 캐시에 데이터를 저장합니다. 그 후 캐시가 백그라운드에서 비동기적인 방식으로 데이터베이스에 데이터를 기록합니다. 이러한 방식은 쓰기처리가 많은 워크로드에 적합한 캐시 방법입니다.