【数据库研究前沿】近数据处理与计算下推：Smart SSD 到 DPU Offload

这是【数据库研究前沿】系列的第 17 篇。上一篇 CXL 3.0 与内存池化 讨论的是”让内存离 CPU 更近”。这一篇走相反的方向：让计算离数据更近——把过滤、聚合、解压、校验这些操作从 CPU 搬到 SSD 控制器、存储卡的 FPGA、或者网卡上的 Arm 核心里去做。

两种方向合起来，才是数据库在硬件层面真正的主题：CPU、DRAM、网络、存储之间的”数据搬运”成本越来越接近、甚至超过”计算本身”。当带宽不再稀缺而每一次数据移动都要算一次能耗预算时，数据库引擎的形态必须跟着变。

本文上半（60%）讲：近数据处理（Near-Data Processing, NDP）的基本动机、早期学术工作、目前可买到的计算存储硬件、SNIA 的标准化尝试、DPU（Data Processing Unit）如何重画存储 I/O 路径、YourSQL / POLARDB-NDP 等关键论文。下半（40%）讲：在 2026 年，过滤、解压、CRC、加密这四类下推是真正能落地的，其他的还要再等；以及 PostgreSQL FDW 的”计算下推”思路，如何作为 NDP 的软件类比。

版本说明 本文硬件参考：Samsung SmartSSD CSD（2020–2022 款）、ScaleFlux CSD 3000 系列、Eideticom NoLoad、NVIDIA BlueField-3 DPU、AMD Pensando DSC3-400。软件参考：Linux 6.x 内核对 NVMe Computational Storage 的实验支持、SNIA Computational Storage API v1.0（2023）。文章不覆盖 GPU offload（见 向量索引 和 学习型查询优化 相关讨论）。

一、NDP 的基本账本：为什么要把计算搬到数据旁边

1.1 一道简单的算术题

假设一个查询：SELECT COUNT(*) FROM logs WHERE level = 'ERROR'，表大小 1 TB，ERROR 行占 0.1%。

• 传统路径：存储读出 1 TB → PCIe 传 1 TB → CPU 过滤保留 1 GB → CPU 计数。
• 下推路径：存储读出 1 TB → 存储内部过滤保留 1 GB → PCIe 传 1 GB → CPU 计数。

PCIe 4.0 x4 带宽大约 8 GB/s，传 1 TB 需要 125 秒，传 1 GB 只需 0.125 秒。对这个典型的”大表小结果”查询，光是省掉 PCIe 传输就把端到端时间拉近两个数量级。

这就是 NDP 的原始动机。它不是一个新概念：1990 年代的 IDISK、2000 年代的 Active Disks 都做过类似尝试。过去二十年它们没有普及的关键原因是：硬件算力太弱、软件生态没有。现在第一条因素被 SSD 控制器里的多核 Arm + FPGA 解决了；第二条正在被 SNIA 标准和 Linux 内核补齐。

1.2 NDP 的三种硬件形态

“近数据处理”这个口袋很大，硬件上至少分三类：

SNIA 在 2022–2023 年的计算存储架构文档里把前两类统一用 CSx（Computational Storage Device, x ∈ {D, P, A}）描述。DPU 严格说不属于存储，但它改造的是”远端存储访问路径”，在数据库里和计算存储经常放在一起讨论。

1.3 “下推”不是一个操作，是一套语义

讨论 NDP 容易陷入一个误区——以为它是”把某个函数装进 SSD”。更准确的说法是：下推需要同时解决五件事：

1. 算子选择：哪些操作可以下推（SELECT / PROJECT 可以；JOIN / AGGREGATE 中有一部分可以；ORDER BY / WINDOW 基本不可以）；
2. 数据格式协商：存储内部的 block 结构（列存 / 行存 / 压缩）要能被下推算子直接识别；
3. 接口规约：数据库怎么把”谓词”变成设备能执行的字节码或规则表；
4. 容错语义：下推失败（FPGA 暂不可用、算子不支持）时要能回退到 CPU 路径；
5. 统计信息：优化器必须知道”下推这个过滤能省多少 I/O”才会选择它。

这五件事里，1、2、3 是硬件厂商 + 标准化组织在做；4、5 是数据库自己必须做的。YourSQL、POLARDB-NDP 等学术工作的贡献，大多集中在 4、5。

