DynamoDB中本地索引和全局索引之间的区别

我对这两个二级索引及其之间的差异感到很好奇。很难想象这是什么样子。而且我认为，这不仅对我有帮助，还将为更多的人提供帮助。

本地二级索引仍然依赖原始哈希键。当您为表提供hash + range时，请将LSI视为hash + range1，hash + range2 .. hash + range6。您还可以查询5个范围属性。同样，只有一个预配置的吞吐量。

全局二级索引定义了一个新范例-每个索引使用不同的哈希/范围键。
这打破了每个表一个哈希键的原始用法。这也是为什么在定义GSI时，您需要为每个索引添加预配置的吞吐量并为其付费的原因。

有关差异的更多详细信息，请参见GSI公告。

这是文档中的正式定义：

全局二级索引 —具有哈希和范围键的索引，该索引可能与表上的索引不同。全局二级索引被认为是“全局”的，因为对索引的查询可以跨所有分区跨越表中的所有数据。

本地二级索引 —具有与表相同的哈希键，但范围键不同的索引。本地二级索引在某种意义上是“本地”，即本地二级索引的每个分区都作用于具有相同哈希键的表分区。

但是，就键定义而言，差异远远超出了可能。在下面找到一些重要因素，这些因素将直接影响维护索引的成本和工作量：

• 吞吐量：

本地二级索引消耗表中的吞吐量。通过本地索引查询记录时，该操作消耗表中的读取容量单位。在具有本地索引的表中执行写操作（创建，更新，删除）时，将有两种写操作，一种是针对表，另一种是针对索引。两种操作都将消耗表中的写入容量单位。

全局二级索引具有其自己的预置吞吐量，当您查询索引时，该操作将消耗索引的读取容量，当您在具有全局索引的表中执行写操作（创建，更新，删除）时，将有两个写操作，一个用于表，另一个用于索引*。

*在定义全球二级索引的预配置吞吐量时，请确保您特别注意以下要求：

为了使表写入成功，该表及其所有全局二级索引的预配置吞吐量设置必须具有足够的写容量以容纳该写操作。否则，将限制对表的写入。

• 管理人员：

只能在创建表时创建本地二级索引，无法将本地二级索引添加到现有表中，而且一旦创建索引便无法删除它。

创建表并将其添加到现有表时，可以创建全局二级索引，也可以删除现有的全局二级索引。

• 读取一致性：

本地二级索引支持最终一致性或强一致性，而全局二级索引仅支持最终一致性。

• 投影：

本地二级索引允许检索未投影到索引的属性（尽管需要额外的成本：性能和消耗的容量单位）。使用全局二级索引，您只能检索投影到索引的属性。

关于为二级索引定义的键的唯一性的特殊考虑：

在本地二级索引中，范围键值对于给定的哈希键值不需要唯一，同样的情况适用于全局二级索引，键值（哈希和范围）不需要唯一。

资料来源：http : //docs.aws.amazon.com/amazondynamodb/latest/developerguide/SecondaryIndexes.html

这些是按索引可能进行的搜索：

• 哈希
• 通过哈希+范围
• 按哈希+本地索引
• 按全球指数
• 按全球指数+范围指数

表的哈希和范围索引： 这些是Amazon AWS SDK早期版本的常规索引。

全局索引和局部索引： 除了表的现有哈希索引和范围索引之外，它们是在表上创建的“附加”索引。 全局索引类似于哈希。范围索引的行为类似于用于表哈希的范围索引。在代码中的实体模型中，必须以这种方式对getter进行注释：

• 对于全局索引：

  @DynamoDBIndexHashKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_USER)
  public String getUser() {
      return user;
  }
  

• 对于与全局索引关联的范围索引：

  @DynamoDBIndexRangeKey(globalSecondaryIndexName = INDEX_GLOBAL_RANGE_US_TS)
  @DynamoDBAttribute(attributeName = PROPERTY_TIMESTAMP)
  public String getTimestamp() {
      return timestamp;
  }
  

此外，如果您通过全局索引读取表，则该表必须是最终读取（不是一致读取）：

queryExpression.setConsistentRead(false);

一种表达方式是：

