Amazon DynamoDB 常见问题

DynamoDB 是无服务器、完全托管的分布式 NoSQL 数据库服务，在任何规模下均具有个位数毫秒级的性能。DynamoDB 无需管理基础设施，支持零停机时间维护，可根据应用需求即时扩展，并采用按请求计费模式。不存在冷启动、版本升级和维护窗口。DynamoDB 为全托管服务，省去了备份、安全、合规、监控等繁杂且无差异化的数据库管理任务。对于全球分布式应用，DynamoDB 全局表是一个多区域、多活动数据库，可用性高达 99.999%，具备极强的数据库韧性。它支持多区域强一致性，确保应用始终可用，且从任意区域读取的数据都保持一致，从而使您能够构建零 RPO 应用程序。DynamoDB 内置广泛的安全控制和合规标准，可满足政府、跨国银行及其他高敏感型组织的要求。

使用 DynamoDB，客户可以将运行和扩展分布式数据库的管理工作负担交给 AWS，因而无需担心硬件预置、设置和配置、吞吐能力规划、复制、软件修补或集群扩展等问题。您可在短短几分钟内部署分布式 NoSQL 数据库。DynamoDB 可自动扩展吞吐能力以满足工作负载需求，并随着您的表大小的增长对数据进行分区和再分区。此外，DynamoDB 还可在一个 AWS 区域的三个可用区（AZ）之间同步复制数据，为您提供高可用性和数据持久性。

DynamoDB 的独特优势包括，它是一个经过验证的完全托管、可缩减到零的无服务器数据库，可提供个位数毫秒的性能和高达 99.999% 的可用性。凭借其稳定的大规模性能，DynamoDB 还为要求严苛的全球应用程序提供所需的内置安全性、持久性和可靠性。由于具有易用性，DynamoDB 经常用于新的数据驱动和生成式人工智能应用程序和成熟的互联网规模应用程序，这些应用程序寻求稳定的快速性能和无限的可扩展性。

DynamoDB 表类是 DynamoDB 表的性能和成本优化选项。可用的两个表类是 DynamoDB Standard（此默认表类为需要最大性能的工作负载而设计，最适合具有不可预测工作负载的表）和 DynamoDB Standard-Infrequent Access（此表类针对以存储为主要成本的表进行了优化，也是存储不经常访问数据的表的理想表类）。Standard 表的读写成本较低，但存储成本较高。Standard-IA 表的存储成本较低，但读写成本较高。您可以在 30 天内在这些表类之间切换两次，无需停机，从而可以根据表的使用模式优化成本。这些类之间的选择取决于应用程序的特定需求和数据的访问模式。

在 DynamoDB 中选择表类时，需要考虑多个因素。最常需要考虑的是数据的访问模式、成本考虑因素和工作负载可预测性。您无需进行任何编码或停机即可在表类之间切换，因此，如果需求随着时间的推移而发生变化，您可以调整选择。

DynamoDB 标准 – IA（不频繁访问）表可与现有 DynamoDB 功能无缝协作。它们使用与常规 DynamoDB 表相同的 API，因此您无需更改代码即可将它们用于现有应用程序。它们支持将全局表用于多区域复制、时间点故障恢复（PITR）、按需备份、使用 AWS Key Management Service（KMS）进行静态加密、DynamoDB Streams、Time To Live 以自动删除项目以及交易读写操作。标准 – IA 表与 DynamoDB Accelerator（DAX）兼容。

Amazon DynamoDB 将数据存储在分区中。分区是指为表分配的存储空间，由固态硬盘（SSD）支持，并自动复制到 AWS 区域内的多个可用区。分区管理完全由 DynamoDB 执行，您无需自己管理分区。

可以存储在 DynamoDB 表中的项目的最大大小为 400 KB。没有预定义的存储限制。

可以，DynamoDB 可以存储 BLOB；但是，它通常不适合存储文档或图像。更好的架构模式是将指向 Amazon S3 对象的指针存储在 DynamoDB 表中。

默认情况下，存储在 Amazon DynamoDB 表中的数据没有设置过期时间或删除时间。除非客户明确删除数据，或者在启用 Time to Live（TTL）的情况下通过 TTL 执行了删除，否则数据将无限期保留在表中。