1.4 和 FDW / Pushdown 的区别

一个更微妙的问题：SQL 优化器本来就有”谓词下推（Predicate Pushdown）“的概念——把 WHERE 从 JOIN 的上方推到下方的 scan。NDP 下推和优化器下推的关系，可以这么理解：

• 优化器下推：在逻辑计划树里把算子位置重排，仍由 CPU 执行；
• 存储下推（FDW）：把算子推到”另一个计算节点”（远端数据库、Parquet 解析器），跨进程/跨机器执行；
• NDP 下推：把算子推到”存储设备内部的计算单元”，跨 PCIe、可能跨 ISA（FPGA bitstream、Arm 核心）执行。

三者的代价/收益模型本质相同——谁离数据近谁来算——但各自的接口约束层层加码。NDP 是其中最紧的那一层，因为设备资源最少、出错恢复最昂贵。

一个值得记住的历史事实：这三类下推在过去二十年是分别发展的，优化器下推从 System R 时代就有，FDW 进 PostgreSQL 是 2011 年，NDP 真正产品化是 2020 年前后。但它们本质是”同一原则在不同层次的重复应用”——未来若干年，各层下推协议可能会出现统一的”算子描述语言”（类似 Substrait 在优化器层正在做的事），使得一个谓词可以同时被优化器、FDW、NDP 设备理解和执行。

二、计算存储硬件：能买到的三家

2.1 Samsung SmartSSD CSD

Samsung 和 Xilinx（现 AMD）合作的 SmartSSD 系列是工业化程度最高的计算存储产品。硬件上：一块 U.2 盘内置一颗 Xilinx Kintex UltraScale+ FPGA，和 NAND / SSD 控制器挂在同一条内部总线上。FPGA 通过”内部 NVMe 命令”访问 SSD，不走主机 PCIe。

对数据库有意义的能力：

• 列过滤：FPGA 加载 Parquet / ORC 解析器，能在 SSD 内部把 block 按列剖开、按谓词过滤；
• 压缩 / 解压：LZ4、Zstd、Snappy 的硬件实现（吞吐可达 10–20 GB/s，远超 CPU 单核）；
• 正则 / 模式匹配：对日志搜索场景，硬件 Aho-Corasick 引擎可以做到 wire speed。

Samsung 2020–2022 年公开演示过 TPC-H Q6（纯过滤 + 聚合）在 SmartSSD 上 4×–10× 加速的结果。但直接把 PostgreSQL 跑在上面并不能享受这些能力——需要专门的 FDW 或者内置支持。

2.2 ScaleFlux CSD

ScaleFlux 走的是”对应用透明”的路径：他们的 CSD 3000 系列内置硬件压缩/解压，盘体对主机暴露的容量（“effective capacity”）比物理 NAND 大 2–4 倍。主机写入原始数据，SSD 内部压缩存储；读出时自动解压。数据库不需要改任何代码。

这个模型的好处：任何数据库都能直接受益——MySQL、PostgreSQL、RocksDB 的表空间落在 ScaleFlux 盘上，写放大会因为硬件压缩降低、有效容量扩大。

代价是：硬件压缩对”已经在软件层压过一遍”的数据不再受益。RocksDB 默认用 Snappy / Zstd 压 SST，配合 ScaleFlux 时通常要关闭软件压缩、把压缩职责完全下沉给硬件。这是一个需要实测的权衡。

2.3 Eideticom NoLoad 与 SNIA 标准

Eideticom 的 NoLoad 是”计算存储处理器（CSP）“——它本身没有 NAND，只是一块 PCIe FPGA 卡，通过 NVMe 命令把”计算任务”下发给它，然后它再用 NVMe peer-to-peer 从别的 SSD 直接读数据，不经过主机内存。

这种架构的关键：Peer-to-peer DMA（P2PDMA）。Linux 5.4 起合入，BAR 空间需要支持。在多盘聚合场景（例如 8 块 NVMe 做 RAID），用一块 NoLoad 做聚合/过滤/压缩，可以把主机 DRAM 的内存拷贝开销几乎归零。

SNIA 在 2023 年发布的 Computational Storage API v1.0 试图把这类能力标准化：

• CSF（Computational Storage Function）：下推算子的元数据描述；
• CSE（Computational Storage Engine）：执行容器，类似虚拟化沙箱；
• CSR（Computational Storage Resource）：FPGA bitstream、eBPF 程序、容器镜像等实际载体。

