跳转到主要内容

黄东旭:在中国打造数据库初创公司

阅读需 1 分钟Tian PanTian Pan

公司

  • 总共成立四年,前两年都在写代码,最近一年半有一两百家企业在用
  • Infra 在中国做很有优势,因为中国市场大,公司快糙猛拿来主义,infra 的好东西能够很快地被用上
  • cofounders 里面没有 db 的经验
  • open source 模式是未来,如果是闭源只能一家一家谈
  • 最重要的商业决策:不在于算法有多nb 团队有多厉害,护城河的关键在于 1)社区 2)mysql 接口 (借用了 mysql 的社区开始,SQL 的支持很重要,比如连Kafka, Spark都支持 SQL)

TiDB 数据库原理

  • 越nb的工程师越喜欢高性能,认为越快越好。但是 TiDB 的首要目标不是做到最快,而是做到 Availability reliability 稳定性 IO和 无限扩展。高性能的成本太高,要根据用户的硬件优化。但是这里是通用的数据库,不可能去优化各种场景。简单留给用户,复杂留给自己(跟AWS意见相反)。
  • 认为 eventual consistency 是个伪概念,实际上就是没一致性或者弱一致性。比如 cassandra WRN 设置好了,但到底过多久 能够resolve?不确定。太复杂,用户最好不需要知道操心这些复杂的设置。
  • 跑分不是唯一的指标,TPCC/TPCH 分数高对实际没有太多指导意义。数据库是磨出来的。比如第一家客户,游戏公司,居然创建了3万张表,json 的 meta 信息连起来非常慢。
  • 构架上不是 P2P,而是不同角色分得很清楚。
  • KV 用的是 RocksDB 但是典型的 LSM tree 的写放大是15倍,这里优化到 value 拆出来,解决写放大的问题。
  • 支持 MySQL 的client,也支持 SparkSQL 的读。
  • SQL layer 没有用 MySQL 的模块。一开始有试过,但是1)下面很难分布式 2)代码太烂很难改。魔改的话,半年能做;但是长期的维护成本更高。重做不麻烦,都重构了三次了。这里用 Go 比用 C/C++/Rust 重构更方便。
  • 一开始只想做 F1只做sql,和 CockroachDB 合作,后来他们往sql这边做,这边就只能往storage 做
  • 挖了 Rust core team 的两个人。rust 很难招人,一般是招 C++的人然后转rust,他们会觉得很多脑袋里的约定编译器帮你搞定了。
  • 不要低估造工业级轮子的难度。用 grpc,raft,rocksdb的好处是,如果业界有新的进展,会直接让使用者收益。
  • Chunk (region) split 做了两个月,merge 做了三年。merge 做了形式化证明。

Tech 趋势

  • 为什么是现在?
    • hardware
    • Hot / cold data -> warm data
    • Log is the new database
  • Everything is pluggable, 顶层 api 不变,下面即插即用可替换
  • Distributed Transaction
    • 2PC is the only option
    • challenges: reduce round-trips
  • Multi-tenancy achieved by kubernetes

中国 Biz Trend

  1. 中国速度,说上就得上
  2. 对新技术服务赋能业务的期望更高。二三线城市的公司或者非BAT用新技术与巨头斗争。必须能够解决使用者的技术焦虑。
  3. 基础软件人才储备逐渐变强。P产能CAP 对技术 content marketing 做了很多贡献。
  4. 一些核心场景(银行核心系统)敢于使用国产技术。
  5. PingCAP路径:开源(互联网/社区) <-> 商业化

参考资料

保持联系,关注我获取更多内容

阅读需 9 分钟

缓存击穿:这次冲击的是你的模型提供商,而不是数据库

当一个热门的 Prompt 前缀在整个集群中过期时,每个工作线程都会在同一瞬间成为缓存写入者 —— 曾经属于数据库的并发压力和账单,现在全都涌向了你的模型提供商。

llm
prompt-caching
阅读需 11 分钟

回填问题:为什么智能体记忆需要像数据库一样进行迁移

智能体记忆是一个生产环境数据库,每当你改进其格式时,它都会发生偏移。在旧记忆悄然失效之前,请对记录进行版本控制,编写真实的迁移脚本,并完成回填。

agent-memory
schema-migration
阅读需 11 分钟

为信任的功能添加 AI:方差如何摧毁你花费多年建立的信任

将 AI 改造进你最常用的功能并非在信任之上构建,而是在透支信任。本文探讨了失效模式、不对称的恢复曲线,以及一套为希望在不摧毁已有成果的情况下引入 AI 的工程师准备的分阶段引入框架。

insider
ai
阅读需 10 分钟

AI 原生 API 设计:构建智能体真正能调用的后端

REST API 是为人工编写的客户端设计的。AI 智能体会以完全可预见的方式破坏它们——幻觉出端点名称、在没有幂等性的情况下重试、忽略稀疏的错误信息。本文介绍如何构建智能体能够可靠调用的后端。

ai-engineering
api-design
阅读需 9 分钟

构建信任修复流程:当你的 AI 犯下显而易见的错误后该怎么办

一份关于在 AI 系统出现显性错误时设计信任修复流程的实践指南 —— 涵盖软失败与硬失败、优雅降级、撤销流程,以及真正衡量信任是否恢复的指标。

insider
ai