工程实践SelectDB 技术分享
文章针对大模型应用中专用向量库成本高、混合查询难的问题，深入剖析 Apache Doris 4.1 原生向量检索的工程设计。作者先比较专用向量数据库、关系型数据库扩展和分析型数据库原生支持三条路径，论证原生集成路线的优势。随后详细阐述 IVF 索引降低内存、IVF_ON_DISK 冷热分层、SQ/PQ 量化压缩以及 ANN Index Only Scan 优化查询性能的具体实现和 DDL 示例。文章还演示了结构化过滤联合查询与基于 RRF 的多路召回融合在 SQL 中的落地方式，并给出 VectorDBBench 基准数据。测试表明该方案在 100 万 768 维向量上取得 900 QPS、97% 召回率，构建速度最快，形成成本与性能的均衡。不过文中基准硬件规格不一，实际部署需根据工作负载进行验证。
推荐收录，因为文章不是简单的功能罗列，而是系统拆解了 Doris 4.1 向量检索的工程实现，包括 IVF 降本、磁盘索引、量化压缩、Index Only Scan 等关键设计，并提供了混合检索的 SQL 实现和基准数据。适合数据库内核、AI 基础设施和 RAG 系统开发者参考，其存储分层、覆盖索引和融合排序思路可迁移到其他 OLAP 或向量检索场景。需注意部分内容来自厂商，基准配置存在差异，应结合自身负载验证。
技术文章SelectDB 技术分享
本文从 AI Agent 日志观测场景切入，指出 Agent 执行流具有嵌套数组、动态 Schema 和非确定性推理等特点，传统扁平日志模型无法还原完整执行树，而全量拍平会破坏上下文关系并导致频繁 DDL，直接存为 String 又会造成全表扫描和 JSON 解析性能瓶颈。作者提出让数据库原生支持半结构化数据，以 Apache Doris/SelectDB 的 VARIANT 类型为例，解释自动子列提取如何保留列式扫描性能和压缩率，倒排索引如何加速长文本和 JSON 内部关键字检索。文章进一步给出动静分离的混合建模实践：高频标量字段用标准列，动态嵌套对象用 VARIANT 列，关键排障字段建立倒排索引，并附建表与查询示例。内容主要基于 Doris/SelectDB 引擎，未提供跨引擎量化对比，但方案思路可迁移到 ClickHouse JSON 类型等类似系统。
推荐收录，因为文章直面 AI Agent 日志观测中 JSON 处理的核心矛盾，清晰对比了全量拍平、String 存储与半结构化原生支持三条路线的优劣，并提供可落地的混合建模 DDL/DML 示例。适合负责可观测性平台、日志分析或 OLAP 数据建模的工程师参考，其动静分离、自动子列提取与倒排索引组合的设计方法可以迁移到其他支持半结构化类型的列式数据库。
工程实践SelectDB 技术分享
文章对 Apache Doris 4.0.5/4.1.0 引入的 ASOF JOIN 进行系统性能实测，该功能面向时间序列近邻关联，可在按业务键分组后找到不晚于左侧记录的最近右侧记录，适用于交易行情补全、事件归因等场景。测试设计覆盖大小表组合、1 亿行对 1 亿行、不同 NDV、长序列、短序列、乱序存储和过滤条件等六大类典型场景，并与 ClickHouse、DuckDB 在相同硬件和并发参数下对比。结果显示 Doris 在绝大多数用例中显著领先，例如大小表 JOIN 低至 0.15-0.38 秒，1 亿对 1 亿约 0.97-1.13 秒，短序列和乱序场景优势更明显。文章强调该实现具有低延迟和高稳定性，适合大规模、复杂分布的真实业务。需注意内容来自 SelectDB 官方技术团队，测试带有厂商视角，但其测试设计和场景覆盖可作为数据库选型与性能评估参考。
推荐收录，因为文章提供了 ASOF JOIN 系统化的性能基准测试，从测试设计、环境配置到多维度场景结果均有详细说明，对需要处理时间序列近邻关联的数据库工程师和架构师有直接参考价值。其可迁移价值在于展示了如何设计覆盖真实业务复杂度的数据库功能基准测试，但需注意来源为厂商官方，数据结论应结合独立验证或实际业务场景再判断。
工程实践SelectDB 技术分享
文章讨论云数仓资源管理中长期存在的矛盾：业务负载波动大，固定规格资源常按峰值锁定，导致平均利用率低；传统存算分离架构弹性慢，扩容伴随缓存预热和数据重分布，容易引发查询延迟抖动。作者提出 SelectDB Serverless 的解决方案，通过计算、缓存、存储三层独立解耦，支持秒级原地纵向伸缩，单集群最高16倍弹性区间，并采用“扩快缩慢”策略——CPU 5秒均值或内存瞬时利用率超过60%触发扩容，CPU与内存同时低于30%且持续1分钟才渐进缩容，同时引入AI辅助决策。文章还给出选型参考：峰谷特征明显、可释放计算资源超过28%时Serverless才具成本优势；纵向弹性有16倍边界，极端场景需横向伸缩约3分钟。内容主要基于产品设计与机制说明，缺少独立用户验证数据。
推荐收录，因为它不只是产品宣传，而是提供了具体的弹性架构设计：三层资源解耦、扩缩容触发阈值、原地纵向伸缩机制和选型成本阈值，对云数仓、Serverless 或弹性架构设计的读者有直接参考价值。可迁移的是“扩快缩慢”的弹性策略和计算/缓存/存储解耦思路；需注意其厂商视角，部分性能数据未经独立验证。
技术文章SelectDB 技术分享
文章分析了 AI Agent 生产环境中可观测性负载的新特点：文本主体大且无结构、关键字段高度动态、trace 有序嵌套、看板需与持续写入并存。作者指出传统搜索、OLAP、文档库难以单独胜任，需要统一混合负载数据系统。AgentLogsBench 用单表 1 亿行 observation 数据评测六种引擎，覆盖 trace 回放、短语搜索、动态 JSON 过滤和实时聚合。结果显示 Apache Doris 综合 slowdown 1.28 领先，hot/cold 均第一，但在长文本 cold phrase search 上仍落后 Elasticsearch。文章解释了 Doris 领先原因包括倒排索引、VARIANT 子列、按 trace_id 分布与排序键、分区裁剪和缓存机制。该文可作为选型或理解混合负载数据系统的参考，但数据来自合成 benchmark，结果需结合实际验证。
推荐收录，因为文章不是空泛宣传，而是给出了 Agent 可观测性基准的具体设计、完整查询负载和跨系统实测数据，并逐项解释 Doris 架构优化如何影响性能。适合从事可观测性、OLAP 或 AI 平台基础设施的读者，用于理解混合负载系统选型与优化。可迁移价值在于把文本搜索、动态 JSON、trace 回放和实时聚合放在同一存储上权衡；主要风险是来自 SelectDB 官方且数据为合成，需结合其他评测交叉验证。
技术文章SelectDB 技术分享
本文介绍 Apache Doris 4.1 对 Iceberg 的能力扩展，从仅支持查询扩大到 UPDATE、DELETE、MERGE INTO 等 DML、表结构管理与日常维护，并完整支持 Iceberg V3。文章重点解析 Deletion Vector 机制：V3 用位图记录失效行并写入 Puffin 文件，使删除文件数量与数据文件同阶，文中测试显示文件数从336降至17、删除信息存储从98MiB降至3.8MiB、高删除比例查询时间降至约1/3。同时介绍 Row Lineage 提供的 _row_id 和 _last_updated_sequence_number 系统列，用于稳定行标识和增量变化识别，可配合 Time Travel 定位记录。作者也说明这些能力仅适用于 format-version=3 且需 Doris 4.1+，收益受数据规模和文件布局影响，Row Lineage 不等同审计系统。文章最后给出五分钟入门步骤并展望 Variant 读写和增量物化视图。
推荐收录，因为文章不是单纯的产品发布，而是提供了 Iceberg V3 关键机制（Deletion Vector、Row Lineage）的清晰解释、具体 SQL 示例和量化测试结果，并明确标注了版本、格式和场景边界。适合从事湖仓一体、Doris 或 Iceberg 数据管线的工程师理解如何在 OLAP 引擎中收敛查询、修改和维护，其关于减少删除文件开销和行级增量识别的思路具有可迁移价值。
工程实践SelectDB 技术分享
文章介绍 Apache Doris 内置倒排索引解决 OLAP 稀疏扫描问题的技术机制与实测效果。针对传统 OLAP 依赖列存、排序和 Zone Maps 在稀疏查询下全表扫描的局限，文章详细解析了三种索引结构：字符串精确匹配用 Posting List，数值范围过滤用 BKD 树，非结构化文本检索用分词器结合倒排列表。在 1.35 亿条亚马逊评论数据集上，50 并发测试显示全文检索提速 59 倍，按 ID 点查提速 156 倍，多维组合查询提速 10 倍。同时评估了资源开销：新增 7 个索引后存储从 26GB 增至 47GB，写入耗时增加约 6%，主要来自大文本列。结论认为 OLAP 内置倒排索引可简化 Elasticsearch+OLAP 双引擎架构，但应根据查询特征选择性建索引以控制成本。
推荐收录，因为文章基于 1.35 亿条真实数据给出可复现的建表、索引和查询测试，定量对比了性能提升与存储/写入开销。适合数据库内核开发者、 OLAP 架构师和数据平台团队参考，其倒排索引设计思路可迁移到类似分析型系统或评估 Elasticsearch 替代方案。需要注意的是测试仅基于单节点和特定数据集，索引列选择需按业务权衡。
技术文章SelectDB 技术分享
文章围绕宽表场景下 Footer 元数据膨胀问题展开，对比 Parquet、Lance 与 Doris Segment V3 的解决思路。作者首先指出列式存储中 Footer 会随列数和 Row Group 增长，在数千列、复杂 JSON/Variant 子列时可达数 MB 甚至数十 MB，拖慢查询启动与元数据解析。随后分析三种格式的约束：Parquet 受生态兼容限制，通过 FlatBuffer 随机访问、裁剪冗余和兼容扩展降低开销；Lance 从文件结构重设计，将列元数据独立存储并放弃传统 Row Group；Doris 则在保留 OLAP 能力前提下，将每列 ColumnMetaPB 外置到独立 Column Meta Region（CMR），并在 Footer 中仅保留轻量目录，同时为 Variant 增加路径索引。性能测试显示极端宽表下 Segment 打开时间从 65 秒降至 4 秒，内存从 60 GB 降至不足 1 GB。适用边界是数千列宽表、复杂 Variant 和大量 Segment 场景，窄表收益有限。
推荐收录，因为文章对列式存储元数据膨胀问题提供了清晰的问题拆解和三种主流格式的取舍对比，并详细说明了 Doris Segment V3 的 CMR 外置、Variant 路径索引以及性能验证数据。适合数据库内核、存储引擎、数据仓库以及对宽表/半结构化数据查询优化感兴趣的工程师阅读。可迁移价值在于理解文件格式设计中的兼容性、功能完整性与查询性能之间的权衡；主要风险是内容带有 Apache Doris 厂商视角，但对 Parquet 和 Lance 的分析仍较客观。
技术文章SelectDB 技术分享
文章围绕 Agent 日志中动态 JSON payload 的性能挑战展开，基于 AgentLogsBench 基准测试对比了 Apache Doris、ClickHouse、Elasticsearch/OpenSearch 和 DuckDB/Parquet Variant。作者剖析了 Doris VARIANT 将常用 JSON Path 转化为列式 subcolumns 的机制，并通过高频路径列式化、低频路径 sparse columns 和 Storage Format V3 来优化宽 JSON 查询。测试显示 Doris 在动态字段聚合、rollup 和低基数过滤上延迟优势明显，平均比 ClickHouse 快 7.4 倍，比 Elasticsearch 快 2.4 倍，存储占用接近 ClickHouse 且远低于 Elasticsearch。文章还分析了其他系统的取舍，如 Elasticsearch 搜索强但动态聚合成本高、ClickHouse 压缩好但长尾路径查询慢、DuckDB/Parquet Variant 开放格式强但在线分析不足。结论指出，将动态 JSON 纳入列式存储、索引和向量化执行链路是决定搜索后分析体验的关键。边界在于结果来自厂商基准，可能带有一定倾向性，但技术原理和权衡分析具有参考价值。
推荐收录。文章不仅给出了性能对比数据，还深入解释了 Doris VARIANT 的 subcolumnization、Storage Format V3 机制，并对比了 ClickHouse、Elasticsearch、DuckDB/Parquet Variant 的架构取舍，技术细节和可迁移性强。适合数据库内核、OLAP、可观测性和大数据工程师理解动态 JSON 在不同系统中的处理方式，为 Agent 日志分析、技术选型和优化提供依据。尽管来自商业公司，但内容以基准和原理为主，推广成分较低，长期参考价值较高。
技术文章SelectDB 技术分享
文章系统介绍 Apache Doris 的 Python UDF 功能，旨在让 SQL 直接调用 Python 生态以应对 AI 和实时分析中日益复杂的业务逻辑。核心方法是通过 Arrow RecordBatch 批量传输数据到独立 Python Server 执行，并支持 Pandas Series 向量化计算，减少跨语言和跨进程开销。Doris Python UDF 完整支持标量 UDF、UDAF 和 UDTF，提供内联与 ZIP 模块化加载方式，并内置进程隔离、复用和自愈机制以保证生产环境稳定性。文中给出支付风险分级和金额分桶等示例，展示在数据不离开分析链路的情况下完成规则判断、特征加工和模型打分。该能力已在 SelectDB 商业化产品中提供，适合需要将 Python 逻辑嵌入实时分析查询的场景，但部署前需在所有 BE 节点配置 Python 环境并安装 pandas/pyarrow。
本文对 Doris Python UDF 的设计机制、使用方式和生产化保障做了完整阐述，包含 Arrow 批量执行、向量化优化和故障恢复等关键细节，而非泛泛介绍。适合数据库内核开发者、数据工程师和需要在 SQL 引擎中集成 Python 生态的读者，可迁移到其他分析型数据库的扩展机制设计，帮助理解如何平衡灵活性、性能与可运维性。
技术文章SelectDB 技术分享
文章系统解析了 Apache Doris 4.1 的 Spill to Disk 机制，用于避免哈希关联、聚合、排序等内存密集型查询触发 OOM。核心增强包括核心算子全覆盖、递归重分区应对数据倾斜，以及基于内存压力感知的主动落盘触发。文章详细说明了由控制层、算子层、基础设施层和内存管理层组成的统一架构，以及预留、暂停、落盘、恢复四阶段流程。针对 Hash Join、Aggregation、Sort 分别给出了化整为零、临时状态落盘和外部归并排序的具体实现策略。基准测试显示，在单 BE 16GB 内存下运行 TPC-DS 10TB 查询，复杂查询全部完成且内存被控制在 8GB 以内，部分场景落盘数据量超过 1000GB，验证了以磁盘 I/O 换取内存空间的可行性。当前 Intersect/Except 算子暂不支持直接 Spill，需要通过等价 Join 改写。
推荐收录，因为文章不仅介绍功能，还深入解释了内存压力感知、算子级落盘策略和统一架构设计，并给出了可验证的基准测试数据。对从事数据库内核开发、性能调优或超大规模分析查询的读者具有直接参考价值，其“预留-暂停-落盘-恢复”的资源控制方法和外部归并排序等思路也可迁移到其他内存受限的查询引擎中。