데이터 분할 지침

많은 대규모 솔루션에서 데이터는 별도로 관리 및 액세스할 수 있는 파티션 으로 나뉩니다. 분할을 통해 확장성을 향상시키고 경합을 줄여 성능을 최적화할 수 있습니다. 데이터를 사용 패턴에 따라 나누는 메커니즘도 제공할 수 있습니다. 예를 들어 더 오래된 데이터를 더 저렴한 데이터 스토리지에 보관할 수 있습니다.

그러나 부작용을 최소화하면서 이점을 최대화하려면 분할 전략을 신중하게 선택해야 합니다.

데이터를 분할하는 이유

• 확장성을 향상시킵니다. 단일 데이터베이스 시스템을 강화하면 결국 물리적 하드웨어 제한에 도달하게 됩니다. 각각 별도의 서버에서 호스트되는 여러 파티션 간에 데이터를 나누는 경우 시스템을 거의 무기한으로 확장할 수 있습니다.

• 성능을 향상시킵니다. 각 파티션에 대한 데이터 액세스 작업은 더 작은 양의 데이터를 통해 수행됩니다. 올바르게 수행하면 분할을 통해 시스템을 보다 효율적으로 만들 수 있습니다. 둘 이상의 파티션에 영향을 주는 작업은 병렬로 실행할 수 있습니다.

• 보안을 향상시킵니다. 경우에 따라 민감하고 민감하지 않은 데이터를 다른 파티션으로 구분하고 중요한 데이터에 다른 보안 제어를 적용할 수 있습니다.

• 운영 유연성을 제공합니다. 분할은 작업을 미세 조정하고, 관리 효율성을 극대화하고, 비용을 최소화할 수 있는 많은 기회를 제공합니다. 예를 들어 각 파티션의 데이터 중요도에 따라 관리, 모니터링, 백업 및 복원 및 기타 관리 작업에 대한 다양한 전략을 정의할 수 있습니다.

• 데이터 저장소를 사용 패턴과 일치합니다. 분할을 사용하면 데이터 저장소에서 제공하는 비용 및 기본 제공 기능에 따라 각 파티션을 다른 유형의 데이터 저장소에 배포할 수 있습니다. 예를 들어 큰 이진 데이터는 Blob Storage에 저장할 수 있지만 더 구조화된 데이터는 문서 데이터베이스에 보관할 수 있습니다. 자세한 내용은 올바른 데이터 저장소 선택을 참조하세요.

• 가용성을 향상시킵니다. 여러 서버에서 데이터를 분리하면 단일 실패 지점이 방지됩니다. 하나의 인스턴스가 실패하면 해당 파티션의 데이터만 사용할 수 없습니다. 다른 파티션에 대한 작업은 계속할 수 있습니다. PaaS(관리형 PaaS) 데이터 저장소의 경우 이러한 서비스는 기본 제공 중복성으로 설계되었기 때문에 이 고려 사항은 관련성이 낮습니다.

파티션 디자인

데이터를 분할하기 위한 세 가지 일반적인 전략이 있습니다.

• 가로 분할(분할라고도 함). 이 전략에서 각 파티션은 별도의 데이터 저장소이지만 모든 파티션에는 동일한 스키마가 있습니다. 각 파티션은 분할 된 데이터베이스라고 하며 특정 고객 집합에 대한 모든 주문과 같은 데이터의 특정 하위 집합을 보유합니다.

• 수직 분할. 이 전략에서 각 파티션은 데이터 저장소의 항목에 대한 필드의 하위 집합을 보유합니다. 필드는 사용 패턴에 따라 구분됩니다. 예를 들어 자주 액세스하는 필드는 한 세로 파티션에 배치되고 다른 세로 파티션에서는 액세스 빈도가 낮은 필드에 배치될 수 있습니다.

• 기능 분할. 이 전략에서 데이터는 시스템의 각 바인딩된 컨텍스트에서 사용되는 방식에 따라 집계됩니다. 예를 들어 전자 상거래 시스템은 청구서 데이터를 한 파티션에 저장하고 제품 인벤토리 데이터를 다른 파티션에 저장할 수 있습니다.

