Jepsen: ParticleDB 1.1.4

本文为原文前 6,000 字符的节选翻译，完整内容请查看原文。

1 Background Modern applications often spread state across a variety of systems: databases, caches, queues, data warehouses, search indices, and so on. Coordinating these systems is challenging: caches are often stale, the analytics platform might lag days behind the primary database, the search index might lose data, and transactional updates across disparate systems remains an open research problem.

1 背景 现代应用程序通常将状态分布在各种系统中：数据库、缓存、队列、数据仓库、搜索索引等。协调这些系统极具挑战性：缓存往往会过期，分析平台可能比主数据库滞后数天，搜索索引可能会丢失数据，而跨不同系统的事务性更新仍然是一个悬而未决的研究课题。

ParticleDB1 aims to unify these workloads in a single engine with a special focus on AI agents and applications. It offers transactional SQL, a key-value store, vector search, live analytics, and user-defined functions called Particles.2 To integrate with existing systems, clients can connect through a variety of interfaces, including the Postgres and Redis protocols, as well as its own gRPC and HTTP2 APIs. Written from the ground up in Rust, ParticleDB claims to be orders of magnitude faster than Postgres while preserving the same safety characteristics.

ParticleDB1 旨在将这些工作负载统一到一个引擎中，并特别关注 AI 代理和应用程序。它提供事务性 SQL、键值存储、向量搜索、实时分析以及称为 Particles 的用户定义函数。为了与现有系统集成，客户端可以通过多种接口进行连接，包括 Postgres 和 Redis 协议，以及其自身的 gRPC 和 HTTP2 API。ParticleDB 使用 Rust 从零开始编写，声称在保持相同安全特性的同时，速度比 Postgres 快几个数量级。

ParticleDB was built by Orkes to support their workflow orchestration platform, Conductor. Conductor was initially built to store data in Redis and Postgres, but to improve performance, Orkes opted to write their own database. ParticleDB 1.0.0 offered a limited feature set specifically for Conductor’s queries, and was deployed as the backing database for some of their Conductor clusters. A few Orkes customers followed suit. In preparation for a broader release, Orkes undertook a major refactoring of ParticleDB, adding a custom wire protocol, more datatypes, additional OLAP queries, and more.

ParticleDB 由 Orkes 构建，旨在支持其工作流编排平台 Conductor。Conductor 最初构建时将数据存储在 Redis 和 Postgres 中，但为了提高性能，Orkes 选择编写自己的数据库。ParticleDB 1.0.0 提供了专门针对 Conductor 查询的有限功能集，并被部署为他们部分 Conductor 集群的后端数据库。一些 Orkes 客户也效仿了这一做法。为了准备更广泛的发布，Orkes 对 ParticleDB 进行了重大重构，增加了自定义传输协议、更多数据类型、额外的 OLAP 查询等。

While Orkes and their customers continued to run 1.0.0, they soft launched the refactored versions on particledb.ai. Orkes engaged Jepsen to test these versions of ParticleDB, beginning with 1.1.4. While ParticleDB could run as a single node, it also offered a replicated cluster using the Raft consensus protocol. This replication feature was available only in enterprise cloud deployments. The builds Orkes provided did not support replication, so this report covers only single-node behavior.

当 Orkes 及其客户继续运行 1.0.0 版本时，他们在 particledb.ai 上软发布了重构后的版本。Orkes 聘请 Jepsen 对这些版本的 ParticleDB 进行测试，从 1.1.4 版本开始。虽然 ParticleDB 可以作为单节点运行，但它也提供使用 Raft 共识协议的复制集群。此复制功能仅在企业云部署中可用。Orkes 提供的构建版本不支持复制，因此本报告仅涵盖单节点行为。

1.1 Safety ParticleDB’s home page advertised that ParticleDB was “formally proven” with a TLA+ proof. However, during our collaboration no TLA+ specification was available. It is unclear what properties might be proven, or whether they described ParticleDB as built. ParticleDB offered three tactics for syncing its Write-Ahead Log (WAL). The sync mode called fsync on each commit, groupsync batched multiple transactions into a single fsync, and nosync skipped fsync altogether.

1.1 安全性 ParticleDB 的主页宣称 ParticleDB 已通过 TLA+ 证明“经过形式化验证”。然而，在我们的合作期间，没有提供任何 TLA+ 规范。目前尚不清楚可能证明了哪些属性，也不清楚它们是否描述了构建后的 ParticleDB。ParticleDB 提供了三种同步其预写日志 (WAL) 的策略。sync 模式在每次提交时调用 fsync，groupsync 将多个事务批处理为单个 fsync，而 nosync 则完全跳过 fsync。

The Transaction Engine documentation described sync as offering “stronger durability” than groupsync. On the other hand, particledb start —help said the groupsync mode ensured that “COMMIT waits for flush”, and Orkes’ internal operator guide concurred: groupsync offered the “same durability as sync”. ParticleDB’s home page proudly claimed “Full ACID. 159K TPS.” However, the text immediately below this said “snapshot isolation”, which is not fully isolated.

事务引擎文档将 sync 描述为比 groupsync 提供“更强的持久性”。另一方面，particledb start —help 指出 groupsync 模式确保“COMMIT 等待刷新”，Orkes 的内部操作指南也表示赞同：groupsync 提供与 sync “相同的持久性”。ParticleDB 的主页自豪地宣称“完全 ACID。159K TPS。”然而，其下方的文字却写着“快照隔离”，这并非完全隔离。

