Apache Doris 4.1：向量搜索、JSON存储、OLAP及湖仓架构

Apache Doris 4.1延续了4.0版本的路线，该版本为项目引入了向量搜索、混合搜索以及search()函数，使其能够服务于AI智能体、RAG系统、AI可观测性工具以及实时分析功能。4.1版本仍沿此方向发展，旨在让同一个引擎同时处理AI和搜索工作负载的存储与检索任务。发布说明重点阐述了团队在将AI应用投入生产时面临的问题：

• 如何以合理成本存储大量AI数据，
• 如何将向量搜索、全文搜索和结构化过滤器整合到同一系统中，
• 如何将长文档及复杂的半结构化记录存储在单个表中，
• 如何为大型语言模型、智能体及RAG系统处理实时查询与可观测性相关问题，
• 如何保持该项目一贯的OLAP和湖仓计算速度，

将大规模批量 ETL 与实时处理管道相结合。

主要改进包括：

• 向量搜索：推出了针对数十亿级及更大规模数据集的新 IVF 和 IVF_ON_DISK 索引。
• 全文搜索：search()功能现在支持 BM25 评分机制以及与 Elasticsearch 兼容的语法。
• 长上下文存储：单个 JSON 文档的大小可达 100 MB，适用于智能体内存及处理长上下文任务。
• OLAP 性能：在 TPC-H 测试中性能提升超过 22.6% 的 4.0 倍，在 TPC-DS 中提升 19.1%，在 SSB 中提升 14.3%，同时在 ClickBench 的冷查询测试中排名第一。
• 数据湖功能：支持 Apache Iceberg V2/V3 的读写操作，可通过 SQL 对 Apache Paimon 执行 DDL 操作，此外还提供了可提升约 20% 效率的 Parquet 页面缓存机制。
• 计算与存储分离：该项目称该模式已在2000多家企业中使用，具有更好的缓存可见性、弹性以及冷查询处理能力。

以下所有性能数据均来自该项目的官方公告，因此应将其视为供应商提供的数值，并结合自身数据进行验证。

1. AI与搜索

向量搜索

IVF被集成到HNSW中。4.0版本将HNSW作为其向量索引。4.1版本则增加了IVF（倒排文件）机制，以处理更大的数据集。其思路是预先将向量分组到不同的桶中，然后仅查询最有可能包含邻近向量的桶，从而以略低的精度换取显著的速度提升。与HNSW相比，IVF能在更少的内存占用下处理更大的数据集，但召回率会稍低一些。你可以通过在索引属性中设置"index_type"="ivf"来启用该功能：

CREATE TABLE sift_1M (
  id int NOT NULL,
  embedding array<float>  NOT NULL  COMMENT "",
  INDEX ann_index (embedding) USING ANN PROPERTIES(
      "index_type"="ivf",
      "metric_type"="l2_distance",
      "dim"="128",
      "nlist"="1024"
  )
) ENGINE=OLAP
DUPLICATE KEY(id) COMMENT "OLAP"
DISTRIBUTED BY HASH(id) BUCKETS 1
PROPERTIES (
  "replication_num" = "1"
);

IVF_ON_DISK。像Faiss这样的库由于将整个索引存储在RAM中，因此能够处理数千万个向量。但当向量数量达到数百亿时，内存消耗会急剧上升。Doris在IVF的基础上开发了IVF_ON_DISK，采用了微软SPANN研究中的方法，通过结合内存缓存与本地文件系统缓存来高效且低成本地筛选向量。

• 由于实现了计算与存储的分离，它能够在极大规模下实现低成本、快速的向量筛选与检索。
• 相比DiskANN，其索引构建成本要低得多，为实现万亿级规模的搜索提供了可行的方案。
• 该技术很可能被应用于人工智能知识库、推荐系统检索以及大型嵌入向量存储等领域。

切换到该模式几乎与使用IVF相同，只需设置"index_type"="ivf_on_disk"即可：

