AWS Keyspaces中实现LIKE与ILIKE查询的最优轻量架构方案问询

完全无需引入OpenSearch、Postgres等额外数据库服务，仅靠AWS Keyspaces原生能力即可实现轻量模糊查询支持，规避全表扫描内存过滤的性能问题，也没有双写多数据源的运维复杂度。

前缀模糊匹配场景（LIKE 'xxx%'，占绝大多数业务模糊查询需求） #

这一特性完全可以通过Keyspaces原生的聚簇列排序能力实现，性能与主键查询一致：

• 表结构设计时，将需要做模糊查询的字段设置为聚簇列，利用聚簇列按序存储的特性，用范围查询等效替代前缀LIKE
• 示例表结构：

CREATE TABLE user_info (
    region text,
    username text,
    uid uuid,
    ext_info text,
    PRIMARY KEY (region, username)
) WITH CLUSTERING ORDER BY (username ASC);

• 要实现username LIKE '李%'的查询，直接执行以下范围查询即可：

SELECT * FROM user_info WHERE region = 'cn-north-1' AND username >= '李' AND username < '李' || char(1048575);

• 这里的char(1048575)为Unicode编码的最大字符，可覆盖所有以指定前缀开头的字符串，等效于前缀LIKE查询。
• 若需要不区分大小写的ILIKE查询，写入时额外存一份该字段全小写/全大写的冗余字段，查询时将输入参数转为对应大小写即可，额外存储成本几乎可以忽略。

任意位置模糊匹配场景（LIKE '%xxx%'） #

如果必须支持中后缀模糊查询，仅需新增一张轻量索引表，无需引入额外服务：

• 写入主表时，对需要模糊查询的字段做N-Gram分词预计算，将拆分后的分词作为分区键、主表主键作为值写入索引表
• 以2-Gram分词为例，商品名称“无线蓝牙耳机”会被拆分为["无线", "线蓝", "蓝牙", "牙耳", "耳机"]，每个分词对应一条索引表数据
• 示例索引表结构：

CREATE TABLE product_name_idx (
    gram text,
    product_id uuid,
    product_name text,
    PRIMARY KEY (gram, product_id)
);

• 查询时先将输入关键词拆为对应长度的N-Gram，查询索引表拿到匹配的主键集合，再到主表拉取完整数据即可，性能为毫秒级，无需全表扫描。
• 也可以直接使用Keyspaces原生的物化视图能力自动同步主表数据到索引表，无需改造业务双写逻辑，运维成本为0。

如果确实需要支持复杂全文检索、多字段组合模糊查询等极端场景，最低运维成本的替代方案是开启Keyspaces增量CDC，通过AWS Lambda自动同步到OpenSearch Serverless，无需自己运维集群，按调用量付费，相比自建独立数据库的方案轻量很多。

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