LSI-允许您在单个哈希键上执行查询，同时使用多个不同的属性来“过滤”或限制查询。

GSI-允许您对表中的多个散列键执行查询，但因此会增加吞吐量。

表类型及其工作方式的详细分类如下：

仅散列

您可能已经知道；哈希键本身必须是唯一的，因为写入已存在的哈希键将覆盖现有数据。

哈希+范围

哈希键+范围键允许您具有多个相同的哈希键，只要它们具有不同的范围键即可。在这种情况下，如果您写入已存在的哈希键，但使用该哈希键尚未使用的Range-Key，则会生成一个新项目，而如果某个项目具有相同的Hash + Range组合已经存在，它将覆盖匹配项。

另一种思考方式是像具有格式的文件。只要文件的格式（范围）不同，就可以在同一文件夹（表）中拥有一个具有相同名称（哈希）的文件。同样，您可以具有相同格式的多个文件，只要它们的名称不同即可。

大规模集成电路

LSI基本与哈希键+范围键相同，并且在创建项目时遵循与它相同的规则，除了您还必须提供LSI的值之外；它们不能为空/空。

说LSI是“ Range-Key 2”并不是完全正确的，因为您不能拥有（使用我的文件和以前的格式类似）名为：file.format.lsi和的文件file.format.lsi2。但是，您可以拥有file.format.lsiand file.format2.lsi或file.format.lsiand file2.format.lsi。

基本上，LSI只是一个“过滤键”，而不是实际的“范围键”。您的基本哈希值和范围值组合必须仍然是唯一的，而LSI值则不必唯一。一种更简单的查看方法可能是将LSI视为文件中的数据。您可以编写代码来查找所有名称为“ PROJECT101”的文件，无论它们是什么fileFormat，然后读取其中的数据以确定应在查询中包括哪些内容，以及忽略哪些内容。基本上，这就是LSI的工作方式（只是没有打开文件来读取其内容的额外开销）。

GSI

对于GSI，实际上是为每个GSI创建另一个表，而无需维护多个单独的表以在它们之间镜像数据。这就是为什么它们需要更多的吞吐量。

因此，对于GSI，您可以指定fileName作为基础哈希键和fileFormat基础范围键。然后，您可以指定一个GSI，其哈希键为fileName2，范围键为fileFormat2。然后，您可以查询fileName或fileName2根据自己的意愿进行查询，这与LSI只能在上进行查询不同fileName。

主要优点是您只需维护一个表，而不是2，并且只要您写入主哈希/范围或GSI哈希/范围，其他表也会自动更新，因此您无法像多表设置那样“忘记”更新其他表。同样，在更新一个表之后，在更新另一个表之前，也不会丢失连接，就像多表设置一样。

此外，GSI可以“重叠”基础哈希/范围组合。因此，如果您想使用fileName和fileFormat作为基本哈希/范围filePriority以及fileName作为GSI 的表格，则可以。

最后，GSI哈希+范围组合不必唯一，而基本哈希+范围组合则必须唯一。对于双/多表设置，这是不可能的，但是对于GSI，这是不可能的。因此，在更新时，您必须同时提供基本AND GSI哈希+范围的值；这些值都不能为空/空。

另一种解释方式：LSI帮助您对具有相同哈希键的项目进行其他查询。GSI可帮助您对“整个桌子”上的商品进行类似的查询。非常有用。

如果您有用户个人资料表：唯一ID，名称，电子邮件。在这里，如果您需要使表可查询名称，电子邮件-那么唯一的方法是使它们成为GSI（LSI不会帮助）

本文档给出了很好的解释：

https://aws.amazon.com/blogs/aws/now-available-global-secondary-indexes-for-amazon-dynamodb/

我无法对此问题发表评论，但是在读写性能方面更好：

（表的读写吞吐量为100的本地索引）或（读/写吞吐量为50的表以及表的读写吞吐量为50？的全局索引）

我的用例不需要单独的分区键，因此本地索引应足以满足所需的功能。

GSI不能用于一致读取。

LSI可以用于一致读取，但是会将主分区大小限制为10GB。LSI也只能在创建表时创建。