首页 文章 精选 留言 我的

精选列表

搜索[TDSQL Boundless],共289篇文章
优秀的个人博客,低调大师

把 JEV 带进 SQL:TDSQL Nexa 全新支持 AI_DECIDE 函数

假设你负责一个客服团队,数据库里每天都会新增许多工单。其中一条写着:“刚刚被重复扣款了,请尽快帮我处理。”在分派这张工单前,你需要先判断几件事:应该交给哪个团队?用户有多不满?是否需要优先处理? 这些问题不需要 AI 写一篇长答案,而是需要能用于后续处理的结果,例如“账单团队”、一个不满程度分数,以及一个紧急程度判断。但如果每条工单都靠人工阅读,数据一多就很难及时处理;如果在应用里调用 AI,还需要编写读取数据、发起请求、整理结果等逻辑。 **Nexa 全新支持的 AI_DECIDE,让你可以直接在 SQL 查询里完成这些判断。** 指定要分析的文本和判断规则,就能逐行分类、评分或判断某个条件是否成立,再用 SQL 筛出需要优先处理的记录,或按类别汇总统计。 这项能力背后是 **JEV 决策模型**。你可以把它理解为一个专做“选择题、评分题和是非题”的 AI:它不负责聊天或写文案,而是针对你给定的问题输出判断结果。需要同时判断多个问题、查看概率和置信度时,可以使用 ai_decide_raw 获取完整结果。 **简单来说:不用先把数据导出来另写一套分析脚本,就能在熟悉的 SQL 中完成 AI 判断,并继续处理结果。** | | | | ----- | ------------------------------- | | **1** | **JEV 是什么:决策模型里的 "System One"** | 与开放式内容生成不同,答案范围明确的判断任务,需要模型理解输入,却不需要它把结果组织成长篇回复。JEV 正是为这类任务设计的。 这种分工可以借用心理学中的两套思考系统来理解:**System One** 负责快速、直觉的判断,System Two 负责缓慢、深度的推理。通用大模型擅长的是 **System Two**,JEV 定位为 **System One Model**,官方的说法是 **"智能版 if 语句"**。 ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/8b3fc4ecafcebf90ae42e5cd525a3dde.webp) 围绕这类判断任务,JEV 有三点关键设计: 1. **RLCD(校准决策强化学习)**:以**概率校准**为训练目标,让预测概率尽量贴近实际发生比例,为业务阈值选择提供参考。 2. **state + questions 输入范式**:state 是待判断的上下文,questions 是一组命名问题,一次请求可以混合多种题型。 3. **并行采样架构**:不走 LLM 那种逐 token 串行生成,多个问题可以并行求解,非常适合 SQL 的批量执行场景。 JEV 与通用 LLM 是**互补**关系:写文案、写代码、长推理交给 LLM;高频、大批量、低延迟的判断交给 JEV。 | | | | ----- | -------------------- | | **2** | **为什么要在 SQL 里用 JEV** | 分类标签可以用于分组,评分可以用于排序,概率可以用于筛选——这些判断结果,本身就适合交给 SQL 继续处理。但如果模型调用放在应用侧,往往还需要导出数据、编写调用脚本,再把结果写回数据库,增加数据流转和维护的工作。 AI_DECIDE 把 JEV 变成了一个普通的 SQL 函数,让模型判断与查询中的筛选、聚合等操作结合起来,减少应用侧的编排: ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/2768492d74a256ea2d12bdfeb38f309b.webp) | | | | ----- | ---------- | | **3** | **三种决策原语** | 不同的业务问题,需要不同形式的结果:有些要选出一个类别,有些要衡量程度,还有些只需判断一个条件是否成立。AI_DECIDE 支持 JEV 的三种决策原语,分别对应这三类需求: ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/f46d584f3bb6a0e05807797ed3125515.webp) 实际选择时,可以从答案的形式来区分: ● 选项之间**没有顺序**、且必须选中一个,用 choice ● 选项**有高低之分**,用 score,连续分数比硬分类更能反映程度 ● 只关心**一个命题成不成立**,用 noul,不要拆成 choice{yes, no} | | | | ----- | -------- | | **4** | **典型场景** | 这些判断方式既可以独立使用,也可以组合起来,为业务提供类别、程度和条件判断等不同维度的结果: **1. 客服运营**:在坐席接手前,为每张工单确定队列、给出不满评分和紧急标记。 **2. 用户反馈分析:**为海量评论打上类别和严重程度,快速汇总情绪、排定功能优先级。 **3. AI 回答质检:**判断 AI 助手的回答是否符合政策、是否完整,人工只复查不达标的部分。 **4. System One / System Two 分层路由:**先用 AI_DECIDE 判断请求难度,难题交给大模型,其余走低成本路径,这也是 JEV 最推荐的组合用法: ``` SELECT     request_id, CASE WHEN ai_decide_noul('nano-jev', query,'This request requires multi-step reasoning')>0.7 THEN'llm'-- System Two:交给通用大模型 ELSE'jev'-- System One:直接用决策结果 ENDAS route FROM user_requests; ``` ### **什么时候用 AI_DECIDE,什么时候用通用 LLM** 业务场景可以不同,选型的依据却相似:任务需要的是范围明确的判断结果,还是开放式生成的内容? ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/582bdc0559d6c408a97fecac6f86af40.webp) JEV 仅接受文本输入,不生成内容,也不擅长复杂数学运算和日期比较;高风险场景保留人工复核。 | | | | ----- | -------- | | **5** | **快速上手** | 只需要单项结果时,调用对应的判定函数;需要同时回答多个问题或查看完整响应时,使用 ai_decide_raw。结果可继续用于筛选、统计和复核。 ### **1. 三个判定函数:直接返回标量** 三个判定函数分别返回概率、分类标签和分数,可直接用于 SQL 表达式。model 是第一个参数(传 '' 使用系统默认),state 逐行取值: ``` -- 是非概率:返回 0–1 的 DOUBLE SELECT ai_decide_noul('nano-jev', ticket_text,'The message conveys urgency')AS is_urgent FROM support_tickets; -- 单选分类:返回选中的标签(VARCHAR) SELECT ai_decide_choice('nano-jev', ticket_text,'Which team should handle this', '{"billing": "Payment or subscription issues",       "technical": "Bugs or integration problems",       "sales": "Pricing or account questions"}')AS queue FROM support_tickets; -- 量表评分:返回加权连续分数(DOUBLE,0 = 最低档,N-1 = 最高档) SELECT ai_decide_score('nano-jev', ticket_text,'How frustrated the customer appears', '["Calm", "Frustrated but civil", "Very angry"]')AS frustration FROM support_tickets; ``` 函数签名(model 均为第一参数): ``` ai_decide_noul (model VARCHAR, state VARCHAR, instructions VARCHAR [, criteria JSON]) -> DOUBLE ai_decide_choice(model VARCHAR, state VARCHAR, instructions VARCHAR,  criteria JSON)  -> VARCHAR ai_decide_score (model VARCHAR, state VARCHAR, instructions VARCHAR,  criteria JSON)  -> DOUBLE ``` ● model:模型名,如 'nano-jev'、'laya'。'' = 系统默认;NULL → 该行结果为 NULL ● state:待判断的输入内容,逐行取值(可以是列,也可以是任意表达式) ● instructions:自然语言问题 ● criteria:noul 可选({"true": "…", "false": "…"} 正反例定义);choice 必填({标签: 描述},1–255 个非空标签,描述可为 null);score 必填(有序等级列表,2–10 项,从低到高) 三个函数的返回样式(对上面三条查询,一行 ticket_text 的输出): ``` is_urgent    queue      frustration 0.8808       billing    1.7908 ``` ![图片](https://developer.qcloudimg.com/http-save/yehe-12181391/3cde7af67a9aac0fb2df429140b1c3d2.webp) 这些函数只提取主结果,便于 WHERE / CASE / GROUP BY 直接使用。概率分布(probabilities)、置信度(confidence)和等级对照表(legend)等信息,可从 ai_decide_raw 的响应中读取。 ### **2. ai_decide_raw:一次调用,回答多个问题** ai_decide_raw 接收完整的 JEV 请求体(自带 model),响应原样返回。在同一次请求中,每个问题可以设置自己的名称、题型和判断规则,并共享同一份 state。 下面将三个问题放入 questions,通过 TO_JSON 结构体字面量在请求里直接引用列: ``` SELECT     ticket_id,     ai_decide_raw(TO_JSON({ 'model': 'nano-jev', 'state': ticket_text, 'questions': { 'department': { 'type': 'choice', 'instructions': 'Which team should handle this', 'criteria': { 'billing':   'Payment or subscription issues', 'technical': 'Bugs or integration problems', 'sales':     'Pricing or account questions'                 }             }, 'frustration': { 'type': 'score', 'instructions': 'How frustrated the customer appears', 'criteria': ['Calm','Frustrated but civil','Very angry']             }, 'is_urgent': { 'type': 'noul', 'instructions': 'The message conveys urgency'             }         }     }))AS decision FROM support_tickets; ``` ### **3. 读取返回结果** 响应中的 answers 按问题名称组织,便于逐项取值。顶层还会回显 model,并附带 usage token 用量等信息: ``` { "model":"nano-jev", "answers":{ "department":{ "type":"choice", "choice":"billing", "confidence":0.9306, "probabilities":{"billing":0.9537,"sales":0.0175,"technical":0.0288} }, "frustration":{ "type":"score", "score":1.7908, "confidence":0.7083, "legend":{"0":"Calm","1":"Frustrated but civil","2":"Very angry"}, "probabilities":{"0":0.0148,"1":0.1797,"2":0.8055} }, "is_urgent":{ "type":"noul", "noul":0.8808 } }, "usage":{"input_tokens":96,"output_tokens":42} } ``` 示例中的三个结果分别表示: **● department:**选择 billing;选项概率为 0.9537,confidence 为 0.9306 **● frustration:**加权分数 1.79(区间 0–2),接近 "Very angry" **● is_urgent:**消息表达紧急性的概率约 0.88 json_extract 返回 JSON 值,json_extract_string 返回纯文本;三个判定函数则直接返回标量。 ### **4. 使用判断结果:筛选、统计与复核** 对结果表 decision_results 继续查询,即可提取字段并生成处理标记: ``` SELECT     ticket_id,     json_extract_string(decision,'$.answers.department.choice')AS queue,     CAST(json_extract(decision,'$.answers.frustration.score')ASDOUBLE)AS frustration,     CAST(json_extract(decision,'$.answers.is_urgent.noul')ASDOUBLE)>0.8AS escalate,     CAST(json_extract(decision,'$.answers.department.confidence')ASDOUBLE)<0.6AS department_need_review FROM decision_results; ``` **● 筛选:**按 escalate 标记找出建议优先处理的记录 **● 统计与排序:**按 queue 分组统计,或按 frustration 排序 **● 复核:**按 department_need_review 标记找出需要复核的部门分类结果 阈值可按业务需求调整,下游应用根据标记执行相应操作。 ## **立即试用:**AI_DECIDE 目前处于内测阶段。如需开通或反馈问题,请到公众号后台留言反馈。