对可以存储在 DynamoDB 表中的项目数量没有预定义的限制。DynamoDB 能够扩展到容纳数百 TB 甚至更多的数据，并且可以支持任意数量的项目。

虽然在技术上可以将图像作为二进制数据（base64 编码）存储在 DynamoDB 中，但由于项目大小限制为 400KB，因此存在一些限制和缺点。与其将图像直接存储在 DynamoDB 中，更好的做法是将图像存储在 Amazon S3（Simple Storage Service）中，然后将 S3 对象 URL 或对象键存储在 DynamoDB 中。

要在 DynamoDB 中存储列表，您需要使用 DynamoDB 的列表数据类型之一，即列表或集合。向表中写入项目时，该属性的值可以是数组或标量（非对象）数据类型（如字符串、数字等）的集合。DynamoDB 将自动序列化列表数据，并存储这些数据同时维护列表结构。然后，您可以查询表属性来检索完整列表。在列表中添加、更新或删除元素的方式与常规写入操作相同。

可以，DynamoDB 支持将映射存储为属性数据类型。 

是的，DynamoDB 支持 IAM 权限。IAM 权限可以在基于身份的策略、基于资源的策略或其他 AWS 策略中定义，以控制对 DynamoDB 资源的访问。您可以将 IAM 策略附加到 IAM 用户、组、角色以及 DynamoDB 表和流，并根据需要对其进行控制。

借助 AWS PrivateLink，您可以使用接口 VPC 端点和私有 IP 地址来简化虚拟私有云（VPC）、DynamoDB 和本地数据中心之间的私有网络连接。使用 PrivateLink，可以通过私有连接访问 DynamoDB 表，并且请求不会离开亚马逊网络。这增强了安全性，因为流量确实会流经任何网络网关，并且可以使用 IAM 策略和安全组来控制访问权限。PrivateLink 对于具有数据安全要求且需要低延迟的应用程序很有用。它还使您可以从跨本地网络和 AWS 的混合环境访问 DynamoDB 表。

是的，DynamoDB 支持基于资源的表和流策略。每个表的基于资源的策略还涵盖表索引（全局二级索引和本地二级索引）的访问权限。通过基于资源的策略，客户可以为 DynamoDB 表和其他资源定义精细的访问权限，而无需在 AWS 账户级别授予完全访问权限。这些策略允许客户控制哪些用户、角色和联合用户可以对特定 DynamoDB 表、索引和流执行读取、写入或删除等操作。基于资源的策略在每个 DynamoDB 资源内附加和管理。

基于资源的策略支持与 AWS Identity and Access Management（IAM）Access Analyzer 和屏蔽公共访问权限（BPA）的集成。IAM Access Analyzer 可帮助客户细化权限并遵守最低权限。BPA 可帮助客户防止公众访问 DynamoDB 表、索引和流，并始终在 DynamoDB 中启用。。
 

DynamoDB 支持基于属性的访问控制，通常可用于 DynamoDB 表和索引。

可以，您可以使用使用 VPC 端点的 Amazon DynamoDB。DynamoDB 支持两种类型的 VPC 端点：网关终端节点和使用 AWS PrivateLink。使用网关端点，您可以从您的 VPC 访问 DynamoDB，而无需为 VPC 使用互联网网关或 NAT 设备。但是，网关端点不允许从本地网络、其他 AWS 区域中的对等 VPC 或通过中转网关进行访问。对于这些场景，您必须使用 AWS PrivateLink，但需要额外付费。

精细访问控制（FGAC）让 DynamoDB 表所有者通过 AWS Identity and Access Management（IAM）策略和条件对表中的数据进行精细控制。FGAC 允许所有者提供对表中项目或属性的访问权限以及相关操作。精细访问控制与 AWS IAM 配合使用，后者可管理安全凭证及相关的权限。

是的，Amazon DynamoDB 中的所有用户数据在传输中和静态时均完全加密。

HTTPS 协议用于通过使用安全套接字层加密来保护网络流量。

DynamoDB 静态加密使用在 AWS Key Management Service（AWS KMS）中存储的加密密钥。静态数据使用 AES-256 进行加密，这是在需要最高安全级别时所采用的黄金标准。

