DynamoDB M-M邻接列表设计模式 [英] DynamoDB M-M Adjacency List Design Pattern

查看:123
本文介绍了DynamoDB M-M邻接列表设计模式的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

请参阅 https://docs.aws. amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html .我想知道是否有人可以帮助我.

Referring to https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html. I was wondering if anyone could help me.

第一个图像是表格的图像,第二个图像是GSI的图像.表格如下:

The first image is of the table, and the second is the GSI. Here is the table:

在桌子上,我不知道如何创建排序键?这是一个同时存储帐单ID和发票ID的属性吗?或两个单独的属性?我觉得这是一个灵活的属性,如果是的话,您如何区分另一个?以及我们应该如何在排序键上构造查询?

On the table, I don't understand how one is to create the sort-key? Is this one attribute that stores both Bill-ID and Invoice-ID? or two separate attributes? I have a feeling it's the one flexible attribute, and if so how do you differentiate one from the other? And how are we meant to construct the query on the sort-key?

是否只是通过查找前缀"Bill-"或"Invoice-"? DynamoDB的实践似乎利用破折号(-")来分隔属性中的值.如果有人可以给我用这样的事例,我也将不胜感激,但是我会切线,除非在这种情况下很重要.

Is it just by looking the prefix "Bill-" or "Invoice-"? The practice of DynamoDB seems to make use of dashes ("-") to separate values in an attribute. If anyone can give me use cases of such things, I would be grateful as well, but I am going off tangent unless it's important in this case.

现在,这非常相关且非常有趣 https://youtu.be/xV -As-sYKyg?t = 1897 ,演示者使用一个产品表存储各种类型的项目:书籍,歌曲专辑和电影;并且每个都有自己的属性.

Now, this is very relatable and very interesting https://youtu.be/xV-As-sYKyg?t=1897, where the presenter uses ONE product table to store various types of items: Books, Song Albums, and Movies; and each has their own attributes.

同样,我在理解此处使用的排序键时遇到问题.我了解到productID = 1是bookID,而productID = 2是相册.现在,让我感到困惑的是我用红色圆圈圈出的内容.这些是专辑2的曲目.但是,排序键的结构为"albumID:trackID".现在,"trackID"在哪里?是否用实际ID代替"trackID"一词?还是说这是与"albumID:trackID"完全相同的文本?

Again I have a problem understanding the sort-key used there. I understand that productID=1 is bookID, and productID=2 is an Album. Now where it gets confusing now is what I circled in red. These are the tracks of Album 2. However, the structure of the sort key is "albumID:trackID". Now, where is the "trackID"? Is it meant to substitute the word "trackID" with actual ID? or is this meant to be a text exactly as "albumID:trackID"?.

如果我想查询特定的trackID怎么办?我的查询的语法是什么?

What if I wanted to query a specific trackID? what would be the syntax of my query?

请在此处从youtube上查看图片:

Please see the image here from the youtube:

提前谢谢大家!!! :-)

Thank you all in advance!!! :-)

推荐答案

在第一张图中,您将项目发布到了基表(主键)中,如下所示:

In the first picture you posted the items in the base table (primary key) would look like this:

First_id(Partition key)        Second_id(Sort Key)          Dated
-------------                   ----------                  ------
Invoice-92551                   Invoice-92551               2018-02-07
Invoice-92551                   Bill-4224663                2017-12-03
Invoice-92551                   Bill-4224687                2018-01-09
Invoice-92552                   Invoice-92552               2018-03-04
Invoice-92552                   Bill-4224687                2018-01-09
Bill-4224663                    Bill-4224663                2018-12-03
Bill-4224687                    Bill-4224687                2018-01-09

GSI 中的相同项目看起来像这样

And the same items in the GSI the items would look like this

Second_id(Partition Key)       First_id
----------                     ---------------
Invoice-92551                  Invoice-92551 
Bill-4224663                   Invoice-92551 
Bill-4224687                   Invoice-92551 
Invoice-92552                  Invoice-92552
Bill-4224687                   Invoice-92552
Bill-4224663                   Bill-4224663
Bill-4224687                   Bill-4224687 

他们以一种非常混乱的方式绘制了它.

They have drawn it in quite a confusing way.

  • 他们将分区键合并到一个框中,但是它们是单独的项.
  • 他们还试图在同一张图片中显示GSI.您可以将基本表和GSI视为两个独立的表,它们在许多方面都是同步的.
  • 他们实际上并未提供关键属性的名称.在我的示例中,我将它们命名为First_id和Second_id.

在基表上进行查询时,可以使用带有分区键Invoice-92551的查询,同时获得发票"项目和属于该项目的所有票据项目.

When you do a query on the base table, you can use a query with the partition key Invoice-92551 and you get both the Invoice item plus all the bill items that belong to it.

想象一下,您正在应用程序中查看发票Invoice-92551,您会看到它具有两个关联的账单(Bill-4224663Bill-4224687).如果单击该账单,则该应用程序可能会在GSI上进行查询. GSI查询将具有分区键Bill-4224687.如果您看一下我上面绘制的GSI表,您会看到它将返回两个项目,表明Bill-4224687是两个发票(Invoice-92551Invoice-92552)的一部分

Imagine you are viewing invoice Invoice-92551 in an application and you can see it has two associated bills (Bill-4224663 and Bill-4224687). If you clicked on the bill, the application would probably do a query on the GSI. The GSI query would have partition key Bill-4224687. If you look at the GSI table I have drawn above, you can see this will return two items, showing that Bill-4224687 is part of two invoices (Invoice-92551 and Invoice-92552)

在第二张图片中,"bookID"和"albumID"等词应该代表实际的ID(让我们说293847和3340876).

In your second picture, the words 'bookID' and 'albumID' etc are supposed to represent actual IDs (lets say 293847 and 3340876).

我会这样画他的例子:

ProductID(Partition Key) TypeID(Sort Key)  Title          Name      
---------                ------            ------         ------
Album1                   Album1            Dark Side
Album1                   Album1:Track1     Speak to me
Album1                   Album1:Track2     Breathe
Movie8                   Movie8            Idiocracy
Movie8                   Movie8:Actor1                    Luke Wilson
Movie8                   Movie8:Actor2                    Maya Rudolph

这是您的查询:

Partition key: Album1

为您提供专辑1(背面)上的所有信息(inc曲目)

Gives you ALL the information (inc tracks) on Album 1 (Dark Side)

Partition key: Album1 and Sort Key: Album1:Track2

仅向您提供有关呼吸的信息.

Gives you just the information on Breathe.

Partition key: Movie8

为您提供有关Movie8(专制)的所有信息(演员)

Gives you ALL the information (inc actors) on Movie8 (Idiocracy)

如果我要建立表格,我会做到这一点,以便将电影,专辑等单词作为实际ID的一部分(例如Movie018274和Album983745987),但这不是必需的,它只是使ID更具可读性.

If I was building the table I would make it so the words Movie, Album etc were part of the actual ID (say Movie018274 and Album983745987) but that's not required, it just makes the IDs more human readable.

这篇关于DynamoDB M-M邻接列表设计模式的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