AWS Dynamo DB: как эффективно проектировать без GSI

#amazon-web-services #database-design #amazon-dynamodb #dynamodb-queries

#amazon-веб-сервисы #база данных-дизайн #amazon-dynamodb #dynamodb-запросы

Вопрос:

Я разрабатываю DynamoDB с учетом требований

  1. список всех заявок по пользователям
  2. перечислите все заявки по типу заявки

Мои столбцы дизайна

p_key s_key ticket_type Подробные сведения дата создания

первичный ключ: p_key (значение: EVENT#<event id> )

ключ сортировки: s_key (значение: <user id>#<ticket type> )

Параметры запроса для требования 1

 let params = {
    TableName: `eventTable`,
    KeyConditionExpression: ‘p_key = :p_key and begins_with(s_key,  :s_key )‘,
    ExpressionAttributeValues: {
      ':p_key': `EVENT#${eventId}`,
      ‘:s_key': `${userId}`,
    }
  };
 

Для выполнения требования 2 мне нужно добавить GSI (например, gsi001-index)

первичный ключ: p_key (такой же, как указано выше)

ключ сортировки: ticket_type

параметры запроса, как показано ниже:

 let params = {
    TableName: `eventTable`,
    IndexName: ‘gsi001-index’,
    KeyConditionExpression: ‘p_key = :p_key and ticket_type = :ticket_type‘,
    ExpressionAttributeValues: {
      ':p_key': `EVENT#${eventId}`,
      ‘:ticket_type’: `${ticketType}`,
    }
  };
 

Мой вопрос: есть ли лучший дизайн, чтобы мне больше не нужен GSI?

Любые предложения приветствуются.

Ответ №1:

Вы могли бы сделать это, введя дублирование в свою базу данных — для каждого элемента:

p_key(СОБЫТИЕ # ${EventID}), s_key({user_id}#{тип билета}), ticket_type, подробности, date_created

вставьте другой с тем же ключом раздела, но ключ сортировки изменен:

p_key(СОБЫТИЕ # ${EventID}), s_key({ticket_type}#{user_id}), идентификатор пользователя, сведения, дата создания

Таким образом, вы можете поддерживать оба запроса без другого GSI.
Недостатком этого является то, что для изменения любого элемента требуется 2 записи. Больше, если вы будете использовать TransactWriteItems. Это зависит от того, загружено ли ваше приложение для записи или чтения.

Ответ №2:

Вы можете использовать локальный вторичный индекс (LSI), когда ключ раздела для LSI совпадает с ключом раздела для таблицы.

Плюсы

  • никаких дополнительных затрат

Минусы

  • LSI должны быть определены, когда таблица есть, они не могут быть добавлены постфактум.
  • Если LSI определен в таблице, то для данного ключа раздела существует ограничение в 10 ГБ данных.
  • для каждой таблицы разрешено только 5 LSI

Подробная информация

Комментарии:

1. очень интересно. Большое спасибо. Посмотрим на это