데이터 분할 지침

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

하지만 부정적인 영향을 최소화하고 이점을 극대화할 수 있도록 분할 전략을 신중하게 선택해야 합니다.

데이터를 분할하는 이유

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

• 성능 향상. 각 파티션에 대한 데이터 액세스 작업은 더 작은 볼륨의 데이터에 대해 발생합니다. 분할을 올바르게 수행하면 시스템 효율성을 높일 수 있습니다. 둘 이상의 파티션에 영향을 주는 작업은 병렬로 실행할 수 있습니다.

• 보안 기능 향상. 경우에 따라 중요한 데이터와 중요하지 않은 데이터를 서로 다른 파티션에 분리하고 중요한 데이터에 다른 보안 컨트롤을 적용할 수 있습니다.

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

• 사용 패턴에 맞게 데이터 저장소 조정. 분할은 데이터 저장소에서 제공하는 기본 제공 기능 및 비용에 따라 각 파티션을 다양한 유형의 데이터 저장소에 배포할 수 있습니다. 예를 들어 대용량 이진 데이터는 Blob 스토리지에 저장할 수 있으며, 좀 더 구조화된 데이터는 문서 데이터베이스에 보관할 수 있습니다. 자세한 내용은 올바른 데이터 저장소 선택을 참조하세요.

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

파티션 디자인

데이터를 분할하는 세 가지 일반 전략이 있습니다.

• 행 분할(일반적으로 분할이라고 함). 이 전략에서는 각 파티션이 별도의 데이터 저장소이지만, 모든 파티션의 스키마가 동일합니다. 각 파티션을 분할된 데이터베이스라고 하며, 특정 고객 집합의 주문 같은 구체적인 데이터 하위 집합을 보관합니다.

• 수직 분할. 이 전략에서는 각 파티션에 데이터 저장소의 항목 필드 하위 집합이 보관됩니다. 필드는 해당 사용 패턴에 따라 구분됩니다. 예를 들어 자주 액세스되는 필드가 하나의 수직 분할에 배치되고 덜 자주 액세스되는 필드가 또 다른 수직 분할에 배치됩니다.

• 기능 분할. 이 전략에서는 시스템의 제한된 컨텍스트별로 데이터가 사용되는 방법에 따라 데이터를 집계합니다. 예를 들어 전자상거래 시스템에서 청구서 데이터와 제품 재고 데이터를 서로 다른 파티션에 저장할 수 있습니다.

이러한 전략을 결합하여 사용할 수 있으며, 파티션 구성표를 디자인할 때 모든 전략을 고려하는 것이 좋습니다. 예를 들어, 데이터를 분할된 데이터베이스에 나눈 후 각각의 분할된 데이터베이스에서 수직 분할을 사용하여 데이터를 더 세분화할 수 있습니다.

행 분할(분할)

그림 1은 행 분할 또는 분할을 보여줍니다. 이 예에서는 제품 재고 데이터가 제품 키에 따라 분할된 데이터베이스로 나뉩니다. 각각의 분할된 데이터베이스에는 연속된 분할 키 범위(A-G 및 H-Z)별로 데이터가 사전순으로 정렬되어 있습니다. 분할을 사용하면 더 많은 컴퓨터에 부하를 분산하여 경합을 줄이고 성능을 향상시킬 수 있습니다.

그림 1 - 파티션 키에 따라 데이터를 수평으로 분할

가장 중요한 요소에는 분할 키의 선택입니다. 시스템이 작동된 후에는 키를 변경하기 어려울 수 있습니다. 키는 분할된 데이터베이스에 워크로드가 최대한 균등하게 분산되도록 데이터를 분할해야 합니다.

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

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

대용량의 분할된 데이터베이스를 분할하거나, 작은 분할된 데이터베이스를 대규모 파티션으로 병합하거나, 스키마를 변경해야 하는 등의 향후 요구 사항을 최소화하는 분할 키를 선택합니다. 이러한 작업에는 시간이 많이 소요될 수 있으며 작업이 수행되는 동안 하나 이상의 분할된 데이터베이스를 오프라인 상태로 설정해야 할 수 있습니다.

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

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

수직 분할

수직 분할은 자주 액세스하는 항목을 가져오는 것과 연관된 I/O 및 성능 저하를 줄이기 위해 가장 많이 사용됩니다. 그림 2에서 수직 분할의 예제를 보여 줍니다. 이 예제에서는 한 항목의 여러 속성이 서로 다른 파티션에 저장됩니다. 한 파티션은 제품의 이름, 설명 및 가격을 포함하여 더 자주 액세스되는 데이터를 보관합니다. 다른 파티션은 재고 수, 마지막 주문 날짜 등의 인벤토리 데이터를 보관합니다.

그림 2 - 사용 패턴에 따라 데이터를 수직으로 분할

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

그 외에도 수직 분할은 다음과 같은 장점이 있습니다.

• 비교적 이동 속도가 느린 데이터(제품 이름, 설명 및 가격)와 동적 데이터(재고 수준 및 마지막 주문 날짜)를 분리할 수 있습니다. 이동 속도가 느린 데이터는 메모리에 캐시할 애플리케이션에 사용하기 좋습니다.

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

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