Most SQL databases use the SET TRANSACTION ISOLATION LEVEL statement to control the concurrent semantics of a transaction. However, ParticleDB ignored or rejected these statements. In some cases it instructed users to choose READ COMMITTED, a relatively weak isolation level. In other cases it accepted requests for different isolation levels, and silently ignored them (despite documentation to the contrary). Instead, transaction isolation was governed by the —txn-mode setting passed at startup.

大多数 SQL 数据库使用 SET TRANSACTION ISOLATION LEVEL 语句来控制事务的并发语义。然而，ParticleDB 忽略或拒绝了这些语句。在某些情况下，它指示用户选择 READ COMMITTED，这是一种相对较弱的隔离级别。在其他情况下，它接受了对不同隔离级别的请求，并默默地忽略了它们（尽管文档中另有说明）。相反，事务隔离由启动时传递的 —txn-mode 设置控制。

The transaction engine documentation described four modes: Mode Behavior When to use fast No locks; commit-on-write Bulk loads, single-writer benchmarks occ Overlay + commit-time OCC validation (default) General OLTP — safe under concurrency zero-copy-occ Partition-pinned OCC; single-partition txns skip cross-partition coordination High-throughput OLTP on partition-affine workloads (TPC-C, key-value) table-2pl Exclusive table locks at first touch Strictest serialization, simple semantics

事务引擎文档描述了四种模式：模式 行为 使用场景 fast 无锁；写入时提交 批量加载，单写入者基准测试 occ 覆盖 + 提交时 OCC 验证（默认） 通用 OLTP — 并发下安全 zero-copy-occ 分区固定 OCC；单分区事务跳过跨分区协调 分区亲和工作负载上的高吞吐量 OLTP（TPC-C，键值） table-2pl 首次接触时独占表锁 最严格的序列化，简单语义

This table was difficult to interpret. While the best practices documentation warned that users should “pick —txn-mode deliberately”, since “it changes correctness and throughput characteristics more than SQL text does”, the documentation did not explain what these modes actually guaranteed. The fast mode was clearly intended for weaker isolation, but was that Read Atomic, Read Uncommitted, or something else? The occ mode was similarly unclear.

该表格难以解读。虽然最佳实践文档警告用户应“谨慎选择 —txn-mode”，因为“它对正确性和吞吐量特性的改变比 SQL 文本更大”，但文档并未解释这些模式实际上保证了什么。fast 模式显然旨在实现较弱的隔离，但那是读原子性、读未提交还是其他什么？occ 模式同样不明确。

“Commit-time OCC validation” could describe a broad spectrum of consistency models from Read Uncommitted to Strong Serializable, but “safe under concurrency” suggests it might be Serializable. The zero-copy-occ mode described a performance optimization which could be as safe as occ, but it was not described as “safe under concurrency”—raising the question: in what ways was it unsafe? Finally, if table-2pl offered the “strictest serialization”, was occ some weaker isolation level?

“提交时 OCC 验证”可以描述从读未提交到强序列化的一系列广泛的一致性模型，但“并发下安全”暗示它可能是可序列化的。zero-copy-occ 模式描述了一种性能优化，其安全性可能与 occ 相当，但它并未被描述为“并发下安全”——这引发了一个问题：它在哪些方面不安全？最后，如果 table-2pl 提供了“最严格的序列化”，那么 occ 是否是一种较弱的隔离级别？

The CLI reference page contained another table which described occ and table-2pl as “Jepsen-safe”, whereas fast was not “Jepsen-safe”, but did not explain their safety properties. Since Jepsen evaluates safety with respect to documentation and marketing claims, it is not clear how to interpret these terms.3 Running particledb start —help provided the following table: Mode Description fast No locks, maximum OLTP throughput (unsafe under concurrency) occ Table locks + commit-time validation (safe for most OLTP) row-2pl Alias for occ zero-copy-occ Partition-pinned OCC (highest throughput safe mode) table-2pl Exclusive table locks, full serialization (strictest) serializable Alias for table-2pl serializable-ssi Adaptive SSI (Cahill 2008), PL-3 with optimistic semantics (v1 scaffolding — see SSI_ADAPTIVE_DESIGN.md)

CLI 参考页面包含另一个表格，将 occ 和 table-2pl 描述为“Jepsen 安全”，而 fast 则不是“Jepsen 安全”，但并未解释其安全属性。由于 Jepsen 根据文档和营销声明来评估安全性，因此不清楚如何解释这些术语。运行 particledb start —help 提供了以下表格：模式 描述 fast 无锁，最大 OLTP 吞吐量（并发下不安全） occ 表锁 + 提交时验证（对大多数 OLTP 安全） row-2pl occ 的别名 zero-copy-occ 分区固定 OCC（最高吞吐量安全模式） table-2pl 独占表锁，完全序列化（最严格） serializable table-2pl 的别名 serializable-ssi 自适应 SSI (Cahill 2008)，具有乐观语义的 PL-3（v1 脚手架 — 参见 SSI_ADAPTIVE_DESIGN.md）

The point of Optimistic Concurrency Control (OCC) is generally to avoid taking locks, so the mention of table locks and a row-2pl4 alias was surprising. Moreover, “safe for most OLTP” undermines the claim that occ was “safe under concurrency”; i

乐观并发控制 (OCC) 的目的通常是避免加锁，因此提到表锁和 row-2pl4 别名令人惊讶。此外，“对大多数 OLTP 安全”削弱了 occ “在并发下安全”的说法；i