过去一周，数据库赛道密集发布了三款面向AI负载的新品：OceanBase 4.3.5（向量增强版）、TiDB 8.1（Serverless AI节点）、以及单机嵌入式DuckDB 1.2（Wasm边缘版）。官方文档都在强调“高吞吐词元处理”，但我们的实测环境只有一个：标准IDC机架，10Gbps上行带宽，混合SSD，网络软件栈为DPDK+RDMA。结果，三者的带宽吞噬能力差了近四倍。
先看OceanBase 4.3.5。它把向量索引与标量过滤下推到存储层，在批量插入128维词元向量（每批1万条）时，单节点写入带宽稳定在6.2Gbps，网络软件侧几乎跑满RDMA队列。优点是延迟抖动极小（P99<8ms），适合实时推荐或RAG检索。但缺点同样刺眼：它对IDC交换机PFC配置敏感，一旦丢包超过0.01%，吞吐断崖下跌。适用人群：已有RDMA网络、运维成熟的头部AI团队。
TiDB 8.1的Serverless AI节点走的是另一条路——计算与存储彻底分离，词元写入先经Kafka队列再落盘。实测单节点写入带宽仅2.1Gbps，但横向扩展极顺滑。优点是不挑网络硬件，普通25G TCP也能跑，且按词元量计费，闲时成本低。缺点是冷启动延迟高达300ms，且跨可用区带宽费用惊人：每百万词元请求额外消耗约0.7GB出口流量。适合中小AI应用、波动大的推理服务，前提是你得接受“带宽账单不可预测”。
最令人意外的是DuckDB 1.2 Wasm边缘版。它在IDC边缘节点（同一机架内）做词元预聚合，写入带宽仅0.5Gbps，但本地计算完全不走网络。优点是零网络软件依赖，延迟低至微秒级，适合在服务器内部做词元缓存与轻量过滤。缺点是无法跨节点共享，单机故障即丢失。适用人群：边缘AI网关、模型前置处理层。
综合建议：若你的IDC有RDMA且运维强，选OceanBase换极致吞吐；若追求弹性与低门槛，TiDB Serverless更务实；若只做本地词元瘦身，DuckDB是隐藏利器。别被“AI数据库”的营销词迷惑——先量一量你的服务器带宽与网络软件栈，再决定让谁吞噬词元。
0 留言