ParticleDB：把四种数据库装进一个引擎
欢迎来到从零开始学AI。今天先不讲模型，讲一个模型离不开的东西：数据库。
这个切入点好。很多人以为 Agent 聪明就够了，其实它做一次决定，背后要查一堆数据。
比如一个客服 Agent。它得先查工单表，知道这个用户买了什么；再查会话状态，知道上一步问到哪；然后做一次向量检索，找出相似的退款政策；最后跑一条聚合，看看这类问题最近是不是变多。
这四步，在传统架构里要跨四套系统。Postgres、Redis、向量库、分析库，各查一遍。
每一步都有网络往返，每一步都可能读到旧数据。真正贵的不是查询，是把四份数据拼成一个能用的上下文。
所以今天要聊的 ParticleDB，就是想把这几套系统并成一个。
它官网的定位很直接：给 AI Agent 的数据库。关系型事实、向量记忆、实时运营数据，放进一个引擎。
一个引擎里到底装了哪几种能力？
五种。关系型 SQL，支持表、join 和 ACID 事务；键值，兼容 Redis 的命令；向量检索，有专门的向量类型和距离排序；实时分析，列式执行，直接查运营数据；最后是 Particles。
前四个我都能理解，Particles 是什么？
简单说，就是你自己写的函数，注册到数据库里，能在 SQL 里直接调用。官方现在支持 Python。
这听起来像存储过程。区别在哪？
存储过程一般用数据库自己的语言写，调试和依赖都受限。Particle 是普通 Python 函数，加一个装饰器，启动服务时把文件传进去。
那它解决的是什么痛点？
举个例子。Agent 要给候选动作打分，公式是影响乘以置信度。传统做法是把候选行全部拉到应用层，算完再写回去。
数据搬来搬去，慢，还容易出现算到一半应用挂了的问题。
Particle 的做法是在数据旁边算，只把结果带出来。省掉的不只是一次往返，还有一致性的麻烦。
这个设计思路我挺喜欢。计算靠近数据，跟以前把代码推到存储层是一脉相承的。
它的接口也尽量贴着现有生态。SQL 兼容 PostgreSQL 的连接方式，KV 兼容 Redis，另外还有 HTTP 和 gRPC。
SDK 呢？
Python、TypeScript、Java、Go、Rust 都有，还有一个 JDBC 驱动。现有项目不用换技术栈，拿熟悉的驱动连上去就行。
安装和启动复杂吗？
一条 curl 脚本安装，然后 particledb start，指定数据目录。服务端默认 7173，自带一个叫 Studio 的网页控制台，端口 7174，能看事务、KV、向量、分析和系统资源。
也就是说，它不是一个套在别的数据库外面的壳。
官方说存储、查询、事务都是自己实现的，用 Rust 从零写。
那它跟“拼四套数据库”相比，最大的好处是什么？
少维护三套系统，少三套同步任务，少三份可能不一致的数据。对 Agent 来说，上下文不用再靠应用层拼。
我想到一个很具体的场景。用 Redis 客户端写一个状态，再用 SQL 读同一个键。
对，官方就给了这个例子。redis-cli 写进去，SQL 里 KV_GET 读出来，同一份数据，多个接口。
这听着简单，但背后要求两套接口共享同一套存储和事务。
对，这才是难点。功能清单谁都能列，真正难的是让四种负载在同一个引擎里不打架。
那它的成熟度呢？新数据库最怕这个。
这也是我觉得它最值得讲的一段。他们请了 Kyle Kingsbury，也就是 Jepsen，做独立测试。
Jepsen 在数据库圈很有名，专门测一致性，手段很狠。
报告覆盖了 1.1.4 到 1.1.18.11.rc-22 这些版本，一共记录了 96 个问题，包括 SQL 正确性、事务隔离、并发异常和数据丢失。
96 个，这个数字不小。
更刺眼的是，很多问题出现在没有注入故障的单机部署上。也就是说，不是只有在网络分区、磁盘抖动这种极端场景才出问题。
单机都能测出数据丢失，那生产环境的风险只会更高。
官方的说法是，到 1.1.19 为止，报告里的问题都已处理。他们还把完整报告公开了。
这个态度比“我们很快”有用。但公开报告也意味着，大家都能看到它早期有多不稳。
对，这是一把双刃剑。对做数据库的公司来说，愿意被独立测试，本身就是一种表态。
那性能呢？新数据库总会放几张对比图。
它反而很克制。基准页面明确说，没有可复现的结果包，就不发布对比数字。
现在有哪些测试在跑？
ClickBench 测分析查询，TPC-C 测事务，另外还有应用分析和键值对比。官方说结果会连同方法、配置和原始日志一起放出来。
这比只放一个“快 3 倍”的柱状图可信。
但也意味着，现在还没有可比较的性能结论。你得自己压。
那如果听众今天就想试，你会怎么建议？
内部工具、原型、Agent 的记忆和状态层，可以先跑起来。它的接口确实省事。
核心账务呢？
别急着搬。先拿自己的数据量和查询模式压一遍，再读一遍 Jepsen 报告原文。官网首页那五张能力卡片，不能代替这两步。
我补一句，它的 GitHub 存在感也还很弱，server 仓库只有 4 个 star。
对，项目很年轻。年轻不等于不好，但意味着社区、文档、踩坑记录都还在积累。
说到最后，我觉得这期讲的其实是一个很老的话题：数据库卖的到底是什么？
功能可以一夜补齐，信任只能一轮一轮测试攒出来。ParticleDB 把 96 个问题摊开讲，这一步比多写五个 SDK 更像在做长期生意。
对做产品的人也一样。你愿意把最难看的测试结果放出来，用户才敢把数据交给你。
好了，今天这期就到这儿。感谢收听从零开始学AI，把这期转给那个正在维护四套数据库的朋友吧，我们下期见。