建设公司设计公司网站,博业建站网,wordpress站外链接,广东深圳本文由 PingCAP 黄东旭撰写#xff0c;讨论了数据库技术在 2023 年的快速变革#xff0c;并对 2024 年的数据库发展趋势进行了预测。文章重点关注了 GenAI 时代对数据库的影响#xff0c;提出了在数据库选择上的两种路径#xff1a;“向量数据库”和“向量搜索插件 SQL 数…本文由 PingCAP 黄东旭撰写讨论了数据库技术在 2023 年的快速变革并对 2024 年的数据库发展趋势进行了预测。文章重点关注了 GenAI 时代对数据库的影响提出了在数据库选择上的两种路径“向量数据库”和“向量搜索插件 SQL 数据库”。文章强调了个性化数据服务的重要性以及数据库在实时交互和弹性方面所起到的关键作用。
如果我们用一个词来总结 2023 年的数据技术领域那个词无疑是“急速变革”。我们见证了数据库内核技术与云原生架构的融合演进AIData 的浪潮涌现以及用户工作负载的深刻转变。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 年数据和数据库技术仍然处于巨大的变革期谁也没办法预测未来因为我们就身处这么一个不确定性巨大的时代。但好的一面是创新仍然层出不穷。我今天预测的很可能过几个月就会被我自己全部推翻也是很正常的事情如果能给当下的你有所启发那就够了。