이러한 전략을 결합할 수 있으며 분할 체계를 디자인할 때 모두 고려하는 것이 좋습니다. 예를 들어 데이터를 분할된 데이터베이스로 나눈 다음 수직 분할을 사용하여 각 분할된 데이터베이스의 데이터를 추가로 세분화할 수 있습니다.

가로 분할(샤딩)

그림 1은 수평 분할 또는 분할을 보여 있습니다. 이 예제에서 제품 인벤토리 데이터는 제품 키에 따라 분할된 데이터베이스로 나뉩니다. 각 샤드는 알파벳 순서로 구성된 연속적인 샤드 키 범위(A-G 및 H-Z)에 대한 데이터를 보유합니다. 분할은 부하를 더 많은 컴퓨터에 분산시켜 경합을 줄이고 성능을 향상시킵니다.

그림 1 - 파티션 키를 기반으로 데이터를 수평 분할(분할)합니다.

가장 중요한 요소는 분할 키 선택입니다. 시스템이 작동한 후 키를 변경하기 어려울 수 있습니다. 키는 작업 부하를 가능한 한 균등하게 분산하도록 데이터를 샤드에 맞게 분할해야 합니다.

조각들의 크기가 같을 필요는 없습니다. 요청 수의 균형을 맞추는 것이 더 중요합니다. 일부 분할된 데이터베이스는 매우 클 수 있지만 각 항목에는 적은 수의 액세스 작업이 있습니다. 다른 분할된 데이터베이스는 더 작을 수 있지만 각 항목은 훨씬 더 자주 액세스됩니다. 또한 단일 분할된 데이터베이스가 데이터 저장소의 크기 제한(용량 및 처리 리소스 측면에서)을 초과하지 않도록 하는 것도 중요합니다.

성능 및 가용성에 영향을 줄 수 있는 "핫" 파티션을 만들지 않습니다. 예를 들어 고객 이름의 첫 글자를 사용하면 일부 문자가 더 일반적이기 때문에 불균형 배포가 발생합니다. 대신 고객 식별자의 해시를 사용하여 파티션 간에 데이터를 더 균등하게 분산합니다.

큰 분할된 데이터베이스를 분할하거나, 작은 분할된 데이터베이스를 더 큰 파티션으로 병합하거나, 스키마를 변경하기 위한 향후 요구 사항을 최소화하는 분할 키를 선택합니다. 이러한 작업은 매우 시간이 오래 걸릴 수 있으며 수행되는 동안 하나 이상의 분할된 데이터베이스를 오프라인으로 전환해야 할 수 있습니다.

분할된 데이터베이스가 복제된 경우 일부 복제본은 온라인 상태로 유지하고 다른 복제본은 분할, 병합 또는 다시 구성할 수 있습니다. 그러나 시스템은 재구성 중에 수행할 수 있는 작업을 제한해야 할 수 있습니다. 예를 들어 복제본의 데이터는 데이터 불일치를 방지하기 위해 읽기 전용으로 표시될 수 있습니다.

수평 분할에 대한 자세한 내용은 분할 패턴을 참조하세요.

수직 분할

수직 분할의 가장 일반적인 용도는 자주 액세스하는 항목을 페치하는 것과 관련된 I/O 및 성능 비용을 줄이는 것입니다. 그림 2는 수직 분할의 예를 보여줍니다. 이 예제에서는 항목의 여러 속성이 다른 파티션에 저장됩니다. 하나의 파티션은 제품 이름, 설명 및 가격을 포함하여 더 자주 액세스되는 데이터를 보유합니다. 또 다른 파티션은 재고 데이터(재고 수 및 마지막 주문 날짜)를 보유합니다.

그림 2 - 사용 패턴에 따라 데이터를 세로로 분할합니다.

이 예제에서 애플리케이션은 고객에게 제품 세부 정보를 표시할 때 제품 이름, 설명 및 가격을 정기적으로 쿼리합니다. 이러한 두 항목은 일반적으로 함께 사용되므로 재고 수와 마지막 주문 날짜는 별도의 파티션에 보관됩니다.

수직 분할의 다른 이점:

• 상대적으로 느리게 이동하는 데이터(제품 이름, 설명 및 가격)는 보다 동적 데이터(재고 수준 및 마지막 주문 날짜)와 구분할 수 있습니다. 느린 이동 데이터는 애플리케이션이 메모리에 캐시할 수 있는 좋은 후보입니다.

