共计 4796 个字符，预计需要花费 12 分钟才能阅读完成。
本文由 PingCAP 黄东旭撰写，探讨了数据库技术在 2023 年的疾速改革，并对 2024 年的数据库发展趋势进行了预测。文章重点关注了 GenAI 时代对数据库的影响，提出了在数据库抉择上的两种门路：“向量数据库”和“向量搜寻插件 + SQL 数据库”。文章强调了个性化数据服务的重要性，以及数据库在实时交互和弹性方面所起到的关键作用。
如果咱们用一个词来总结 2023 年的数据技术畛域，那个词无疑是“急速改革”。咱们见证了数据库内核技术与云原生架构的交融演进，AI+Data 的浪潮涌现，以及用户工作负载的粗浅转变。GenAI 时代的到来，就像一股不可抗拒的潮流，推动着数据技术的每一朵浪花，朝着更智能化、更灵活化的巨浪之海奔流。
2023 年，咱们的眼前充斥了炫目的 AI Demo 与炫技，你追我赶。转眼间，当我 们步入 2024 年，这个年份将因为“AI 在从 Demo 到实在场景落地”的急剧转变而被人们记住。随着开源大模型老本的减速降落，企业和开发者对数据的关注也急剧回升，对数据的关注度将很快取代对模型的关注度。有预测认为，在 2023 年，用户违心在 AI 模型上投入 80% 的估算，然而在将来这一两年里，随着模型老本的升高，这一比重可能会逆转，用户将更多的投资（甚至大于 80%）偏向于数据，数据处理和剖析能力变得更加重要。
毫无疑问，AI 将会对数据处理提出十分多新的诉求，数据技术畛域也会面临着多重挑战与时机，AI 正在重塑数据技术的全新生态。咱们不禁要问：在 GenAI 的大潮中，抉择“向量数据库”还是“以 SQL 数据库作为外围，增加向量搜寻插件”？数据库如何应答 Gen AI 对数据库扩展性和实时交互的诉求？浪涌般海量数据的实时查问会不会带来微小的老本压力？AI 带来的天然交互方式催生怎么的开发者体验？这些问题将在本文中一一解答
/ 预测一 /
“向量数据库”还是“向量搜寻插件 + SQL 数据库”？这是一个答案很明确的问题。
如果说过来 CRUD 利用是对数据库拜访的动态封装，那么随着 GenAI 的遍及，尤其是 Chatbot 或 Agent 的产品状态，对数据的应用会是更加灵便和动静的。过来，集中的数据存储和利用是因为技术的局限，很难为集体提供个性化的服务，只管古代的 SaaS 其实很心愿往这个方向倒退，然而为每个用户都提供个性化的体验对算力和开发的挑战太高，而 GenAI 和 LLM 将提供个性化服务的老本降得很低（可能就是几段 Prompt），以至于对于数据库而言，带来几个变动：
○ 集体（或一个组织）产生的数据价值会变得越来越高，但这类数据通常不会很大
○ GenAI 会应用更加动静和灵便的形式间接拜访数据，这样效率最高
○ 对数据的拜访从边缘发动（从 Agent 或者 GenAI 间接发动）
一个很好的例子是 GPTs，GPTs 反对通过的自定义的 Prompt 和用户提供的 RESTful API 来创立本人的 ChatGPT，根底的 ChatGPT 会在它认为须要的时候以灵便的形式调用你给定的 Action。这个调用产生形式和参数是后端的 Action 提供者无奈意料的。而且能够意料的是很快 GPTs 将会提供标记个人身份信息的机制，这样对于 Action 的提供者来说，相当于后端的数据库有了最重要的索引：UserID，剩下的就很好了解了。
这里你可能会提出质疑，RAG 不是规范的做法吗？但现有的 RAG 构建的形式简直都是动态的，而常识应该是能够实时被更新的，这里不得不提到向量数据库。
对向量的反对，在去年是数据库迭代的一个热门方向，产生了很多专门的向量数据库，然而我认为，更丰盛的数据拜访接口，使得向量搜寻成为标配，然而 SQL 依然是基石。向量搜寻并不值得专门应用一个独立的数据库来反对，更应该是现有的数据库中的一个性能，就像：
Plaintext
Rust INSERT INTO tbl (user_id, vec, ...) VALUES (xxx, [f32, f32,
f32 ...], ...); SELECT * FROM tbl WHERE user_id = xxx and
vector_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 时代的利用要求常识和数据是能够被实时更新的，这对数据库的弹性以及实时交互提出了十分间接的需要。
数据库的可扩展性始终是过来十年间，业界关注的重点之一。依据咱们的察看，大多数繁多在线业务，100TB 曾经是很大规模，而这个规模下的个别 OLTP 业务，曾经能够被市场上很多零碎自信的解决。
但这些数据库大多是 Shared Nothing 的零碎，Shared nothing 的零碎通常会有一个假如：在集群中的节点是对等的，只有这样数据和 Workload 能力平均的扩散在各个节点上。这个假如对于海量数据 + 拜访模式平均的场景没有问题，然而依然 有很多的业务具备显著的冷热特色，尤其是在 GenAI 带来的数据拜访形式越来越动静和灵便的 2024 年及当前。
咱们最常常解决的数据库问题之一就是部分热点。如果数据拜访歪斜是一个业务的人造属性的话，对等的假如就不再是正当的，更正当的形式是将更好的硬件资源歪斜给热点的数据，而冷数据库应用更便宜的存储，例如，TiDB 从一开始将存储节点（TiKV）/ 计算节点（TiDB）/ 元信息（PD）拆散，以及在起初 TiDB 5.0 中引入自定义 Placement Rule 让用户可能尽可能决定数据摆放策略，就是为了尽可能弱化节点对等假如。
然而更终极的解决办法在云端，在根本的扩展性问题失去解决后，人们开始谋求更高的资源利用效率，在这个阶段，对于 OLTP 业务来说，我想可能更好的评估规范是 Cost Per Request。因为在云端，计算和存储的老本差异是微小的，对于冷数据来说，如果没有 Traffic，你甚至能够认为老本简直为 0，然而计算却是低廉的，而在线服务不可避免的须要计算（CPU 资源），所以 高效利用计算资源，云提供弹性将成为要害。
另外，请不要误会，弹性并不意味着便宜，on-demand（随需提供的）的资源在云上通常比 provisioned（预调配）的资源更贵，继续的 burst 肯定是不划算的，这种时候应用预留资源更适合，burst 那局部的老本是用户为不确定性领取的费用。认真思考这个过程，这可能会是将来云上数据库的一种盈利模式，
与弹性同样重要的需要就是实时交互。GenAI 时代的利用须要数据库不仅要有弱小的数据处理能力，还须要有高效的实时数据播送和同步机制。这不只是让数据可能实时更新，而是确保数据流可能实时流动，让数据库能即时捕捉到每一次交互，每一个查问，确保每一个决策都是基于最新、最精确的信息。（就是用户违心为更高价值的实时交互付钱，想想股票实时交易和直播电商的场景就晓得了）
于是整个零碎——从数据的产生到解决、再到存储和检索——都必须要在实时的框架下工作，可能在毫秒级别做出实时响应，这也须要数据库能实时在事务处理（OLTP）和剖析解决（OLAP）之间无缝同步。这样的实时交互能力，将会是古代数据库区别于传统数据库的决定性因素之一。
/ 预测三 /
老本剖析曾经成为所有人关怀的问题，在云数据库的可观测性中成为独立新视角。
明天我还想谈的一点是云数据库的可观测性，尤其是它是否能让我的云生产更通明。对于数据库云服务来说，可观测性的要求会更高，因为对于开发者来说，服务商提供的 Dashboard 简直是惟一的诊断伎俩。介绍可观测性的文章也很多，类似的局部因为篇幅关系我也不打算说太多。
与传统的可观测性不一样的是：在云上，所有 Workload 都会成为客户的帐单的一部分。对于用户来说一个新的问题便是：为什么我的帐单看起来是这样？我须要做什么能力让我的帐单更便宜？账单的可解释性做得越好，用户体验也就越好。
然而如果计费测量的粒度过细，也会影响产品自身的性能以及减少实现的老本。这外面须要均衡。但能够确定的是，在思考可观测性产品的方向上，老本剖析能够作为一个独立的新视角。
老本剖析能够帮忙用户发现零碎运行中的潜在问题，并采取措施予以优化。例如，如果用户观测到某个数据库实例的 CPU 使用率较低，但老本却很高，就能够思考将该实例的规格调整为更低的级别。
AWS 往年公布的 Cost and Usage Dashboard 和 Reinvent 上 Amazon CTO Dr. Werner 的演讲专一于老本的架构艺术也同样能够看到这个趋势。他提出了“俭约架构”七大法令来在云的环境中打造更加高效、可继续的零碎，为咱们提供了一个系统性的领导框架。
/ 预测四 /
当 GenAI 时代的各种利用和工具变得越来越笨重，开发者体验将成为古代数据库设计的外围指标之一。
数据库平台化不仅仅是丑陋的 Web 管控界面以及一些花哨的性能堆砌。我很喜爱 PlanetScale 的 CEO Sam Lambert 在他的集体 Blog 外面关 Develop Experience 的形容他援用了乔布斯的一句话“Great art stretches taste, it doesn’t follow tastes（平凡的艺术拓展审美边界，而不是刻意投合。）”。
好用的工具之所以好用，是因为其中是饱含了设计者的巧思和品尝，而且这个设计者也必须是重度的使用者，这样人们能力领会到那些轻微的高兴与苦楚，然而又不至于沉迷其中使其自觉，其实这对负责开发者体验的产品经理来说是极高的要求。
数据库管理工具作为一种频率不算高频、但每次应用都很庄重的工具，在 AI 和云的时代，我认为有一些与体验严密相干的设计准则是须要恪守的：
API First, 数据库平台应该提供稳固的 / 前向兼容的 API，所有在管控平台里无能的事件，API 都要能做到，最好你的管控平台是基于你的 API 结构的。这为你提供一个性能完备的好用的 CLI Tool 也是要害的必要条件。
应用对立的认证体系，在设计阶段将管控的认证和用户体系与数据库外部的认证体系买通，传统的数据库基于用户名和明码的权限体系在云的时代是不够的。这为了后续与云的 IAM 和 Secret 管理体系对接打下基础。
对不同的性能构建不同的 / 稳固的小工具 (Do one thing, do things well)，然而通过一个对立的 CLI 入口和语义零碎进行调用。比拟好的例子是 rustup, 甚至 git 也是个很好的例子。
略微总结一下，2024 年，数据和数据库技术依然处于微小的改革期，谁也没方法预测将来，因为咱们就身处这么一个不确定性微小的时代。但好的一面是，翻新依然层出不穷。我明天预测的，很可能过几个月就会被我本人全副颠覆，也是很失常的事件，如果能给当下的你有所启发，那就够了。