以下密钥类型可用于加密静态数据：
1.AWS 拥有的密钥：这些密钥完全由 AWS 管理，如果未指定其他选项，则默认使用。它们可以免费使用，无需额外设置。
2.AWS 托管式密钥：这些是存储在 AWS Key Management Service（KMS）中的客户主密钥（CMK），由 AWS 代表客户创建、管理和使用。与 AWS 拥有的密钥相比，它们提供了额外的控制和审计功能。
3.客户托管密钥：这些是您在 AWS KMS 中创建、拥有和管理的 CMK。它们对加密密钥提供最高级别的控制，包括创建、轮换、禁用和定义访问控制的功能。

每种密钥类型在便利性、控制和成本之间都提供了不同的平衡。AWS 拥有的密钥最容易使用，而客户管理的密钥提供了最大的控制权，但需要更多的管理开销。

静态加密通过在包含敏感信息的文件处于非活动状态时对其进行加密，从而帮助保护数据。当数据静态加密时，未经授权的各方即使能够获得对存储数据的设备的物理访问权限，也无法访问纯文本内容。除了访问控制之外，这还为数据提供了额外一层安全性，并且即使物理设备丢失或被盗，也有助于确保机密信息的私密性。

是的，DynamoDB 确实支持对表上的项目级别更改进行审计日志记录。DynamoDB 与 AWS CloudTrail 服务集成，后者提供用户、角色或 DynamoDB 中的 AWS 服务在项目级别所执行操作的记录。捕获的其他日志记录数据包括创建、更新、删除和任何条件检查失败。客户可以访问存储在 CloudWatch Logs 中的这些日志记录，并构建应用程序来分析项目级别的变化，以用于审计、监控或其他目的。审计日志记录可在不影响 DynamoDB 表的正常读取/写入性能的情况下精细地呈现数据的变化。

可以，您可以依照与 AWS 签署的业务合作协议（BAA），使用 Amazon DynamoDB 构建符合 HIPAA 要求的应用程序，并存储医疗保健相关信息，包括受保护的健康信息。

DynamoDB 通过了许多合规认证，包括符合 HIPAA 资格、FedRAMP、ISO 27001、SOC 1/SSAE 16/ISAE 3402（前身为 SAS 70）和 SOC 2。有关更多信息，请参阅 DynamoDB 的行业合规性验证。您可在 AWS Artifact 中下载 AWS Artifact。

Amazon DynamoDB 全局表是一个完全托管、无服务器、多区域和多活动的数据库。全局表提供 99.999% 的可用性、更高的应用程序弹性和经过改进的业务连续性。它会在您选择的 AWS 区域中自动复制您的 DynamoDB 表，使您可以实现快速的本地读写性能。全局表使用与单区域 DynamoDB 表相同的 API，因此您无需更改应用程序即可轻松地使 DynamoDB 表全局可用。

全局表是一个或多个副本表的集合，全部由单个 AWS 账户所有。单个 Amazon DynamoDB 全局表在每个 AWS 区域只能有一个副本表。

您应该使用全局表来提高应用程序在多个区域的弹性。全局表还使应用程序能够保持高度可用，即使在偶尔发生整个区域被隔离或降级的情况下也是如此。

有两种版本的 DynamoDB 全局表：版本 2019.11.21（当前）和版本 2017.11.29（旧版）。客户应对所有新的全局表使用版本 2019.11.21（当前），因为此版本效率更高，消耗的写入容量更少。使用版本 2017.11.29（旧版）的任何人都应将其全局表升级到版本 2019.11.21（当前）。

在 AWS 管理控制台中，只需单击几下鼠标，即可升级全局表的版本。从版本 2017.11.29（旧版）升级到版本 2019.11.21（当前）是一次性操作，无法撤消。在升级之前，请确保您已经查看版本之间的行为差异，并已执行所有必要的测试。有关更多信息，请参阅将全局表从版本 2017.11.29（旧版）升级到版本 2019.11.21（当前）。

DynamoDB 全局表使用跨区域的多活动复制，其中全局表中所有区域的所有副本表都支持读写流量。全局表没有主区域，因此在将读写流量定向到其他区域时不需要进行数据库故障转移。一旦发生 AWS 区域被隔离或降级，您的应用程序只需从未受影响区域的副本表中读取和写入即可。有关更多信息，请参阅 DynamoDB 全局表设计的最佳实践。

