相同的 $16.49/月服务器，相同的 Traceway 二进制，两个嵌入式数据库。DuckDB 的写入速度比 SQLite 快 4 到 15 倍，能以 100 倍的行数提供仪表盘，且在 10.8 GB 中存储十亿个度量点。具体数字和方法论详见文中。简而言之，我花了六天时间工作，并运行了 DuckDB 的可观察数据基准测试。我在上一篇博客中使用了 SQLite，并非常想看看 DuckDB 在廉价 CCX13 Hetzner 实例上的表现。我测量数据的方式是将 DuckDB 实现为 Traceway 的有效存储引擎，然后运行其基准测试套件。基准测试显示，DuckDB 的列式引擎能够在没有任何重大后端更改的情况下查询 100 倍的数据点。写入吞吐量也高出 3 到 15 倍。结果是，你现在可以在一个相当小的服务器上自行托管完整的 OTel 堆栈，处理大数据量。继续阅读，了解我如何进行测量！以下是结果：SQLite（第 2 篇） DuckDB（本篇文章） 变化 指标写入 61,712 pts/sec 254,242 pts/sec 4 倍 Spans 写入 30,508 spans/sec 95,737 spans/sec 3 倍 Logs 写入 4,877 rec/sec 75,225 rec/sec 15 倍 指标读取临界值 1M 行（中位数 3.85 秒） 100M 行（中位数 3.0 秒） 100 倍 Spans 读取临界值 100k 行（中位数 2.27 秒） 10M 行（中位数 902 毫秒） 100 倍 Logs 读取临界值 100k 行（中位数 114 毫秒） 10M 行（中位数 85 毫秒） 100 倍 A 读取临界值，在整个系列中，最大的表大小是实际仪表盘页面仍然加载的最大表大小：三次端点探测的中位数在 5 秒内，且没有超时。之所以得名，是因为其后 10 倍的步长：查询不会减速，而是停止返回。每个信号的读取临界值在 DuckDB 上比在 SQLite 上远出 100 倍，延迟相等或更好，硬件相同。我在相信之前对原始 JSON 进行了两次对称性检查。该盒子在不到一小时内摄取了十亿个度量点，数据占用 10.8 GB，并保持正常运行，这一规模是 SQLite 基准从未接近过的 100 倍。日志，信号第 2 篇完全不建议使用 SQLite，是 DuckDB 的最大胜利。实际上在比较什么 第 2 篇承诺了一个 ClickHouse 的比较，那个帖子仍在筹备中。但是每次我坐下来构建它时，都会出现一个问题：在寻求一个客户端-服务器 OLAP 数据库之前，考虑到其自身的容器、内存需求和故障模式，一个嵌入式的能走多远？Traceway 提供一个可选构建的 DuckDB 远程数据后端，与 SQLite 构建相同的二进制文件、相同的部署方式，远程数据表下使用不同的存储引擎。如果你在一个便宜的服务器上自我托管，这两种构建就是你面前的实际决策，我找不到有人发布过相关数据。因此，我将第 2 篇的整个方法论与 DuckDB 构建进行了比较，并将结果并排展示。接下来是计划。方法论先，包括与第 2 篇相比的变更以及这些数字所依赖的后端中的一个修复。然后是写入，所有三种信号与其 SQLite 基准线的对比。接着是读取，相同的形式。然后是一亿行的运行，超过临界值的查询成本，两个构建的舰队数学，以及我实际上会运行哪个构建。 如何进行测量 设置与第 2 篇相同，所以我简短说明：一个运行 Traceway 二进制的测试系统（SUT），另一个在私有连接上的负载生成器，都是在 Hetzner 的纽伦堡数据中心，OTLP，OpenTelemetry 传输协议，通过 gzip 压缩 protobuf，统一随机数据在边界范围内。Traceway 从提交 14b4aa6e 构建，操作系统为 Ubuntu 24.04，在基准测试期间关闭数据保留。每个信号两个场景。 吞吐量爬升：以固定速率的批量大小爬升，然后在获胜批量上的请求速率爬升（这次使用了更细的速率阶梯，从 1 到 25 req/sec，因为有趣的临界值位于第 2 篇的更粗步长之间），然后是形状类似于 SDK 舰队的小批量高速爬升。一次测试通过的标准是错误率低于 5% 并且至少达成 70% 的目标速率。 读取探测：将表填充到 1M、10M、100M、1B，然后 5B 行，并在每一层加载每个信号的三个真实仪表盘端点，当中位数在 5 秒内且没有一个超过 6 秒超时时，水平通过。5 秒的标准是故意设定为宽松的，第 2 篇对此的讨论仍适用。与第 2 篇的测试工具有三个不同之处，全部披露：负载生成器增加了。第 2 篇的负载来自第二个 CCX13，而 SQLite 的上限从不施压。在我第一次从 DuckDB 生成 spans 的测试中，那个负载生成器在爬升过程中崩溃，而数据库保持 0% 错误率，流量产生器在崩溃之前就已经坏了。负载生成器现在是 CCX23。测试系统，没有变化。消化门。DuckDB 在摄取停止后检查其写前日志；在此期间探测会测量到繁忙的引擎，而非查询。读取探测现在会轮询后端的深度健康端点，直到数据库和 WAL 文件更新。