AI可观测性行业面临的挑战 - AI系统产生的数据量级与传统监控存在质变：生产环境AI系统每秒可产生10万个span（观测数据单元），单个span约50KB，一条完整追踪记录约10MB，P90分位时一个span可达几十MB，一条追踪记录可达几十GB，比传统可观测性数据大两到三个数量级[6][7] - AI数据具有半结构化、大体积、长周期和乱序更新的特点：追踪记录包含完整的提示词、模型回复、中间推理步骤等，字段常超过1MB；追踪可持续运行数天，反馈数据会乱序到达，数据库需支持对已完成记录的更新[7] - 读取需求呈现“双模式”，对数据库架构提出矛盾要求：工程师既需要快速精准加载单条数GB的追踪记录（行存储优势），又需要对海量数据进行快速扫描和聚合分析（列存储优势），两种模式必须同时高效[8] Braintrust公司原有架构的局限性 - 公司早期采用三件套架构（数据仓库、Postgres、浏览器端DuckDB）但遭遇全面瓶颈：数据仓库端到端数据延迟以分钟计；Postgres在负载上升后读写变慢，写入有时需几分钟且会无响应；浏览器端DuckDB存在正确性问题且内存消耗巨大[10][11][12] - 多系统架构带来高昂的维护成本和产品体验问题：需维护统一的查询语法（BTQL）到三种不同SQL方言的翻译，成本不可持续；全文搜索性能差，复杂查询返回错误结果，系统稳定性受开发者硬件配置影响[12][13] - 团队经过一年多实践后得出结论，原有架构需要推倒重来[14] Brainstore数据库的核心设计原则 - 所有数据存储在对象存储上：提供近乎无限的存储扩展能力和强一致性，同时大幅简化运维[16] - 每个客户的数据独立分区：避免全局大表导致的性能下降，查询仅需扫描特定客户数据，速度更快[16] - 将半结构化数据视为一等公民：原生支持对嵌套深、变化快、字段大的AI数据结构进行查询和过滤，而非强行拍平成关系型列[16] Brainstore数据库的写入与读取路径设计 - 写入路径追求高吞吐与异步索引：写入直接追加至对象存储的预写日志（WAL），无需协调与锁；后台异步进行数据处理与压缩，将WAL条目转换为多种高效索引格式[18][19] - 同时维护五种索引格式以服务不同查询模式：包括倒排索引、行存储、列存储、向量索引和布隆过滤器，以应对AI数据“太大太杂”的挑战[19][20] - 读取路径实现实时查询与多源合并：查询时合并未处理的WAL条目、已处理未压缩的数据及完全索引好的数据三个层次，确保数据写入后立即可查，无需等待压缩完成[21] Brainstore带来的关键产品特性 - 实现数据写入后的实时可见性：消除了传统架构中几分钟的延迟，满足在线调试的刚需[22] - 支持对超大追踪记录的精准快速加载：优化单条记录读取，避免全表扫描[22] - 提供交互式数据探索能力：在大数据量下，过滤、分组、聚合等操作仍保持交互性[22] - 将文本搜索作为核心调试功能：对提示词和回复的全文搜索是一等查询路径[23] - 架构简单，易于私有化部署：仅依赖无状态容器、对象存储、Postgres（元数据）和Redis（事务ID分配），降低了企业客户因合规要求进行部署的门槛[23] 自研数据库的决策逻辑与行业启示 - 现有数据库方案无法同时满足AI可观测性的全部核心要求：包括超大payload、半结构化数据、实时更新、双模式读取和私有化部署，现有方案如ClickHouse或Elasticsearch只能满足部分需求[26] - 自研数据库被视为一项集中的技术赌注：投入近两年核心工程资源，风险与收益并存；赌对则建立深厚护城河，赌错则可能导致产品发展停滞[27] - 这一决策揭示了AI时代基础设施层的重要趋势：AI正在重塑数据库、存储等底层组件；当应用场景足够独特时，“自建vs外购”的决策边界会发生移动[28] - AI可观测性能力直接关联产品迭代速度与竞争力：可观测性即调试性，快速洞察智能体行为与问题直接影响产品迭代速度，而数据体积随着智能体复杂化只会持续增长[28] - AI产品的竞争壁垒可能向工程化工具链转移：在模型与数据优势趋同的背景下，可观测性、评估、迭代等“脏活累活”背后的基础设施能力可能构成新的壁垒[29]