刚刚在 Interrupt! 大会上宣布！SmithDB。代理追踪已经超出了为它们构建的数据库的容量。这就是为什么我们构建了 SmithDB，一个专为代理可观测性设计的分布式数据库。阅读联合创始人 @ankush_gola11 的公告 → https://langchain.com/blog/introducing-smithdb/?utm_source=linkedin&utm_medium=social…

我们构建了 SmithDB——代理可观测性的数据层

来源：https://www.langchain.com/blog/introducing-smithdb?utm_source=linkedin&utm_medium=social 我们推出了 SmithDB，这是我们专为代理可观测性构建的分布式数据库，现已成为核心 LangSmith 工作负载的基础。

SmithDB 为 LangSmith 提供了关键可观测性工作负载中的行业领先性能，具备可移植性，能部署在客户需要数据驻留的任何位置，并支持传统可观测性存储无法设计的代理原生查询模式。

代理带来了新的数据问题

在代理可观测性中，追踪是代理的核心行为记录（https://www.langchain.com/blog/in-software-the-code-documents-the-app-in-ai-the-traces-do）。

当 LangSmith 在 2023 年首次推出时，AI 应用相对简单：团队正在构建 RAG 管道、提示链和非常早期的代理。

自那以后，代理变得更加普及且运行时间更长，LLM 上下文窗口大小急剧增加，工作负载中越来越多地包含图像和音频等多模态内容。

因此，与现代代理相关的追踪数据在数量（追踪数量）和大小（单个负载大小）上都出现了爆炸式增长。一个现代代理追踪可能包含数百个深度嵌套的跨度。

smithdbpayloadovertime.png)

.png)

除了庞大且嵌套外，代理追踪还是分片到达的：代理跨度的开始事件可能在结束事件几分钟甚至几小时前到达。

分析这些数据所需的查询模式也变得越来越复杂。代理可观测性需要支持：

• 随机访问： 即时加载单个运行或追踪
• 交互式过滤： 按元数据、反馈、延迟、错误、标签和时间对大型追踪数据集进行切片
• 全文搜索： 在代理运行的输入和输出中查找短语和模式
• JSON 过滤： 查询任意用户定义的元数据和结构化工具输出
• 树感知查询： 基于根运行、子运行或追踪中的任何节点进行过滤
• 线程重建： 立即跨多个代理追踪重建长时间运行的对话
• 聚合： 计算不同过滤条件下的成本、延迟、令牌使用量、评估器分数

支持所有这些功能，并在低延迟下处理大型代理追踪，同时满足自托管和多云要求，需要一种全新的架构。

这就是 SmithDB 背后的动机。

介绍 SmithDB

SmithDB 是 LangSmith 的数据层，专为代理可观测性和评估工作负载而构建。

它使用 Rust 构建，并利用 Apache DataFusion 查询引擎和 Vortex 文件工具包，针对 LangSmith 的独特工作负载进行了大量定制。

在高层次上，SmithDB 由三个组件组成：

1. 对象存储用于持久追踪数据
2. 小型 Postgres 元存储用于段元数据
3. 无状态摄取、查询和压缩服务

%201.png)

性能

对于可观测性来说，性能不仅仅是锦上添花。对于人和代理而言，缓慢的可观测性工具会成为代理开发循环中的瓶颈。SmithDB 在代理可观测性关键工作负载上提供了领先的性能，使核心 LangSmith 体验比之前快达 15 倍。

工作负载SmithDB 延迟追踪树加载P50 92ms / P99 595ms单次运行加载P50 71ms / P99 358ms运行过滤P50 82ms / P99 434ms追踪摄取P50 630ms / P99 1.47s全文搜索P50 400ms / P99 870ms线程过滤P50 131ms / P95 268ms

可移植性

由于 SmithDB 由对象存储支持，因此无需管理本地磁盘。查询和摄取服务是无状态的。系统通过增加计算资源进行扩展，而持久数据则存储在对象存储中。

这使得 SmithDB 在自托管和多云环境中比需要本地磁盘和复杂分片的传统数据库集群更容易部署。

SmithDB 现已服务于生产流量

今天：

