DynamoDB 高频面试题及详细答案（实战向）

DynamoDB高频面试题及详细答案（实战向）一、基础概念类面试题1.简单介绍下DynamoDB，它是什么类型的数据库？核心定位是什么？DynamoDB是AWS提供的一款完全托管的键值&文档型NoSQL数据库，属于分布式非关系型数据库。它的核心定位是低延迟、高可用、无限扩容，专门用于应对高并发、海量数据、毫秒级读写响应的业务场景。不同于MySQL这类关系型数据库，DynamoDB不支持复杂联表查询、事务能力轻量化，舍弃了部分复杂查询能力，换取极致的读写性能和横向扩容能力，全程无需手动运维服务器、磁盘、集群，所有底层运维由平台托管。2.DynamoDB的核心特性有哪些？结合工程使用，核心特性主要有以下几点：毫秒级低延迟：无论数据量多大，读写请求基本维持在个位数毫秒级，性能稳定不衰减。无限横向扩容：吞吐量和存储容量可按需动态扩容，无硬性上限，适配业务流量暴涨场景。高可用高容错：数据自动跨多可用区冗余存储，默认三副本，单节点、单可用区故障不会影响业务读写。完全托管：无需部署、升级、备份、运维集群，自动完成补丁更新、故障迁移、数据备份。按需计费&预置容量：支持两种吞吐模式，适配稳定业务和突发流量业务。支持键值和文档存储：可存储简单键值对，也可直接存储JSON格式文档，支持嵌套属性查询。3.DynamoDB与传统关系型数据库（MySQL）的核心区别？核心差异集中在架构、能力、适用场景三个维度：架构层面：MySQL是集中式关系型数据库，依赖主从架构，扩容成本高、上限低；DynamoDB是分布式架构，天然分片，横向扩容无压力。查询能力：MySQL支持复杂SQL、联表、子查询、聚合、完整事务；DynamoDB无SQL，仅支持主键、索引精准查询和范围查询，不支持联表，事务仅支持单表有限事务。性能表现：MySQL数据量千万级以上性能明显下降；DynamoDB海量数据下性能始终稳定，无性能衰减问题。运维成本：MySQL需要手动运维服务器、备份、容灾、扩容；DynamoDB零运维，全托管。适用场景：MySQL适合复杂业务、事务要求高、查询灵活的场景；DynamoDB适合高并发、简单读写、低延迟要求的场景，比如用户信息、订单缓存、日志存储、IoT设备数据等。二、核心架构与数据模型面试题4.讲解DynamoDB的核心数据模型：表、主键、分区键、排序键DynamoDB最小数据单元是Item（条目），对应关系型数据库的行；每个Item由多个Attribute（属性）组成，对应字段；所有Item存储在Table（表）中。主键是表的核心，分为两种类型：简单主键（仅分区键）：表只设置PartitionKey（分区键），每条数据的分区键必须唯一。相同分区键只能存在一条数据，适用于一对一数据场景，比如用户ID对应用户信息。复合主键（分区键+排序键）：由PartitionKey+SortKey组成联合主键。分区键用于数据分片，排序键用于同一分区内数据排序。同一分区键下可以存在多条不同排序键的数据，适用于一对多场景，比如一个用户的多条订单、多条消息记录。核心规则：分区键决定数据存储的分片位置，排序键决定同分片内的数据有序性。5.什么是DynamoDB分片机制？分区键如何影响数据分布？DynamoDB底层会将大表自动拆分为多个物理分片（Partition），每个分片独立承担读写吞吐量和存储压力，是实现分布式扩容的核心。所有数据根据分区键的哈希值均匀分配到不同物理分片。系统会对分区键做哈希计算，根据哈希结果将数据路由到对应分片。如果分区键选择合理，数据会均匀分布在所有分片，读写压力分散，性能最优；如果分区键取值单一、集中，会导致所有数据落在同一个分片，形成分片热点，吞吐量被单分片上限限制，出现性能瓶颈。6.DynamoDB支持哪些数据类型？常用的有哪些？DynamoDB数据类型分为标量类型、集合类型、文档类型，日常开发高频使用的类型如下：标量类型：字符串、数字、布尔、二进制、空值，是最常用的基础类型。集合类型：字符串集合、数字集合、二进制集合，适合存储多值字段，比如标签列表、权限列表。文档类型：List（列表）、Map（对象），支持嵌套存储，可直接存储复杂JSON结构，无需拆表，适配复杂业务数据。区别于传统数据库，DynamoDB字段无需提前定义类型，每条数据可以拥有不同的字段，结构灵活可变。三、索引相关高频面试题7.DynamoDB有哪两种索引？主索引和二级索引的区别？DynamoDB索引分为主索引和二级索引（GSI/LSI），主索引随表创建，不可删除，二级索引可动态创建、修改、删除。主索引：就是表的主键（分区键/复合主键），所有数据默认基于主索引存储，读写性能最高，查询零开销，数据与主索引一一对应。全局二级索引GSI：跨所有分片的索引，拥有独立的分区键和排序键，独立的吞吐量配额。GSI的数据是主表数据的冗余副本，支持独立查询，无分区绑定限制，是开发中最常用的索引。本地二级索引LSI：依附主表分区键的索引，必须和主表共用同一个分区键，仅排序键不同。只能在同分区内做索引查询，无法跨分区，且创建后无法修改，日常使用极少。8.GSI全局二级索引的使用注意事项和优缺点？优点：解决主索引查询维度单一的问题，支持多维度条件查询。拥有独立读写吞吐量，不会占用主表吞吐，互不影响。支持动态创建和删除，业务迭代灵活。缺点与注意事项：GSI是冗余数据，主表数据新增、修改、删除时，会同步更新所有GSI，会消耗额外写入吞吐，索引越多，写入开销越大。GSI不支持强一致性查询，只能最终一致性读取。GSI字段不能为空，如果主表对应字段为空，该条数据不会同步到GSI，会导致查询缺失数据。单表GSI数量有限制，默认最多创建20个，不适合无限建索引。四、读写模式与一致性面试题9.DynamoDB两种吞吐模式：预置容量和按需容量的区别、适用场景预置容量模式（Provisioned）需要手动预设读吞吐量、写吞吐量数值，系统按照预设值分配分片资源，流量平稳时性能最稳定、成本最低。缺点是突发流量超过预设值会触发限流，请求报错。适合流量稳定、可预估的核心业务，比如日常用户查询、固定频次的订单读写。按需容量模式（On-Demand）无需预设吞吐，系统自动适配流量，流量暴涨暴跌都不会限流，按实际读写次数计费。缺点是单位计费成本更高。适合流量突发、不可预估、低频波动大的业务，比如营销活动、秒杀、临时日志存储、新业务上线初期。10.DynamoDB强一致性读取和最终一致性读取的区别？DynamoDB数据多副本存储，读写一致性分为两种：最终一致性读取（默认）：读取时优先访问就近副本，速度更快、消耗读吞吐更少。数据写入后，副本同步存在极短延迟，刚写入的数据可能暂时查询不到，短暂时间后数据最终一致。绝大多数查询业务默认使用该模式。强一致性读取：读取时强制访问主分片最新数据，确保读取到的数据是已提交的最新数据，无延迟、无数据不一致问题。但会消耗更多读吞吐，延迟略高，且仅支持主索引查询，不支持二级索引。适用于资金、库存等对数据实时性要求极高的场景。11.讲解DynamoDB读写吞吐量RCU、WCU的计算规则RCU（读容量单元）、WCU（写容量单元）是DynamoDB吞吐的计费和限流基础单位：RCU读单元：最终一致性读取，1个RCU支持每秒读取4KB数据；强一致性读取双倍消耗RCU。超过4KB的条目按向上取整计算，比如5KB数据读取需要2个RCU。WCU写单元：1个WCU支持每秒写入1KB数据，无强弱一致性区分，所有写入统一计算，超过1KB向上取整。批量读写会合并计算总数据量，再换算对应单元，超大条目会大幅消耗吞吐，日常设计需控制单条目数据大小。五、热点问题与性能优化面试题12.什么是DynamoDB热点分区？热点问题产生的原因和解决方案热点分区定义：大量读写请求集中落在同一个物理分片，导致单分片吞吐打满、触发限流、接口超时，而其他分片空闲，整体表吞吐量无法扩容。产生核心原因：分区键设计不合理，数据分布不均。常见场景：按时间戳当分区键、固定用户ID、固定设备ID作为分区键，导致大量请求集中在单个分片。解决方案：优化分区键设计，选择离散度高、均匀分布的字段，比如用户ID、设备唯一ID。对时间类业务，采用分区键加盐的方式，将热点数据打散到多个分片。避免高频读写数据共用同一个分区键。冷热数据分离，将高频热点数据单独建表存储。13.DynamoDB日常性能优化的核心手段有哪些？合理设计主键和索引：优先使用主索引查询，减少GSI查询；控制GSI数量，减少写入冗余开销；杜绝热点分区。控制单条目大小：单条数据越小，RCU/WCU消耗越低，读写速度越快，避免存储大文本、大嵌套数据。合理选择吞吐模式：稳定业务用预置容量降低成本，突发流量业务用按需容量避免限流。批量操作优化：使用批量写入、批量查询接口，减少网络请求次数，提升吞吐效率。查询条件优化：尽量精准查询，避免大范围扫描；必须扫描时使用分页、限制返回条数。一致性模式选择：非核心业务全部使用最终一致性读取，降低开销、提升速度。六、实战场景与踩坑面试题14.DynamoDB为什么不适合做复杂查询？实际业务中如何规避？DynamoDB底层是KV分布式存储，设计初衷是极致读写性能，不支持SQL语法、联表查询、模糊查询、复杂聚合、子查询。大范围扫描查询性能极差，会消耗大量吞吐，极易触发限流。业务规避方案：业务层做数据冗余、宽表设计，用空间换查询能力，避免联表。通过GSI预定义查询维度，所有查询走索引精准查询。复杂统计、聚合、报表类需求，通过DynamoDB数据同步到ES、数仓、MySQL处理。15.DynamoDB数据扫描（Scan）和查询（Query）的区别？生产环境为什么禁止随意使用Scan？Query查询：基于分区键精准匹配，配合排序键范围过滤，只扫描指定分区数据，开销小、速度快，是规范的查询方式。Scan扫描：遍历表中所有分片、所有数据，再过滤符合条件的数据，数据量越大，开销越高。生产禁止随意使用Scan的原因：海量数据下Scan会消耗巨量RCU，直接打满表读吞吐，导致正常业务查询限流报错。扫描耗时极长，接口超时严重，完全无法满足业务低延迟要求。无业务价值，属于低效查询，是线上常见性能事故诱因。16.讲讲DynamoDB宽表设计思路，适配一对多业务场景DynamoDB不支持联表，一对多业务必须用宽表设计，核心思路是：一张表承载所有关联数据，通过分区键+排序键区分不同业务数据，避免多表关联。以用户订单场景为例：分区键：用户ID（保证同一用户所有数据落在同一分区）排序键：订单ID/时间戳（区分该用户的多条订单记录）通过复合主键，直接实现一个用户下所有订单的精准查询，无需分用户表、订单表，完全适配NoSQL的分布式查询逻辑，性能远优于多表设计。七、高阶运维与容灾面试题17.DynamoDB的备份与容灾机制是什么？DynamoDB天然具备高容灾能力，底层数据跨多可用区三副本存储，单节点、单可用区故障自动切换，业务无感知。备份分为两种：自动持续备份：默认开启，支持任意时间点恢复，可回溯最近35天数据，应对误删、误改数据问题。手动快照备份：可手动创建永久快照，用于长期数据归档、跨环境数据迁移。18