AI 时代的数据检索困境
在大模型和 AI 应用快速迭代的今天，"检索"已经从一个辅助功能演变为核心能力。无论是 RAG（检索增强生成）系统的语义召回，还是电商场景的商品搜索，亦或是日志分析中的全文匹配，对检索能力的需求正呈指数级增长。
然而，传统架构中实现高性能检索的代价并不小。一套典型的业务系统往往是这样的：业务数据写入 MySQL 等关系型数据库，再通过 Canal/Debezium 等 CDC 工具同步到 Elasticsearch 或 OpenSearch 等外部搜索引擎。这条链路涉及多个独立组件的运维------消息队列、同步任务调度、Schema 映射管理------每一个环节都可能成为故障点。
更棘手的问题在于数据一致性。CDC 链路的延迟、消费者端的处理异常、搜索引擎索引的构建耗时，这些因素叠加后，业务侧经常面临"写入成功但搜索不到"的窗口期。对于金融交易、实时推荐等对延迟敏感的场景而言，这不仅是体验问题，更是业务正确性问题。
问题本质：数据链路过长带来的工程复杂度
从技术本质上看，传统方案的核心矛盾在于：事务数据库和搜索引擎是两个完全独立的系统，它们之间需要一个"搬运工"来维持数据同步。
具体而言，这套架构存在以下技术痛点：
**第一，运维成本高。**CDC 组件（如 Canal Server）、消息队列（如 Kafka）、消费者服务各自需要独立部署、监控和扩容，任何一个环节出问题都可能导致数据不一致。
**第二，延迟不可控。**数据从写入到可搜索，经历了 Binlog 解析、消息传输、索引构建等多个阶段，端到端延迟往往在秒级甚至分钟级。
**第三，Schema 演进困难。**业务表结构变更时，需要同步调整 CDC 配置、消息格式和搜索引擎的 Mapping，协调成本极高。
**第四，资源利用率低。**搜索引擎集群需要独立的计算和存储资源，而实际上很多中小规模的搜索场景并不需要一个完整的 Elasticsearch 集群。
PolarSearch：数据库原生的搜索引擎
PolarSearch 是 PolarDB 内置的智能搜索引擎，基于 OpenSearch 内核构建。它并非一个外挂组件，而是作为 PolarDB 集群架构中的一种专用节点类型存在。这意味着搜索节点与数据库读写节点共享同一个存储层，数据的流转完全在集群内部完成，无需任何外部中间件。
从架构上看，PolarSearch 节点独立承载搜索负载，与事务处理节点实现了计算隔离。这保证了搜索请求的高并发不会影响在线事务的延迟和吞吐。
AutoETL：集群内自动数据同步
AutoETL 是 PolarDB 内置的数据同步能力，专门负责将读写节点中的业务数据自动、持续地同步至集群内的 PolarSearch 节点。AutoETL 的核心设计思想是"零运维同步"：用户只需通过一条 SQL 声明同步关系，后续的数据变更捕获、格式转换、索引写入全部由系统自动完成。
两种同步模式
AutoETL 提供了两种同步模式，覆盖从简单到复杂的各类场景。
**搜索视图（Search View）：**适用于简单的表到索引的映射场景。用户通过标准 SQL 语法创建一个搜索视图，系统自动将源表数据同步到 PolarSearch 索引。当源表发生 INSERT、UPDATE、DELETE 时，搜索视图中的数据实时跟随变化。搜索视图的使用体验接近创建一个数据库视图，学习成本低。
**ETL 存储过程（dbms_etl.sync_by_sql）：**适用于需要数据清洗和转换的场景。该模式基于 Flink SQL 语法，允许用户在同步过程中执行字段映射、过滤、聚合等 ETL 操作。例如，将多张业务表 JOIN 后写入一个搜索索引，或者对文本字段做分词预处理后再索引。ETL 存储过程在集群内部的 Flink 引擎上执行，同样无需用户部署任何外部组件。
使用约束
AutoETL 当前支持 PolarDB MySQL 8.0.1 和 8.0.2 特定内核版本的企业版集群，需要开启 Binlog 功能。
• **同步方向：**仅支持从PolarDB MySQL版同步至同一集群内的PolarSearch节点。
• **DDL限制：**对已建立搜索视图/ETL存储过程的源表进行DDL操作时，需遵循特定的规则以避免同步中断。部分不兼容的变更需要重建搜索视图。详情请参见DDL变更规则与实践。
• 数据类型： 暂不支持BIT类型以及GEOMETRY、POINT、LINESTRING、POLYGON、MULTIPOINT、MULTILINESTRING、MULTIPOLYGON、GEOMETRYCOLLECTION等空间数据类型的同步。
• **搜索视图查询限制：**搜索视图目前仅支持定义同步语义，不支持数据查询。数据查询请直接连接PolarSearch节点执行。
典型应用场景
**RAG 检索增强生成：**将业务知识库数据通过 AutoETL 同步到 PolarSearch，结合向量检索能力实现语义级别的文档召回。整个链路在数据库集群内闭环，避免了向量数据库和业务数据库之间的数据同步开销。
**电商商品搜索：**商品信息存储在 PolarDB 中，通过 AutoETL 自动同步到 PolarSearch，利用全文检索和向量检索的混合能力提供"搜索即推荐"的体验。商品信息变更后毫秒级可搜索，无需等待外部同步链路。
**实时日志分析：**应用日志直接写入 PolarDB，AutoETL 自动将其索引到 PolarSearch，开发者无需搭建独立的日志采集和检索系统即可实现高效的日志查询。
技术价值总结
AutoETL 的核心技术价值在于将原本需要多个独立系统协作完成的"存储-同步-检索"链路，内化为数据库集群的一项原生能力。这种架构选择带来的直接收益是：同步延迟从秒级降低到毫秒级，运维复杂度从管理一套分布式同步系统降低到执行一条 SQL，资源成本从独立搜索集群降低到按需添加搜索节点。
对于正在构建 AI 应用的开发者而言， PolarSearch AutoETL提供了一种"开箱即用"的选择------不需要额外引入 Elasticsearch，不需要搭建 CDC 链路，不需要为数据一致性问题头疼。你只需要在 PolarDB 集群中添加 PolarSearch 节点，用一条 SQL 声明同步关系，搜索能力就已经就绪了。
这正是云原生数据库演进的方向：不只是更快的事务处理，而是将更多数据处理能力内聚到数据库内核中，用统一的系统解决分散的问题。