• 100% 的美国云摄取 流向 SmithDB
• 100% 的追踪 UI 查询流量 流向 SmithDB，包括线程
• 所有主要过滤器 均由 SmithDB 支持，包括元数据、反馈、文本搜索、树过滤器和追踪过滤器
• 产品集成（如运行规则、批量导出和实验）即将完成

很快：

• 所有相关的产品表面都将迁移到 SmithDB，并且 SmithDB 将可用于 LangSmith 的自托管部署。

早期反馈

过去几个月，我们一直在将客户工作负载迁移到 SmithDB。以下是 Clay、Vanta、Unify 和 Cogent 团队的评价：

我们每天向 LangSmith 记录数亿个代理可观测性事件。SmithDB 使我们的团队能够以改进生产环境代理所需的速度搜索、调试和分析这些数据。性能改进立竿见影，令人印象深刻，尤其是在大型项目上，以前追踪探索往往是瓶颈。—— Jeff Barg，Clay 公司 AI 主管

迁移到 SmithDB 后，性能改进立刻变得明显。我们的用户体验感觉明显更灵敏，探查数据变得比以往更快、更直观。这是一次很棒的体验。—— Andy Almonte，Vanta 公司 AI 高级工程经理

我们有很多包含大型工具调用的追踪，迁移到 SmithDB 后，在我们的项目中查询和阅读追踪变得容易得多。这帮助我们更快地定位边缘情况、构建评估数据集并迭代追踪。—— Kunal Rai，Unify 公司 AI 软件工程师

在 Cogent，我们的后台代理可能会一次性产生大量追踪。我们需要对这些系统进行实时可观测性，而 SmithDB 能够提供这种体验：在几秒钟内看到追踪，而不是几分钟——这是我们测试其他提供商时遇到的情况。—— Larsen Weigle，Cogent Security 公司技术人员

关键工程挑战

为了让 SmithDB 成为代理可观测性工作负载的高性能数据库，工程上投入了巨大的努力。

在高层次上，SmithDB 构建为基于对象存储的日志结构合并树（https://en.wikipedia.org/wiki/Log-structured_merge-tree）（LSM）。LSM 在内存中缓冲写入，将数据作为不可变的排序批次刷新到持久存储，并定期将这些段合并在一起。在查询时，读取多个段并将它们合并为单个有序流。

SmithDB 有五个主要组件：

• 摄取服务： 接受追踪写入，按分区和时间桶进行批处理，并写入不可变文件
• 元存储： 记录段元数据，包括位置、时间范围、行数和更新/删除向量
• 查询服务： 公开查询接口，具有自定义执行计划，理解 LangSmith 运行语义和对象存储。大量使用 SSD 和内存缓存。
• 压缩服务： 将写优化段重写为查询优化段，同时应用删除、升级、TTL 过期和索引合并
• 集群管理器： 将实时服务节点分配给键范围。这很重要，因为 SmithDB 不仅尝试分配负载，还尝试使重复查询落在可能缓存了正确数据的节点上。

以下是关键工程挑战的一些细节，我们将在未来的博客文章中进一步展开：

在对象存储上进行渐进式查询

许多 LangSmith 查询会询问特定租户和追踪项目的最新运行。一种天真的对象存储方案会发现所有候选文件，打开其中许多文件，排序合并并去重数据，然后才应用限制。

SmithDB 向后遍历时间，并在最新的候选段上构建一个有界时间窗口。这将“先排序所有内容，再限制”转变为“读取最新的有界切片，流式处理、合并和去重行，并在正确性允许时立即停止”，这显著减少了完成“Top K”风格查询时扫描的数据量。

%201.png)

从摄取节点读取新鲜数据

对象存储是持久的事实来源，但最新鲜的数据通常仍然存在于写入它的摄取节点上。

每个文件段记录产生该节点的服务器标识符。如果该写入节点仍然在线，查询规划器可以使用自定义计划直接从摄取节点的本地 SSD 和内存缓存扫描这些文件，而不是立即从对象存储读取它们。这使我们无需从对象存储中读取许多小文件来满足前沿查询。

%201.png)

每次运行的多个事件

代理可观测性围绕长时间运行的跨度构建。

在传统的请求/响应应用程序中，跨度可能在毫秒内开始和结束。但代理跨度可以保持打开更长时间。单个运行可能涉及模型完成、工具调用、重试、后台工作或移交给其他代理。在跨度完成之前等待写入任何内容并不理想。