优秀的个人博客,低调大师

TDSQL交易型分布式数据库背景分析

一、背景 随着各行各业电子信息化的不断加深,线上交易数据保持了长时间高速增长的态势,对数据存储的需求越来越大,数据库管理系统(DBMS)面临越来越大的性能、空间和稳定性压力。在此过程中,得利于计算&存储&网络等硬件领域的不断进步,业界流行的数据库管理系统逐步从单机架构向分布式架构演变。笔者希冀从梳理数据库管理系统所面临的一个又一个实际挑战及业界所提出的诸多解决方案的过程中,发现片缕灵感以指引未来的数据库开发工作。 二、从单机数据库到分布式数据库 业界起步阶段诞生的第一代交易型数据库具有以下主要特点:和程序一起运行在大型机/小型机为代表的高端计算机上; 利用硬件层面大量冗余设计带来的强大可靠性来保障数据库可用性,通过直接升级硬件规格的方式来扩容数据库性能容量。即使到今天仍然有很多银行核心系统以这样的方式运行。 很快,这种堆硬件模式来获取提升的模式局限性就暴露出来了。首先,数据库可用性对硬件层面冗余的依赖抬高了大型机等存储型设备的造价,动辄单台上千万美元的价格是诸多中小客户难以承受的负担。次之,由于性能扩容只能通过提升硬件规格的方式实现,而硬件规格的10%性能容量提升,往往需要客户付出成倍的购买成本,且整体性能极限也受限于当时的硬件发展的天花板。由于上述所说的诸多成本原因,业界一直没有停止过尝试以x86服务器为代表的“廉价”硬件替换大型机来提供交易型数据库服务的努力。 三、基于共享存储的分布式数据库方案 1. 共享存储方案 首当其冲要解决的是,如何保障数据库服务的可用性。由于交易型业务往往都是企业中较为核心的往往会涉及金钱相关的线上业务,因此对数据库服务的可用性有比较高的要求。最简单地,通过把数据库架设在共享存储系统,将数据文件存储在共享存储,实现数据库实例和存储介质的解耦,从而实现数据库服务的高可用。 当数据库所在机器出现故障时,另一台备用机器通过接管共享存储的数据文件并快速对外继续提供数据库服务,从而保障数据库可用性。 不过,传统的共享存储也是一种高昂的硬件设备,其本身的成本&可用性&容量同样面临着硬件的限制,所以采用共享存储的数据库方案一直难以大规模流行开来。直到后来分布式文件存储系统的日益成熟,这种数据库方案才真正地流行开来。时至今日,事实证明云盘产品能在云分布式环境提供稳定可靠的存储服务,以RDS为代表的各类云数据库产品普遍通过云盘的可用性来保障数据库服务的可用性。 共享存储方案的缺点也很明显。一方面,数据放在远端的共享存储意味着数据库需要通过网络才能访问数据,这导致比单机数据库更明显的访问延迟和性能开销。数据库方案引入共享存储,意味着额外引入了对网络&共享存储等更多的外部依赖,进而导致整个数据库的稳定性有所降低。 另一方面,共享存储方案需要另一台备用机器时刻等待着接管数据库服务,意味着一个数据库服务需要两台机器但却只能有一台机器在提供服务,无法充分利用备用机器资源。因此,如何更好地将闲置的备用机器利用起来,也是一个重要的技术课题。与此同时,当前互联网时代流量特点除海量数据/海量吞吐外,还包括写入修改只占据请求总览的一小部分,用户请求绝大部分都是对内容的查询展示,内容查询场景对数据实时性的要求并不高。基于上述特点,既然另一台备用机器本身空闲又能访问到所有的数据,那是不是可以让它也同时提供一些历史版本的只读查询服务呢?是的,云盘存储方案就能通过只读节点的方式把原本灾备用的节点对外提供只读服务,从而提升整个数据库系统的查询能力。 2. 共享存储方案的演进 然而,云盘存储方案只是相对简单地将数据库服务架构在云盘上,只读节点无法和读写节点同时访问共享存储的同一份数据文件,只能通过单独使用一份共享存储文件后再通过额外机制来和主节点进行同步来实现。共享存储中的数据文件本身就是有多副本的,这意味着数据库层面的多节点会带来乘法效应,浪费更多的存储资源。这和提高机器资源利用率的初衷是想违背的,而且没有利用上共享存储可以被多个机器访问到的天然优势。那么,有没有办法让数据库实例的主节点和多个只读节点同时使用一份共享存储数据文件呢? 共享盘存储方案,通过在数据库层实现多节点间的协调同步,规避多个节点各自对数据文件的变更冲突,从而实现一份数据存储多个节点服务的数据库架构。共享盘存储方案在利用存储产品高可用性保障数据库可用性之余,又很好地利用了共享存储的数据共享优势提供多节点服务。 3. 可计算存储 共享盘存储方案的查询性能可以通过多个只读实例进行扩展,但写入请求只有一个读写节点可以提供服务。而读写节点的性能极限仍然受限于单机硬件的性能上限,特别是网络IO设备的性能上限,不仅没从分布式架构中获得收益,甚至由于共享存储的额外开销反而有所下滑。那么,要怎么样才能让数据库服务的写入性能从分布式共享存储中获益呢? 可计算存储方案即是业界对这一问题给出的一份答卷。经过长时间的观察研究,工程师们发现线上数据库服务的写入性能瓶颈通常都在网络IO。特别是RDS数据库在运行期间需要不停刷写预写日志(write ahead log)/数据文件(data file)等多种数据到远端的分布式共享存储,占用了大量机器IO容量。但与此同时,RDS数据库持久化到分布式共享存储的预写日志/数据文件等数据中包含了大量的冗余信息。比如,针对MySQL/innodb数据库架构下的binlog/redolog这两种预写日志,虽然日志格式各不相同(逻辑日志/物理日志),但二者都是对同一份数据修改的记录,却占用两倍IO流量。再比如数据库以页为单位持久化数据文件,而数据文件的页大小通常是16KB,意味着即使只修改某一页中的一行记录,在写数据文件的时候数据库实例也会产生16KB IO流量,存在比较大的写放大现象。甚至更近一步地,这一行记录的数据变更其实已经随着之前的预写日志写到分布式共享存储,写数据文件的脏页数据完全没有必要,是一种浪费!! 单机数据库之所以采用预写日志技术,是为了通过把数据脏页的随机写操作变成预写日志的顺序写操作,从而提升单机数据库整体性能。但预写日志技术只能推迟并尽可能合并对数据文件的随机写入操作,却不能完全避免对数据文件的随机写入。单机数据库需要不断地把脏页逐步刷写到数据文件来推进检查点,从而释放出更多的日志容量&控制实例故障的恢复时长。而刷脏页通常属于磁盘随机写操作,特别在随机写入的业务场景下,非常影响数据库性能,是单机数据库的一大性能瓶颈点。 因此,工程师们提出了Log is Database的技术理念,这也是可计算存储方案的核心理念。数据库读写节点只通过必要的预写日志把数据库数据变更信息传递给分布式共享存储,而不再需要传递数据文件脏页等额外信息,读写节点机器的IO开销大大减少。那么,数据文件的数据变更怎么办呢?既然预写日志里面已经有所有的数据变更信息,那分布式共享存储系统可以直接从预写日志里获取到数据变更信息,直接将其更新到相应的数据文件中。针对MySQL/innodb数据库架构,更是可以进一步把binlog日志直接省略,单单传递redolog日志就足以把整个数据库的数据变更传递到共享存储系统,大大减少了RDS MySQL数据库实例的IO流量,有效提升了MySQL数据库的性能上限。 在此方案中,数据库读写节点只需要负责传递必要的预写日志给存储系统,不再需要处理数据文件更新维护的任务。而这部分数据维护任务由于涉及大量缓慢的数据IO操作,往往正是整个数据库系统的性能瓶颈所在。数据库读写节点从维护数据文件的高昂开销中脱身后,也得以拥有了极高的数据写入性能。而分布式共享存储系统在处理数据维护任务时,由于自身的分布式架构优势,天然可以通过添加新节点的方式进行水平扩展,不断提升整个系统的吞吐性能上限。 在海量写入的场景中,数据库通常会延缓推进检查点&保留较多预写日志,尽量避免频繁刷脏页导致影响数据库性能。而数据库在故障恢复时又必须回放在检查点后的所有预写日志,以保障数据一致性。因此,数据库在海量写入场景故障恢复中可能会因回放预写日志而消耗大量时间,导致数据库服务较长时间无法服务。由于存储系统的分布式架构优势,可计算存储方案预写日志回放操作被打散到多个存储节点上并行执行,极大提升故障恢复的速度,有效减少数据库服务的不可用时间。 更进一步的,由于拥有数据库全量历史信息,分布式存储系统能够提供历史版本数据页内容。在读取历史版本数据的时候,数据库节点只需要在数据页请求中带上历史版本信息。分布式存储系统在收到历史版本请求时,通过读取该数据页当前的数据文件和历史相关的回滚日志(undolog),然后将两者处理生产历史版本数据页后返回。由此,数据库历史数据处理任务也被下沉到存储系统,得以利用分布式存储系统的水平扩展优势来提升数据库的历史数据查询性能。 至此可以看到,与共享盘存储方案相比,可计算存储方案虽然写入请求只有一个读写节点可以提供服务,但该读写节点只需要负责请求解析、查询执行、事务管理、缓存管理等任务,而数据文件更新维护、数据页版本维护这部分数据库中开销极重的部分流程却拥有了水平扩展的能力。这意味着可计算存储方案在保证可用性的基础上,已经在一定程度上摆脱了传统单机数据库面临的硬件瓶颈,大大提升了服务能力上限。 四、总结 文章篇幅所限,本文简单地介绍了基于共享存储的架构下数据库产品从单机数据库逐步向分布式数据库眼睛的发展历程中逐步面对的问题和对应的解决思路。后续文章中,笔者将尝试探讨数据库的另一条发展路线,即基于独立存储的架构下数据库产品如何从单机数据库逐步走向分布式数据库。

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册