副本表是单个 DynamoDB 表。每个副本表存储相同的数据项集，具有相同的表名和相同的主键架构。当应用程序将数据写入一个区域中的副本表时，DynamoDB 会将写入操作自动复制到其他 AWS 区域中的其他副本表。

是的，DynamoDB 全局表可增强业务连续性，因为它提高了应用程序的弹性并为单个区域提供强一致性。借助多区域强一致性，您可以构建具备零 RPO 和最高弹性等级的应用程序。

您可以按照这份分步指南，使用 DynamoDB 控制台、AWS CLI 或 AWS CloudFormation 创建全局表。

在向 DynamoDB 全局表添加其他区域的副本之前，该表必须满足以下条件：已启用 DynamoDB Streams；与所有其他副本同名；具有与所有其他副本相同的分区键；并且具有相同的写入容量设置。

DynamoDB 全局表中的所有副本表必须具有相同的名称。

与其他数据库类似，DynamoDB 也将数据存储在表中。表是项目的集合，每个项目都是属性的集合。DynamoDB 使用主键来唯一标识表中的每个项目，并具有二级索引，可提供更大的查询灵活性。

是的，您可以在 DynamoDB 全局表的每个副本上启用时间点恢复。

是的，DynamoDB 支持变更数据捕获（CDC），这是使用流模型实现的，让应用程序可以通过数据记录流的形式近乎实时地捕获 DynamoDB 表中的项目级变化。借助数据记录 CDC 流，应用程序能够高效地处理和响应 DynamoDB 表中的数据修改。DynamoDB 为 CDC 提供两种流模型：DynamoDB Streams 和 Kinesis Data Streams for DynamoDB。为了帮助您为应用程序选择正确的解决方案，请参阅变更数据捕获的流式处理选项。

DynamoDB 流是有关 DynamoDB 表中项目更改的有序信息流。DynamoDB Streams 可在表中捕获去除重复项、按时间排序的项目级修改序列，并将这类信息存储在日志中长达 24 个小时。DynamoDB Streams 会自动扩展容量，从而将您从资源调配和容量管理中解放出来。 根据您的 DynamoDB Streams 配置，您可以查看数据项在修改前后的显示情况。您可以构建使用这些流事件的应用程序，并根据事件流的内容调用工作流程。

当您想使用与 AWS Lambda 的原生集成通过触发器响应数据变化、跟踪和分析客户互动或近乎实时地监控应用程序性能、捕获有序的事件序列以及通过复制项目级交易数据提高应用程序弹性时，DynamoDB Streams 非常有用。

Kinesis Data Streams 捕获任何 DynamoDB 表中的项目级修改，并将其复制到 Kinesis 数据流。您的应用程序可以访问此流并近乎实时地查看项目级别的变更。借助 Kinesis Data Streams，您可以构建用于处理或分析流数据的自定义应用程序，以满足特定需求。与 DynamoDB Streams 不同，Kinesis Data Streams for DynamoDB 不提供记录排序或重复数据删除保证。记录排序和重复数据删除必须由客户端应用程序在项目级记录中使用 ApproximateCreationDateTime 字段来实现。

如果您需要与更广泛的 Kinesis 功能（例如 Kinesis 客户端库、适用于 Apache Flink 的亚马逊托管服务或 Amazon Data Firehose）进行集成，想要延长数据留存期和可重播性（长达 365 天），并且为下游消费和流分析执行定制分片管理，则 Kinesis Data Streams for DynamoDB 非常有用。

在 DynamoDB 表上启用 DynamoDB 流或 Kinesis 数据流时，该表会发出一份数据记录，用于捕获该表数据的任何更改。此数据记录包括最近创建、更新或删除任何项目的具体时间、该项目的主键、修改前的项目图像以及修改后的项目图像

您可以使用 AWS 管理控制台、AWS SDK、AWS 命令行界面（AWS CLI）或 Kinesis 客户端库（KCL）在现有 DynamoDB 表上启用或禁用流。

