Amazon dynamodb 如何开始使用DynamoDB

我读了《亚马逊入门指南》，但还是花了很长时间陷入了多重陷阱，抓挠着脑袋。

---

让我的Dynamo DB项目沿着正确的道路前进，这样我就不会遇到性能或成本问题的最佳方法是什么？

您需要做的第一件事是清除您对关系数据库的所有了解。在设计关系数据库时，首先从数据模型开始，然后添加索引以支持针对该模型进行的查询。在DynamoDB中，情况正好相反，您必须首先考虑要进行的查询，然后构造表以使这些查询高效。在DynamoDB中，您还需要保存数据的多个副本以提高查询效率，因此整个方法完全不同

用这个概念填满你头脑中刚刚形成的空间。假设您的DynamoDB数据库有数万亿项（行）分布在数千台服务器上。每台服务器包含数百万个项目，并且每个项目只存在于一台服务器上。每次查询DynamoDB时，它只会将请求发送到其中一个服务器，因此服务器必须包含必须返回以满足查询的所有数据。慢慢地再读一遍，想想这对如何组织数据意味着什么

请注意，这是一个很有用的模型，可以放在您的头脑中，但实际上，DynamoDB保留项目的副本以确保可靠性

这意味着，如果要按姓氏返回人员，则具有相同姓氏的所有人员必须存储在同一服务器上。如果还希望按出生年份返回人员，则具有相同出生年份的所有人员必须存储在同一服务器上。要同时满足这两个条件，必须存储两个数据副本

由于每个查询的结果必须来自一台服务器，因此必须根据查询方式将数据存储在服务器上。告诉DynamoDB这个信息的方法是在每个表上设置分区键。分区键是项目属性的名称，用于确定项目将存储在哪个服务器上。查询表时，必须传递分区键中要查找的值，以便DynamoDB知道将查询发送到哪个服务器

例如，如果您创建一个以姓氏作为分区键的人员表，那么所有姓氏相同的人员都将存储在同一台服务器上。这意味着每次查询此表时，必须选择与姓氏完全匹配的项（以便结果集中的所有项都来自同一服务器），因此对该表的查询只能返回姓氏相同的人

如果分区键不是唯一的，则必须指定另一个属性（排序键），该属性在与分区键组合时产生唯一值。在这种情况下，每台服务器将存储按排序键排序的项目，在该属性上选择的查询将高效且廉价。要继续使用person表示例，因为姓氏不是唯一的，所以需要表的排序键，并且在与姓氏组合时必须是唯一的-例如，可以使用政府发布的ID或GUID

请注意，不可能存储分区键和排序键具有相同值的两个项目，添加第二个项目时，它将覆盖第一个项目

起初，这似乎很有限制，但请容忍我，我们还没有完成

总而言之，查询表时，查询执行分为三个阶段

必须在分区键属性上指定精确匹配。这用于确定哪个服务器包含数据。 只有一台服务器处理该请求。数据按分区键和排序键的顺序物理存储在该服务器上，因此可以使用索引高效地找到匹配的记录。您的查询不必完全匹配排序键，您可以使用小于、大于等。 如果您的查询选择了其他属性，这是DynamoDB中的一个过滤器，它将应用于步骤2中选择的所有项目。请注意，所有这些项目必须从备份存储读取，您将为此收取费用。 我在线阅读了一些建议，您可以通过为每个项目添加一个包含相同值的属性，并将该属性设置为分区键，从而使DynamoDB更加灵活，但请考虑在这种情况下会发生什么。首先，由于所有项都具有相同的分区键值，因此它们都存储在一台服务器上（请记住，DynamoDB是为在数千台服务器上分布数十亿项而设计的，这就是它的扩展方式）。其次，任何不包含排序键的查询都需要进行完整的表扫描，该扫描将从备份存储中读取所有这些数十亿项，即使只有少数项与查询匹配，并且您需要为从存储中读取的每个项收费，而不是为返回到应用程序的项收费

请注意，DynamoDB还有一个扫描功能，它向所有服务器发送请求，并将结果整理成一个巨大的resultset。这仅适用于导出所有数据等特殊情况，不应在常规应用程序编程中使用

许多应用程序需要以多种方式查询数据，而不会降低效率。DynamoDB为此提供了两种二级索引

本地二级索引与关系数据库上的索引相似，因为它们提供了一种基于特定属性查找项的有效方法，但它们与关系数据库不同，因为每个服务器只对存储在该服务器上的项进行索引。这意味着您必须先选择与基础表的分区键匹配的项（以选择正确的服务器），然后再匹配辅助索引。这意味着，如果person表上的分区键是姓氏，则查询所有l