• 중요한 데이터는 추가 보안 컨트롤을 사용하여 별도의 파티션에 저장할 수 있습니다.

• 수직 분할은 필요한 동시 액세스의 양을 줄일 수 있습니다.

수직 분할은 데이터 저장소 내의 엔터티 수준에서 작동하며, 엔터티를 부분적으로 정규화하여 넓은 항목에서 좁은 항목 집합으로 분해합니다. HBase 및 Cassandra와 같은 열 지향 데이터 저장소에 이상적으로 적합합니다. 열 컬렉션의 데이터가 변경되지 않을 경우 SQL Server에서 열 저장소를 사용하는 것도 고려할 수 있습니다.

기능 분할

애플리케이션에서 각 고유 비즈니스 영역에 대해 제한된 컨텍스트를 식별할 수 있는 경우 기능 분할은 격리 및 데이터 액세스 성능을 향상시키는 방법입니다. 기능 분할의 또 다른 일반적인 용도는 읽기-쓰기 데이터를 읽기 전용 데이터와 분리하는 것입니다. 그림 3에서는 인벤토리 데이터가 고객 데이터와 구분되는 기능 분할에 대한 개요를 보여줍니다.

그림 3 - 제한된 컨텍스트 또는 하위 도메인을 사용하여 데이터를 기능적으로 분할합니다.

이 분할 전략은 시스템의 여러 부분에서 데이터 액세스 경합을 줄이는 데 도움이 될 수 있습니다.

확장성을 위해 파티션 디자인

최대 확장성을 달성하기 위해 데이터가 분산되도록 각 파티션의 크기 및 워크로드를 고려하고 균형을 맞추는 것이 중요합니다. 그러나 단일 파티션 저장소의 크기 조정 제한을 초과하지 않도록 데이터를 분할해야 합니다.

확장성을 위해 파티션을 디자인할 때 다음 단계를 수행합니다.

1. 애플리케이션을 분석하여 각 쿼리에서 반환된 결과 집합의 크기, 액세스 빈도, 내재된 대기 시간 및 서버 쪽 컴퓨팅 처리 요구 사항과 같은 데이터 액세스 패턴을 이해합니다. 대부분의 경우 일부 주요 엔터티는 대부분의 처리 리소스를 요구합니다.
2. 이 분석을 사용하여 데이터 크기 및 워크로드와 같은 현재 및 미래의 확장성 목표를 확인합니다. 그런 다음 확장성 목표를 충족하기 위해 파티션에 데이터를 분산합니다. 수평 분할의 경우 올바른 분할 키를 선택하는 것이 배포가 짝수인지 확인하는 것이 중요합니다. 자세한 내용은 분할 패턴을 참조하세요.
3. 각 파티션에 데이터 크기 및 처리량 측면에서 확장성 요구 사항을 처리할 수 있는 충분한 리소스가 있는지 확인합니다. 데이터 저장소에 따라 파티션당 스토리지 공간, 처리 능력 또는 네트워크 대역폭의 양이 제한될 수 있습니다. 요구 사항이 이러한 제한을 초과할 가능성이 있는 경우 분할 전략을 구체화하거나 데이터를 추가로 분할하여 둘 이상의 전략을 결합해야 할 수 있습니다.
4. 시스템을 모니터링하여 데이터가 예상대로 분산되고 파티션이 부하를 처리할 수 있는지 확인합니다. 실제 사용량이 분석에서 예측하는 것과 항상 일치하지는 않습니다. 그렇다면 파티션의 균형을 다시 조정하거나 시스템의 일부 부분을 다시 디자인하여 필요한 균형을 얻을 수 있습니다.

일부 클라우드 환경에서는 인프라 경계 측면에서 리소스를 할당합니다. 선택한 경계의 한도가 데이터 스토리지, 처리 능력 및 대역폭 측면에서 예상되는 데이터 볼륨 증가를 위한 충분한 공간을 제공하는지 확인합니다.