CREATE TABLE for_ivf_on_disk (
  id BIGINT NOT NULL,
  embedding ARRAY<FLOAT> NOT NULL,
  INDEX idx_emb (embedding) USING ANN PROPERTIES (
    "index_type"="ivf_on_disk",
      "metric_type"="l2_distance",
      "dim"="128",
      "nlist"="1024"
  )
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 8
PROPERTIES ("replication_num" = "1");

量化。除索引算法外，还支持三种量化方法：INT8标量、INT4标量以及乘积量化（PQ）。通过这种方式，在略微牺牲召回率的前提下，可将索引大小压缩到原有内存的1/4至1/8；再结合IVF_ON_DISK技术，还能进一步降低大型检索系统的硬件成本。下方的DDL展示了对128维向量的PQ压缩效果：

CREATE TABLE product_quant (
  id BIGINT NOT NULL,
  embedding ARRAY<FLOAT> NOT NULL,
  INDEX idx_emb (embedding) USING ANN PROPERTIES (
    "index_type"="ivf_on_disk",
      "metric_type"="l2_distance",
      "dim"="128",
      "nlist"="1024",
      "quantizer"="pq",
      "pq_m"=64,
      "pq_nbits"=8
  )
) ENGINE=OLAP
DUPLICATE KEY(id)
DISTRIBUTED BY HASH(id) BUCKETS 8
PROPERTIES ("replication_num" = "1");

更快的查询速度。新的“仅索引扫描”优化功能让向量查询可以跳过对原始列的磁盘读写操作，从而大幅降低开销。该项目称向量索引查询的速度比4.0版本快多达四倍。在16核、64GB的机器上对一百万个向量进行测试时，Doris据说能达到约900次每秒的查询量，并保持97%的召回率，足以满足大多数实际应用中的检索需求。

公告还引用了VectorDBBench的公开测试数据（截至2026年1月），显示Doris构建向量索引的速度优于Milvus、Qdrant和pgvector，这要归功于其数据分层架构。在4.1版本中，向量在构建过程中会在内存中分批处理，索引也以批次方式生成，这样既提升了构建效率，又不会影响索引质量。

search()函数

向量搜索用于处理语义检索，而全文搜索则负责关键词查找、故障排查、日志搜索及文本分析。新的 search() 函数将其引入 SQL，使得单个查询即可同时完成过滤和聚合操作。

• 它支持 Elasticsearch 的 query_string 语法，有助于简化从 Elasticsearch 迁移的过程。
• 运算符包括 TERM、PHRASE、WILDCARD、REGEXP、PREFIX、NOT 和 NESTED，这些运算符均可嵌套并组合使用。
• 内置 BM25 相关性评分机制，并在存储层进行 TopN 优化，从而无需传输整个结果集。
• 结合 VARIANT 类型，NESTED 可以查询嵌套在 JSON 数组中的数据。

多字段搜索支持best_fields（在单个字段内进行精确匹配）和cross_fields（在多个字段间进行匹配）。

典型的查询格式如下：

-- Multi-condition: TERM + PHRASE + NOT evaluated in a single pass
SELECT request_id, error_msg, latency_ms
FROM inference_logs
WHERE search('
  level:ERROR
  AND error_msg:"CUDA out of memory"
  AND NOT module:healthcheck
  AND model_name:gpt*
')
  AND log_time > NOW() - INTERVAL 1 HOUR
ORDER BY latency_ms DESC LIMIT 100;
​
-- BM25 relevance scoring
SELECT request_id, error_msg, score() AS relevance
FROM inference_logs
WHERE search('error_msg:"memory allocation failed" OR error_msg:"CUDA error"')
ORDER BY relevance DESC LIMIT 20;
​
-- Nested search: query inside a VARIANT array
SELECT * FROM agent_logs
WHERE search('NESTED(steps, status:error AND tool:code_exec)');
​
-- search + aggregation: filter and analyze in one query
SELECT model_name, COUNT(*) AS error_count,
       PERCENTILE_APPROX(latency_ms, 0.99) AS p99_latency
FROM inference_logs
WHERE search('level:ERROR AND error_msg:"CUDA out of memory"')
  AND log_time > NOW() - INTERVAL 1 HOUR
GROUP BY model_name ORDER BY error_count DESC;

search() 返回一个布尔值谓词，因此它可以用于连接操作、窗口函数和子查询中，这使得全文搜索成为 SQL 的常规功能。

最大 100 MB 的 JSON 文档

人工智能代理、RAG 以及多轮长上下文应用越来越希望将复杂的交互上下文存储在同一个地方。Doris 4.1 支持单行存储最大 100 MB 的 JSON 文档，这样整个会话数据都可以保存在数据库中：多轮对话内容、长文本、音视频转录稿、代理运行日志、工具调用记录，以及用于 RAG 的上下文信息。无需对这些数据进行拆分、截断或移至外部存储。一旦写入数据库，这些文档就会像其他数据一样，支持过滤、条件查询、聚合和连接操作，从而使庞大的 AI 上下文变成可查询的结构化数据资产。

根据该项目，以这种方式存储大型 JSON 可让团队：

• 无需依赖独立的对象存储服务，
• 不必编写用于保持元数据与原始内容一致的逻辑，
• 省去分块存储及重新组装的数据处理工作，
• 从而获得更低的查询延迟、更强的事务保障以及更简单的操作流程。

Segment V3 与宽表

搜索和人工智能类工作负载通常会产生字段众多、结构较为松散的半结构化数据，其模式会不断变化，且存在明显的热数据和冷数据访问模式。这类应用需要强大的随机读取能力、精确的点查询功能以及高并发写入支持。

在 4.1 版之前，Doris 使用的是 Segment V2 格式，该格式将元数据存储在文件尾部。虽然这适合批量扫描操作，但随机读取和小范围查询每次都需加载整个文件尾部，从而增加了磁盘 I/O 和解析开销。

V3版本受到Lance和Vortex等新格式的影响，将元数据与页脚分离，并按需加载。它旨在解决元数据过多、文件打开速度慢以及随机读取带来的高开销问题。适用场景包括列数众多的表格、包含大量VARIANT子列的表格、对象存储的冷启动延迟会带来严重影响的任务，以及需要频繁进行随机读取的半结构化AI数据或车辆远程信息处理数据。据称，在一个拥有7,000列和10,000个分段的表格中，V3版本的打开速度可提升至原来的16倍，内存占用则可减少60倍。要启用该功能，请在表格属性中设置"storage_format" = "V3"：

CREATE TABLE table_v3 (
    id BIGINT,
    data VARIANT
)
DISTRIBUTED BY HASH(id) BUCKETS 32
PROPERTIES (
    "storage_format" = "V3"
);

稀疏列

结构复杂的 JSON 通常存在大量很少被访问的路径以及少数高频访问的路径。Doris 4.1 对稀疏读取路径进行了优化，避免长尾路径成为单个稀疏列的瓶颈。

• 热路径与冷路径分离：高频访问的路径仍以列式子列的形式存在，而长尾路径则被存储在稀疏存储中，从而防止子列数量过度增加。
• 稀疏分片：通过 variant_sparse_hash_shard_count 将长尾路径分散到多个稀疏列中，降低对任意单个列的读取负载。
• 稀疏缓存：为稀疏列设置读取缓存，可减少重复的磁盘 I/O、解码及反序列化操作。

这种机制非常适合来自车辆远程信息处理系统、用户档案和事件日志的结构复杂 JSON，即那些记录字段众多但只有几十到几百条路径会被频繁查询的场景：

CREATE TABLE user_feature_wide (
    uid BIGINT,
    features VARIANT<
        'user_id' : BIGINT,
        'region' : STRING,
        properties(
            'variant_max_subcolumns_count' = '2048',
            'variant_sparse_hash_shard_count' = '32'
        )
    >
)
DUPLICATE KEY(uid)
DISTRIBUTED BY HASH(uid) BUCKETS 32
PROPERTIES (
    "storage_format" = "V3"
);

DOC模式

当需要优先考虑写入效率或获取完整的JSON文档时，DOC模式是更好的选择。它在写入时会保留原始JSON数据，将子字段提取操作推迟到压缩阶段，从而降低写入成本和写入放大效应。

• 延迟物化：写入时保留原始JSON，可减少小批量数据处理的开销。
• DOC分片：variant_doc_hash_shard_count会将Doc Store划分为多个分片，有助于整体文档读取和路径提取操作。
• 阈值：variant_doc_materialization_min_rows决定了何时开始物化处理；小于该阈值的批次会等待到压缩阶段再进行处理。

它针对的是大语言模型输出、追踪数据、上下文快照以及事件回放，这类任务通常会返回完整文档。要配置它，请开启 variant_enable_doc_mode，然后根据数据量调整阈值和分片数量。DOC模式与稀疏列无法同时使用，因此请选择其一，并将其与 storage_format = "V3" 配合使用：

CREATE TABLE trace_archive (
    ts DATETIME,
    trace_id STRING,
    span VARIANT<
        'service_name' : STRING,
        properties(
            'variant_enable_doc_mode' = 'true',
            'variant_doc_materialization_min_rows' = '100000',
            'variant_doc_hash_shard_count' = '32'
        )
    >
)
DUPLICATE KEY(ts, trace_id)
DISTRIBUTED BY HASH(trace_id) BUCKETS 32
PROPERTIES (
    "storage_format" = "V3"
);

2. 更快速的 OLAP

Doris 因其快速、实时的 OLAP 功能而闻名，4.1 版本通过减少不必要的计算、传输更少的数据以及提高执行效率，继续优化这一功能，从而确保在真实负载下复杂查询仍能保持快速响应。

多表及宽表基准测试

在标准的连接和聚合测试中，该版本相比 4.0 版实现了以下提升：TPC-H 测试中提升 22.6%，TPC-DS 测试中提升 19.1%，SSB 测试中提升 14.3%。

对于宽表测试，ClickBench 使用 100 GB 的数据及 43 个复杂查询来考验列式存储、向量化执行以及压缩技术，因此它是要求最苛刻的单表基准测试之一。在 c7a.metal-48xl 实例上，Doris 4.1 在冷查询处理速度和存储空间占用方面位居第一，在整体性能上则仅次于 ClickHouse（Web 版）。

这些提升背后的优化措施将在下文中详细介绍。

通过连接操作进行聚合下推

这种优化方式将复杂的聚合操作拆分，并将其分配到连接操作的两侧。每个表都在本地进行聚合，得到简化后的结果后再进行连接，最终的全球聚合操作则最后执行。先压缩数据再执行连接可以减少进入连接操作的数据量，从而显著降低内存占用和延迟。在项目的测试中，整体性能提升了200%以上，超过一半的案例提升了50%以上，近三分之一的案例提升了100倍以上。

分组集合

该引擎现在能够识别最细粒度的数据组及其聚合比例，并将策略从并行聚合多个组改为两步流程：首先完成最详细的聚合以缩小数据量，然后再根据该结果推导出其他组。据报告，整体改进幅度超过10%，其中五分之多的案例改进幅度超过20%，最佳案例的改进幅度达160%，而最差的案例则出现不到5%的退化。

嵌套列剪枝

该引擎能更精确地理解嵌套字段结构。当查询仅涉及某个子字段时，只会读取相关数据而跳过其余部分，从而节省磁盘I/O。在4.1版本中，该功能既适用于内部表，也适用于外部ORC和Parquet格式的数据。据报告，整体效率提升幅度超过60%，在极端情况下甚至可达到700%以上。

条件缓存

大规模分析往往会在多次查询中重复使用相同的过滤条件：

SELECT * FROM orders WHERE region = 'ASIA';
SELECT count(*) FROM orders WHERE region = 'ASIA';

反复对相同数据段应用相同的过滤操作会消耗大量的CPU资源和磁盘I/O。条件缓存会存储每个数据段的过滤结果以供后续查询使用，从而减少不必要的扫描和计算。对于复杂的查询任务，其性能提升幅度可超过10%。

查询缓存

分析型任务也会在未发生变化的数据上重复相同的聚合操作：

SELECT region, SUM(revenue) FROM orders WHERE dt = '2024-01-01' GROUP BY region;

每次运行都会扫描相同的表格并重新计算相同的聚合结果。查询缓存会保存中间聚合结果，当查询上下文匹配时直接返回这些结果，从而节省计算资源和磁盘I/O。

CASE WHEN

CASE WHEN是用于业务分类、行级逻辑处理以及条件聚合的核心结构。4.1版本增加了分支合并、分支消除、公共子表达式提取，以及枚举值的提取和下推功能。在基准测试中，其平均性能提升幅度超过200%，极端情况下甚至可达50倍以上。

3. 计算与存储分离

该项目表示，采用计算与存储分离架构后已有超过2,000名生产环境用户在使用，因此稳定性与查询性能已成为重点关注领域。

文件缓存

文件缓存元数据现在会被持久化存储，从而避免了早期版本在启动时重建缓存状态所需的大量磁盘I/O操作。一个新的系统表information_schema.file_cache_info可通过SQL显示块级缓存详情，可按tablet_id、be_id、cache_path和type进行查询。这有助于更轻松地找到高频使用的数据、诊断缓存分布不均的问题以及发现异常的增长趋势。

其一个用途是查看单个数据表的缓存构成：

mysql> select * from information_schema.file_cache_info where TABLET_ID = 1761571031445;
+----------------------------------+---------------+-------+--------+-------------+-----------------+---------------+
| HASH                             | TABLET_ID     | SIZE  | TYPE  | REMOTE_PATH | CACHE_PATH       | BE_ID         |
+----------------------------------+---------------+-------+--------+-------------+-----------------+---------------+
| 468448215c52334ae5bee147259b1027 | 1761571031445 | 15120 | index | | /mnt/disk1/project/filecache | 1761571031251 |
| 71bb73d34cd8ffe280b16dd329df5ba1 | 1761571031445 | 13117 | index | | /mnt/disk1/project/filecache | 1761571031251 |
| 77c6b69d1a7c4fe740a11bab5c1bbaa3 | 1761571031445 | 12249 | index | | /mnt/disk1/project/filecache | 1761571031251 |
+----------------------------------+---------------+-------+--------+-------------+-----------------------------------------------------------------------------+---------------+

另一种方法是汇总分布情况，以判断各BE节点间的平衡性及资源使用情况：

SELECT be_id, tablet_id, type, SUM(size) AS cache_bytes
    FROM information_schema.file_cache_info
    WHERE tablet_id = 1761571031445
    GROUP BY be_id, tablet_id, type
    ORDER BY cache_bytes DESC;

弹性扩展、冷查询及其他功能

• 弹性伸缩：在这种模式下，对数百万台节点的扩展操作可在几分钟内完成，因为调度不再依赖于全局节点总数。
• 冷查询：基于Doris的页面扫描机制进行预取，可加快对内部表的冷查询速度；同时通过参数调优，Doris能更高效地利用远程存储带宽。
• 大规模部署：前端节点中的副本及节点对象被简化，使得在数百万台节点的情况下，前端内存使用量可减少30%以上。
• 元服务：缓存层减少了对元服务的重复请求，提升了元数据处理效率；此外，部分系统表的访问路径也得到了优化。

对象存储成本：对于高频导入场景，通过节点级请求合并可减少对象存储请求次数及小文件数量，该项目称整体成本最多可降低90%。

压缩与编码：更高效的二进制编码结合预解码功能可降低运行时的解码成本，且默认压缩算法正逐步转向ZSTD，以在压缩比与解压速度之间取得平衡。对于宽表和明细表而言，这意味着更小的存储空间以及更好的冷数据读取性能。

4. 数据湖仓

4.1版本在格式覆盖范围、查询速度及生态系统兼容性方面进一步提升了湖仓功能。借助Doris SQL，无需Spark或其他外部引擎，即可单独使用该语言读取、写入和管理Apache Iceberg、Apache Paimon等主流开放表格式数据。

生命周期管理

创建表、插入数据、更新数据和删除数据均通过 Doris SQL 完成，因此一个引擎即可覆盖整个湖仓工作流。

• Iceberg V2/V3 读写功能：支持 INSERT、UPDATE、DELETE 和 MERGE INTO 操作，同时还具备 V3 版本的功能，如删除向量和行溯源功能。数据的导入、更新和删除操作可在无需外部引擎的情况下端到端完成。
• Paimon 管理：CREATE DATABASE、CREATE TABLE 以及其他 DDL 语句可直接在 Doris SQL 中执行。向 Paimon 表写入数据的功能将在后续版本中推出。

湖仓数据的查询性能

• Iceberg 排序写入功能：数据可以按照指定的排序顺序写入，从而生成有序的元数据（下限和上限），引擎可利用这些元数据来筛选文件。在 TPC-DS 测试中，该功能可使查询性能提升约 15%。

冰山清单缓存：通过缓存清单级别的元数据，可避免在规划阶段重复读取和解析，从而降低磁盘I/O及CPU使用率。据称，在高频查询情况下，复杂的元数据解析时间可降至百毫秒级别。

Parquet页面缓存：解压后的页面会被缓存在内存中，从而减少重复解压和磁盘读取操作，显著降低高频查询时的延迟。在ClickBench测试中，整体性能提升了约20%。

联邦分析的易用性

• 缓存准入控制：在用户、目录、数据库和表层面设置规则，决定哪些查询可以写入缓存，从而防止冷数据挤走热数据，并提升热门数据的命中率。这些规则以JSON文件形式存储在指定目录中，一旦更改会立即热加载，无需重启前端服务，且通过EXPLAIN指令可以查看准入决策结果，便于进行调优。
• MaxCompute写入功能：现在CREATE TABLE和INSERT操作可在MaxCompute外部目录中执行，从而完成了从Doris到MaxCompute的数据导出路径。该功能还支持ARN跨账户访问，便于与阿里云生态系统集成。

Parquet元数据检查：一个新的表值函数可通过SQL提供分区、行组和列的统计信息，有助于调试文件结构、检查分区裁剪情况以及优化查询。

5. 批量处理

Doris一直致力于将交互式分析与大规模批量处理整合到同一引擎中，从而降低并行运行多个系统的架构复杂性。4.1版本进一步增强了原生ETL和ELT功能。

MERGE INTO

通过一条标准的SQL MERGE INTO语句即可完成INSERT、UPDATE和DELETE操作（即插入或更新），简化了如CDC之类的增量合并任务，同时降低了开发与维护的工作量：

MERGE INTO target t
USING source s
ON t.id = s.id
WHEN MATCHED THEN
    UPDATE SET t.value = s.value
WHEN NOT MATCHED THEN
    INSERT (id, value) VALUES (s.id, s.value);

更强的溢出到磁盘功能

大规模连接、高基数聚合以及全局排序都会消耗大量内存，4.1版本将这些操作也纳入了溢出到磁盘的功能范围：

• 递归式多级溢出机制使中间数据能够分阶段传输，从而避免内存压力骤增；
• 该功能适用于连接、聚合和排序操作；
• 动态溢出触发机制可在内存使用与磁盘I/O之间取得平衡，保持查询稳定性。

根据这些改进，该项目称Doris能够在拥有8GB内存的单个BE节点上运行所有TPC-DS 10 TB规模的查询，这被认为比传统的Hadoop、Greenplum或Spark架构具有更高的性能且资源成本更低。不过和此处所有的数据一样，这一说法仍需用户自行验证。

6. 易用性

4.1版本完善了分析语法，提升了在复杂场景下的表达能力，同时增强了与其他系统的兼容性。

执行引擎扩展

UNNEST。 内置的UNNEST功能可简化对JSON及日志数据中数组和嵌套结构的分析，无需进行繁琐的函数重写：

SELECT user_id, tag
FROM user_profile,
UNNEST(tags) AS t(tag);

递归 CTE。 现在您可以编写递归查询，用于遍历组织结构图、层级结构及图形路径，或分析其他需要遍历的关系：

WITH RECURSIVE org_tree AS (
    SELECT id, parent_id, name
    FROM org
    WHERE parent_id IS NULL
​
    UNION ALL
​
    SELECT o.id, o.parent_id, o.name
    FROM org o
    JOIN org_tree t ON o.parent_id = t.id
)
SELECT * FROM org_tree;

ASOF JOIN。该连接方式依据时间列上的最近匹配值进行关联（使用<=或>=条件），适用于需要时间序列对齐及最近值查询的金融、物联网和监控类工作负载：

SELECT t1.ts, t1.value, t2.price
FROM trades t1
ASOF JOIN prices t2
ON t1.symbol = t2.symbol
AND t1.ts >= t2.ts;

数据摄入与写入路径

• 持续S3导入：可基于S3数据源创建持续任务，系统会检测新文件并持续导入，适用于从对象存储进行增量数据摄入。
• MySQL与PostgreSQL同步：Doris现在能够实时从MySQL和PostgreSQL获取最新数据，支持完整初始化及增量同步。这简化了基于操作型数据库构建实时数据管道的工作，有助于实现实时数据存储、数据整合及分析加速。

模型写入与更新

• 自适应写入调度：MemTable刷新线程池会根据集群负载调整，使写入并发度与当前状况相匹配，从而在大量写入场景下提升吞吐量、资源利用率及系统稳定性。

主键模型下的多流更新：sequence_mapping支持合并来自多个数据流的更新。不同的数据流可以更新同一张表中的不同列，并根据各自的序列字段进行合并，这非常适合并发实时更新与离线补录场景。

常规加载：可对非主键列进行灵活的局部更新，同时支持动态参数调整和自适应分批处理，从而在高吞吐量环境下提升稳定性。

导入审计：Stream Load操作会被记录到审计系统表中，因此历史记录、调试信息与审计数据均可通过同一入口查询。

TIMESTAMPTZ

诸如跨区域日志、用户行为分析以及金融交易等全球性工作负载都涉及明确的时间区信息。使用无时区的 DATETIME 类型时，转换操作需要在应用程序中完成，这既容易出错又会增加开发工作量。Doris 4.1 引入了 TIMESTAMPTZ（带时间区的时间戳）类型，以实现标准化的时区处理：

• 写入时的值以 UTC 格式存储，
• 读取时会转换为当前会话所使用的时间区，
• 无论输入是否包含时区信息，都会被自动解析并转换，
• TIMESTAMPTZ 和 DATETIME 可以互相转换，并能与现有函数协同使用。

这样就将时区处理从应用程序代码移至数据库内核，提升了系统间的一致性，同时也降低了多时区数据的处理复杂度。

其带来的好处

总体而言，4.1版本在将Doris打造为人工智能应用和实时分析的核心数据层方面取得了显著进展：IVF索引使得向量搜索能够处理规模大得多的数据集，100 MB的JSON文档容量足以支持长上下文对话，而OLAP及湖仓架构的性能也相比4.0版本有了明显提升。其优势在于提供一个集向量搜索、全文搜索、实时分析及湖仓功能于一体的基础设施，从而减少对独立向量数据库、搜索引擎和查询引擎的需求。这种整合能否带来实际效益，则取决于您的业务规模、延迟目标，以及供应商提供的数据在您实际工作负载下的表现。