Что будет, если выбрать плохой partition key?

Типичные плохие примеры PK

BAD: PK = "status"        # Значения: OPEN, CLOSED, PENDING - 3 партиции
BAD: PK = "country"       # 90% трафика = US → hot partition
BAD: PK = "date"          # Все записи за день в одну партицию
BAD: PK = "type"          # Если типов мало (User, Order, Product)
BAD: PK = sequential_id   # Если ID монотонно возрастает (timestamp-based)

Последствия плохого Partition Key в DynamoDB

Partition Key — фундамент DynamoDB-архитектуры. Плохой выбор приводит к throttling, высокой latency и дорогостоящим переделкам, которые нельзя сделать in-place — только пересоздание таблицы.

Физические последствия

• Hot partition: DynamoDB хэширует PK и направляет запросы к физической партиции. Если 80% запросов идут к одному PK-значению, одна партиция перегружена, остальные простаивают.
• Throttling: каждая партиция ограничена 3000 RCU и 1000 WCU. Превышение вызывает ProvisionedThroughputExceededException независимо от того, сколько capacity выделено глобально.
• On-demand mode не панацея: при резком spike on-demand mode тоже throttlит, если нагрузка превышает 2x предыдущего пика — adaptive capacity помогает, но не убирает физический лимит партиции.

Стратегии исправления

Write Sharding

import random
import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('events')

SHARD_COUNT = 10  # количество шардов

def write_event(event_type: str, payload: dict) -> None:
    shard = random.randint(0, SHARD_COUNT - 1)
    table.put_item(Item={
        'PK': f'{event_type}#{shard}',  # sharded key
        'SK': f'{payload["timestamp"]}#{payload["id"]}',
        **payload,
    })

def read_events(event_type: str) -> list:
    # Fan-out: читаем из всех шардов параллельно
    results = []
    for shard in range(SHARD_COUNT):
        response = table.query(
            KeyConditionExpression=(
                boto3.dynamodb.conditions.Key('PK').eq(f'{event_type}#{shard}')
            )
        )
        results.extend(response['Items'])
    return sorted(results, key=lambda x: x['timestamp'])

Добавление high-cardinality компонента

БЫЛО:  PK = status (OPEN/CLOSED)
СТАЛО: PK = tenantId#status — каждый tenant изолирован в своей партиции

ИЛИ:   PK = userId          — tenant-per-user модель, максимальная cardinality
        GSI: PK = status     — для admin запросов по статусу

Диагностика в CloudWatch

# Метрики для анализа hot partitions:
# ConsumedReadCapacityUnits / ConsumedWriteCapacityUnits per-partition (через DynamoDB Contributor Insights)
aws dynamodb describe-contributor-insights \
  --table-name my-table

# Включить Contributor Insights для видимости top keys
aws dynamodb update-contributor-insights \
  --table-name my-table \
  --contributor-insights-action ENABLE

Подводные камни

• Write sharding упрощает запись, но усложняет чтение: нужен fan-out по всем шардам, что увеличивает read amplification и стоимость.
• GSI на hot attribute (например, status) не решает проблему — GSI тоже имеет partition ключ и те же физические ограничения.
• Adaptive capacity DynamoDB помогает при кратковременных spikes, но не устраняет структурную проблему hot partition — это не решение, а временное смягчение.
• Пересоздание таблицы с новым PK — единственный способ изменить ключ. В production это требует dual-write, backfill, validation и cutover — минимум несколько дней работы.
• Sequential timestamp как PK при insert-heavy нагрузке создаёт монотонно возрастающий ключ, что концентрирует writes на последней партиции — аналог B-tree right-hand insert в PostgreSQL.
• DynamoDB Contributor Insights необходимо включить заранее — без него увидеть top keys в CloudWatch невозможно.

• Выбирать partition key с несколькими значениями.
• Считать on-demand capacity решением любой hot partition.
• Добавлять GSI с тем же плохим распределением.

• Объясняет hot partition и throttling.
• Предлагает realistic mitigations.
• Учитывает trade-offs write sharding и GSIs.