这个标准是否能成为事实标准仍是开放问题。NVM Express 工作组也在推一套并行的 “Computational Programs”（TP 4091，2023）。2025 年两套标准尚未合并。

2.4 DPU：另一条侧翼

BlueField-3 / Pensando 不是存储设备，但它们同样把”数据到 CPU 的路径”改写了：

• NVMe over Fabrics 的卸载：NVMe-oF 协议栈跑在 DPU 的 Arm 核上，主机 CPU 看到的是”本地 NVMe 盘”；
• 存储加密 / 解密：AES-XTS 硬件引擎，线速处理；
• RAID / 纠删码（Erasure Coding）：可以把 RAID5/6、Reed-Solomon 下沉到 DPU；
• 压缩与去重：类似于存储侧的计算，但放在网卡层。

对于云数据库（Aurora、Snowflake、PolarDB）这种”存算分离 + 远端存储”的架构，DPU 是最自然的计算下推载体。阿里云 PolarDB 发表过关于”Smart NIC 辅助存储路径”的工程论文（待核实具体会议/年份），腾讯云、字节也有类似内部工作。

DPU 和计算存储的一个微妙区别：DPU 更”通用”但”离数据远”——它看到的是 NVMe-oF 流量而不是 NAND 块，能做协议层卸载（CRC、加密、压缩），但做不了应用层的列式过滤。CSD 则相反，离 NAND 最近但能做的算子受限于固件/bitstream。实际生产部署，两者往往同时存在：CSD 做应用层下推，DPU 做协议层卸载，CPU 只处理真正需要集中状态的事务逻辑。这是 2026 年云数据库架构的一种合理分层形态。

2.5 硬件形态对比：快速选型参考

团队评估 NDP 硬件时，常常需要一张”谁解决什么问题”的速查表。下面这张表给一个起点：

需要说明的是，“对象存储 + Lambda 下推”虽然不属于硬件 NDP，但对很多数据团队是最容易落地的”下推”路径——AWS S3 Select、Snowflake External Table 提供的”服务端过滤”语义完全等价于 NDP 的接口层。如果你当前的数据湖在 S3、数据量大、过滤选择率高，先把 S3 Select 用起来比等 CSD 硬件更有性价比。

选两篇切入点合适、公开材料完整的工作。

3.1 YourSQL（VLDB 2016）

Jo et al. 的 YourSQL: A High-Performance Database System Leveraging In-Storage Computing（VLDB 2016）是较早把 NDP 做到完整 SQL 引擎的工作。它的贡献点：

1. 在 SSD 内部跑一个精简查询引擎：支持过滤、列裁剪、部分聚合；
2. Cost-based 下推决策：MySQL 优化器增加了一条”如果下推，估算多少 I/O 和多少 CPU 在设备侧能完成”；
3. 回退机制：设备执行失败时，主机 CPU 接管。

YourSQL 在选中表上的简单查询能达到 3–4× 加速。更重要的是它给后来的工作定义了一个方法学：不要追求完整 SQL 在 SSD 里跑，只下推最有价值的算子，并让优化器懂。

3.2 POLARDB-NDP / 阿里的工程工作

阿里巴巴的 PolarDB 在 2020 年前后有若干关于”把查询下推到底层智能存储”的论文和技术博客（具体命名在不同材料里有 PolarDB-NDP、PolarStore-NDP 等变体，待核实最权威标题）。公开材料里较一致的几个点：

• 目标算子：过滤（Filter）、投影（Project）、部分聚合（Partial Aggregate），以及 OLAP 场景下 Join 的 build 侧扫描；
• 数据格式：PolarDB 的列存引擎定义了一种可以被 FPGA 直接解析的 block 格式（CStore block），规避了通用列格式解析的开销；
• 事务一致性：只下推”已提交快照”的读路径，写路径和 MVCC 判定仍在 CPU 完成。

这三条共同指向一个工程判断：NDP 在 OLAP 读路径上最容易落地；OLTP 与事务写路径基本没戏。这个判断到 2026 年仍然成立。

3.3 其它值得一看的工作

