Chapter 7, 데이터베이스 문제 상황에 따른 해결책
낮은 검색 성능 - 인덱싱
효율적인 검색을 위한 시도
데이터를 요청에 맞게 찾아서 제공하는 데이터베이스 기능에 좀더 효율적인 검색을 하기위해 인덱스(색인)을 이용합니다. 인덱싱을 하면 전체를 스캔할 필요없이, 인덱스되어 있는 데이터를 넘겨줄 수 있습니다.
데이터 검색에 도움을 주기 위한 메타데이터
인덱스는 데이터베이스에 저장된 기본데이터(primary data)에서 파생된 부가적인 메타데이터(meta-data : 데이터에 관한 구조화된 데이터)입니다. 이 메타데이터인 인덱스가 우리가 원하는 데이터의 위치를 찾는데 도움을 주는 이정표가 됩니다. 우리가 책에서 어떠한 내용(data)을 찾을 때 앞부분에 따로 구성된 목차(index)를 통해서 해당 데이터의 위치를 빠르게 찾아 나가는 것에 비유할 수 있습니다.
데이터에 영향을 주지 않는 인덱스
데이터가 추가되고, 삭제되며, 업데이트 되는 것 처럼 인덱스도 이와같이 변경될 수 있습니다. 하지만 인덱스는 데이터에 영향을 주지않습니다. 다만 질의(Query)성능에만 영향을 줍니다.
많은 사용자 - 레플리카
안정적인 서비스를 제공하기 위한 시도
많은 사용자가 하나의 데이터베이스에 접근을 시도하는 경우 성능 저하가 발생할 수있습니다. 이 경우 데이터베이스의 복사본을 저장하는 각각의 노드인 레플리카(복제서버)를 활용하며 문제를 해결할수있습니다.
레플리카는 원본데이터베이스와 같은 데이터를 여러 노드에 유지하는 방식입니다.
레플리카는 데이터 중복성이 발생하며, 이로 인해 얻을 수있는 장점이 존재하고, 해결해야하는 문제점 역시 존재합니다.
레플리카 활용의 장점
시스템 장애 발생시에도 동작할 수 있도록 가용성 확보
일부노드가 장애로 인한 접근불가(사용불가) 인상황에도, 다른노드를 통해 여전히 데이터에 접근이 가능합니다.
읽기 쿼리 제공 장비 수를 확장해 읽기 처리량을 늘림
사용자의 요청이 하나의 데이터베이스의 집중되는것을 막을 수 있습니다.
레플리카를 읽기전용 데이터베이스로 활용이 가능합니다.
리더에서는 읽기와 쓰리를 처리하고, 레플리카에서는 읽기전용으로만 데이터베이스를 제공하고, 쓰기가 발생했을 시 데이터를 저장하여 동기화를 진행합니다.
지연시간 감소
원본데이터베이스의 거리가 지리적(물리적)으로 멀 경우, 응답이 시간이 느려질 수 있습니다. 이러한 지연시간 감소를 위해 레플리카를 지역별로 분산시킬수 있습니다.(대륙별, 나라별 등)
레플리카 활용 시 고려해야할 사항
동기식 복제(synchronous)
- 동기식으로 복제가 진행되는 레플리카 구조에서는 리더의 데이터 처리와 별개로 레플리카에서의 데이터 처리 까지 무도 완료가 되어야 프로세스가 진행됩니다.
- 동기식 복제의 경우 리더 데이터베이스가 일관성 있게 최신 데이터 복사본을 가지고 있는 것을 보장합니다.
동기식 복제(synchronous)의 문제점
- 네트워크 문제나, 기타 문제로 레플리카가 정상적으로 데이터처리 작업을 완료 하지 못한경우, 응답받지 못한 리더 데이터베이스 역시 프로세스를 진행하지못합니다.
- 리더 데이터베이스를 프로세스가 진행되지 못함에 따라, 읽기 쓰기를 차단하고, 레플리카의 정상화를 기다리기 때문에, 시스템 운영이 멈출 수 있는 위험이 있습니다.
비동기식 복제 (Asynchronous)
- 비동기식 복제는 동기식 복제와 다르게 리더가 레플리카의 처리응답을 기다리지 않습니다.
- 리더는 레플리카에 데이터 처리를 요청한 후 자진의 작업을 완료하면 사용자의 요청에 바로 응답합니다.
- 비동기식 복제의 경우 레플리카가 어떠한 이유로든 처리를 지속할 수 없더라도, 리더에게는 영향이 없어서 서비스를 지속하여 제공 할 수 있습니다.
비동기식 복제 (Asynchronous) 문제점
- 레플리카가 읽기전용으로 이용될 경우, 사용자에게 리더와 같은 응답을 주지 못하는 경우가 발생할 수 있습니다.
- 데이터의 불일치가 발생하기 때문에 불일치 상태가 길어지는 경우 큰 문제가 될 수 있습니다.
- 리더가 잘못되고 복구할 수 없는 상황이 발생 시, 복제되지 못한 모든 처리가 유실될 수 있습니다.
- 클라이언트에게는 정상 작동을 알린 상태여도, 지속성을 보장받지 못 할 수 있습니다.
반동기식 복제(semi-synchronous)
앞서 설명한 두 복제 방식의 장단점을 보완하기 위해서, 하나의 레플리카는 동기식 복제를 사용하고, 다른 레플리카들은 비동기식으로 사용하는 반동기식 복제도 활용됩니다.
대용량의 데이터 - 파티셔닝
대용량 데이터를 처리하기 위해 데이터셋을 쪼개기
데이터베이스에 들어가는 데이터셋이 너무 크거나, 쿼리 처리량이 너무 높은 경우에는 단순이 레플리싱하는 것으로는 해결되지 않을 수 있습니다.
큰데이터베이스를 파티션이라는 작은 단위로 쪼개서 활용하는 방법을 파티셔닝(샤딩)이라합니다.
파티셔닝의 목적
- 데이터 파티셔닝을 필요로 하는 주된 이유는 확장성 때문입니다.
- 데이터베이스가 확장되면서 점점 대용량의 데이터베이스가 되고, 그러한 환경에 맞게 프로세스를 처리할 필요성이 생기기 때문입니다.
- 데이터셋을 여러 디스크에 분산하의 요청에 따른 질의 부하를 여러 곳으로 분산하는 것에 그 목적이 있습니다.
- 많은 정보를 가진 데이터베이스에는 많은 정보에 대한 요청이 발생합니다. 이때 각각의 요청을 처리하기 위한 지점이 하나뿐이라면, 데이터베이스 성능에 영향을 줄 수 있습니다.
쏠림현상(skewed) 방지를 위한 시도
정리 : 파티셔닝과 레플리카는 함께 사용됩니다. 4개의 노드가 사용된다면 이론적으로는 4배의 데이터를 저장하고, 4배의 읽기 쓰기 요청을 처리 할 수 있어야합니다. 하지만 데이터를 분산시킴에도 특정 패턴을 가진 요청에 의해 한 곳으로 요청이 쏠리는 현상이 나타날수 있는데, 이는 4개의 노드중 3개의 노드가 사용되지 않는것과 비슷한 효과가 날수 있습니다. 이렇게 불균형하게 부하가 높하진 파티션을 핫스팟이라 합니다.
고른 분포를 위한 전략
- 첫번째 방법은 레코드를 할당할 노드를 무작위로 선택하는 것입니다. 이 경우 기계적으로 무작위 선택을 통해 분산효과를 얻을 수 있지만, 데이터를 읽어내야할 때는 특별한 기준으로 찾을 수 없기 때문에 성능저하를 가져올 수 있습니다.
- 두번째 방법은 키 범위를 기준으로 한 파티셔닝을 진행하는 것입니다. 이 방식은 마치 백과사전처럼 데이터에 접근하기 위한 키를 일정한 기준(키이름에 대해서 a to z를 확인하거나 또는 저장 날짜를 기준으로 키를 분류)에 따라 배치해서 파티션을 구성하는 것입니다.
a to z를 통해 키 범위를 설정할 경우, 단어 수가 많은 a는 크기 때문에 단독으로 분류하고, 후반부 xyz로 시작되는 단어들은 하나의 파티션으로 묶이는 형태를 보일 것입니다. 그러나 이러한 키 범위 기준 파티셔닝의 경우에도 특정 접근 패턴이 핫스팟을 유발하는 경우가 여전히 존재할 수 있습니다. 만약 타임스탬프를 키로 사용해서 파티션 범위를 구성했다면, 하루치 데이터를 담당하는 특정 파티션에 쏠림 현상이 발생할 수 있습니다. - 세번째 방법은 키의 해시값 기준 파티셔닝입니다. 쏠림 현상이 일어날 수 있는 데이터라도 해시함수를 통해 처리를 거쳐 균일하게 분산시킬 수 있습니다. 이 경우에 핫스팟 발생을 막을 수 있지만, 역시 범위 쿼리 효율성이 높은 키 범위 파티셔닝의 장점을 잃어버린다는 단점이 있습니다.
- 결과적으로 파티셔닝을 진행할 때는 각 서비스의 목적에 따라 검색 효율성을 높이는 것이 좋을지, 핫스팟 발생을 방지하는 것이 좋을지, 균형을 유지할 수 있는 적절한 방법을 구현해야 합니다.
동일 데이터의 잦은 조회 - 캐싱
특정 데이터에 대한 반복된 요청을 효과적으로 처리하기 위한 시도
캐시(Cache)는 임시로 복제된 데이터를 저장하는 장소로 사용자가 더 효율적이고 빠르게 원하는 데이터에 접근할 수 있도록 하기위해 설정됩니다. 캐싱을 이용하면, 원본 데이터베이스가 제공할 수 있는 것보다 짧은 대기 시간을 제공하면서 웹 애플리케이션의 성능을 향상시킬 수 있으며, 데이터베이스의 비용을 절감할 수 있습니다.
캐시 사용의 장점
- 성능향상
- 캐시는 데이터베이스와 다르게 임시로 데이터가 저장되는 장소(인 메모리 캐시)이기 때문에, 반복되는 데이터를 빠르게 제공할 수 있습니다.
- 비용감소
- 캐시를 사용하게 됨으로, 원본 데이터베이스에 대한 쿼리 수를 줄이고, 데이터베이스 자체를 스케일링 할 필요성을 낮추면, 성능향상과 비용 절감하는 효과를 낼 수 있습니다.
캐시 타입
Cache-aside
애플리케이션은 우선적으로 캐시에서 원하는 데이터를 검색하고, 캐시에 존재하지 않는다면 데이터베이스에게 요청합니다. 데이터 베이스에서 직접 데이터를 확보했다면, 해당데이터를 캐시에 복사합니다.
Read-through/Write-through Cache
Read-through/Write-through 캐시 모두 데이터베이스와 일렬로 배치되며, 애플리케이션은 뒤에 있는 데이터베이스가 아닌 캐시를 주 데이터 저장소처럼 취급합니다.
Read-through를 통해서 애플리케이션이 데이터를 읽으려 한다면, 최초 데이터를 로드할 때만 캐시가 데이터베이스에 접근합니다. 이후 동일 데이터는 캐시에서 처리됩니다. Cache-Aside 방식과 달리 애플리케이션이 캐시에 기록하지 않기 때문에, 애플리케이션 자체의 부담을 줄일 수 있습니다. 읽기처리가 많은 워크로드에 적합한 캐시 방법입니다.
Write-through를 통해서 에플리케이션에서 쓰기 요청이 발생한다면, 우선적으로 캐시에 데이터를 추가한 뒤 데이터베이스에도 데이터를 추가하게 됩니다. 이로 인해서 항상 최신 상태를 유지하면서 데이터 일관성을 보장 받을 수 있습니다.
결과적으로 Read-through/Write-through를 함께 사용하면 데이터의 일관성을 보장하면서, 애플리케이션의 코드를 단순화 하고 원본 데이터베이스에 전달되는 요청을 최소화 할 수 있습니다.
Write-behind/write-back Cache
Write-behind(back) 방식을 사용하면, 애플리케이션은 일단 캐시에 데이터를 저장합니다. 그 후 캐시가 백그라운드에서 비동기적인 방식으로 데이터베이스에 데이터를 기록합니다. 이러한 방식은 쓰기처리가 많은 워크로드에 적합한 캐시 방법입니다. 애플리케이션은 데이터베이스에 쓰기가 완료되는 것을 기다릴 필요없이 다음 작업을 진행할 수 있으므로 사용자에게 좀 더 쾌적한 사용환경을 제공할 수 있습니다.
배치 작업에 따른 성능 저하 - 스트림 처리
데이터 배치작업(데이터 일괄처리작업)
일괄 작업은 최소한의 인간 상호 작용으로 실행 할 수 있으며, 자주 사용되는 프로그램을 위한 것입니다
배치의 특징
대량의 데이터 처리
특정 시간에 프로그램 실행
일괄적으로 처리
배치 작업의 단점
예약된 일이 순차적으로 실행되기 때문에 앞선 프로그램의 실행이 다 끝나야지만 뒤에 등록된 데이터가 실행이 됩니다. 즉 앞단에 실행시간이 많이 필요한 응용 프로그램이 실행될 경우 컴퓨터 응답시간이 오래 걸릴 수가 있습니다. 그리고 CPU가 필요없는 시간대에도 응용 프로그램이 CPU를 점유하고 있을 수 있기 때문에 총 실행 시간도 오래 걸릴 수 있습니다. 컴퓨터 프로세스에서 시간이 오래 걸린 다는 뜻은 곧 성능 저하를 의미합니다.
DB를 효율적으로 처리하는 방법
지체를 줄이기 위해서는 좀 더 자주 처리를 실행해야 합니다. 시간을 초단위, 밀리초 단위로 해서 데이터를 처리하거나, 또는 고정된 시간이 아닌 단순히 이벤트가 발생할 때마다 처리를 해야 합니다.
데이터 배치 처리 vs 데이터 스트림 처리
데이터 스트림
데이터 스트림 처리
일괄 처리 작업과 다르게 데이터가 생성되는 즉시 연속 스트림을 처리하는 것을 의미합니다. 데이터크기를 알 수 없고, 연속적일 때 사용 됩니다.
데이터 스트림 특징
- 시간에 민감함
테이터 스트림의 각 요서는 타임 스탬프를 전달합니다. 데이터 스트림은 시간에 민감하며 특정 시간이 지나면 중요성을 잃게 됩니다. 예를 들어, 의심스러운 움직임을 나타내는 홈 보안 시스템의 데이터는 관련성을 유지하기 위해 짧은 시간 내에 분석 및 처리되어야 합니다. - 연속성
스트리밍 데이터에는 시작도 끝도 없습니다. 데이터 스트림은 연속적이고 실시간으로 발생하지만 시스템 요구 사항에 따라 항상 그 순간에 실행되는 것은 아닙니다. - 다양성
스트림 데이터는 지리적으로 멀리 떨어져 있을 수 있는 수천 개의 서로 다른 소스에서 오는 경우가 많습니다. 소스의 불일치로 인해 스트림 데이터에는 다양한 형식이 혼합되어 있을 수 있습니다. - 불완전성
소스의 다양성과 데이터 전송 메커니즘의 차이로 인해 데이터 스트림에 데이터 요소가 누락되거나 손상될 수 있습니다. 또한 스트림의 데이터 요소가 순서대로 도착하지 않을 수 있습니다. - 휘발성
데이터 스트리밍이 실시간으로 이루어지기 때문에 스트림을 반복적으로 전송하는 것은 상당히 어렵습니다. 재전송에 대한 조항이 있지만 새 데이터는 마지막 데이터와 동일하지 않을 수 있습니다. 이로부터 데이터 스트림은 휘발성이 높습니다. 그러나 많은 최신 시스템은 데이터 스트림의 기록을 유지하므로 현재 액세스할 수 없더라도 나중에 분석할 수 있습니다.
데이터 스트림을 처리하기 위해서는
- 짧은 대기 시간
스트림 프로세서는 연속적인 데이터 스트림에서 빠르게 작동해야 합니다. 이것은 데이터 스트림이 시간에 민감한 특성때문입니다. 모든 처리 지연은 데이터의 가치를 저하시키는 것과 직결이 됩니다. - 확장성
스트리밍 데이터의 양이 항상 같지는 않습니다. 예를 들어, 운행중인 자동차의 위치를 추적하는 시스템에서 운행 차량의 양이 많을 수도 있고 늦은 시간에는 운행하는 차량이 없을 수도 있습니다. 데이터의 양은 예측할 수 없기 때문에 프로세서는 필요한 경우 많은 양의 데이터를 처리할 수 있도록 확장되어야 합니다. - 가용성
스트림 프로세서는 긴 가동 중지 시간을 감당할 수 없습니다. 스트림 데이터는 연속적이며 실시간으로 도착합니다. 프로세서는 결함 내성이 있어야 합니다. 즉, 일부 구성 요소에 장애가 발생하더라도 계속 작동할 수 있어야 합니다. 또한 스트림 프로세서는 정보를 수집, 처리 및 즉시 상위 계층으로 전달하여 프레젠테이션을 수행할 수 있어야 합니다.
데이터 스트림 처리의 이점
- 스트리밍 데이터 처리는 새로운 동적 데이터가 지속적으로 생성되는 시나리오 대부분에서 유용
합니다
데이터 스트림 처리의 예
- 사물 인터넷: IoT에는 센서를 사용하여 데이터를 수집하고 실시간으로 데이터 프로세서에 전송하는 수많은 장치를 포함하고 있습니다. IoT 데이터는 스트림 데이터를 생성합니다. 워치와 같은 웨어러블 건강 모니터, 가정 보안 시스템, 교통 모니터링 시스템, 생체 인식 스캐너, 연결된 가전 제품, 사이버 보안 및 개인 정보 보호 시스템은 실시간으로 데이터를 생성하고 스트리밍합니다.
- 실시간 주식 시장 모니터: 실시간 금융 데이터는 종종 스트림 형식으로 전송됩니다. 금융 데이터(예: 주가 및 시장 동향)의 처리 및 분석은 조직에 중요한 결정을 빠르게 내리는 데 도움을 줍니다.
- 활동 및 트랜잭션 로그: 인터넷은 실시간 스트림 데이터의 주요 소스이기도 합니다. 사람들이 웹사이트를 방문하거나 링크를 클릭하면 웹 브라우저는 활동 로그를 생성합니다. 신용 카드 구매와 같은 온라인 금융 거래도 실시간 조치를 위해 스트리밍 및 처리할 수 있는 시간이 긴급한 데이터를 생성합니다.
- 프로세스 모니터: 모든 회사는 내부 시스템에서 수십억 개의 데이터 포인트를 생성합니다. 기업은 이 데이터를 스트리밍하고 실시간으로 처리함으로써 시스템 상태를 모니터링하고 상황이 확대되기 전에 조치를 취할 수 있습니다. 예를 들어, 제조 회사에는 종종 조립 라인의 상태를 모니터링하고 결함을 감지하여 생산 위험을 평가하는 장치가 있습니다. 이러한 장치는 또한 시간적으로 긴급한 데이터를 스트리밍하여 중지를 모니터링하고 방지할 수도 있습니다
이벤트
정리 : 이벤트란 시스템 하드웨어 또는 소프트웨어 상태가 변화다는 것을 의미합니다. 또는 중대 사건의 발생을 의미하기도 합니다. 이벤트는 시스템의 다른 부분에 이벤트가 발생했음을 알리기 위해 해당 시스템에서 보내는 메시지 또는 알림을 뜻하는 이벤트 알림과는 다릅니다.
빅 데이터 처리에서 확장성의 중요성
데이터 중복성
데이터 중복 발생의 원인
1.관리시스템 내의 소프트웨어(코딩) 품질
2.백업시스템
데이터 중복성의 이점
- 정보 보호 개선
- 데이터 백업 생성
- 데이터 엑세스 속도 향상
- 데이터 정확성 보장
- 정확한 분석
데이터 중복성의 문제점
- 불일치 증가
- 데이터 손상 가능성
- 유지 비용 증가
- 스토리지 : 무엇보다도 클라우드와 온프레미스를 불문하고 스토리지 블록을 저장하는 데는 비용이 들기 때문에 중복 데이터를 제거하는 것은 매우 중요합니다.
- 네트워크: 중복 데이터 블록을 기기에서 백업 서버와 스토리지로 불필요하게 전송하면 네트워크 경로가 여러 지점에서 포화 상태가 됩니다.
- 디바이스: 파일을 호스팅하는 디바이스든 단순히 데이터를 전달하는 디바이스든 백업 경로상의 모든 기기는 중복 데이터를 위해 프로세서 사이클과 메모리를 낭비해야 합니다.
- 시간: 기업은 애플리케이션과 데이터를 24시간 사용할 수 있어야 하므로 백업으로 인한 성능 저하는 달갑지 않은 현상입니다. 이런 이유로 IT 관리자는 백업이 시스템 성능에 미치는 영향을 최소화하도록 일반적으로 백업 작업시간을 야간에 계획합니다. 중복 데이터는 이렇게 귀중한 시간을 낭비합니다.
- 사용할 수 없는 데이터 생성
데이터의 중복을 줄이는 방법
1.마스터 데이터 활용
2.데이터베이스 정규화
3.미사용 데이터 삭제
4.데이터베이스 설계
데이터 중복처리
1. 데이터 중복 제거(Deduplication)
데이터 중복제거 유형
<저장 시점에 따른 유형 >
인라인 중복 제거(Inline deduplication)
후처리 중복 제거(Post-process deduplication)
<데이터 분류 방식에 따른 유형>
고정 블록 중복 제거(Fixed block deduplication)
가변 블록 중복 제거(Variable block deduplication)
<진행 위치에 따른 유형>
소스 기반 중복 제거(Source-based deduplication)
타깃 기반 중복 제거(Target-based deduplication)
2. 데이터 압축(Compresstion)