수직 분할은 데이터 저장소에서 엔터티 수준으로 수행되며, 특히 엔터티를 부분적으로 정규화하여 범위가 넓은 항목을 범위가 좁은 항목 집합으로 분할합니다. HBase 및 Cassandra와 같은 열 기반 데이터 저장소에 가장 적합합니다. 열 컬렉션의 데이터가 변경될 가능성이 없는 경우 SQL Server의 열 저장소를 사용할 수도 있습니다.

기능 분할

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

그림 3 - 제한된 컨텍스트 또는 하위 도메인별로 데이터를 기능적으로 분할

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

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

데이터가 분산되어 최대 확장성을 달성하도록 각 파티션의 크기 및 워크로드를 고려하여 부하를 분산해야 합니다. 그러나 데이터 분할도 수행하여 단일 파티션 저장소의 확장 한도를 초과하지 않도록 해야 합니다.

확장성을 위해 파티션을 디자인하는 경우 다음 단계를 따르세요.

1. 애플리케이션을 분석하여 데이터 액세스 패턴(예: 각 쿼리에서 반환된 결과 집합의 크기, 액세스 빈도, 고유 대기 시간, 서버 쪽 컴퓨팅 처리 요구 사항)을 이해합니다. 대부분의 경우 소수의 주요 엔터티에서 대부분의 처리 리소스를 요청합니다.
2. 이 분석을 사용하여 현재 및 미래의 확장성 목표(예: 데이터 크기 및 워크로드)를 결정합니다. 그런 다음 확장성 목표에 맞도록 데이터를 파티션에 분산합니다. 행 분할의 경우 데이터를 고르게 분산할 수 있도록 적절한 분할 키를 선택하는 것이 중요합니다. 자세한 내용은 분할 패턴을 참조하세요.
3. 데이터 크기 및 처리량의 관점에서, 각 파티션에는 확장성 요구 사항을 처리하기에 충분한 리소스가 있어야 합니다. 데이터 저장소에 따라 스토리지 공간의 양, 처리 능력 또는 파티션당 네트워크 대역폭에 제한이 있을 수 있습니다. 요구 사항이 이러한 제한을 초과할 가능성이 있는 경우 분할 전략을 세분화하거나 데이터를 더 분할해야 할 수 있습니다. 가능하다면 두 개 이상의 전략을 결합할 수 있습니다.
4. 시스템을 모니터링하여 데이터가 예상대로 분산되는지, 파티션에서 부하를 처리할 수 있는지 확인합니다. 실제 사용량이 분석 예측과 항상 일치하는 것은 아닙니다. 이 경우 파티션 균형을 다시 조정할 수 있고, 그렇지 않은 경우 시스템 일부를 다시 디자인하여 필요한 균형을 맞출 수 있습니다.

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

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

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

일반적으로 더 작은 데이터 집합을 사용하고 병렬 쿼리를 실행하여 쿼리 성능을 높일 수 있습니다. 각 파티션에는 전체 데이터 집합의 일부분이 포함됩니다. 이렇게 볼륨이 감소하면서 쿼리 성능이 개선될 수 있습니다. 그러나 분할은 데이터베이스를 적절하게 디자인하고 구성하는 작업에 대한 대안이 아닙니다. 예를 들어 필요한 인덱스가 있는지 확인합니다.

쿼리 성능을 위해 파티션을 디자인하는 경우 다음 단계를 따릅니다.

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

   • 비즈니스 요구 사항을 사용하여 항상 신속하게 수행해야 하는 중요 쿼리를 결정합니다.
   • 시스템을 모니터링하여 느리게 수행되는 쿼리를 식별합니다.
   • 어떤 쿼리가 가장 자주 수행되는지 확인합니다. 단일 쿼리의 비용이 가장 적을 수 있지만, 누적 리소스 사용량은 매우 높을 수 있습니다.

2. 성능 저하를 초래하는 데이터를 분할합니다.

   • 쿼리 응답 시간이 목표 범위에 해당하도록 각 파티션 크기를 제한합니다.
   • 행 분할을 사용하는 경우 애플리케이션에서 적절한 파티션을 쉽게 선택할 수 있도록 분할된 데이터베이스 키를 디자인합니다. 이렇게 하면 쿼리가 모든 분할을 검색할 필요가 없습니다.
   • 파티션의 위치를 고려합니다. 가능한 경우 애플리케이션 및 액세스하는 사용자와 지리적으로 가까운 파티션에 데이터를 보관하도록 합니다.

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

4. 성능 개선을 위해 여러 파티션에서 쿼리를 병렬로 실행하는 방안을 고려합니다.

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

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

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

비즈니스 운영에 대한 데이터의 중요도 트랜잭션처럼 중요한 비즈니스 정보와 로그 파일처럼 중요도가 낮은 운영 데이터를 식별합니다.

• 적절한 백업 계획을 사용하여 중요한 데이터를 가용성이 높은 파티션에 저장하는 방안을 고려합니다.

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

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

