
EventSourcingDB 1.3.0 发布:性能提升并引入新 v2 API
来源标题:EventSourcingDB 1.3.0 Is Available
EventSourcingDB 1.3.0 正式发布,写入、EventQL 查询和读取速度均明显提升,每个请求都有时间上限,并包含六十多项修复。该版本新增 v2 API,在响应体中返回每个已接受请求的结果并为每种错误分配独立代码,与 v1 API 在相同数据上并行运行。v1 API 支持至 2027 年 1 月 31 日,官方文档已迁至 eventfoundation.io。
以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。
EventSourcingDB 1.3.0 已发布,速度更快、稳定性也超过以往任何版本。写入和 EventQL 查询的速度大幅提升,读取也更快,每个请求都有时间上限,此外还包含六十多项修复。除此之外,它还带来了新的 API:对于它接受的每个请求,结果都体现在响应体中;每个错误都有自己的错误码。
本文介绍有哪些改动,以及升级时需要注意什么。v1 API 的支持将持续到 2027 年 1 月 31 日,之后的某个版本会将其移除,因此你可以按自己的节奏迁移到新 API。从今天起,EventSourcingDB 的文档托管在 eventfoundation.io 上,所有旧链接都会指向那里。
新的 v2 API 与 v1 API 并行运行,使用同一份数据。它的核心理念很简单:一旦服务器接受了请求,其结果就体现在响应体中。请求被接受的条件是:已通过身份验证、请求体的结构与路由的预期相符,并且没有超出限制。前置条件不满足、事件类型未知、数据库处于只读模式——所有这些都会作为客户端可读的应答返回,而不是让客户端去解读某个状态码。
每个错误都带有一个错误码,该错误码是指向专门页面的链接,说明错误发生的原因以及如何修复。你可以在 Errors 下找到全部错误码。会结束的流式应答(例如读取事件)以一个显式的结束项收尾,这样客户端就能区分完整应答和被中断的应答。流在等待期间,服务器会通过它发送心跳,防止代理在此期间将其关闭。
v2 API 还带来了递归前置条件:isSubjectPristine、isSubjectPopulated 和 isSubjectOnEventId 现在可以连同其下所有 subject 一起作用于某个 subject。当决策依赖于整棵子树而非单个 subject 时,这非常有用。
全部八个客户端 SDK 的当前版本都同时支持两种 API,并在服务器提供 v2 API 时使用它。因此,除了更新 SDK 之外,你无需改动代码——前提是数据库前面的代理允许通过 v2 API 用于读取的 HTTP 方法 QUERY。如果你直接调用 HTTP API,Migrating to v2 会逐路由说明有哪些变化。
导出和导入让把事件迁移到新数据库变得更容易。两者都以每行一个普通 CloudEvent 的形式工作,包含其 ID 和时间,因此导出的数据可以直接导入,无需任何转换。由于导入会自行计算哈希,你也可以导出一段历史、从中移除个人数据,然后导入结果,而无需手动计算任何哈希。
增量备份只保存自上次备份以来写入的事件。恢复时需要一个完整备份加上其增量备份,这让大型数据库的常规备份保持很小。恢复本身也快了很多,因为它现在批量写入事件。
写入速度大幅提升,无论单个客户端还是多个客户端同时写入都是如此,而且不再随存储增长而变慢。运行 EventQL 查询也快了很多,尤其是读取大量事件、分组、排序或连接多个数据源的查询,读取事件同样如此。索引占用的文件大幅减少,因此在大型数据库中读取某个 subject 的事件变得更快,而校验存储完整性时会报告发现的每一处不一致(最多一百处),而不是只报告第一处。
1.3 中的许多其他工作在你需要之前是看不见的。每个请求、每个应答、每个空闲连接都有时间上限,因此缓慢或卡住的客户端再也无法永久占用资源。EventQL 查询对嵌套深度和内存占用都有限制,防止单个查询耗尽栈空间或随意占用内存。
服务器以恒定时间比较 API token,并拒绝使用可被猜到的 token 启动。如果写入存储失败(例如磁盘已满),它会切换到只读模式直到重启,继续提供读取服务,通过健康检查端点报告这一情况,并在日志中说明原因。Limits 列出了各项限制。
还有一些新增功能针对在生产环境中运行 EventSourcingDB。限流默认启用,并随机器规模扩展,因此发送过多请求的单个客户端无法压垮数据库。v2 API 的健康检查端点使用 OpenMetrics,这意味着你可以直接用 Prometheus 及类似工具抓取它,并且它会报告更多进程信息,例如内存和文件描述符;Logging and Monitoring 列出了它报告的内容。
如果你想确保只写入已知的事件类型,新标志 --require-event-schemas 会拒绝写入和恢复那些类型没有注册 schema 的事件。该标志默认关闭。此外,/.well-known/api-catalog 上的 API 目录会指引工具找到两个 API 的 OpenAPI 文档。
此版本在升级时需要一些注意。开始前请阅读 Upgrading EventSourcingDB;以下是最重要的几点:
升级指南和变更日志列出了所有其他需要注意的事项,例如对事件来源和事件 schema 的更严格规则。
在关键之处更快,在出错时更稳健,并在你熟悉的 API 旁边提供一个新 API:这就是 1.3。如果你已经在运行 EventSourcingDB,升级指南会带你安全完成升级。
如果你还没有尝试过 EventSourcingDB——这个为 Event Sourcing 打造的数据库,现在是个好时机。Installing EventSourcingDB 为你提供二进制文件和 Docker 镜像,Quickstart 则带你从启动服务器到写入并读取第一个事件,只需几分钟。我们很想知道你用它构建了什么。
native web 的 CTO 兼创始人。www.thenativeweb.io
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。