예를 들어 Azure Table Storage를 사용하는 경우 특정 기간 동안 단일 파티션에서 처리할 수 있는 요청 볼륨에 제한이 있습니다. (자세한 내용은 Azure Storage 확장성 및 성능 목표를 참조하세요.) 사용 중인 분할된 데이터베이스에는 단일 파티션에서 처리할 수 있는 것보다 더 많은 리소스가 필요할 수 있습니다. 그렇다면 부하를 분산하기 위해 분할된 데이터베이스를 다시 분할해야 할 수 있습니다. 이러한 테이블의 총 크기 또는 처리량이 스토리지 계정의 용량을 초과하는 경우 추가 스토리지 계정을 만들고 이러한 계정에 테이블을 분산해야 할 수 있습니다.

쿼리 성능을 위한 파티션 디자인

더 작은 데이터 집합을 사용하고 병렬 쿼리를 실행하여 쿼리 성능을 높일 수 있는 경우가 많습니다. 각 파티션은 전체 데이터 집합의 작은 비율을 포함해야 합니다. 볼륨이 감소하면 쿼리 성능이 향상될 수 있습니다. 그러나 분할은 데이터베이스를 적절하게 디자인하고 구성하는 대안이 아닙니다. 예를 들어 필요한 인덱스가 있는지 확인합니다.

쿼리 성능을 위해 파티션을 디자인할 때 다음 단계를 수행합니다.

1. 애플리케이션 요구 사항 및 성능을 검사합니다.

   • 비즈니스 요구 사항을 사용하여 항상 신속하게 수행해야 하는 중요한 쿼리를 결정합니다.
   • 시스템을 모니터링하여 느리게 수행되는 쿼리를 식별합니다.
   • 가장 자주 수행되는 쿼리를 찾습니다. 단일 쿼리에 최소 비용이 있더라도 누적 리소스 사용량이 클 수 있습니다.

2. 성능 저하를 일으키는 데이터를 분할합니다.

   • 쿼리 응답 시간이 대상 내에 있도록 각 파티션의 크기를 제한합니다.
   • 수평 분할을 사용하는 경우 애플리케이션이 올바른 파티션을 쉽게 선택할 수 있도록 분할 키를 디자인합니다. 이렇게 하면 쿼리가 모든 파티션을 검색할 필요가 없습니다.
   • 파티션의 위치를 고려합니다. 가능하면 데이터에 액세스하는 애플리케이션 및 사용자와 지리적으로 가까운 파티션에 데이터를 유지합니다.

3. 엔터티에 처리량 및 쿼리 성능 요구 사항이 있는 경우 해당 엔터티에 따라 기능 분할을 사용합니다. 그래도 요구 사항을 충족하지 않는 경우 수평 분할도 적용합니다. 대부분의 경우 단일 분할 전략으로 충분하지만 경우에 따라 두 전략을 결합하는 것이 더 효율적입니다.

4. 성능을 향상시키려면 파티션 간에 쿼리를 병렬로 실행하는 것이 좋습니다.

가용성을 위한 파티션 디자인

데이터를 분할하면 전체 데이터 세트가 단일 실패 지점을 구성하지 않고 데이터 세트의 개별 하위 집합을 독립적으로 관리할 수 있도록 하여 애플리케이션의 가용성을 향상시킬 수 있습니다.

가용성에 영향을 주는 다음 요소를 고려합니다.

데이터가 비즈니스 운영에 얼마나 중요한지. 트랜잭션과 같은 중요한 비즈니스 정보 및 로그 파일과 같이 덜 중요한 운영 데이터인 데이터를 식별합니다.

• 적절한 백업 계획을 사용하여 고가용성 파티션에 중요한 데이터를 저장하는 것이 좋습니다.

• 다양한 데이터 세트에 대한 별도의 관리 및 모니터링 절차를 설정합니다.

• 동일한 수준의 중요도를 가지는 데이터를 동일한 파티션에 배치하여 적절한 빈도로 함께 백업할 수 있도록 합니다. 예를 들어 트랜잭션 데이터를 보유하는 파티션은 로깅 또는 추적 정보를 보유하는 파티션보다 더 자주 백업해야 할 수 있습니다.

개별 파티션을 관리하는 방법. 독립적인 관리 및 유지 관리를 지원하도록 파티션을 디자인하면 몇 가지 이점이 있습니다. 다음은 그 예입니다.

• 파티션이 실패하면 다른 파티션의 데이터에 액세스하는 애플리케이션 없이 독립적으로 복구할 수 있습니다.