• Biscuit（ISCA 2016）：在 SSD 里用 Flowlet 抽象做流式计算，被后来的工作反复引用；
• Caribou（VLDB 2017）：FPGA 做 kv store + range scan，展示了”简单存储协议 + 硬件加速”的可行性；
• InSituDB / CSD-KV 系列（2021–2023）：把 RocksDB 的部分读路径下沉到 CSD；
• Saving Money by Better Caching in Distributed Databases（VLDB 2023，待核实确切标题）：把计算存储与内存池化放在一起做成本建模。

3.4 一个小型代码类比：用 eBPF 模拟下推

在真正拥有 CSD 硬件之前，可以用 eBPF + XDP / io_uring 做一个”软件版 NDP”来培养直觉。思路是在内核的 I/O 路径上挂一个 eBPF 程序，读到的数据按谓词过滤后再返回给用户态：

// 伪代码：eBPF 程序过滤日志记录的 level 字段
SEC("nvme/read_complete")
int filter_error_logs(struct nvme_read_ctx *ctx) {
    struct log_record *r = (struct log_record *) ctx->buf;
    if (r->level != LEVEL_ERROR) {
        return NVME_DROP;  // 不往用户态返回
    }
    return NVME_PASS;
}

这段程序不会真正跑在 2026 年的 Linux 内核里——现有 eBPF hook 点还没到”NVMe 读完成”这个粒度，但 XDP 已经为网络侧提供了相似范式（Cilium、Katran 都是这条路）。存储版本的 eBPF hook 是 Linux 社区 2023–2025 年讨论的方向。如果这条路走通，存储 NDP 可能先以 eBPF 形式出现，再推到硬件，就像 XDP 推动智能网卡上的可编程管线一样。

本节到此可以总结一句：NDP 的学术史密密麻麻，但工程落地线条清晰——先在 OLAP 读路径、再可能拓展到流处理、OLTP 写路径大概率无缘。

四、真正能落地的四类下推：过滤、解压、CRC、加密

上面这些工作看起来很多，但企业 IT 团队能立刻用得上的其实非常有限。下半把话题聚焦到”2026 年就能上生产”的四类下推。

4.1 过滤（Predicate Pushdown）

这是最经典的下推场景，也是任何 NDP 讨论的默认主角。几个要点：

• 受益最大的是”高选择率 + 大表”：WHERE 条件过滤掉 ≥ 90% 的行时，下推收益明显；
• 最适合的格式是列存 + 自描述 block：Parquet 的 row group 统计、ORC 的 stripe 索引，都可以作为 FPGA 过滤的元数据入口；
• 工程落地：Snowflake、BigQuery、ClickHouse 在底层对象存储 + 存储网关做过同类优化（虽然不是 SSD 级 NDP，但语义完全一致）。

对 PostgreSQL，当前最现实的路径是通过 FDW：用 parquet_fdw / ogr_fdw 把”下推”委托给底层文件格式或对象存储服务。这在第五节会展开。

一个常被忽视的限制：NDP 过滤只对 equality / range 谓词友好，LIKE / 正则类半结构化谓词目前还难以下推到 FPGA 里高效执行（除非硬件有专门的模式匹配引擎，如 Intel 的 HyperScan on FPGA、SmartSSD 的 regex coprocessor）。生产环境中这类谓词经常占比很高（日志搜索、全文过滤），因此”能下推的查询占总负载比例”往往比想象的低。

4.2 解压（Decompression Offload）

现代存储几乎都压缩。下推解压的收益：

1. CPU 核被解放：LZ4 / Zstd 单核解压大约 1–5 GB/s，占用一个核还不够喂饱一块 NVMe；
2. 端到端延迟下降：解压和 I/O 流水线化，而不是串行；
3. 功耗收益：专用解压引擎的 J/GB 比 CPU 低一个数量级。

Intel QAT（QuickAssist Technology）、ScaleFlux 的盘内解压、BlueField 的 Compression/Decompression Engine 都是这条路。PostgreSQL 17 的 lz4、zstd wal 压缩可以配合 QAT；RocksDB 的 CompressionOptions.parallel_threads 也可以搭配硬件压缩库。

几个实际部署要点：

• 压缩算法要和硬件能力对齐：FPGA 上的 Zstd 通常只支持固定 level（例如 level 3），用了自定义字典或高 level 时会 fallback 回 CPU；
• 和仓库 压缩算法工程实践 对照：软件层选型同样重要，硬件不能解决所有问题；
• 警惕双重压缩：ScaleFlux 盘内自带压缩，如果 RocksDB 再开 Zstd，会导致数据进一步压缩率极低但 CPU 开销叠加。正确做法是关掉软件压缩，让硬件统一处理。

