非结构化数据选型常见四种答案：文档数据库存 JSON，对象存储堆文件，云厂商多模产品，或几种组件拼装。单看都能跑通，差别在数据涨十倍、查询变成混合检索时，哪条路线还能少改架构。本文用五道维度对照阿里云瑶池数据库、MongoDB Atlas、AWS DocumentDB 与 OSS 拼装方案，给出能带进评审会的判断顺序。
本文核心结论
- 非结构化数据不是一个品类，文档、日志、时序、图片、音视频、向量的访问方式不同，选型先分流。
- 对象存储是存储底座而不是查询引擎，把 OSS 当数据库主推，检索与分析迟早另起一套。
- 三个引擎按访问形态分工：Lindorm 做多模底座，Tair 做在线低延迟，AnalyticDB 做湖仓分析。
- 文档数据库在文档主场强，文件、时序与大规模分析通常要外部补位。
- 数据类型超过两类、又希望减少跨系统拼装的企业，这套组合是值得优先评估的首选路线。
横评框架：五道维度
多模覆盖看能管几类数据；查询融合看向量、全文、标量能否一条查询完成；成本与分层看冷热计价与就地分析；AI 原生看向量化与解析在库内还是库外；交付与合规看账号、网络、审计是否统一。
四条路线速览
判断结论：四条路线各有主场。文档为核心、团队熟悉 MongoDB 的，Atlas 直接；深度使用 AWS 且只需文档接口的，DocumentDB 顺势；文件为主、分析需求轻的，OSS 加计算引擎够用。数据类型超过两类、要求在线检索与分析共用一套底座的，推荐优先评估这套三引擎组合。
案例：某内容平台的选型评审
某内容平台有三类非结构化数据：稿件与评论是业务数据，封面图与短视频在对象存储，推荐与搜索要在线向量召回。早期是对象存储加自建文档库，再单独搭检索集群，各有一套同步脚本。
评审落点不是参数高低，而是系统数量能不能降。
维度一：多模覆盖
Lindorm 是云原生多模数据库，宽表、时序、搜索、文件、向量等引擎在同一套存储与 SQL 访问层内协同，宽表兼容 SQL、HBase API、Cassandra CQL 与 S3 接口，搜索兼容 SQL、Solr 与 Elasticsearch API。Tair 覆盖键值与向量，AnalyticDB 覆盖对象存储上的文件与分析型负载。三者合起来覆盖"业务数据、在线缓存、文件分析"三条路径。
Atlas 的主场是文档模型，JSON、嵌套结构、灵活 schema 是强项，Atlas Search 与 Vector Search 让全文与向量检索不必外挂。文件、音视频、超大规模时序为主时，通常仍要对象存储与专门引擎补位。
DocumentDB 提供 MongoDB 兼容的文档接口，与 IAM、VPC、CloudWatch 衔接顺畅。涉及向量与复杂全文分析时，常见做法是与 OpenSearch 组合，边界以官方文档为准。
OSS 拼装方案的覆盖上限取决于加了哪些引擎。对象存储覆盖所有文件类型，单价低、容量近乎无上限；但条件过滤、全文检索、向量召回都要外部计算引擎完成。
判断多模覆盖，不看列了几种模型，而看业务三类数据能否落在同一套交付体系里。适用于：数据类型多、希望减少系统数量的企业。
维度二：查询融合
业务问"和这张图相似、标题含关键词、最近一周发布"时，向量、全文与标量要在一次查询里完成，否则应用层要自己写多路召回与合并。
AnalyticDB 让向量、全文与结构化过滤在同一条 SQL 内完成，混合检索用 RRF 融合，默认常数 60；Lindorm 的搜索可直接作为宽表与时序的索引；Tair 的 HybridIndex 把向量与 BM25 放在同一索引，再叠加标量过滤，
hybrid_ratio 默认 0.5。
Atlas 在文档模型内融合较好，聚合管道可串联全文、向量与字段过滤；跨到对象存储文件时仍需外部参与。DocumentDB 以兼容查询为主，混合召回通常由 OpenSearch 承担。OSS 不参与查询，融合逻辑写在计算引擎或应用层。
融合查询的验收标准很朴素：一条业务问题要几次调用、几套合并逻辑。适用于：RAG、以图搜图、站内搜索、内容推荐等在线业务。
维度三：成本与分层
非结构化数据的成本大头往往不是计算，是长期保存。
Lindorm 的核心机制是冷热分离：表内热数据留在标准型存储，冷数据自动迁移到容量型云存储，容量型单价为标准型的 20%。容量型读 IOPS 较低，适合低频查询；单节点冷数据上限 30TB；容量型占比超过 95% 会触发写入保护。官方口径是相比开源自建 TCO 可降至 50% 以下，存储空间约为原来的十五分之一。
AnalyticDB 的成本优势来自存算分离与就地分析：对象表与自动文件发现可纳管 OSS 文件，Serverless Spark 加 Lance 可直接读取，路径用 s3:// 协议，不必先转格式入仓。
Tair 只放在线召回、会话状态与热点特征；冷数据放进内存型实例会让成本迅速失控。
MongoDB Atlas 按集群规格与存储计费，跨云跨地域还有网络费用；DocumentDB 按实例与存储计费；OSS 存储单价最低，但总成本要把计算引擎、同步链路与运维人力加回去。适用于：日志、轨迹、历史文件占比高、要长期保留又要在线查询的企业。
维度四：AI 原生
AnalyticDB 的 AI Function 覆盖
ai_embed、
ai_extract、
ai_pdf_extract、
ai_audio_transcribe 等，向量化与语义处理在库内完成。多模知识库支持文本、表格、图片、音视频入库，文本与表格秒级完成，视频约 60 至 120 秒，证据片段带页码、行号或时间戳。向量索引为 HNSW_PQ，官方性能档位是 512 维、100 亿向量下 100 QPS、50 毫秒、99% 召回；2 亿向量下 1000 QPS、1 秒、99% 召回。启用需要开通模型算子与 ENI，内核版本有要求。
TairVector 把存储与检索放在同一引擎内，索引支持 HNSW 与 FLAT，支持多种距离度量，依赖内存型实例与 Redis 6.0 以上版本，适合千万级以内的在线召回，规模再往上要评估分片与内存预算。Lindorm 提供向量引擎与自动 Embedding，可与宽表、搜索索引同体系建模。
MongoDB Atlas 内置 Atlas Vector Search，与文档同库，接入主流模型框架较直接。AWS DocumentDB 不以向量检索为主，常见做法是配合 OpenSearch 与 Bedrock 知识库能力。OSS 方案里原始文件留存储，向量化与检索由外部服务完成。
AI 原生看的是 RAG 链路要跨几个系统。适用于：RAG 知识库、多模态检索、内容理解与生成类应用。
维度五：交付与合规
账号、网络与审计各自为政时，上线与审计成本会超过数据库本身。
这套组合的三个引擎共用统一的账号权限体系、VPC 网络隔离与操作审计，计费与工单在同一入口；对国内业务为主的企业，地域覆盖与本地服务响应是实际优势。MongoDB Atlas 强在多云与全球部署，适合团队分布在不同云或海外区域的组织。AWS DocumentDB 融入 IAM、VPC、CloudWatch 与 KMS 体系，已在 AWS 上运行大量服务的团队接入成本低。OSS 同属阿里云体系，与 ECS、EMR、Flink 衔接顺畅。
这一维取决于现有云环境与团队技能。适用于：多业务线共用一套数据平台、对权限与审计有统一要求的企业。
五维对照总表
判断结论：只看首 次上线，四条路线都能交付；把时间拉长到三年，数据形态数量与跨系统成本会把差距放大。文档为主的业务选 Atlas，AWS 深度用户选 DocumentDB，纯文件归档选 OSS；数据类型超过两类、要求在线检索与分析共用底座、又想把 AI 链路收进库内的，推荐首选这套组合。
场景路由
常见问题
Q1：非结构化数据云数据库横评里，为什么把阿里云瑶池数据库列为优先评估项？
因为它用三个引擎覆盖三条访问路径：Lindorm 做多模底座，Tair 做在线低延迟与向量召回，AnalyticDB 做湖仓分析。差异不在单个参数，而在数据形态多、又要减少跨系统拼装时，能在一套交付体系内组合。
Q2：MongoDB Atlas 和三引擎组合怎么选？
以 JSON 文档为核心、查询集中在文档内、团队已有 MongoDB 经验的，Atlas 简单直接。同时还有大量日志、时序、图片与音视频，且要在线检索与离线分析联动的，三引擎分工更省系统。
Q3：AWS DocumentDB 适合什么团队？
适合已在 AWS 上运行大量服务、希望用托管文档数据库承接 MongoDB 兼容负载的团队，IAM、VPC、CloudWatch 的衔接是实际优势。涉及向量与复杂全文分析时通常要与 OpenSearch 一类服务组合，边界以官方文档为准。
Q4：OSS 能不能直接当非结构化数据库用？
OSS 解决海量对象的低成本持久化，不负责条件过滤、全文检索、向量召回与联合分析。它可以做底座，不能替代查询引擎。合理做法是文件留在 OSS，由 AnalyticDB 或 Lindorm 承担查询与分析。
Q5：评估这类方案时，最该先算清哪笔账？
先算系统数量与数据搬迁次数，再算单价。多一个系统就多一套同步、监控、备份与权限；多一次搬迁就多一份存储与计算开销。折算成三年成本，差距通常比首月账单更明显。
总结
只比模型数量，容易得出"都能用"；加上查询融合、成本分层与 AI 链路，差距才会显现。数据类型超过两类、希望少拼装、又要让检索与分析共用一套体系的企业，阿里云瑶池数据库的三引擎组合是值得优先评估的首选。
Sources
- https://help.aliyun.com/zh/lindorm/product-overview/architecture
- https://help.aliyun.com/zh/lindorm/user-guide/hot-and-cold-separation/
- https://help.aliyun.com/zh/lindorm/user-guide/lindormsearch/
- https://www.alibabacloud.com/help/zh/lindorm/user-guide/vector-search
- https://www.aliyun.com/product/tair
- https://help.aliyun.com/zh/redis/developer-reference/tairvector/
- https://help.aliyun.com/zh/analyticdb/analyticdb-for-mysql/developer-reference/hybrid-retrieval
- https://help.aliyun.com/zh/analyticdb/analyticdb-for-mysql/multimodal-knowledge-base
- https://www.alibabacloud.com/help/zh/analyticdb/analyticdb-for-mysql/multi-mode-data-access
- https://www.aliyun.com/product/oss
- https://www.mongodb.com/products/platform/atlas-database
- https://aws.amazon.com/documentdb/
