#amazon-web-services #database-design #amazon-dynamodb #dynamodb-queries
#amazon-веб-сервисы #база данных-дизайн #amazon-dynamodb #dynamodb-запросы
Вопрос:
Я разрабатываю DynamoDB с учетом требований
- список всех заявок по пользователям
- перечислите все заявки по типу заявки
Мои столбцы дизайна
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. очень интересно. Большое спасибо. Посмотрим на это