4.3 CRC 与数据校验

几乎所有存储和网络协议都要做 CRC。CPU 版本（即使是 SSE4.2 crc32）在高带宽下依然是瓶颈。

• DPU 卸载：NVMe-oF 和 iSCSI 的 CRC32C 直接在 DPU 里做；
• SSD 内部 ECC / CRC：对数据库透明，但影响工程决策——启用硬件端到端校验后，软件层的 data_checksums 是否值得再开一遍？通常答案是：仍然要开，因为 CRC 只能保证传输路径，不能保证”软件位反转”。

和 Checksum 与数据完整性 一文对照：端到端数据完整性（End-to-End Data Integrity）要求校验码覆盖”应用写入 → 最终读取”全路径。硬件 CRC 只覆盖一段，软件校验才是完整保证，两者互补而非替代。

4.4 加密（Encryption Offload）

TDE（Transparent Data Encryption）在数据库里的代价主要是 AES-XTS 吞吐。硬件卸载非常成熟：

• Intel AES-NI：CPU 指令级，2010 年以来的任何 x86 都有；
• DPU AES Engine：线速加/解密，尤其对”存算分离”架构有价值；
• SSD SED / OPAL：盘级自加密，但密钥管理不够灵活。

这四类是当前的”甜点区”。其它算子（Join、TopK、复杂聚合、排序、窗口函数）都还在实验室，不建议在生产里依赖。

4.5 为什么 JOIN 很难下推

不同于过滤、解压这类”一元算子”，JOIN 是”二元”的——需要同时访问两张表。要在 SSD 里做 JOIN，有几条路径都不容易走：

1. Hash Join：build side 要放在 SSD 内部 DRAM 里，但 CSD 的 DRAM 通常只有 1–4 GB，难以放下大表的 hash table；
2. Merge Join：要求两张表预排序，对 SSD 来说需要跨 block 的数据组织能力，目前的 FPGA 实现很少做到；
3. Bloom Join / 半连接：可行但收益有限——主要是先用 Bloom filter 过滤，再把结果传回 CPU 做真正的 JOIN。POLARDB-NDP 和几篇学术论文（待核实具体文献）做过这一路径。

结论是：短期 JOIN 的”下推”只能是”半下推”——下推其中一侧的过滤与投影，主 JOIN 运算留给 CPU。

4.6 排序、TopK 与窗口函数

排序几乎不可能下推到 SSD：需要全局视图、需要大量中间状态，且 SSD 内部 DRAM 容量不足以放下排序 buffer。TopK 在某些限定条件下（K 很小、值域有限）可行，但工程上罕见。窗口函数由于依赖跨行状态和分区边界，目前没有任何商用 NDP 实现。

这不是坏消息，而是一个收敛的工程边界：接受 NDP 只能处理”扫描附近”的运算，把精力放在怎么把这些运算做到极致，而不是追求”任何 SQL 都能下推”。

五、软件类比：PostgreSQL FDW 的”下推”思路

即使没有任何计算存储硬件，PostgreSQL 的 Foreign Data Wrapper（FDW）已经演练了一套完整的”下推语义”。理解 FDW 是理解未来 NDP 软件接口的最好起点。

5.1 FDW 下推的四个钩子

FDW API 定义了一组回调函数，优化器通过它们询问”远端数据源能做什么”：

• GetForeignRelSize / GetForeignPaths：告诉优化器远端的扫描代价估计；
• GetForeignPlan：生成远端执行计划（对 postgres_fdw 来说就是远程 SQL 字符串）；
• IterateForeignScan：拉取远端结果；
• 更进阶：GetForeignUpperPaths 允许下推 Aggregate / Sort / Join。

以 postgres_fdw 为例：

-- 本地表
CREATE FOREIGN TABLE orders_remote (...)
  SERVER remote_pg OPTIONS (schema_name 'public', table_name 'orders');

-- 带过滤的查询
EXPLAIN (VERBOSE) SELECT SUM(amount) FROM orders_remote WHERE status = 'PAID';

-- 输出中可以看到 Remote SQL：
-- SELECT SUM(amount) FROM public.orders WHERE status = 'PAID'
-- 整个 WHERE + SUM 都被下推了