• 지리적 영역별로 데이터를 분할하면 각 위치에 대해 사용량이 많은 시간에 예약된 유지 관리 작업을 수행할 수 있습니다. 파티션이 너무 커서 이 기간 동안 계획된 유지 관리가 완료되지 않도록 합니다.

파티션 간에 중요한 데이터를 복제할지 여부입니다. 이 전략은 가용성 및 성능을 향상시킬 수 있지만 일관성 문제를 발생시킬 수도 있습니다. 변경 내용을 모든 복제본과 동기화하는 데 시간이 걸립니다. 이 기간 동안 다른 파티션에는 다른 데이터 값이 포함됩니다.

애플리케이션 디자인 고려 사항

분할은 시스템의 디자인 및 개발에 복잡성을 더합니다. 처음에 시스템에 단일 파티션만 포함되더라도 분할을 시스템 디자인의 기본 부분으로 고려합니다. 분할을 사후 고려 사항으로 처리하면 유지 관리할 라이브 시스템이 이미 있으므로 더 어려울 수 있습니다.

• 데이터 액세스 논리를 수정해야 합니다.
• 파티션 간에 분산하려면 대량의 기존 데이터를 마이그레이션해야 할 수 있습니다.
• 사용자는 마이그레이션 중에 시스템을 계속 사용할 수 있을 것으로 예상합니다.

초기 데이터 세트가 작고 단일 서버에서 쉽게 처리할 수 있기 때문에 분할이 중요하지 않은 경우도 있습니다. 이는 일부 워크로드에 해당할 수 있지만 사용자 수가 증가함에 따라 많은 상용 시스템을 확장해야 합니다.

또한 분할의 이점을 활용하는 것은 큰 데이터 저장소일 뿐만 아니라 예를 들어 수백 개의 동시 클라이언트에서 작은 데이터 저장소에 크게 액세스할 수 있습니다. 이 상황에서 데이터를 분할하면 경합을 줄이고 처리량을 개선하는 데 도움이 될 수 있습니다.

데이터 분할 체계를 디자인할 때 다음 사항을 고려합니다.

파티션 간 데이터 액세스 작업을 최소화합니다. 가능한 경우 가장 일반적인 데이터베이스 작업에 대한 데이터를 각 파티션에 함께 보관하여 파티션 간 데이터 액세스 작업을 최소화합니다. 파티션 간 쿼리는 단일 파티션 내에서 쿼리하는 것보다 시간이 더 오래 걸릴 수 있지만 한 쿼리 집합에 대해 파티션을 최적화하면 다른 쿼리 집합에 부정적인 영향을 줄 수 있습니다. 파티션 간에 쿼리해야 하는 경우 병렬 쿼리를 실행하고 애플리케이션 내에서 결과를 집계하여 쿼리 시간을 최소화합니다. (이 방법은 한 쿼리의 결과가 다음 쿼리에서 사용되는 경우와 같은 경우에 불가능할 수 있습니다.)

정적 참조 데이터를 복제하는 것이 좋습니다. 쿼리에서 우편 번호 테이블 또는 제품 목록과 같은 비교적 정적 참조 데이터를 사용하는 경우 모든 파티션에서 이 데이터를 복제하여 다른 파티션에서 별도의 조회 작업을 줄이는 것이 좋습니다. 또한 이 방법을 사용하면 참조 데이터가 전체 시스템에서 트래픽이 많은 "핫" 데이터 세트가 될 가능성을 줄일 수 있습니다. 그러나 참조 데이터에 대한 변경 내용을 동기화하는 데 추가 비용이 발생합니다.

파티션 간 조인을 최소화합니다. 가능한 경우 수직 및 기능 파티션에서 참조 무결성에 대한 요구 사항을 최소화합니다. 이러한 체계에서 애플리케이션은 파티션 간에 참조 무결성을 유지 관리합니다. 애플리케이션은 일반적으로 키 및 외래 키를 기반으로 연속 쿼리를 수행해야 하므로 여러 파티션에서 데이터를 조인하는 쿼리는 비효율적입니다. 대신 관련 데이터를 복제하거나 정규화 해제하는 것이 좋습니다. 파티션 간 조인이 필요한 경우 파티션을 통해 병렬 쿼리를 실행하고 애플리케이션 내에서 데이터를 조인합니다.

