如果我们用一个词来总结2023年的数据技术领域，那个词无疑是“急速变革”。我们见证了数据库内核技术与云原生架构的融合演进，AI+Data的浪潮涌现，以及用户工作负载的深刻转变。GenAI时代的到来，就像一股不可抗拒的潮流，推动着数据技术的每一朵浪花，朝着更智能化、更灵活化的巨浪之海奔流。
毫无疑问，AI将会对数据处理提出非常多新的诉求，数据技术领域也会面临着多重挑战与机遇，AI正在重塑数据技术的全新生态。我们不禁要问：在GenAI的大潮中，选择“向量数据库”还是“以SQL数据库作为核心，添加向量搜索插件”？数据库如何应对GenAI对数据库扩展性和实时交互的诉求？浪涌般海量数据的实时查询会不会带来巨大的成本压力？AI带来的自然交互方式催生怎样的开发者体验？这些问题将在本文中一一解答
“向量数据库”还是“向量搜索插件+SQL数据库”？这是一个答案很明确的问题。
如果说过去CRUD应用是对数据库访问的静态封装，那么随着GenAI的普及，尤其是Chatbot或Agent的产品形态，对数据的使用会是更加灵活和动态的。过去，集中的数据存储和应用是因为技术的局限，很难为个人提供个性化的服务，尽管现代的SaaS其实很希望往这个方向发展，但是为每个用户都提供个性化的体验对算力和开发的挑战太高，而GenAI和LLM将提供个性化服务的成本降得很低（可能就是几段Prompt），以至于对于数据库而言，带来几个变化：
○个人（或一个组织）产生的数据价值会变得越来越高，但这类数据通常不会很大
○GenAI会使用更加动态和灵活的方式直接访问数据，这样效率最高
○对数据的访问从边缘发起（从Agent或者GenAI直接发起）
一个很好的例子是GPTs，GPTs支持通过的自定义的Prompt和用户提供的RESTfulAPI来创建自己的ChatGPT，基础的ChatGPT会在它认为需要的时候以灵活的方式调用你给定的Action。这个调用发生方式和参数是后端的Action提供者无法预料的。而且可以预料的是很快GPTs将会提供标记个人身份信息的机制，这样对于Action的提供者来说，相当于后端的数据库有了最重要的索引：UserID，剩下的就很好理解了。
这里你可能会提出质疑，RAG不是标准的做法吗？但现有的RAG构建的方式几乎都是静态的，而知识应该是可以实时被更新的，这里不得不提到向量数据库。
PlaintextRustINSERTINTOtbl(user_id,vec,...)VALUES(xxx,[f32,f32,f32...],...);SELECT*FROMtblWHEREuser_id=xxxandvector_search([f32,f32,f32,f32...])类似的访问可能是更符合开发者直觉的。
而关系型数据库天然支持插入和更新，另外配合向量索引的搜索能力，便可以将RAG变成一个可以实时更新实时查找的正反馈循环（利用LLM引入进行二次的Summary，然后将更新的Index储存在DB中）。更重要的是，关系型数据库的引入消除了向量数据库带来的数据孤岛的问题，当你可以将向量索引筛出来的数据关联（JOIN）到同一个DB中其他的数据的时候，灵活性带来的价值就得以显现。
另一个好处是，Serverless的产品形态，同样也将数据的所有权归还给用户本人，大家思考一下，在我们熟知的Web2时代，我们的数据是隐藏在一个个互联网公司的服务背后的黑箱，我们没有办法直接访问；而在GenAI的应用场景下，数据的交互变成一个三角的关系，用户-数据(RAG)-GenAI。很有意思的是，这个正是Web3的理想之一，GenAI的普及很可能顺手也将Web3想实现的将数据的所有权交还给用户的理想，这在Web2时代是不可能实现的，这其实是一种技术理想的回归。
当然，我相信在未来RAG会成为数据库的很重要的一种新应用场景，在这种场景中Serverless形态提供的云数据库服务会变成标准化的。
由高价值数据驱动的应用成为GenAI应用的主流，弹性与实时交互成为数据库能力的基石。
在预测一里我们提到，GenAI时代的应用要求知识和数据是可以被实时更新的，这对数据库的弹性以及实时交互提出了非常直接的需求。
但这些数据库大多是SharedNothing的系统，Sharednothing的系统通常会有一个假设：在集群中的节点是对等的，只有这样数据和Workload才能均匀的分散在各个节点上。这个假设对于海量数据+访问模式均匀的场景没有问题，但是仍然有很多的业务具有明显的冷热特征，尤其是在GenAI带来的数据访问方式越来越动态和灵活的2024年及以后。
我们最经常处理的数据库问题之一就是局部热点。如果数据访问倾斜是一个业务的天然属性的话，对等的假设就不再是合理的，更合理的方式是将更好的硬件资源倾斜给热点的数据，而冷数据库使用更廉价的存储，例如，TiDB从一开始将存储节点（TiKV）/计算节点（TiDB）/元信息（PD）分离，以及在后来TiDB5.0中引入自定义PlacementRule让用户能够尽可能决定数据摆放策略，就是为了尽可能弱化节点对等假设。
但是更终极的解决办法在云端，在基本的扩展性问题得到解决后，人们开始追求更高的资源利用效率，在这个阶段，对于OLTP业务来说，我想可能更好的评价标准是CostPerRequest。因为在云端，计算和存储的成本差别是巨大的，对于冷数据来说，如果没有Traffic，你甚至可以认为成本几乎为0，但是计算却是昂贵的，而在线服务不可避免的需要计算（CPU资源），所以高效利用计算资源，云提供弹性将成为关键。
另外，请不要误解，弹性并不意味着便宜，on-demand（随需提供的）的资源在云上通常比provisioned（预分配）的资源更贵，持续的burst一定是不划算的，这种时候使用预留资源更合适，burst那部分的成本是用户为不确定性支付的费用。仔细思考这个过程，这可能会是未来云上数据库的一种盈利模式，
与弹性同样重要的需求就是实时交互。GenAI时代的应用需要数据库不仅要有强大的数据处理能力，还需要有高效的实时数据广播和同步机制。这不只是让数据能够实时更新，而是确保数据流能够实时流动，让数据库能即时捕捉到每一次交互，每一个查询，确保每一个决策都是基于最新、最准确的信息。（就是用户愿意为更高价值的实时交互付钱，想想股票实时交易和直播电商的场景就知道了）
于是整个系统——从数据的产生到处理、再到存储和检索——都必须要在实时的框架下工作，能够在毫秒级别做出实时响应，这也需要数据库能实时在事务处理（OLTP）和分析处理（OLAP）之间无缝同步。这样的实时交互能力，将会是现代数据库区别于传统数据库的决定性因素之一。
成本分析已经成为所有人关心的问题，在云数据库的可观测性中成为独立新视角。
与传统的可观测性不一样的是：在云上，一切Workload都会成为客户的帐单的一部分。对于用户来说一个新的问题便是：为什么我的帐单看起来是这样？我需要做什么才能让我的帐单更便宜？账单的可解释性做得越好，用户体验也就越好。
但是如果计费测量的粒度过细，也会影响产品本身的性能以及增加实现的成本。这里面需要平衡。但可以确定的是，在思考可观测性产品的方向上，成本分析可以作为一个独立的新视角。
成本分析可以帮助用户发现系统运行中的潜在问题，并采取措施予以优化。例如，如果用户观测到某个数据库实例的CPU使用率较低，但成本却很高，就可以考虑将该实例的规格调整为更低的级别。
AWS今年发布的CostandUsageDashboard和Reinvent上AmazonCTODr.Werner的演讲专注于成本的架构艺术也同样可以看到这个趋势。他提出了“俭约架构”七大法则来在云的环境中打造更加高效、可持续的系统，为我们提供了一个系统性的指导框架。
当GenAI时代的各种应用和工具变得越来越轻巧，开发者体验将成为现代数据库设计的核心目标之一。
数据库平台化不仅仅是漂亮的Web管控界面以及一些花哨的功能堆砌。我很喜欢PlanetScale的CEOSamLambert在他的个人Blog里面关DevelopExperience的描述他引用了乔布斯的一句话“Greatartstretchestaste,itdoesn’tfollowtastes（伟大的艺术拓展审美边界，而不是刻意迎合。）”。
好用的工具之所以好用，是因为其中是饱含了设计者的巧思和品味，而且这个设计者也必须是重度的使用者，这样人们才能体会到那些细微的快乐与痛苦，但是又不至于沉浸其中使其盲目，其实这对负责开发者体验的产品经理来说是极高的要求。
APIFirst,数据库平台应该提供稳定的/前向兼容的API，一切在管控平台里能干的事情，API都要能做到，最好你的管控平台是基于你的API构造的。这为你提供一个功能齐备的好用的CLITool也是关键的必要条件。
使用统一的认证体系，在设计阶段将管控的认证和用户体系与数据库内部的认证体系打通，传统的数据库基于用户名和密码的权限体系在云的时代是不够的。这为了后续与云的IAM和Secret管理体系对接打下基础。
对不同的功能构建不同的/稳定的小工具(Doonething,dothingswell)，但是通过一个统一的CLI入口和语义系统进行调用。比较好的例子是rustup,甚至git也是个很好的例子。
稍微总结一下，2024年，数据和数据库技术仍然处于巨大的变革期，谁也没办法预测未来，因为我们就身处这么一个不确定性巨大的时代。但好的一面是，创新仍然层出不穷。我今天预测的，很可能过几个月就会被我自己全部推翻，也是很正常的事情，如果能给当下的你有所启发，那就够了。
PingCAP是国内开源的新型分布式数据库公司，秉承开源是基础软件的未来这一理念，PingCAP持续扩大社区影响力，致力于前沿技术领域的创新实现。其研发的分布式关系型数据库TiDB项目，具备「分布式强一致性事务...