这个模式和 NDP 几乎一一对应：

5.2 从 FDW 经验学到的三件事

第一，下推的前提是代价模型必须诚实。postgres_fdw 的早期版本经常下推失败，原因是优化器默认远端代价等于本地——不开 use_remote_estimate 就不会真去问远端。NDP 里完全一样的问题：必须有一条路径让数据库问”SSD 现在负载如何、这个过滤能多快”。

第二，类型和表达式语义必须严格匹配。postgres_fdw 对字符串比较的 collation 敏感——如果远端 collation 不同，包含 ORDER BY 的查询不能下推。对 NDP 同理：SSD 里 FPGA 实现的 UTF-8 比较未必和 glibc 一致，优化器必须能识别”这个谓词不能安全下推”。

第三，可观测性决定是否敢开。EXPLAIN (VERBOSE, ANALYZE) 能看到 Remote SQL 和 rows estimate，DBA 才敢打开下推。NDP 的 EXPLAIN 要能显示”谓词下推到 SSD，减少 PCIe 流量 X GB”，否则没人愿意启用。

5.3 从 FDW 到 NDP 的桥

几个项目实际在尝试这条桥：

• parquet_fdw / duckdb_fdw：把查询下推到 Parquet 文件或嵌入的 DuckDB，这是 PostgreSQL 做”湖仓一体”的主流路径，参考 Lakehouse；
• CSD-aware FDW（实验性）：学术界有原型 FDW 直接对接计算存储盘，把 Parquet block 级过滤下放到 FPGA；
• kvstore_fdw + NDP：对 RocksDB 这类 KV 引擎，下推主要是”scan + filter”，和 FDW 的语义非常接近。

未来 2–3 年，如果 NDP 真要走进生产数据库，极有可能是先以 FDW 形态出现，再逐步合并到核心引擎，而不是直接改 heap 或 buffer manager。

六、选型建议：什么时候考虑 NDP

6.1 决策流程

写到这里，可以给团队一个可操作的决策流程：

1. 先算 I/O / CPU 比。用 iostat + top 跑 1 小时典型负载。如果 I/O 带宽没有打满 50%，NDP 收益有限，优先考虑 buffer pool 调优 或 LSM 调参。
2. 看负载特征。OLAP 大表扫描 + 高选择率过滤最适合；OLTP 点查几乎没有收益。
3. 看生态一致性。整个 fleet 都能换计算存储硬件、应用层能接受驱动/固件升级，才值得做；小规模试点大概率被运维反弹。
4. 从”透明加速”开始。ScaleFlux 这类”对应用透明”的盘风险最低；需要改代码、改 bitstream 的部署，先在非关键链路试点。
5. 把能力留在 FDW 层。如果你已经在用 PostgreSQL + 外部存储（S3 / Parquet），先把 FDW 下推用到极致，再考虑下沉到硬件。

6.5 一个”下推友好”的架构草图

对准备新做系统设计的团队，下面是一个”从设计之初考虑 NDP”的存储层骨架：

• 底层：ZNS SSD + computational storage，zone 对齐到 LSM level；
• 格式：列存 + 字典编码，block header 可被 FPGA 解析；
• 接口：所有扫描走统一的 ScanDescriptor，包含 “projection + predicate + limit”，可序列化发送到设备；
• 回退：如果设备拒绝（不支持算子、资源不足），同一个 ScanDescriptor 直接由 CPU 执行；
• 代价：优化器维护一张”设备能力表”，记录当前 drive 的吞吐上限、支持的谓词类型、当前排队深度。

这个草图没有任何一部分是 2026 年无法实现的；但把整套做对需要跨存储、FS、SQL 三个层面的协作，这正是 NDP 在现有系统里难以进入的原因。新做系统的团队可以用这张草图作为起点，对老系统来说只有逐步切入 FDW 一条路。

6.2 一个最小可执行的 pilot 方案

如果你的团队现在想”动手试一下 NDP”，下面是一个风险最小的 12 周 pilot 方案：

• 第 1–2 周：采集生产环境的 I/O / CPU profile，识别”下推候选查询”——通常是大表扫描 + 高选择率过滤；
• 第 3–4 周：在 PostgreSQL 上用 parquet_fdw + DuckDB 或 S3 Select 做软件版下推，记录收益；
• 第 5–8 周：如果第 3–4 周的收益 > 20%，采购 1–2 块 ScaleFlux CSD 做透明压缩试点，观察写放大、吞吐、寿命三指标；
• 第 9–12 周：结合前两步数据，决定是否进入更深的硬件下推（SmartSSD / NoLoad）。

