DynamoDB如何实现含嵌套map列表的多字段关键词搜索

DynamoDB原生查询能力对嵌套结构、多字段模糊匹配的支持有明确边界，以下是可直接落地的实现路径，覆盖从小规模测试到生产级场景：

小规模场景方案（数据量<10W行） #

首先明确一个容易踩的官方规则：contains函数无法直接匹配List类型字段里嵌套Map的单个属性，直接写contains(Columns.Column_Name, 关键词)不会生效，因为Columns是Map对象的数组，不是纯字符串数组。
要实现需求需要做两步冗余设计，再配合带过滤条件的Scan操作：

• 新增冗余平铺字段Searchable_Column_Names（类型为String数组/字符串集合），每次写入、更新记录时，把Columns数组下所有Column_Name的值抽出来，统一转小写后存入这个字段。比如示例数据里的orderId就直接存为数组项。
• 对其他需要搜索的顶层字符串字段（PK、SK、Custom_Table_Description、Default_Table_Description），同样存一份统一转全小写的冗余副本，解决DynamoDB字符串匹配大小写敏感、不支持过滤表达式内运行大小写转换函数的问题。

之后直接写带过滤条件的Scan即可，参考SDK v3的代码示例：

const { DynamoDBClient, ScanCommand } = require("@aws-sdk/client-dynamodb");
const { marshall, unmarshall } = require("@aws-sdk/util-dynamodb");
const ddbClient = new DynamoDBClient({ region: "你的服务区域" });

async function keywordSearch(keyword) {
  const searchTerm = keyword.trim().toLowerCase();
  const commandParams = {
    TableName: "你的业务表名",
    FilterExpression: `
      contains(PK_LC, :term) OR
      contains(SK_LC, :term) OR
      contains(Searchable_Column_Names, :term) OR
      contains(CustomDesc_LC, :term) OR
      contains(DefaultDesc_LC, :term)
    `,
    ExpressionAttributeValues: marshall({
      ":term": searchTerm
    }),
    ProjectionExpression: "PK, SK, Custom_Table_Description, Default_Table_Description, Columns"
  };

  // 注意：单次Scan最多返回1MB数据，结果集较大时需要循环读取LastEvaluatedKey实现分页
  const resp = await ddbClient.send(new ScanCommand(commandParams));
  return resp.Items.map(i => unmarshall(i));
}

注意：该方案依赖全表Scan，会消耗大量读容量单位，数据量超过10万行后延迟、成本都会快速上升，仅适合内部工具、小规模业务使用，不要直接上核心生产链路。

生产级方案（中大规模数据） #

如果表数据量超过10万行，不要硬用Scan操作，直接走「DynamoDB + 全文检索引擎」的架构：

• 开启DynamoDB Stream，将表的所有增删改操作实时同步到OpenSearch（原Elasticsearch）等全文检索服务
• 同步过程中把Columns数组内的Column_Name、其他所有待搜索字段平铺为可检索的文本字段，配置分词规则、大小写不敏感匹配规则，建好索引
• 用户发起搜索时直接请求检索服务拿到匹配结果的主键，按需回查DynamoDB获取完整记录即可

这个方案的优势很明显：

• 支持分词、模糊匹配、权重排序等复杂搜索能力，性能不会随数据量上涨明显下降
• 搜索请求不占用DynamoDB的读容量，不会影响线上正常业务的读写
• 后续新增搜索字段只需要调整索引配置，不需要修改DynamoDB表结构

常见避坑点 #

• 不要尝试直接用contains(Columns, 关键词)匹配嵌套Map：该语法只有当传入值和数组内某一个完整Map对象完全一致时才会命中，无法匹配Map内的单个属性
• 不要在大表上跑无索引的全表Scan：除了成本高、延迟大，还容易触发读容量限流拖垮正常业务
• 不要图省事把整个Columns数组序列化成JSON字符串做模糊匹配：这种方式会把Column_ID、Custom_Column_Desc等不需要搜索的字段也纳入匹配范围，很容易出现误命中。

内容的提问来源于stack exchange，提问作者robo98