这周公司邀请了大佬来分享一下neon的一些场景，针对AI这块，neon的优势主要有几点：
* serveless，秒级别拉起服务
* PITR，事务级别的状态闪回
* branching，可写快照
分享的时候演示的neon功能毫无疑问是非常强的，这里主要想来看看这几个功能对应的具体的需求到底是什么
- serveless这个
- 可能是用户希望快速拉起一个数据库做测试，这个其实理由并不是很强，因为SQL lite等一些本地数据库在使用上应该相对来说更加方便。
- 希望是针对PG做快速拉起，比如希望利用pg vector以及数据库的能力，这里可能现有的其他的方案不能很好的解决。一个fallback的手段就是放到两个local的数据库里，来做测试了。这个也涉及到一些技术选型相关的。
- 如果是非关系性的建模的话，NEO4j可能拉起来也比较容易
- 可用性？这个个人感觉并不是现在AI开发者非常关注的一点。主要是这里的收益比较边际
- PITR：
- agent场景，数据修改坏了可以回退，这个个人感觉理由不是很强，因为git显然更容易管理这块。接一下mcp肯定就更加自动化了
- git不擅长处理的，就是大规模的数据了，这种情况下应该和agent关系不大，可能是导入一批数据，然后失败了，可以切回老的一致的数据版本。
- branching，其实和上面的PITR是类似的
- 可能能想到的和AI关联不大的一个点是，branch一个分支出来作为测试版本可以用来做在线流量的灰度。应该挺好用的。
可能和branching相关的一点就是，线上应该有大量的创建新的知识库/codebase的需求，对应到数据库上可能是大量的表，可能每一个表就有一个对应的向量索引来支撑AI。所以需求可能变成了，在系统中维护大量的向量索引（这里可以泛化，AI依赖的那些数据结构）。
* 目前我还不清楚各个向量数据库支持的collection的数量，不过盲猜应该不会非常多。
* 从我比较熟悉的Graph场景来说，向量索引的隔离一般来说简单实现是在向量索引上加一个filter，这种可能就会牺牲向量索引的效果。
* 当然了，用不用向量索引也是一个时间/空间的tradeoff
* 从现在做RAG的经验上看，如果底层的存储是一个：
* 有类似branching的能力
* 原子读写，即每一次写入我可能会写入若干的数据，但是对一致性要求比较高。所以希望写一堆数据，都成功后，再通知上层新的数据生成完了，可以读了。
* 测试效果用，比如我可以基于现在的数据fork一个新的表出来，用新的算法做写入，然后让业务测试效果。（这个其实类似上面说的，利用branch做测试）
* 管理大量元数据的能力。因为上游可能有很多类型的库。单说知识图谱，我们就可以根据不同的层级构建多种知识图谱，比如文档级别的，目录级别的，空间级别的。这依赖数据库可以管理大量的相互隔离的数据，以及对应的向量/全文索引
* 易用性？毕竟现在大家都愿意为灵活和易用性付费
文章评论