SurrealDB 3.x 与 Postgres、Mongo、Neo4j 和 Redis 的基准测试（含Fsync）

# SurrealDB 3.x 数据解读 来源：https://surrealdb.com/blog/surrealdb-3-x-by-the-numbers ## 单一引擎，多工作负载，完整持久性 您可以访问 [基准测试页面](https://surrealdb.com/benchmarks) 查看完整结果、方法以及各数据库的详细分解。 ## 我们为何运行这些基准测试 数据库基准测试众所周知容易被操纵，且难以做到公平。不同的硬件、不同的持久性设置、不同的客户端库，或者恰好适合某个引擎索引策略的工作负载——任何一点都可能倾斜数字。因此我们做了三件事： 1. 所有数据库均在同一硬件上运行——AMD Ryzen Threadripper 9970X（32核/64线程）、128 GiB DDR5、NVMe 存储、Ubuntu 24.04。 2. 使用相同的开源测试工具 [crud-bench](https://github.com/surrealdb/crud-bench)，将每种工作负载翻译成各引擎的原生查询语言，以避免因不熟悉的方言而惩罚任何数据库。 3. 将每个引擎配置为生产级持久性——启用 fsync、快照隔离、无内存捷径（除非明确指出用于嵌入式对比）。 我们还特意给每个数据库公平的机会。我们并未使用各引擎的出厂默认设置，而是**全面采用优化配置**——即生产团队在上线前会应用的那种调优。具体包括：提高连接和工作者池限制以匹配128客户端负载、调整缓冲池、页面缓存和共享内存大小以充分利用128 GiB RAM、启用并行查询执行和预编译语句缓存（如果支持）、将WAL和检查点间隔设置为各项目性能指南推荐的值，并启用各数据库文档为OLTP工作负载推荐的索引和存储引擎（InnoDB、WiredTiger、RocksDB等）。目标是确保没有引擎因保守的默认配置而受限——如果某个数据库在此表现不佳，那绝不是因为我们使用了适合笔记本电脑的初始配置。 工作负载由128个客户端发出，每个客户端执行48个并发查询，数据集为单表，包含500万至1500万行混合类型记录（字符串、整数、浮点数、UUID、日期时间、布尔值、大文本字段、地理空间数据以及嵌套对象和数组）。 ### 关于上次的说明 我们需要对持久性做一个说明。上一轮基准测试结果中，所有引擎都禁用了 `fsync` —— 每个数据库的写入仅停留在操作系统页面缓存中，而未刷新到磁盘。比较中的所有数据库都使用相同设置，因此并没有相对于其他引擎“作弊”，但我们没有明确说明该设置，最终的头条数字描述的大多数生产部署可能不会运行的工作负载。 这一轮不同了。**这些基准测试中的每个数据库都启用了完整的磁盘持久性**——`fsync` 开启，每次提交时WAL刷新，没有隐藏在内核缓存后的缓冲写入。每个引擎的配置文件已提交到 [基准测试仓库](https://github.com/surrealdb/benchmarks) ，任何人都可以审查。以上数字是每个引擎在客户端收到确认之前，每个已提交事务都已写入磁盘时所能维持的性能。这比你在某些营销文章中（包括我们自己的）看到的缓存友好型数字要慢，但这是比较能够在断电后存活下来的数据库的唯一诚实方式。 ## SurrealDB 的进步 最大的故事在于内部。跨越三个主要版本，我们从根本上重构了查询、解析器和存储层： | 工作负载 | SurrealDB 1.x | SurrealDB 2.x | SurrealDB 3.x | |----------|---------------|---------------|---------------| | 混合 CRUD（50% 写入） | 78k ops/s | 107k ops/s | **141k ops/s** | | 全表扫描 | 0.06 ops/s | 0.09 ops/s | **11 ops/s (164×)** | | 索引查找 | 32 ops/s | 44 ops/s | **104 ops/s (3.2×)** | 仅从 SurrealDB 2.x 到 3.x： - CRUD 平均吞吐量提升 31% - 批量操作速度提升 58% - 无索引全表扫描速度提升 11,894% - 索引查询速度提升 136% - 尾部延迟改善：CRUD 改善 27%，批量操作改善 32%，索引查询改善 59%，扫描改善 99% 扫描数字并非笔误。SurrealDB 3.x 的查询计划器和存储引擎消除了早期版本中占主导地位的逐行解码开销，因此过去需要几分钟的工作负载现在只需几秒即可完成。 ## 与其他数据库的对比 SurrealDB 是一个持久化、事务性、多模型数据库，因此最重要的比较对象是用户实际评估它的主要数据库——PostgreSQL（关系型）、MongoDB（文档型）、Neo4j（图型）。以下是在同一硬件上、每个引擎均采用调整后的生产级配置时，相同工作负载在这三类数据库中的表现。 ### 对比 PostgreSQL（以及 MySQL） CRUD 吞吐量（ops/s）和批量读取指标： | 工作负载 | SurrealDB | PostgreSQL | MySQL | |----------|-----------|------------|-------| | 创建 | 122k | 83k | 22k | | 读取 | 254k | 327k | 195k | | 更新 | 106k | 81k | 22k | | 删除 | 156k | 86k | 22k | | 写入吞吐量（C+U+D 平均） | 128k | 84k | 22k | | 500万行上的 count(*) | 128 | 42 | - | SurrealDB 在所有写入操作上都比 PostgreSQL 快——**创建约 1.5 倍、更新约 1.3 倍、删除约 1.8 倍**——而 PostgreSQL 在原始单记录读取上仍然略胜一筹。与 MySQL 相比，差距进一步拉大：SurrealDB **在写入上快 5-7 倍**。 平均创建、更新和删除操作，**SurrealDB 的写入吞吐量约为 PostgreSQL 的 1.5 倍**——这是基准测试页面在关系型类别中引用的头条数字——并且在全表计数上比 PostgreSQL 快约 1.5 倍。PostgreSQL 的查询计划器已有 30 年历史，在索引谓词过滤方面仍然领先；我们不会假装不是这样，并且正在努力在 3.1 版本中缩小这一差距。 ### 对比 MongoDB（以及 ArangoDB） CRUD 吞吐量（ops/s）和批量读取指标： | 工作负载 | SurrealDB | MongoDB | ArangoDB | |----------|-----------|---------|----------| | 创建 | 122k | 183k | 1.0k | | 读取 | 254k | 200k | 255k | | 更新 | 106k | 160k | 0.9k | | 删除 | 156k | 200k | 1.0k | | 过滤扫描（无索引，ops/s） | 8.3 | 3.0 | 8.5 | 这是最接近的竞赛。MongoDB 在单记录写入上仍然领先，而 SurrealDB **在读取上约快 1.3 倍**——而且在更重的工作负载上情况翻转。在无索引表上的谓词过滤扫描——基准测试页面用于文档类别的头条指标——**SurrealDB 比 MongoDB 快约 2.7 倍**，并且始终具有更低的平均和 p99 延迟。与 ArangoDB 的文档引擎相比，SurrealDB **在写入上快 100 到 150 倍**。 ### 对比 Neo4j（以及 ArangoDB） CRUD 吞吐量（ops/s）和批量读取指标： | 工作负载 | SurrealDB | Neo4j | ArangoDB | |----------|-----------|-------|----------| | 创建 | 122k | 42k | 1.0k | | 读取 | 254k | 174k | 255k | | 更新 | 106k | 50k | 0.9k | | 删除 | 156k | 44k | 1.0k | | 过滤扫描（已索引，平均 ops/s） | 421 | 12 | - | SurrealDB 在所有 CRUD 操作上都优于 Neo4j——**写入约快 2-3.5 倍**，**读取约快 1.5 倍**——同时在处理文档和表的同一引擎上运行相同的图遍历。 过滤扫描上的差距更加显著。在索引谓词过滤查询上——基准测试页面用于图形类别的头条指标——**SurrealDB 比 Neo4j 快约 35 倍**。无需单独的数据库、单独的查询语言或单独的操作方案。 ### 参考点：Redis 和 KeyDB 针对原始键值吞吐量，我们还运行了 SurrealDB 的内存引擎（带追加式持久化），并与 Redis 和 KeyDB 进行了对比： | 操作 | SurrealDB | Redis | KeyDB | |------|-----------|-------|-------| | 创建 | 300.8k | 85.8k | 79.5k | | 读取 | 288.1k | 367.9k | 348.6k | | 更新 | 300.6k | 89.0k | 85.2k | | 删除 | 279.3k | 100.6k | 100.0k | 这大约相当于**在写入、更新和删除上比 Redis 快 3 倍**，同时提供持久化、快照隔离的事务以及 Redis 所不具备的完整查询语言。Redis 在大型 1000 条记录批量操作上仍然胜出，并在单记录读取上略微领先。 ### 嵌入式模式（对比 SQLite） SurrealDB 的嵌入式引擎在相同的磁盘格式上运行相同的 SurrealQL，如同服务器版本。 | 工作负载 | SurrealDB 嵌入式 | SQLite | |----------|------------------|--------| | 创建 | 110k | 1.3k | | 读取 | 138k | 154k | | 更新 | 145k | 1.3k | | 删除 | 101k | 1.3k | | 过滤扫描（无索引，ops/s） | 39 | 6 | | 过滤扫描（已索引，平均 ops/s） | 7.5k | 2.3k | 与 SQLite 相比，SurrealDB **创建快约 85 倍，更新快约 110 倍，删除快约 75 倍**，单记录读取大致相当。在无索引表上的谓词过滤扫描中，它比 SQLite **快约 6.5 倍**，在已索引过滤扫描中**快约 3 倍**。 完整的详细分解——包括 p50、p95 和 p99 延迟、100 到 1000 行的批量大小、已索引和无索引谓词过滤以及全文搜索——都在 [基准测试页面](https://surrealdb.com/benchmarks) 上。 ## 弥补剩余差距 以上数字是诚实的快照，并非终点线。仍然存在一些工作负载，其中 Redis、MongoDB 和 PostgreSQL 击败了我们——例如与 Redis 相比的大批量操作、与 Mongo 相比的单记录写入、与 PostgreSQL 相比的已索引谓词过滤——并且我们确切知道每个差距的来源。弥补这些差距是 SurrealDB 3.1 开发周期的核心重点。 我们正在积极努力的方向： - 批处理路径重写，使 100 行和 1000 行的批量操作更接近 Redis 的吞吐量，包括更好的客户端管道设计和更精简的服务端批处理执行器。 - 更智能的查询计划器，带有基于成本的优化、谓词下推到存储引擎以及更丰富的索引选择性统计信息——这是实现与 PostgreSQL 在已索引过滤扫描上持平的工作。 - 针对文档工作负载的存储层改进——更紧凑的就地更新、更低的写放大、键编码与文档路径解析器之间的更紧密集成——这正是 Mongo 目前在单记录写入上占优的地方。 - 向量和图遍历优化，随着这些工作负载加入基准测试套件，使多模型故事在同样严格的 CRUD 级别上成立。 目标并非“在某方面最快”。而是**在所有重要的工作负载上最快，或具有竞争力**，同时保持任何专业引擎无法匹敌的一个特性：一种查询语言（SurrealQL）能够处理关系型、文档型、图型、键值、时间序列、向量和全文搜索数据，所有这些都在同一个数据库中，具有相同的事务保证，使用相同的磁盘格式——并且同一引擎，无论你是在应用程序内嵌入式运行、在单台服务器上运行、在靠近用户的边缘运行，还是分布式运行于数百个节点以实现水平扩展。我们认为你不必在 PostgreSQL、MongoDB、Neo4j 和 Redis 之间做出选择——也不必在开发笔记本电脑上运行的数据库和跨全球机群运行的数据库之间做出选择。我们认为单一的数据库应该能够以生产速度运行所有四种形状的工作负载，无论它位于何处，而上面 SurrealDB 3.x 的数字是迄今为止最有力的证据。 ### 这对 AI 代理为何重要 我们之所以不断推动这种数据模型的组合，是有原因的，而且并非历史偶然。**代理记忆本质上是多模型的。**一个有用的 AI 代理需要关于世界的结构化事实（关系型）、半结构化上下文和工具输出（文档型）、实体和事件关系（图型）、用于语义回忆的嵌入（向量）、语料库的关键词和 BM25 检索（全文搜索）、情节和时间上下文（时间序列），以及快速的会话和缓存状态（键值）——并且所有这些都需要存在于单一的事务一致性存储中，因为一旦这些形状位于不同的数据库中，你就构建了一个胶水代码问题，每当模式更改或模型更新时都会崩溃。 代理还需要**在其运行位置附近**的记忆。在浏览器、手机、车载系统或每租户边缘工作器中推理的代理，无法承受每次检索都往返于中央数据库的代价。SurrealDB 作为嵌入式引擎运行，使用与分布式服务器相同的磁盘格式——相同的查询语言和相同的事务保证——这一事实使其非常适合在本地、边缘和集中部署之间灵活移动的代理作为记忆层。更快的 CRUD、更快的扫描和更快的索引查找不仅仅是抽象的基准测试胜利；它们直接决定了代理可以调用多少工具、每次轮询可以回忆多少上下文、以及单个主机可以支持多少并发代理。这正是 SurrealDB 3.x 所构建的工作负载，也是下一轮基准测试（涵盖向量搜索、图遍历和全文检索）将直接衡量的工作负载。 ## 下一步计划 我们计划将基准测试扩展至涵盖 **CockroachDB、TiDB、MongoDB 和 Aerospike** 以进行分布式比较，这些将在未来一轮中发布。我们还计划扩展工作负载集，包括图遍历、向量搜索和全文搜索——这两个领域正是 SurrealDB 单一引擎多模型设计展现最大优势的地方。 在此之前：测试工具是开源的，结果可重现，我们希望您能在自己的硬件上运行并告诉我们您的发现。