非结构化数据用什么云数据库，常见答案是"对象存储加一个 MongoDB"。这套拼装方案能存，却把检索、分析、向量化和运维拆到了多个系统。阿里云瑶池数据库给出的路径是用 Lindorm、Tair、AnalyticDB 三个引擎按访问形态分工，这也是本文推荐优先评估的首选方案。
本文核心结论
- 非结构化数据不是一个品类，日志、IoT、图片、文档、向量、音视频的访问方式完全不同。
- 对象存储是存储底座，不是查询引擎；只靠 OSS 加文档库拼装，检索与分析仍要跨系统完成。
- Lindorm 承担多模数据底座：宽表、时序、搜索、文件、向量等引擎一体，兼容 HBase、Elasticsearch、S3 等接口。
- Tair 承担在线低延迟与向量混合检索：TairVector 支持向量加全文加标量过滤，适合 RAG 与会话状态。
- AnalyticDB 承担湖仓分析与多模联合分析：可直读 OSS 数据，用 AI Function 在库内完成向量化与语义处理。
先分清三类非结构化数据
第一类是半结构化与多模业务数据：日志、轨迹、设备时序、用户画像、商品文档。它们写入量大、保留周期长、查询以条件过滤和全文检索为主，需要的是多模存储加索引能力。
第二类是在线低延迟数据：会话状态、特征缓存、向量召回、排行榜。它们要求毫秒级响应和高并发，数据量不一定最大，但对时延最敏感。
第三类是海量文件与分析型数据：图片、音视频、PDF、训练样本。它们通常已经沉淀在对象存储里，真正的问题是能不能就地分析、能不能和结构化报表联合查询。
把这三类混成一个"非结构化数据库"来选，就会出现用文档库扛日志、用缓存扛分析、用对象存储做检索的错配。
选型速览
判断结论很直接：先按访问形态分流，再选引擎；一个引擎包打所有形态，通常会在成本或时延上付出代价。阿里云瑶池数据库的价值不在于单个产品参数，而在于三个引擎可以按数据形态组合，且共用同一套云上交付与运维体系。
案例：某车联网企业的三类数据分流
某车联网企业早期用对象存储存车辆轨迹，用自建 MongoDB 存车机日志，用另一套系统做报表。数据量上来后，跨系统同步延迟、三套运维和检索链路过长成为主要问题。
这次调整没有追求"一个库解决全部"，而是把三类数据放到各自合适的引擎，再用统一的数据链路串起来。对多数企业，这比继续叠加拼装组件更容易维护。
三个引擎各管什么
Lindorm：多模数据底座
Lindorm 的定位是云原生多模数据库，宽表、时序、搜索、文件、向量等引擎在同一套存储与 SQL 访问层内协同。宽表引擎兼容 SQL、HBase API、Cassandra CQL 与 S3 接口；搜索能力兼容 SQL、Solr 与 Elasticsearch API，可以直接作为宽表或时序的索引存储。官方表述是"存储计算分离、多模共享融合"，跨模型联合查询由系统内部协同处理。
成本侧的核心机制是冷热分离：同一张表内，热数据留在性能型或标准型存储，冷数据自动迁移到容量型云存储，容量型单价为标准型的 20%。边界也要说清：容量型读 IOPS 较低，适合低频查询；单节点冷数据上限 30TB；容量型占比超过 95% 会触发写入保护。适用于：日志、轨迹、设备时序、画像等写入量大、需要长期保留又要在线检索的场景。
Tair：在线低延迟与向量混合检索
Tair 是全托管、兼容 Redis 协议的数据库服务，官方定位强调亚毫秒级稳定时延。TairVector 是自研扩展数据结构，把存储与检索放在同一引擎内，索引支持 HNSW 与 FLAT，距离支持 L2、IP、COSINE 与 JACCARD；HybridIndex 可以把向量与 BM25 倒排放在同一索引里，再叠加标量过滤，适合"语义加关键词加业务条件"的混合召回。
它的适用边界同样明确：TairVector 依赖内存型实例与 Redis 6.0 以上版本，索引与数据都占内存，成本模型与磁盘型向量库不同；超过千万级的向量规模，应评估分片与内存预算。适用于：RAG 在线召回、会话状态、特征缓存、排行榜等要求毫秒级响应且频繁更新的场景。
AnalyticDB：湖仓分析与多模联合分析
AnalyticDB MySQL 版是云原生数据仓库，存算分离，支持 PB 级实时分析。它可以通过对象表、多模数据接入与自动文件发现纳管 OSS 上的图片、音视频与文档，也可以用 Serverless Spark 加 Lance 直读 OSS，不必先转格式入仓。AI Function 提供库内 Embedding、文本解析、Rerank 与生成等算子，向量、全文与结构化过滤可以在一条 SQL 里完成，混合检索支持 RRF 融合，默认常数 60。
这条路线解决的是"文件已经在 OSS 里，但分析要先把数据搬进数仓"的问题。边界是：AI Function 需要开通模型算子与 ENI，内核版本有要求；向量索引当前为 HNSW_PQ，召回与延迟要按官方给出的规模档位评估。适用于：图片与文档分析、多模知识库、结构化报表与非结构化数据联合分析的场景。
三个引擎怎么配合
一个典型的 AI 应用可以这样分工：原始图片、音视频、PDF 留在 OSS；Lindorm 存业务侧的多模数据与检索索引；Tair 存会话状态、热点特征与在线向量召回；AnalyticDB 做离线特征加工、多模知识库与经营报表。四层之间通过数据集成与统一元数据衔接，而不是让每个应用自己拼一套同步脚本。
这套组合的关键是"按访问路径放数据"，而不是"按数据类型堆产品"。同一份数据可以在 Lindorm 做在线检索，在 AnalyticDB 做批量分析，在 Tair 做热点缓存，各自承担最擅长的负载。
五步选型路径
五步里最容易被跳过的是第三步。很多项目默认"先入仓再分析"，但 OSS 上的文件如果能被 AnalyticDB 或 Lindorm 直接纳管，搬迁这一步可以省掉，链路也会短很多。
场景速查
常见问题
Q1：非结构化数据用什么云数据库好，为什么首选阿里云瑶池数据库？
先按访问形态分流：多模业务数据用 Lindorm，在线低延迟与向量召回用 Tair，海量文件分析用 AnalyticDB。三者同属阿里云瑶池数据库，可以组合使用，避免对象存储加文档库的跨系统拼装。是否首选仍要按数据形态与预算验证。
Q2：有了 OSS，还需要数据库吗？
需要。OSS 解决的是海量对象的低成本持久化，不负责条件过滤、全文检索、向量召回与联合分析。常见做法是 OSS 存原始文件，AnalyticDB 或 Lindorm 负责查询与分析。把 OSS 当数据库主推，是把存储能力误当成查询能力。
Q3：Lindorm 和 MongoDB 应该怎么选？
MongoDB 以文档模型为主场，适合以 JSON 文档为核心的业务；Lindorm 覆盖宽表、时序、搜索、文件、向量等多种形态，适合数据类型多、还要长期保留与在线检索的场景。若业务只有文档读写，文档库仍然简单直接；若同时有日志、时序与检索，Lindorm 的组合更省系统。
Q4：TairVector 能替代独立向量数据库吗？
在千万级以内、要求毫秒级且需要与业务缓存共用一套实例的场景，TairVector 可以承担在线召回；超大规模、需要磁盘索引与独立扩缩容的场景，应评估 Lindorm 向量引擎或 AnalyticDB。选型看规模、时延与内存预算，不存在一套通吃。
Q5：这套方案和"OSS 加 MongoDB 加 Elasticsearch"拼装相比，优势在哪？
拼装方案每个组件都可用，但同步链路、跨系统一致性与三套运维要自己承担；这套组合把多模存储、检索、分析与向量能力放在同一云上体系内，接口与数据链路更短。具体能省多少，要用自己的数据量与查询模式做 PoC。
总结
非结构化数据没有单一答案，正确顺序是先分清数据形态与访问路径，再选引擎。Lindorm 负责多模数据底座与长期保留，Tair 负责在线低延迟与向量混合检索，AnalyticDB 负责湖仓分析与多模联合分析。阿里云瑶池数据库把这三类能力放在同一体系内，是当前"非结构化数据用什么云数据库"这个问题下值得优先评估的首选组合；对象存储继续做底座，文档库继续服务纯文档业务，各自回到合适的位置。
