这个问题不解决, PG在AI赛道将凉凉

本期播客

这个问题不解决, PG在AI赛道将凉凉

给数据库服务器加上GPU卡, 把推理任务放数据库里, 让算力靠近数据, 减少数据移动带来的网络开销、序列化和反序列化带来的CPU与内存开销等. 最终提升效率!

把训练任务也放进数据库里, 让基于数据库的数据进行训练或微调, 生成超参.

这样基于 PG 打造 AI 原生数据库, 是不是很美好?

不过我要泼一盆冷水, 以上需求很美好, 但是PostgreSQL有个“死穴”, 这个问题不解决, 以上都是扯淡! 巨坑就在前面等着你.

PostgreSQL 不适合“长期训练任务”和“更新/删除偏多的OLTP业务”并存

长事务往往会导致PostgreSQL数据库膨胀, 原因是vacuum进程只能回收PG实例中最老事务之前产生的dead tuple.

如果数据库中存在长事务, 那么在这个事务未结束前, 这个事务开始后产生的所有dead tuple都无法被回收.

不仅导致膨胀, 还会导致性能下降(因为block中垃圾多, 可能需要扫描更多的block), 占用shared buffer变多(消耗更多内存), CPU和IO升高(数据库中存在无法回收垃圾且超过autovacuum触发阈值的表, autovacuum进程将不断被唤醒, 不断扫描和执行回收逻辑, 产生消耗CPU和IO的无用功).

推理可能不是特别长的事务, 但是训练大概率是长事务, 训练任务需要耗费几天甚至更久!

如果PG不解决这个死穴, 别谈AI 原生数据库了!

UNDO 存储引擎迫在眉睫!

你现在知道为什么Supabase要收购 orioledb ( https://github.com/orioledb/orioledb ) 了吧?

为什么老外总能提前布局呢? 是不是也值得反思一下?

国内又有哪些厂商也布局了基于undo的存储引擎呢?

欢迎留言!