一个容易被忽视的配套问题：运维团队的可观测性工具。CSD 的性能计数器不在 /proc/diskstats 里，而在厂商专用 API 中。没有一套统一的 Prometheus exporter，Grafana 面板就无法反映设备状态。pilot 前就要把监控链路列入待办——许多团队在硬件到货后因监控无法接入而无限期搁置项目。

6.3 和其它主线的关系

• 与 CXL 3.0 与内存池化（第 16 篇）：一个把”数据搬到 CPU”，一个把”计算搬到数据”，两者在机柜级架构里互补；
• 与 持久内存退场之后（第 18 篇）：ZNS SSD 的 zone 抽象天然适合”一个 zone 一个下推任务”的批处理风格；
• 与仓库已有文章 SSD NAND 架构、NVMe 协议、压缩算法工程实践、Checksum 与数据完整性、新硬件综述：计算存储正是建立在这些底层协议之上。

七、开放问题

1. 算子库的通用性：每家厂商的 FPGA bitstream 彼此不兼容。SNIA / NVMe 标准能不能真正做到”下推一次，多盘运行”？这是标准化组织的主要战场。
2. 优化器的下推收益估计：在混合工作负载下，设备侧排队、失败回退、固件升级都会影响实际收益。一个稳健的代价模型还没人给出。
3. 安全隔离：计算存储允许”把任意代码放进盘里”（eBPF、WebAssembly 甚至容器）。盘厂商怎么保证一个租户的下推不影响另一个租户的 I/O 延迟？在多租户云环境里，这是上生产前必须解决的问题。
4. 与向量检索的结合：HNSW 的图遍历能不能下推到 SSD？Milvus、pgvector 社区 2025 年有相关实验（待核实具体项目），但还没有公认答案。理论上图遍历的随机访问模式极不利于传统 SSD，但如果 NAND 内部有多通道并行 + 硬件 prefetcher，“设备内图遍历”可能把 HNSW search 的延迟从几毫秒降到几十微秒。这是一个 2027 年前会有初步验证的方向。
5. 多租户下的公平性：一块计算存储同时服务多个数据库实例时，如何保证 QoS？CPU 侧的 cgroup / BPF 限流机制需要对等地扩展到设备侧，这在 SNIA / NVMe 标准层面都还是空白。

这些问题没有共识，也是为什么 NDP 在 2026 年仍然是”研究前沿”而非”工程常识”的原因。这个判断可能在 2028 年改变。

参考文献

1. I. Jo et al. YourSQL: A High-Performance Database System Leveraging In-Storage Computing. PVLDB 9(12):924–935, 2016. https://dl.acm.org/doi/10.14778/2994509.2994512
2. S. Kim et al. In-Storage Processing of Database Scans and Joins. Information Sciences, 2016.
3. SNIA. Computational Storage Architecture and Programming Model, v1.0. 2023. https://www.snia.org/tech_activities/standards/curr_standards/computational
4. NVM Express. Computational Programs – Technical Proposal 4091. 2023. https://nvmexpress.org/
5. L. Woods, Z. István, G. Alonso. Ibex: An Intelligent Storage Engine with Support for Advanced SQL Off-loading. PVLDB 7(11):963–974, 2014.
6. Z. István et al. Caribou: Intelligent Distributed Storage. PVLDB 10(11):1202–1213, 2017.
7. B. Gu et al. Biscuit: A Framework for Near-Data Processing of Big Data Workloads. ISCA 2016.
8. NVIDIA. BlueField-3 DPU Datasheet. 2023. https://www.nvidia.com/en-us/networking/products/data-processing-unit/
9. Samsung. SmartSSD CSD Reference Architecture. 2021. https://samsungsemiconductor-us.com/smartssd/
10. PostgreSQL Documentation. postgres_fdw. https://www.postgresql.org/docs/current/postgres-fdw.html

上一篇：【数据库研究前沿】CXL 3.0 与内存池化：对缓冲池与共享内存模型的重塑

下一篇：【数据库研究前沿】持久内存退场之后：ZNS SSD 与下一代非易失内存