DynamoDB и таблица входа пользователей

Я создал приложение, и в настоящее время оно имеет довольно стандартную пользовательскую таблицу, например:

int id, электронная почта varchar, пароль varchar

Если бы я переключил это на DynamoDB, то как бы я создал эту таблицу?

Если я использую хеш-ключ с адресом электронной почты, то я не смогу предложить возможность обновить вашу электронную почту, а если я использую хэш для хранения идентификатора, мне нужно будет использовать сканирование, которое является дорогим и ограничен лимитом в 1 Мб.

Любые советы, пожалуйста? Спасибо, Марк


amazon-dynamodb
person Mark    schedule 19.04.2012    source источник
comment
Похоже, это дубликат stackoverflow.com/q/12920884/268898.   -  person Jeff Walker Code Ranger    schedule 12.05.2014
comment
такая же проблема для меня   -  person Jayani Sumudini    schedule 22.04.2020

Ответы (3)


arrow_upward
5
arrow_downward

Вы говорите, что было бы дорого использовать идентификатор в качестве хэша, потому что вам нужно фильтровать по полю электронной почты?

Если вам нужно отфильтровать запросы по неключевому столбцу, вы часто заканчиваете созданием для него индекса.

DynamoDB не имеет встроенного дополнительного индекса, но реализовать собственное решение довольно просто.

Основная таблица может использовать ID в качестве хэша, как вы указали, а другая таблица будет служить индексом, это может быть:

varchar email, int id

Являясь email хеш-ключом для вторичной таблицы. Если разрешено иметь несколько пользователей с одним и тем же адресом электронной почты, вы можете использовать ID в качестве диапазона, чтобы упростить задачу, иначе подойдет простой столбец.

person Rodrigo Ribeiro    schedule 19.04.2012
comment
Это правда, что таким образом вы можете создать свой собственный вторичный индекс, но имейте в виду, что ваш код отвечает за его синхронизацию с основной таблицей. Кроме того, операции по обновлению таблицы и индексной таблицы не будут атомарными. Это может быть или не быть проблемой в зависимости от того, насколько параллельны ваши модели доступа. - person bkirkbri; 25.05.2012
comment
DynamoDB теперь имеет глобальные вторичные индексы, которые можно использовать для этого (docs.aws .amazon.com/amazondynamodb/latest/developerguide/) - person Jeff Walker Code Ranger; 12.05.2014
comment
@JeffWalkerCodeRanger Я не понимаю, как GSI могут помочь решить эту проблему. Вы можете объяснить? - person rob; 03.02.2016
comment
@RobertOliveira Просто создайте таблицу пользователей, чей хеш-ключ равен ID (я бы использовал guids, а не целые числа) с атрибутами Email и Password. Затем создайте глобальный вторичный индекс с хэш-ключом Email. Затем вы можете запросить индекс по электронной почте. Когда вы обновляете строку пользователя, вам придется делать это по идентификатору, но индекс будет автоматически синхронизироваться. - person Jeff Walker Code Ranger; 03.02.2016
comment
@JeffWalkerCodeRanger Но обеспечивает ли это атомарную операцию при выполнении пут? Разве мне не нужно будет запрашивать GSI перед выполнением операции размещения? - person rob; 03.02.2016
comment
@RobertOliveira Глобальные индексы в конечном итоге соответствуют таблице, в которой они находятся. Это все же лучше, чем пытаться поддерживать отдельную индексную таблицу самостоятельно. Если вы обновляете адрес электронной почты, вам потребуется идентификатор пользователя. Если у вас его еще нет (скажем, потому что они вошли в систему и вы сохранили его в файле cookie), вам нужно сначала выполнить запрос к индексу, чтобы получить его. - person Jeff Walker Code Ranger; 04.02.2016

arrow_upward
2
arrow_downward

Наличие другой таблицы для индексации приведет к высоким затратам на обслуживание. Я наткнулся на избыточную модель от моего бывшего технического директора.

Для вашего стола : ПОЛЬЗОВАТЕЛЬ

СУБД:

идентификатор, пароль электронной почты

1, [email protected], спрашивает

DynamoDB:

КЛЮЧ, идентификатор, электронная почта, пароль

1, 1, [email protected], спрашивает

[email protected],1 , [email protected], спрашивает

Вместо того, чтобы хранить одну запись, вы сохраняете избыточно для выборки с использованием неиндексированных столбцов.

Надеюсь, решение понятно.

person senthil3569    schedule 27.04.2012
comment
Почему это решение требует меньше обслуживания, чем решение с вторичной таблицей? У вас снова есть 2 записи, и их нельзя обновить в транзакции, даже если они находятся в одной таблице. - person ivant; 30.11.2012

arrow_upward
1
arrow_downward

Создайте таблицу User с идентификатором хеш-ключа (UUID пользователя) и другими атрибутами. Создайте глобальный вторичный индекс с хэш-ключом электронной почты, и у вас есть возможность выбрать ключ сортировки в соответствии с вашими требованиями (активный статус пользователя, тип пользователя).

  • вы можете получить их и обновить пользователя по UUID (идентификатор пользователя)
  • Получить пользователя с emailId
  • Получить пользователя с активным статусом без фильтра (по ключу сортировки)
UserTable:
   Type: AWS::DynamoDB::Table
   Properties:
     TableName: UserTable
     AttributeDefinitions:
       - AttributeName: id
         AttributeType: S
       - AttributeName: email
         AttributeType: S
       - AttributeName: status(optional sort key according to your requirement)
         AttributeType: S
     KeySchema:
       - AttributeName: id
         KeyType: HASH
     ProvisionedThroughput:
       ReadCapacityUnits: 5
       WriteCapacityUnits: 5
     GlobalSecondaryIndexes:
       - IndexName: UserDetail
         KeySchema:
           - AttributeName: email
             KeyType: HASH
           - AttributeName: status(option)
             KeyType: RANGE
         Projection:
           ProjectionType: ALL
         ProvisionedThroughput:
           ReadCapacityUnits: 5
           WriteCapacityUnits: 5
person Jha Nitesh    schedule 14.08.2019