개별 파티션을 관리하는 방법 파티션을 독립적으로 관리 및 유지 관리할 수 있도록 디자인하면 몇 가지 이점이 있습니다. 예를 들면 다음과 같습니다.

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

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

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

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

분할을 사용하면 시스템 디자인 및 개발이 더 복잡해집니다. 초기 시스템에 하나의 파티션만 포함되어 있는 경우에도 시스템 디자인의 기본적인 부분으로 분할하는 것이 좋습니다. 나중에 분할을 처리하면 이미 유지 관리할 라이브 시스템이 있으므로 더 어려워집니다.

• 데이터 액세스 논리를 수정해야 합니다.
• 대량의 기존 데이터를 마이그레이션하여 여러 파티션에 분산해야 할 수 있습니다.
• 사용자는 마이그레이션하는 동안 시스템을 계속 사용할 수 있기를 기대합니다.

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

또한 분할하는 것이 좋은 대용량 데이터 저장소만 있는 것이 아닙니다. 예를 들어, 수백 개의 동시 클라이언트에서 작은 데이터 저장소에 과도하게 액세스할 수 있습니다. 이러한 상황에서 데이터를 분할하면 경합을 줄이고 처리량을 향상시키는 데 도움이 될 수 있습니다.

데이터 파티션 구성표를 설계할 때 다음 사항을 고려하세요.

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

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

파티션 간 조인을 최소화합니다. 가능하면 수직 파티션과 기능 파티션 간 참조 무결성 요구 사항을 최소화합니다. 이 구성표에서 애플리케이션은 파티션 간 참조 무결성을 유지하는 책임을 맡습니다. 여러 파티션에서 데이터를 조인하는 쿼리는 효율성이 떨어집니다. 왜냐하면 일반적으로 애플리케이션은 키 그리고 그 다음에는 외래 키를 기반으로 연속 쿼리를 수행해야 하기 때문입니다. 대신, 관련 데이터를 복제하거나 비정규화하는 것이 좋습니다. 파티션 간 조인이 필요한 경우 파티션에 병렬 쿼리를 실행하고 애플리케이션으로 데이터를 조인합니다.

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

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

분할된 데이터베이스를 주기적으로 리밸런싱하는 방안을 고려합니다. 행 분할을 사용하면 분할된 데이터베이스를 리밸런싱하여 크기 및 워크로드에 따라 데이터를 균등하게 분산하여 핫스폿을 최소화하고, 쿼리 성능을 최대화하고, 실제 스토리지 제한 사항을 해결할 수 있습니다. 그러나 이 작업은 흔히 사용자 지정 도구 또는 프로세스를 사용해야 하는 복잡한 작업입니다.

파티션을 복제합니다. 각 파티션을 복제하면 실패를 방지할 수 있는 추가 보호 기능을 제공합니다. 단일 복제본이 실패하면 쿼리가 작업 복사본으로 전달될 수 있습니다.

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

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

모든 데이터 저장소에는 몇 가지 운영 관리 및 모니터링 활동이 필요합니다. 이러한 작업에는 데이터 로드, 데이터 백업 및 복원, 데이터 재구성 및 시스템이 올바르고 효율적으로 수행되도록 보증하는 일까지 포함됩니다.

운영 관리에 영향을 주는 다음 요인을 고려하도록 합니다.

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

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

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

• 데이터 무결성 문제를 찾는 방법. 데이터 무결성 문제(예: 다른 파티션의 누락된 정보를 참조하는 파티션 데이터)를 찾을 수 있도록 정기적인 프로세스를 실행하는 것이 좋습니다. 프로세스에서 자동으로 이러한 문제를 해결하려고 시도할 수도 있고 수동 검토를 위한 보고서를 생성할 수도 있습니다.

파티션 리밸런싱

시스템이 성숙함에 따라 파티션 구성표를 조정해야 할 수도 있습니다. 예를 들어 개인 파티션이 불균형적인 트래픽 볼륨을 가져오기 시작하여 핫 상태가 되고, 결국 과도한 경합으로 이어질 수 있습니다. 또는 일부 파티션의 데이터 볼륨을 과소 평가하여 일부 파티션이 저장소 용량 한도에 근접했을 수 있습니다.

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

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

   • 어떤 파티션을 분할해야 하나요(또는 결합도 가능)?
   • 새 파티션 키는 무엇인가요?

2. 기존 파티션 구성표의 데이터를 새 파티션 집합으로 마이그레이션합니다.

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

오프라인 마이그레이션

오프라인 마이그레이션은 경합이 발생할 가능성이 낮기 때문에 간단한 방법입니다. 개념적으로 오프라인 마이그레이션은 다음과 같이 작동합니다.

1. 파티션을 오프라인으로 표시합니다.
2. 데이터를 분할-병합한 후 새 파티션으로 이동합니다.
3. 데이터 확인
4. 새 파티션을 온라인으로 전환합니다.
5. 기존 파티션을 제거합니다.

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

온라인 마이그레이션

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

다음 단계

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

관련 리소스

• 적절한 데이터 저장소 선택

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

• 분할 패턴은 데이터를 분할하는 일반적인 전략을 설명합니다.

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

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