기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 데이터 모델링 모범 사례: 데이터 모델 설계를 위한 권장 사항
Amazon Keyspaces(Apache Cassandra용)로 작업할 때 성능을 최적화하고 비용을 최소화하려면 효과적인 데이터 모델링이 중요합니다. 이 주제에서는 애플리케이션의 데이터 액세스 패턴에 맞는 데이터 모델을 설계하기 위한 주요 고려 사항과 권장 사항을 다룹니다.
+ **파티션 키 설계** - 파티션 키는 Amazon Keyspaces의 파티션 간에 데이터가 분산되는 방식을 결정하는 데 중요한 역할을 합니다. 적절한 파티션 키를 선택하면 쿼리 성능 및 처리량 비용에 상당한 영향을 미칠 수 있습니다. 이 섹션에서는 파티션 간 읽기 및 쓰기 활동의 균등한 배포를 촉진하는 파티션 키를 설계하기 위한 전략에 대해 설명합니다.
+ **주요 고려 사항:**
+ **균일 활동 배포** - 모든 파티션에서 균일한 읽기 및 쓰기 활동을 목표로 하여 처리량 비용을 최소화하고 버스트 용량을 효과적으로 활용합니다.
+ **액세스 패턴** - 파티션 키 설계를 애플리케이션의 기본 데이터 액세스 패턴과 정렬합니다.
+ **파티션 크기** - 너무 커지는 파티션은 성능에 영향을 미치고 비용이 증가할 수 있으므로 생성하지 마세요.
[NoSQL Workbench](workbench.md)를 사용하면 데이터 모델을 보다 쉽게 시각화하고 설계할 수 있습니다.
**Topics**
+ [Amazon Keyspaces에서 파티션 키를 효과적으로 사용하는 방법](bp-partition-key-design.md)
# Amazon Keyspaces에서 파티션 키를 효과적으로 사용하는 방법
Amazon Keyspaces 테이블의 각 행을 고유하게 식별하는 프라이머리 키는 데이터가 저장되는 파티션을 결정하는 하나 이상의 파티션 키 열과 파티션 내에서 데이터가 클러스터링되고 정렬되는 방식을 정의하는 하나 이상의 선택적 클러스터링 열로 구성될 수 있습니다.
파티션 키는 데이터가 저장되는 파티션 수와 파티션에 데이터가 분산되는 방식을 설정하므로 파티션 키를 어떻게 선택하느냐에 따라 쿼리 성능이 상당히 달라질 수 있습니다. 일반적으로 디스크의 모든 파티션에서 균일하게 작동하도록 애플리케이션을 설계해야 합니다.
애플리케이션의 읽기 및 쓰기 작업을 모든 파티션에 균등하게 분배하면 처리량 비용을 최소화하는 데 도움이 되며, 이는 온디맨드뿐 아니라 프로비저닝된 읽기/쓰기 용량 모드에도 적용됩니다. 예를 들어 프로비저닝된 용량 모드를 사용하는 경우, 애플리케이션에 필요한 액세스 패턴을 결정하고, 각 테이블에 필요한 읽기 용량 단위(RCU)와 쓰기 용량 단위(WCU)의 총계를 추정할 수 있습니다. Amazon Keyspaces는 특정 파티션 키에 대한 트래픽이 3,000RCU 및 1,000WCU를 초과하지 않는다면, 는 자동으로 사용자가 프로비저닝한 처리량을 사용해 액세스 패턴을 지원합니다.
파티션에 높은 읽기 또는 쓰기 처리량이 지속되면 Amazon Keyspaces는 트래픽 패턴에 따라 파티션을 자동으로 두 개의 새 파티션으로 분할할 수 있습니다. 각 새 파티션에는 원본 파티션 행의 하위 집합이 포함되어 두 파티션에 처리량을 균등하게 분산합니다.
Amazon Keyspaces는 버스트 용량 을 제공하여 파티션당 처리량 프로비저닝에서 추가적인 유연성을 제공합니다. 자세한 내용은 [Amazon Keyspaces에서 버스트 용량을 효과적으로 사용하기](throughput-bursting.md) 섹션을 참조하세요.
**Topics**
+ [쓰기 샤딩을 사용하여 파티션 간에 워크로드를 고르게 분산](bp-partition-key-sharding.md)
# 쓰기 샤딩을 사용하여 파티션 간에 워크로드를 고르게 분산
Amazon Keyspaces의 파티션에 더 효과적으로 쓰기 작업을 배포하는 방법 중 하나는 공간 확장입니다. 여러 방법을 사용할 수 있습니다. 여러 파티션에 행을 분배하기 위해 난수를 쓰는 파티션 키 열을 추가할 수 있습니다. 또는 쿼리하는 항목을 기반으로 계산된 숫자를 사용할 수 있습니다.
## 복합 파티션 키와 무작위 값을 사용한 샤딩
파티션에 부하를 더 균등하게 분산하기 위한 한 가지 전략은 난수를 기록할 파티션 키 열을 추가하는 것입니다. 그러면 더 큰 공간으로 쓰기를 무작위화 할 수 있습니다.
예를 들어 날짜를 나타내는 단일 파티션 키가 있는 테이블은 다음과 같습니다.
```
CREATE TABLE IF NOT EXISTS tracker.blogs (
publish_date date,
title text,
description int,
PRIMARY KEY (publish_date));
```
이 테이블을 여러 파티션에 더 균등하게 분배하려면 난수를 저장하는 파티션 키 열 `shard`를 추가하면 됩니다. 예제:
```
CREATE TABLE IF NOT EXISTS tracker.blogs (
publish_date date,
shard int,
title text,
description int,
PRIMARY KEY ((publish_date, shard)));
```
데이터를 삽입할 때 `shard` 열의 `1`와(과) `200` 사이의 난수를 선택할 수 있습니다. 이렇게 하면 `(2020-07-09, 1)`, `(2020-07-09, 2)`, `(2020-07-09, 200)`까지의 복합 파티션 키 값이 생성됩니다. 파티션 키를 임의 지정했기 때문에, 각 날짜의 테이블에 대한 쓰기가 모든 파티션 키 값에 고르게 분산됩니다. 이는 병렬 처리를 개선하고 전반적인 처리량을 높입니다.
하지만 지정된 날짜의 모든 행을 읽으려면, 모든 샤드의 행을 쿼리해 결과를 병합해야 합니다. 예를 들어 먼저 파티션 키 값 `(2020-07-09, 1)`에 대한 `SELECT`문을 생성합니다. 그런 다음 `(2020-07-09, 2)`에서 `(2020-07-09, 200)`까지에 대해 또 다른 `SELECT`문을 생성합니다. 마지막으로 애플리케이션은 모든 `SELECT`문 결과를 병합해야 합니다.
## 복합 파티션 키와 계산된 값을 사용한 샤딩
임의 지정 전략으로 쓰기 처리량을 크게 향상시킬 수 있습니다. 하지만 행을 작성할 때 `shard` 열에 어떤 값이 기록되었는지 모르기 때문에 특정 행을 읽기가 어렵습니다. 개별 행을 더 쉽게 읽을 수 있도록 만들려면 다른 전략을 사용합니다. 난수(임의의 수)를 사용해 여러 파티션으로 행을 배포하는 대신, 쿼리하고 싶은 내용을 토대로 계산할 수 있는 수를 사용합니다.
테이블의 파티션 키에 오늘 날짜를 사용한 앞의 예를 가정하겠습니다. 이제 각 행에 액세스가 가능한 `title` 열이 있고, 날짜에 더해 제목으로 행을 찾아야 하는 경우가 많다고 가정하겠습니다. 애플리케이션은 테이블에 행을 쓰기 전에 제목에 따라 해시 값을 계산하고 `shard` 열에 이를 입력할 수 있습니다. 계산 결과 임의 지정 전략에서 생산되는 결과와 유사하게 골고루 배포된 1-200 사이의 숫자가 생성될 것입니다.
제목의 문자에 대한 UTF-8 코드 포인트 값의 제품이나 모듈로 200 \$1 1과 같이 간단한 계산으로 충분합니다. 그러면 복합 파티션 키 값은 날짜와 계산 결과의 조합이 됩니다.
이러한 전략을 통해 쓰기가 파티션-키 값 및 물리적 파티션에 고르게 분산됩니다. 특정 행과 날짜에서 `SELECT`문을 손쉽게 수행할 수 있습니다. 특정 `title` 값에 대한 파티션-키 값을 계산할 수 있기 때문입니다.
지정된 날의 모든 열을 읽으려면 각 `(2020-07-09, N)`(여기서 `N`은 1\$1200) 키를 `SELECT`해야 하며, 애플리케이션은 모든 결과를 병합해야 합니다. 장점은 모든 워크로드를 취하는 하나의 '핫' 파티션 키 값이 발생하지 않도록 만든다는 것입니다.