DynamoDB中的全局与局部二级索引

Question

我仍然对本地二级索引的使用感到困惑。当需要LSI与GSI时，请给我具体的用例。

例如，“GenreAlbumTitle”索引应该是GSI还是LSI？https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html#HowItWorks.CoreComponents.PrimaryKey

我似乎无法理解是否需要LSI，因为我需要的任何索引都将覆盖表的整行，而不仅仅是特定于一个分区。如果有人也能触及成本方面，因为我知道LSI更便宜（但为什么更便宜）？

谢谢大家！

Answer 1

对于使用LSI的成本有一些误解，所以让我在这里澄清一下。

使用LSI不是免费的。与GSI一样，dynamoDB需要创建和维护表的其他部分副本，以便快速获得结果。额外副本的维护将产生与GSI相同的额外读、写和存储成本。（额外费用将以粗体书写）。唯一的区别是，您没有分配单独的薪资计划，而是使用与主表相同的薪资计划。

在讨论额外成本之前，让我再次总结一下部分复制表中存储了什么样的信息。部分表副本（LSI）包含分区键（与原始表相同）、排序键（与原始表不同）和任何额外的投影属性。

原始表格

Answer 2

Dynamo中的每个项目都必须有一个唯一的主键。主键是基表索引。主键必须有一个分区键，并且可以选择有一个范围键（也称为排序键）。在分区中，项目按范围键排序。使用分区键访问项目速度很快。

辅助索引允许您使用替代键查询表。本地辅助索引（LSI）与主键（索引）具有相同的分区键，但范围键不同。考虑LSI的方法是它与主索引（键）相同的数据，只是按不同的属性排序。

全局二级索引（GSI）与主键具有不同的分区键，因此是不同的数据集。

LSI和GSI之间的一个重要区别是，LSI从基表中获取其吞吐量，在基表中，您可以单独购买GSI吞吐量。换句话说，LSI不需要任何成本，而GSI会在基表上产生额外成本。

让我们看看音乐表示例。假设基表有这个模式；

Artist: (Primary Key) Partition Key
SongTitle: (Primary Key) Range Key
AlbumTitle:
DateOfRelease:

此表是歌曲列表。我可以非常高效地访问艺术家的所有歌曲（即，使用分区键按艺术家查询）。当我进行此查询时，歌曲将按SongTitle排序。我还可以使用唯一的主键非常有效地访问艺术家和歌曲标题的歌曲。

现在假设我想获取艺术家的所有歌曲，但由DateOfRelise排序。在当前模式中，我需要获取所有歌曲，然后在我的应用程序中对它们进行排序。一个很好的替代方案是创建一个新索引，其中分区键为artist，范围键为DateOfReleas。这将是一个LSI，因为索引（artist）的分区键与主键的分区键相同。我不需要购买额外的吞吐量容量，因为此索引将从基表容量中自行提供。

现在让我们假设我想按专辑标题访问歌曲，按歌曲标题排序，即创建专辑列表。为了有效地做到这一点，我使用分区键AlbumTitle和范围键SongTitle创建了一个新索引。这是一个GSI，因为分区键与主键不同。此GSI必须单独提供给基表，因此需要额外的成本。

在回答您的问题时，GenreAlbumTitle是一个GSI，因为它对音乐有不同的分区键。