최종 일관성을 수용합니다. 강력한 일관성이 실제로 요구 사항인지 여부를 평가합니다. 분산 시스템의 일반적인 접근 방식은 최종 일관성을 구현하는 것입니다. 각 파티션의 데이터는 별도로 업데이트되고 애플리케이션 논리는 업데이트가 모두 성공적으로 완료되도록 합니다. 또한 최종적으로 일관된 작업이 실행되는 동안 데이터 쿼리에서 발생할 수 있는 불일치를 처리합니다.

쿼리가 올바른 파티션을 찾는 방법을 고려합니다. 쿼리가 필요한 데이터를 찾기 위해 모든 파티션을 검색해야 하는 경우 여러 병렬 쿼리가 실행되는 경우에도 성능에 큰 영향을 미칩니다. 수직 및 기능 분할을 사용하면 쿼리에서 파티션을 자연스럽게 지정할 수 있습니다. 반면에 수평 분할은 모든 분할된 데이터베이스에 동일한 스키마가 있기 때문에 항목 찾기를 어렵게 만들 수 있습니다. 특정 항목에 대한 분할된 데이터베이스 위치를 조회하는 데 사용되는 맵을 유지 관리하는 일반적인 솔루션입니다. 이 맵은 애플리케이션의 분할 논리에서 구현되거나 투명한 분할을 지원하는 경우 데이터 저장소에서 유지 관리할 수 있습니다.

정기적으로 분할된 데이터베이스의 균형을 다시 조정하는 것이 좋습니다. 수평 분할을 사용하면 분할된 데이터베이스의 크기를 조정하고 워크로드별로 데이터를 균등하게 분산하여 핫스팟을 최소화하고 쿼리 성능을 최대화하며 물리적 스토리지 제한을 해결할 수 있습니다. 그러나 사용자 지정 도구 또는 프로세스를 사용해야 하는 복잡한 작업입니다.

파티션을 복제합니다. 각 파티션을 복제하는 경우 오류에 대한 추가 보호를 제공합니다. 단일 복제본이 실패하면 쿼리를 작업 복사본으로 보낼 수 있습니다.

분할 전략의 물리적 제한에 도달하는 경우 확장성을 다른 수준으로 확장해야 할 수 있습니다. 예를 들어 분할이 데이터베이스 수준에 있는 경우 여러 데이터베이스에서 파티션을 찾거나 복제해야 할 수 있습니다. 분할이 이미 데이터베이스 수준에 있고 물리적 제한 사항이 문제인 경우 여러 호스팅 계정에서 파티션을 찾거나 복제해야 한다는 의미일 수 있습니다.

여러 파티션의 데이터에 액세스하는 트랜잭션을 방지합니다. 일부 데이터 저장소는 데이터가 단일 파티션에 있는 경우에만 데이터를 수정하는 작업에 대한 트랜잭션 일관성 및 무결성을 구현합니다. 여러 파티션에서 트랜잭션 지원이 필요한 경우 대부분의 분할 시스템이 네이티브 지원을 제공하지 않기 때문에 애플리케이션 논리의 일부로 이를 구현해야 할 수 있습니다.

모든 데이터 저장소에는 일부 운영 관리 및 모니터링 작업이 필요합니다. 태스크는 데이터 로드, 데이터 백업 및 복원, 데이터 재구성, 시스템이 정확하고 효율적으로 수행되도록 하는 것까지 다양할 수 있습니다.

운영 관리에 영향을 주는 다음 요소를 고려합니다.

• 데이터가 분할될 때 적절한 관리 및 운영 작업을 구현하는 방법입니다. 이러한 작업에는 백업 및 복원, 데이터 보관, 시스템 모니터링 및 기타 관리 작업이 포함될 수 있습니다. 예를 들어 백업 및 복원 작업 중에 논리적 일관성을 유지하는 것은 어려울 수 있습니다.

• 데이터를 여러 파티션에 로드하고 다른 원본에서 도착하는 새 데이터를 추가하는 방법입니다. 일부 도구 및 유틸리티는 데이터를 올바른 파티션으로 로드하는 것과 같이 분할된 데이터 작업을 지원하지 않을 수 있습니다.

• 정기적으로 데이터를 보관하고 삭제하는 방법입니다. 파티션이 과도하게 증가하지 않도록 하려면 정기적으로(예: 매월) 데이터를 보관하고 삭제해야 합니다. 다른 보관 스키마와 일치하도록 데이터를 변환해야 할 수도 있습니다.

