我用Rust构建了一个用于智能体跟踪的数据库（10亿行数据P95低于1毫秒）

过去几个月我一直在捣鼓智能体基础设施，存储层不断吃我们的预算。分享一下我们为了解决这个问题而构建的东西。 痛点：智能体跟踪的形状很奇怪。一个跟踪很长。每个跨度有数百个属性，其中大部分是NULL。非NULL的属性中有宽JSON载荷（提示词、工具输出、补全）。评估分数几周后才到达，需要干净地合并。热点查询是“显示整个跟踪”，而不是“扫描十亿行并聚合”。Postgres、ClickHouse和DuckDB在这种形状下性能都会下降。我们对10亿跨度进行了基准测试： - Postgres: P95跟踪获取延迟7.9毫秒 - DuckDB: P95跟踪获取延迟3.5秒 - ClickHouse: P95跟踪获取延迟178毫秒 - 我们: P95跟踪获取延迟571微秒 核心思想是跟踪局部性：在压缩时，单个跟踪的每个跨度都落在同一个行组中，按(trace_id, start_time, span_id)排序。无论数据集有多大，跟踪获取都只需一次段读取。这就是为什么从100万到10亿跨度延迟保持平稳。 其他设计选择：全文搜索（Tantivy）内嵌在存储段中，无需单独维护Elasticsearch作为边车服务。基于对象存储的WAL替代Kafka。延迟物化使得对于被其他谓词过滤掉的行，不会解码宽提示/补全列。 它叫ZenithDB。使用Rust开发，Apache 2.0许可，alpha版本。支持SQL和OTLP摄入。兼容OpenAI Agents SDK、Anthropic SDK以及任何OTel插桩的栈。 很好奇大家目前在用什么存储来存智能体跟踪。我听过很多“我们在用Postgres jsonb，但随着规模增长越来越慢”的故事；想知道这是否和大家的经历一致。