当您特别需要跟踪 DynamoDB 表的更改时，请选择 DynamoDB Streams。在需要更广泛的流式传输、需要更高的吞吐量或需要更长的数据留存期时，选择 Kinesis Data Streams。

Amazon DynamoDB 生存时间（TTL）功能会自动从表中删除不再相关的过期项目，从而减少存储使用量并降低成本。使用 TTL，您可以定义每个项目的时间戳以确定何时不再需要某个项目，DynamoDB 会自动从您的表中删除该项目，而不会消耗任何写入吞吐量。每次创建或更新项目时，您都可以计算过期时间并将其保存在 TTL 属性中。如果您存储的项目在特定时间后失去相关性，TTL 会很有用。

DynamoDB 支持使用用户定义的主键来执行 GET/PUT 操作。对于表中的项目，主键是唯一所需要的属性。您在创建表时指定主键，它是标识每个项目的唯一标识符。DynamoDB 还提供灵活的查询功能，让您可以使用全局二级索引和本地二级索引查询非主键属性。

主键可以是单属性的分区键或复合的分区-排序键。例如，单属性的分区键可以是 UserID。通过这样的单属性分区键，可以对与特定用户 ID 相关联的项目快速读取和写入数据。

DynamoDB 将复合的分区-排序键作为一个分区键元素和一个排序键元素进行索引。这个多部分键可保持第一个元素值和第二个元素值之间的层次结构。例如，复合的分区-排序键可以由 UserID（分区）和 Timestamp（排序）组成。通过保持分区键元素的恒定，您可以在排序键元素中进行搜索以检索项目。利用这种搜索，您就可以使用 Query API 进行检索，例如在一系列时间戳中检索单个 UserID 的所有项目。

DynamoDB 支持由全局二级索引（GSI）中最多八个属性组成的主键，分区键和排序键各有最多四个属性。

使用 DynamoDB 控制台或 CreateTable API 创建表之后，您可以使用 PutItem 或 BatchWriteItem API 来插入项目。然后，您可以使用 GetItem、BatchGetItem 或 Query API（如果复合主键已启用且正在表中使用）来检索您添加到表中的项目。

是的。DynamoDB 是一项完全托管的云服务，可以通过 API 使用。在任何操作系统（例如，Linux、Windows、iOS、Android、Solaris、AIX 和 HP-UX）上运行的应用程序都可以使用 DynamoDB。我们建议借助 AWS SDK 开始使用 DynamoDB。

DynamoDB 与 OpenSearch Service 的零 ETL 集成简化了将数据从事务性数据存储复制到搜索数据存储的操作复杂性。构建和管理用于保持事务性数据存储和搜索数据存储同步的数据管道可能棘手且成本高昂，并且会出现难以跟踪的间歇性错误。 

此集成使 DynamoDB 客户能够通过提供完全托管的解决方案，从其事务性数据中获得近乎实时的搜索结果，确保事务性数据从 DynamoDB 写入后，在几秒钟内就能在 OpenSearch Service 中使用。客户只需选择包含他们想要使用 OpenSearch Service 分析的数据的 DynamoDB 表，此零 ETL 集成即可使用 OpenSearch Ingestion 管道将相应的架构和数据无缝复制到 OpenSearch Service 中。客户可以将多个 DynamoDB 表中的数据复制到单个 OpenSearch Service 托管域或无服务器集合中，实现对多个应用程序的全面洞察，同时还可以整合核心分析资产，实现显著的成本节省和运营效率提升。 

客户可以使用 DynamoDB 的 AWS 管理控制台、OpenSearch Service、AWS CLI、AWS SDK 或 AWS CloudFormation 开始使用。要启用集成，客户首先要选择需要复制数据的 DynamoDB 表。然后，客户可选择 DynamoDB Streams 进行近乎实时的复制，或选择 DynamoDB 增量导出进行延迟复制，并将两者作为 CDC 机制，使两个系统之间的数据保持同步。 

此零 ETL 集成会在客户账户中设置 OpenSearch Ingestion 管道，该管道负责将数据复制到 OpenSearch Service 托管集群或无服务器集合。OpenSearch Ingestion 理解 DynamoDB 表的结构，然后创建等效的 OpenSearch Service 托管域或无服务器集合，并使用来自 DynamoDB 表的现有数据启动目标系统。或者，客户可以为将在 OpenSearch Service 中创建的索引指定架构。 