• 데이터 무결성 문제를 찾는 방법입니다. 한 파티션의 데이터와 같이 다른 파티션의 누락된 정보를 참조하는 데이터와 같은 데이터 무결성 문제를 찾으려면 주기적인 프로세스를 실행하는 것이 좋습니다. 이 프로세스는 이러한 문제를 자동으로 해결하거나 수동 검토를 위해 보고서를 생성할 수 있습니다.

파티션 리밸런싱

시스템이 완성되면 분할 체계를 조정해야 할 수 있습니다. 예를 들어 개별 파티션은 트래픽의 불균형 볼륨을 가져오기 시작하고 뜨거워서 과도한 경합이 발생할 수 있습니다. 또는 일부 파티션의 데이터 볼륨을 과소평가하여 일부 파티션이 용량 제한에 근접했을 수 있습니다.

Azure Cosmos DB와 같은 일부 데이터 저장소는 파티션의 균형을 자동으로 조정할 수 있습니다. 다른 경우에는 리밸런싱이 다음 두 단계로 구성된 관리 작업입니다.

1. 새 분할 전략을 결정합니다.

   • 분할해야 하는 파티션(또는 결합 가능)은 무엇입니까?
   • 새 파티션 키란?

2. 이전 분할 체계에서 새 파티션 집합으로 데이터를 마이그레이션합니다.

데이터 저장소에 따라 파티션을 사용하는 동안 파티션 간에 데이터를 마이그레이션할 수 있습니다. 이를 온라인 마이그레이션이라고 합니다. 가능하지 않은 경우 데이터를 재배치하는 동안(오프라인 마이그레이션) 파티션을 사용할 수 없도록 해야 할 수 있습니다.

오프라인 마이그레이션

일반적으로 오프라인 마이그레이션은 경합이 발생할 가능성을 줄이기 때문에 더 간단합니다. 개념적으로 오프라인 마이그레이션은 다음과 같이 작동합니다.

1. 파티션을 오프라인으로 표시합니다.
2. 데이터를 분할-병합하고 새 파티션으로 이동합니다.
3. 데이터를 확인합니다.
4. 새 파티션을 온라인으로 가져옵니다.
5. 이전 파티션을 제거합니다.

필요에 따라 1단계에서 파티션을 읽기 전용으로 표시하여 애플리케이션이 이동하는 동안에도 데이터를 읽을 수 있도록 할 수 있습니다.

온라인 마이그레이션

온라인 마이그레이션은 수행하기가 더 복잡하지만 중단이 적습니다. 원래 파티션이 오프라인으로 표시되지 않는다는 점을 제외하면 프로세스는 오프라인 마이그레이션과 유사합니다. 마이그레이션 프로세스의 세분성(예: 항목별 항목 및 분할된 데이터베이스별 분할)에 따라 클라이언트 애플리케이션의 데이터 액세스 코드는 원래 파티션과 새 파티션의 두 위치에 보관된 데이터를 읽고 쓰는 작업을 처리해야 할 수 있습니다.

다음 단계

• 특정 Azure 서비스에 대한 분할 전략에 대해 알아봅니다. 자세한 내용은 데이터 분할 전략을 참조하세요.
• Azure Storage 확장성 및 성능 목표

관련 리소스

• 올바른 데이터 저장소 선택

다음 디자인 패턴은 시나리오와 관련이 있을 수 있습니다.

• 분할 패턴은 데이터를 분할하기 위한 몇 가지 일반적인 전략을 설명합니다.

• 인덱스 테이블 패턴은 데이터에 대한 보조 인덱스를 만드는 방법을 보여 줍니다. 애플리케이션은 컬렉션의 기본 키를 참조하지 않는 쿼리를 사용하여 이 방법으로 데이터를 신속하게 검색할 수 있습니다.

• 구체화된 뷰 패턴은 빠른 쿼리 작업을 지원하기 위해 데이터를 요약하는 미리 채워진 뷰를 생성하는 방법을 설명합니다. 이 방법은 요약되는 데이터가 포함된 파티션이 여러 사이트에 분산된 경우 분할된 데이터 저장소에서 유용할 수 있습니다.