在 SmithDB 中，运行是一系列事件，而不是单个不可变行。这听起来简单，但会影响整个查询引擎。需要格外小心地将过滤器分派到特定事件，并在查询时以高效的方式合并事件。处理每次运行的多个事件也会影响我们的压缩策略。

时间分层压缩

摄取优化了写入延迟，从而产生许多小的不可变段。永远查询这些段会带来过多的文件打开开销和去重工作。

压缩将这些写优化段转换为查询优化段。SmithDB 使用时间分层策略。时间分层决定了 SmithDB 的压缩强度。最近的数据更有可能接收结束事件，因此过早将其压缩成大文件会造成不必要的写入放大。较旧的数据更稳定，更可能被重复扫描，因此值得将其折叠为更大的文件。

这使摄取保持快速，同时逐步使较旧数据的查询成本更低。

删除、TTL 和保留策略更改

在可观测性系统中，删除和升级等修改通常很困难，因为数据文件是不可变的。默认情况下，SmithDB 不会为每次删除同步重写数据文件。相反，元存储将删除和升级向量附加到段条目中。查询和压缩路径使用这些向量来正确解释不可变文件。文件重写在压缩期间发生。

这种策略使 SmithDB 中的修改具有高度可扩展性。这对于代理可观测性尤其重要，因为保留策略很少是统一的。大多数追踪对于最近的调试、监控和评估很有用，但只有一小部分需要根据特定追踪的内容长期保留。

大字段的延迟物化

代理追踪通常包含大型、无界的负载。SmithDB 通过将核心运行字段与大字段分离，使常见列表和过滤查询保持快速。核心行携带指向大字段文件的指针，查询引擎仅在查询实际投影这些字段时才获取那些大型负载。

这意味着加载运行列表或应用过滤器不需要读取兆字节的 JSON，除非用户实际打开运行或请求这些字段。

全文搜索和 JSON 过滤

支持对 1MB+ 负载进行亚秒级全文搜索和 JSON 键路径过滤是一个具有挑战性的工程问题。

SmithDB 通过针对对象存储优化的自定义倒排索引布局高效处理这些查询。在本地磁盘上，索引可以依赖廉价的寻道和许多小读取。在对象存储上，这种模式失效：每个不必要的请求都会增加延迟，过早获取大型 posting 列表或位置列表可能会主导查询。

SmithDB 的索引布局旨在避免这种情况。术语被排序到行组中，每个行组记录最小/最大术语区域。因此，精确和前缀术语查询可以在 SmithDB 获取 posting 字节之前修剪索引行组。posting 和位置与术语字典分开分块，因此常见术语不会强制进行一次巨大的内存分配或一次巨大的对象存储范围读取。行组和分块阈值限定了构建内存和查询时 I/O。

集群管理和粘性路由

SmithDB 包含一个轻量级集群管理器，用于控制哪些服务节点拥有哪些流量。这很重要，因为 SmithDB 不仅尝试分配负载，还尝试使重复查询落在可能缓存了正确数据的节点上。

集群管理器灵感来自 Google 的 Slicer（https://research.google/pubs/slicer-auto-sharding-for-datacenter-applications/）和 Databrick 的 Dicer（https://www.databricks.com/blog/open-sourcing-dicer-databricks-auto-sharder）项目，通过将键空间划分为切片并将每个切片分配给一组稳定的服务节点来避免这种情况。路由器使用这些分配将相关请求发送到同一节点或小型副本集。

这赋予了 SmithDB 两个重要特性：

• 粘性路由： 相关请求更有可能落在已缓存正确元数据或段字节的节点上。
• 自适应平衡： 当节点加入、离开或过载时，集群管理器可以移动切片而无需更改持久段元数据。

接下来是什么

除了将更多 LangSmith UI 迁移到由 SmithDB 支持外，我们对这个数据层解锁的新产品体验感到非常兴奋。

LangSmith 的下一阶段不仅仅是更快的追踪加载。而是让追踪数据更有用：更容易搜索、更容易分析、更容易反馈到代理开发循环中。SmithDB 将成为实现这一目标的基础层。

我们也在寻找有才华的系统和数据库工程师加入我们！（https://www.langchain.com/careers）

试用 SmithDB（https://smith.langchain.com/）