Ответ 1
Надеюсь, это ответит на все ваши вопросы. Здесь пара вводных вещей. Я буду использовать общую таблицу для всех моих примеров. Ключ хеша - это node_a а ключ сортировки - это node_b. Существует GSI обратного просмотра, где node_b - это ключ хеша, а node_a - ключ сортировки.
1. Может ли атрибут данных быть картой?
Атрибутом данных может быть любой из поддерживаемых типов данных в DynamoDB, включая карту.
2. Должен ли атрибут данных записываться в два места при записи?
Атрибут данных должен быть записан только в одном месте. В качестве примера даты рождения вы можете сделать одну из следующих записей DynamoDB:
node_a | node_b | data
----------|-----------|---------------
user-1 | user-1 | {"birthdate":"2000-01-01", "firstname": "Bob", ...}
user-1 | birthdate | 2000-01-01
В первой строке мы создали ребро из узла user-1 которое возвращается на себя. Во втором ряду мы создали грань от user-1 до birthdate. В любом случае это хорошо, и лучший выбор зависит от того, как вы будете получать доступ к вашим данным. Если вам нужно найти пользователей с датой рождения в заданном диапазоне, вам следует создать узел с birthdate. Если вам просто нужно найти информацию о пользователях по их идентификатору, вы можете использовать любую стратегию, но первая строка обычно будет более эффективно использовать пропускную способность вашей таблицы.
3. Если я хочу добавить нового человека, родившегося 1980-12-19, должен ли я сначала искать соответствующий узел?
Нет. Просто вставьте одну из строк из примера выше.
Вам нужно искать узел только в том случае, если существует более сложный шаблон доступа, например, "обновить имя человека, родившегося в 1980-12-19". В этом случае вам потребуется поискать по дате рождения, чтобы получить узел человека, а затем изменить что-то, связанное с узлом человека. Однако этот вариант использования на самом деле является двумя разными операциями. Вы можете перефразировать это предложение как "Найти человека, который родился в 1980-12-19, и обновить имя", что делает эти две операции более очевидными.
4. (а) Как я могу получить все свойства, связанные с узлом?
Предположим, вы хотите найти все ребра для "myNode". Вы запросите основную таблицу с помощью ключевого выражения условия node_a="myNode" и запросите GSI обратного просмотра с ключевым условием выражения node_b="myNode". Это эквивалент SELECT * FROM my_table WHERE node_a="myNode" OR node_b="myNode".
4. (б) Как получить все свойства, связанные с ребром?
Все свойства ребра хранятся непосредственно в атрибутах ребра, но вы все равно можете столкнуться с ситуацией, когда вы точно не знаете, где находятся данные. Например:
node_a | node_b | data
----------|-----------|---------------
thing-1 | thing-2 | Is the data here?
thing-2 | thing-1 | Or here?
Если вы знаете порядок краевых узлов (т. node_a node_b узел является node_a и node_b), то вам потребуется только одна операция GetItem для извлечения данных. Если вы не знаете, в каком порядке расположены узлы, то вы можете использовать BatchGetItems для поиска обеих строк в таблице (должна существовать только одна из строк, если вы не делаете что-то особенно сложное с участием ориентированного графа).
5. Как я могу запросить соседние узлы?
Смежные узлы - это просто два узла, которые имеют ребро, соединяющее их. Вы бы использовали тот же запрос, что и 4a, за исключением того, что вместо интереса к атрибуту data вас интересуют идентификаторы других узлов.
Еще несколько примеров
- Использование графического шаблона для моделирования простой социальной сети
- Использование графического шаблона для моделирования пользовательских ресурсов
- Как смоделировать круговые отношения между актерами и фильмами в DynamoDB (ответ использует графическую схему)
- Моделирование отношений "многие ко многим" в DynamoDB
- От реляционной БД до одной таблицы DynamoDB: пошаговое исследование. Это убийственный кусок. В него встроен доклад AWS re: Invent, и автор этого поста в блоге добавляет собственное объяснение.