Как добиться отношения "один ко многим" в Dynamodb?
Я новичок в Dynamodb, но работал с отношениями MongoDB. Я очень смущен, читая документы aws для отношения "один ко многим" с Dynamodb.
Итак, мой сценарий:
Например, у меня есть таблицы пользователя и адреса:
Table: User
----
username
fname
lname
address: ref to addresses
Table: Addresses
----------
address line 1
address line 2
city
Zip
state
country
Не могли бы вы помочь мне, как добиться этого в Dynamodb.
- Как хранить реляционные данные?
- Получить данные, в том числе реляционные, в одном запросе?
Ответы 1
DynamoDB не является реляционной базой данных. Вы не можете выполнять те типы реляционных запросов, о которых думаете (особенно в одном запросе, как описано в вашем вопросе №2). Это требует другого образа мыслей о том, как вы будете хранить и получать доступ к своим данным, и, соответственно, это может быть неподходящей технологией для вашего приложения.
Dynamo не предлагает внешние ключи или соединения таблиц. Каждая таблица имеет либо ключ раздела (PK), либо комбинацию ключа раздела и ключа сортировки (SK). Когда таблица имеет только PK, ее можно запрашивать только для отдельных элементов. Если у него есть как PK, так и SK, он может быть запрошен для одного элемента с помощью PK / SK, или его можно запросить для всех элементов, которые имеют один и тот же PK.
Один из способов реализации данных 1 к N, как вы описываете, будет выглядеть примерно так:
Table: Users
------------
[PK] userId
username
fname
lname
Table: Addresses
----------------
[PK] userId
[SK] addressId
address line 1
address line 2
city
zip
state
country
В этом макете вам все равно потребуется два звонка в Dynamo, чтобы получить всю информацию для пользователя, включая адреса. Вы должны сделать один вызов getItem к таблице Users с помощью этого userId и сделать запрос к Addresses с тем же userId. Первый вызов вернет единственную запись пользователя, а второй вызов вернет список адресных записей, отсортированных по addressId.
Вы должны вручную управлять своими данными. Поскольку нет внешних ключей, также нет ограничений или каскадов. Очень легко получить потерянные данные, если вы не будете осторожны. Опять же, Dynamo может быть не самым подходящим инструментом для вашего приложения.
То, что я здесь описал, лишь поверхностно. Для любого, кто надеется создать корпоративное программное обеспечение с использованием DynamoDB для хранения данных, крайне важно хорошо понимать его архитектурный подход и лучшие практики. Исходя из опыта работы с SQL или даже MongoDB, ваша интуиция может сбить вас с пути, из-за чего вы создадите что-то, что не будет хорошо работать и будет трудно отлаживать. Это чрезвычайно мощный инструмент для правильного типа работы, но вы должны проявить должную осмотрительность, чтобы сначала понять его.
-
Отредактировано, чтобы добавить: подход, который я описал выше, даже не очень хороший! AWS поделился документацией и рассказывает об этом, в том числе об их Лучшие практики для DynamoDB, что выходит далеко за рамки этого ответа.