这种零 ETL 集成为您提供了一个控制面板，您可以在其中使用 Amazon CloudWatch 实时指标和日志监控端到端集成的状态。您可以设置警报，以防违反用户定义的阈值。此集成还会持续监控 DynamoDB 表和 OpenSearch Service 索引的状态，并在其中任何一个实体出现回归时立即通知用户。

为确保 OpenSearch Ingestion 拥有在这两个系统间复制数据的必要权限，DynamoDB 与 OpenSearch Service 的零 ETL 集成会创建一个 IAM 角色，该角色具有从 DynamoDB 表中读取数据并写入 OpenSearch 域或集合所需的权限。然后，OpenSearch Ingestion 管道将代入此角色，以确保在将数据从源移至目标时始终保持正确的安全状态。

这种零 ETL 集成使用 OpenSearch Ingestion 管道的原生数据转换功能，对动态数据进行聚合和筛选。从 DynamoDB 表中移动数据时，客户可能希望删除一些字段或根据现有字段的聚合创建新字段。 

客户还可以选择为 OpenSearch Ingestion 编写自定义逻辑，以实现定制的转换功能。对于其他只想将全部数据从源移至目标位置的用户，这种零 ETL 集成将提供开箱即用的 OpenSearch Ingestion 蓝图，这样他们只需单击几下按钮即可执行集成。

这种零 ETL 集成为客户提供了指定其自定义数据架构及索引映射的选项，此自定义数据架构供 OpenSearch Ingestion 在将数据从 DynamoDB 写入 OpenSearch Service 时使用。这种体验已添加到 DynamoDB 的用户界面控制台中，因此客户可以完全控制在 OpenSearch Service 上创建的索引的格式。

除了需要为现有底层组件支付费用外，使用 DynamoDB 与 OpenSearch Service 的零 ETL 集成不会产生任何额外费用。这种零 ETL 集成使用 OpenSearch Ingestion 来读取 DynamoDB 表中的数据并复制到 OpenSearch Service。使用 DynamoDB 与 OpenSearch Service 的零 ETL 集成所需支付的费用是 OpenSearch Ingestion 跨系统复制数据所需的 OpenSearch 计算单位（OCU）的费用。此外，客户可以选择 DynamoDB Streams 或增量导出作为 CDC 的选项。对于增量导出，会产生与向 S3 桶写入数据关联的费用。对于 DynamoDB Streams，将向客户收取使用 DynamoDB Streams 的标准费用。

在目前推出 OpenSearch Ingestion 的所有区域，均可使用 DynamoDB 与 OpenSearch Service 的零 ETL 集成。

是的，您可以为自己的 Amazon DynamoDB 使用购买数据库节省计划，当您承诺在 1 年期限内保持稳定的使用量时，成本最多可降低 18%。 有关符合条件的使用情况的更多信息，请参见数据库节省计划定价页面。

是的，DynamoDB 提供慷慨的免费套餐，该套餐具有 25GB 的存储空间以及 25 个预置写入容量单位和 25 个预置读取容量单位（WCU、RCU），足以处理每月 2 亿个请求。

DynamoDB 是完全无服务器的非关系数据库。与其他按存储等各种指标收费的数据库相比，DynamoDB 可以缩减到零，这意味着当客户使用按需模式时，他们只需为消耗的活跃资源付费。

简而言之，按需容量更适合那些更愿意只为实际用量付费或工作负载不可预测的客户。对于那些应用程序流量一致或可预测，并且更愿意预测容量需求以控制成本的客户，预置容量更受青睐。

DynamoDB 的独特之处在于，它是一个无服务器数据库，客户可以选择仅为所使用的资源付费，在不使用时可通过按需定价缩减到零。在使用数据库时，使用写入请求单位和读取请求单位来计算费用。

DynamoDB 包含一组可以添加到服务中的选项。部分清单包括：

• 按需备份，在指定时间点进行快照备份
• 用于多区域、多活动复制的全局表
• DynamoDB Accelerator（DAX），一项与 Amazon DynamoDB 兼容的缓存服务，通过内存缓存减少延迟
• DynamoDB 流，用于对表进行按时间排序的项目级更改序列