Первичный ключ списка смежности DynamoDB - PullRequest
Новая
       18

Первичный ключ списка смежности DynamoDB

0 голосов
/ 27 июня 2018

Я выполняю упражнение, используя DynamoDB, чтобы смоделировать отношения многие ко многим. Мне нужно разрешить много-много отношений между постами и тегами. В каждом сообщении может быть много тегов, а в каждом теге может быть много сообщений.

У меня есть первичный ключ на id и первичный ключ сортировки на type, а затем еще один глобальный индекс на id и data, я снова добавил еще один глобальный индекс на id и type, но я думаю, что это излишне.

Вот что у меня есть. 

id(Partition key)      type(Sort Key)       target       data
-------------          ----------           ------       ------
1                      post                 1            cool post
tag                    tag                  tag          n/a
1                      tag                  tag          orange

---------------------------------------------
---- inserting another tag will overwrite ---
---------------------------------------------

1                      tag                  tag          green

Я беру совет из этого удивительного разговора https://www.youtube.com/watch?v=jzeKPKpucS0 и эти не очень удивительные документы https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html

Проблема, с которой я столкнулся, заключается в том, что если я попытаюсь добавить еще один тег с тегом id "1" и type, он перезапишет существующий тег, поскольку у него будет тот же составной ключ. Что мне здесь не хватает? Кажется, что предложение состоит в том, чтобы сделать первичный ключ и ключ сортировки id и type. Должен ли мой тип быть больше похож на «tag # orange»? В этом случае я мог бы поместить глобальный индекс на target с ключом сортировки на тип. Таким образом, я мог получить все сообщения с определенным тегом, выполнив запрос target = "tag", и тип начинается с "tag".

Просто ищите несколько советов по обработке такого рода данных списка смежности с Динамо, поскольку это кажется очень интересным. Спасибо!

Ответы [ 2 ]

0 голосов
/ 30 июня 2018

Основные рекомендации для списка смежности

Вам нужно внести несколько изменений в способ моделирования. В списке смежности у вас есть два типа предметов:

  1. Верхний уровень (это ваши сообщений и Метки )
  2. Ассоциация (выражает, какие Теги связаны с каждым Постом и наоборот)

Чтобы построить этот список смежности, вы должны следовать двум простым правилам (которые, я думаю, отсутствуют в вашем примере):

  • Каждый элемент верхнего уровня (в вашем случае Post или Tag ) должен быть представлен с помощью первичного ключа , Кроме того, эти элементы должны иметь одинаковое значение в ключе сортировки и первичном ключе
  • Для ассоциаций используйте первичный ключ для представления источника (или parent ) и ключ сортировки для представления target (или * 1046) * ребенок ).

Из того, что я вижу в ваших примерах, вы устанавливаете первичный ключ ваших сообщений и Теги как просто элемент ID, в то время как вы должны также использовать type ; например Post-1 или Tag-3. В элементах, которые представляют ассоциации, я также не вижу, чтобы вы хранили целевой объект ID .

Пример * * 1 067 Допустим, у вас есть: Три сообщения: "Привет, мир" , "foo bar" и "Что бы ..." И три тега: «круто» , «круто» , «здорово» Пост "Привет, мир" имеет один тег: "Круто" Post "foo bar" имеет два тега: "cool" и "great" Пост "Что бы ..." не имеет тегов Вам нужно смоделировать этот способ в Динамо: PRIMARY-KEY | SORT-KEY | SOURCE DATA | TARGET DATA --------------|-------------|--------------|------------- Post-1 | Post-1 | hello world | Post-2 | Post-2 | foo bar | Post-3 | Post-3 | Whatever... | Tag-1 | Tag-1 | cool | Tag-2 | Tag-2 | awesome | Tag-3 | Tag-3 | great | Post-1 | Tag-1 | hello world | cool Post-2 | Tag-1 | foo bar | cool Post-2 | Tag-3 | foo bar | great Tag-1 | Post-1 | cool | hello world Tag-1 | Post-2 | cool | foo bar Tag-3 | Post-2 | great | foo bar Как вы запрашиваете этот список смежности

1) Вам нужен определенный предмет, скажем, Пост-1 :

Запрос primary-key == "Post-1" & sort-key == "Post-1" - возвращает: только Пост-1

2) Вам нужны все теги, связанные с Пост-2 :

Запрос по primary-key == "Post-2" & sort-key BEGINS_WITH "Tag-" - возвращает: Tag-1 и Tag-3 ассоциаций.

Проверьте документацию о выражении условия ключа begin_with .

3) Вам нужны все сообщения, связанные, скажем, с Tag-1 :

Запрос по primary_key == "Tag-1" & sort-key BEGINS_WITH "Post-" - возвращает: Пост-1 и Пост-2 ассоциаций.

Обратите внимание, что если вы изменяете содержимое данного сообщения, вам также необходимо изменить значение во всех элементах ассоциации.

Вы также можете не хранить содержание записей и тегов в элементах ассоциаций, что экономит место для хранения. Но в этом случае вам понадобятся два запроса в приведенных выше примерах запросов 2 и 3: один для получения ассоциаций, другой для получения данных каждого исходного элемента. Так как запросы обходятся дороже, чем хранение данных, я предпочитаю дублировать хранилище. Но это действительно зависит, если ваше приложение интенсивно для чтения или интенсивно для записи . Если интенсивно для чтения , дублирование контента в ассоциациях дает вам преимущество сокращения запросов на чтение. Если интенсивная запись , отсутствие дублирования содержимого сохраняет запросы на запись для обновления ассоциаций при обновлении исходного элемента.

Надеюсь, это поможет! ;)

0 голосов
/ 27 июня 2018

Я не думаю, что вы что-то упускаете. Идея заключается в том, что идентификатор уникален для типа элемента. Обычно для идентификатора вы генерируете длинный UUID, а не последовательные числа. Другой альтернативой является использование даты и времени, когда вы создали элемент, возможно, с добавленным случайным числом, чтобы избежать коллизий при создании элементов.

Этот ответ, который я ранее предоставил, может немного помочь Шаблон проектирования списка смежности DynamoDB M-M

Не удаляйте ключ сортировки - это не поможет сделать ваши предметы более уникальными.

...