移動(dòng)互聯(lián)網(wǎng)時(shí)代,幾乎每一位做過(guò)中大型應(yīng)用的程序員,都經(jīng)歷過(guò)海量數(shù)據(jù) + 高并發(fā)帶來(lái)的折磨。
記得之前做過(guò)一個(gè)中型的互聯(lián)網(wǎng)應(yīng)用,為了應(yīng)付海量數(shù)據(jù)和高并發(fā),不得不硬著頭皮做了分庫(kù)分表,雖然技術(shù)成熟,但是運(yùn)維非常復(fù)雜,按需擴(kuò)展能力很差,尤其是當(dāng)數(shù)據(jù)的規(guī)模和查詢需求與之前的規(guī)劃不一樣的時(shí)候,調(diào)整起來(lái)非常的痛苦。比如按商戶id做了拆分,但是卻想從另外一個(gè)維度(如用戶id)進(jìn)查詢,處理起來(lái)非常麻煩。
海量數(shù)據(jù)再加上復(fù)雜的數(shù)據(jù)庫(kù)表結(jié)構(gòu),讓DBA每天都戰(zhàn)戰(zhàn)兢兢,因?yàn)閿?shù)據(jù)庫(kù)對(duì)程序員來(lái)說(shuō)就是“黑盒子”,不定哪天就在代碼里寫了一條會(huì)觸發(fā)全表掃描的SQL,讓整個(gè)系統(tǒng)掛掉。特別是對(duì)于一些分析和查詢的場(chǎng)景,查詢耗時(shí)可能達(dá)到分鐘級(jí)別,嚴(yán)重影響用戶體驗(yàn)。
在那時(shí)候沒(méi)啥好辦法,出了問(wèn)題只有靠人力撲上去做分析,加索引,半夜被叫醒都是家常便飯,非??啾?。
我時(shí)常想,就沒(méi)有一種強(qiáng)大的云數(shù)據(jù)庫(kù)把這些問(wèn)題都解決了,讓數(shù)據(jù)庫(kù)更好用、更高效,讓程序員的生活更加輕松一點(diǎn)嗎?
前幾天參加了騰訊全球數(shù)字生態(tài)大會(huì),發(fā)現(xiàn)騰訊推出了一個(gè)叫做TDSQL Boundless(簡(jiǎn)稱TDSQL-B)的分布式數(shù)據(jù)庫(kù),它的幾個(gè)特性不由得讓人眼前一亮,讓我覺(jué)得騰訊云真是瞄準(zhǔn)了互聯(lián)網(wǎng)時(shí)代的數(shù)據(jù)庫(kù)痛點(diǎn)問(wèn)題,并且提供了漂亮的解決方案。
01
和單機(jī)MySQL一樣好用的分布式數(shù)據(jù)庫(kù)
TDSQL Boundless(簡(jiǎn)稱TDSQL-B)是騰訊云推出的最新一代超高性能分布式數(shù)據(jù)庫(kù),我覺(jué)得它最大的亮點(diǎn)就是:“看起來(lái)/用起來(lái)”像個(gè)單機(jī)MySQL,但是性能和拓展性卻達(dá)到了分布式級(jí)別。
無(wú)需分片,彈性擴(kuò)容
就拿最讓人頭疼的數(shù)據(jù)分片來(lái)說(shuō),傳統(tǒng)的方式需要程序員手工指定分片鍵(shard key),一旦分片選錯(cuò),或者之后需要改動(dòng),后果極為嚴(yán)重。
但是在TSQL-B中,系統(tǒng)會(huì)根據(jù)數(shù)據(jù)量自動(dòng)完成分片和調(diào)度,當(dāng)業(yè)務(wù)增長(zhǎng)需要擴(kuò)容時(shí),僅需新增節(jié)點(diǎn),數(shù)據(jù)會(huì)自動(dòng)遷移至新節(jié)點(diǎn),傳統(tǒng)的分布式數(shù)據(jù)庫(kù)擴(kuò)容可能得“按月計(jì)算”,在TSQL-B這里縮減到了分鐘級(jí),整個(gè)過(guò)程上層業(yè)務(wù)無(wú)感知,非常方便。
這比傳統(tǒng)分庫(kù)分表強(qiáng)太多了,程序員無(wú)需提前“絞盡腦汁”規(guī)劃分片策略,業(yè)務(wù)發(fā)展怎么變,無(wú)論數(shù)據(jù)從GB級(jí)增長(zhǎng)到PB級(jí),還是并發(fā)從萬(wàn)級(jí)提升到十萬(wàn)級(jí),數(shù)據(jù)庫(kù)都能自動(dòng)適應(yīng)。
百萬(wàn)級(jí)QPS
傳統(tǒng)數(shù)據(jù)庫(kù)的“主從模式”,只有主節(jié)點(diǎn)能寫,其他節(jié)點(diǎn)只讀,都在“打下手”。TDSQL-B 不一樣,它采用多主模式,每個(gè)節(jié)點(diǎn)都能又讀又寫,就像多開(kāi)了好幾個(gè)高速窗口,同時(shí)處理請(qǐng)求。并發(fā)能力直接拉滿,一個(gè)實(shí)例就能頂住百萬(wàn)級(jí)QPS,突發(fā)流量來(lái)了也不慌。
存儲(chǔ)這塊兒,TDSQL-B 用上了高壓縮比引擎,對(duì)比 InnoDB,壓縮率最高能做到 20 倍。存儲(chǔ)成本直接砍下來(lái),業(yè)務(wù)規(guī)模再大也能玩得起。
金融級(jí)可靠
TDSQL-B 天生就帶著金融級(jí)可靠性,系統(tǒng)會(huì)自動(dòng)把數(shù)據(jù)拷貝成3份,放在不同機(jī)房或者機(jī)架里。就算一個(gè)機(jī)房斷電、硬盤壞了,其他副本馬上頂上,數(shù)據(jù)一條都不會(huì)丟(RPO=0)。哪怕是銀行轉(zhuǎn)賬、證券交易這種最嚴(yán)苛的場(chǎng)景,也能穩(wěn)穩(wěn)撐住。
如果遇到硬盤壞了、整機(jī)掛了,系統(tǒng)會(huì)在 30 秒內(nèi)自動(dòng)切換到備用節(jié)點(diǎn),全程不用人工操作,用戶完全無(wú)感知。對(duì)金融、政務(wù)這種對(duì)“零中斷”要求極高的行業(yè)來(lái)說(shuō),簡(jiǎn)直不要太省心。
TDSQL-B 還有個(gè)“數(shù)據(jù)親和性調(diào)度”的黑科技,會(huì)把主鍵、索引和相關(guān)表的數(shù)據(jù)安排在同一個(gè)節(jié)點(diǎn)上。這樣原本復(fù)雜的分布式事務(wù)就變成了單機(jī)事務(wù),避免了數(shù)據(jù)不一致的問(wèn)題。賬單計(jì)算、余額更新這種關(guān)鍵操作,結(jié)果都能做到精準(zhǔn)無(wú)誤。
由于100%兼容MySQL語(yǔ)法,支持存儲(chǔ)過(guò)程、觸發(fā)器等MySQL核心功能,同時(shí)支持原生的Online DDL操作,現(xiàn)有MySQL業(yè)務(wù)無(wú)需改動(dòng)一行代碼,即可無(wú)損遷移到TSQL-B,非常方便。
TSQL-B的這些能力不但讓它適合高并發(fā)的互聯(lián)網(wǎng)用戶,還適合要求“零中斷、零丟失”的金融行業(yè)用戶,例如銀行、證券、保險(xiǎn)等核心交易系統(tǒng)。
比如某游戲中臺(tái)系統(tǒng),原來(lái)是8 * 一主3備分庫(kù)分表老架構(gòu),替換成TSQL-B以后,不但可以像單機(jī)MySQL那樣使用,資源成本還降低了60%,擴(kuò)容從月降到了分鐘。
02
TDAI:程序員的SQL守護(hù)神
相信不少人都有這樣的經(jīng)歷,上線的功能中包含了一個(gè)不起眼的SQL,結(jié)果把整個(gè)系統(tǒng)都搞掛掉。
在大會(huì)上我就看到了一個(gè)券商的案例,一個(gè)工程師在優(yōu)化債券交易模塊時(shí),隨手添加了一條看似普通的SQL清理語(yǔ)句。這個(gè)SQL本來(lái)計(jì)劃在凌晨執(zhí)行,但是由于沒(méi)有正確利用索引,引發(fā)了核心交易表的全網(wǎng)掃描,數(shù)據(jù)庫(kù)性能持續(xù)惡化。
等到上午開(kāi)市,大量高頻交易指令涌來(lái)的時(shí)候,數(shù)據(jù)庫(kù)鎖等待時(shí)間攀升至30+秒,高凈值客戶的交易被迫終止,應(yīng)急團(tuán)隊(duì)緊急回滾代碼后才逐步恢復(fù)服務(wù)。
這個(gè)事故反映出來(lái)的其實(shí)開(kāi)發(fā)和DBA之間存著認(rèn)知鴻溝。
開(kāi)發(fā)團(tuán)隊(duì)對(duì)業(yè)務(wù)邏輯和代碼門兒清,但一到數(shù)據(jù)庫(kù)這塊兒,基本就是個(gè)“黑盒子”,反正 ORM 框架能幫忙生成 SQL,管它呢。結(jié)果 SQL 寫出來(lái)跑得好不好,全憑運(yùn)氣。DBA懂?dāng)?shù)據(jù)庫(kù)內(nèi)核,也懂各種優(yōu)化技巧,但是沒(méi)法進(jìn)入開(kāi)發(fā)環(huán)節(jié),只能是出了問(wèn)題被動(dòng)“救火”。
能不能在開(kāi)發(fā)階段就發(fā)現(xiàn)并且消除SQL風(fēng)險(xiǎn)的萌芽呢?
這就是TDAI要做的事情,它既懂代碼,又懂?dāng)?shù)據(jù)庫(kù),在開(kāi)發(fā)者在寫代碼的時(shí)候就能掃描代碼,發(fā)現(xiàn)有風(fēng)險(xiǎn)的SQL,給出優(yōu)化建議。
這個(gè)功能還能無(wú)縫集成到CI/CD的流程中:
這就像給代碼裝上了一個(gè)“風(fēng)險(xiǎn)透視鏡”,把可能出現(xiàn)的SQL風(fēng)險(xiǎn)都消滅在無(wú)形之中。這個(gè)功能真的是很贊。
你可能會(huì)好奇,TDAI是怎么實(shí)現(xiàn)的呢?
現(xiàn)在的通用大模型肯定是不行的,數(shù)據(jù)庫(kù)是個(gè)垂直場(chǎng)景,通用大模型理解不了那些復(fù)雜的表和復(fù)雜的SQL。當(dāng)前業(yè)界智能體記憶系統(tǒng)(如AWS Bedrock AgentCore、Google Vertex AI Memory)側(cè)重記錄用戶偏好和對(duì)話上下文,未與企業(yè)私域數(shù)據(jù)深度打通。
所以騰訊云專門訓(xùn)練了一個(gè)數(shù)據(jù)庫(kù)大模型(DB LLM),包含了Code2SQL模型(C1)、智能診斷模型(D1)、智能優(yōu)化大模型(O1),將SQL抽取準(zhǔn)確率提升至90%+,并對(duì)SQL診斷推理持續(xù)深度優(yōu)化,診斷結(jié)果高置信度。
其次,TDAI還有一個(gè)全域上下文,整合Memory(長(zhǎng)短期記憶)、DeepSearch(深度檢索)、Catalog(數(shù)據(jù)目錄),構(gòu)建企業(yè)級(jí)數(shù)據(jù)中樞,實(shí)現(xiàn)企業(yè)數(shù)據(jù)與智能體記憶的深度融合。
而工具集則基于MCP協(xié)議封裝上層智能體所需的原子能力(如實(shí)例克隆、流量回放),為智能體提供“從規(guī)劃到執(zhí)行”的工具支撐。
這一套組合拳打下來(lái),就實(shí)現(xiàn)了事前預(yù)測(cè)SQL風(fēng)險(xiǎn)的驚艷效果。
TDAI不僅解決了風(fēng)險(xiǎn)SQL治理“先上線,再發(fā)現(xiàn)”的困境,還突破性地實(shí)現(xiàn)了從“人找數(shù)據(jù)”到“數(shù)據(jù)找人”的范式躍遷,它就像個(gè)24小時(shí)不間斷工作的哨兵,能自動(dòng)看懂業(yè)務(wù),找出關(guān)鍵指標(biāo)的因果關(guān)系,能實(shí)時(shí)盯著數(shù)據(jù)流,秒級(jí)發(fā)現(xiàn)異常和趨勢(shì)變化。一旦發(fā)現(xiàn)問(wèn)題,它會(huì)立刻生成帶有原因分析、趨勢(shì)預(yù)測(cè)和行動(dòng)建議的報(bào)告,直接推送給決策者。
可以說(shuō),TDAI重新定義了數(shù)據(jù)庫(kù)治理范式,實(shí)現(xiàn)了用AI治理好數(shù)據(jù)庫(kù)。
03
AI自學(xué)習(xí)優(yōu)化器:越用越聰明
在云計(jì)算和大數(shù)據(jù)時(shí)代,數(shù)據(jù)不僅越來(lái)越多,還越來(lái)越復(fù)雜。企業(yè)的業(yè)務(wù)需求也跟著升級(jí),尤其是做統(tǒng)計(jì)和分析的時(shí)候,動(dòng)不動(dòng)就是上億行的數(shù)據(jù),要跑多表 JOIN、好幾層嵌套查詢,還要面對(duì)動(dòng)輒上百列的大寬表,這些查詢耗時(shí)經(jīng)常達(dá)到分鐘級(jí)別,嚴(yán)重影響用戶體驗(yàn)。
為了降低一個(gè)復(fù)雜SQL的查詢時(shí)間,經(jīng)常把DBA給累得夠嗆。
其實(shí)SQL執(zhí)行速度的快與慢,和數(shù)據(jù)庫(kù)的優(yōu)化器有極大的關(guān)聯(lián),優(yōu)化器的核心任務(wù)是從海量可能的執(zhí)行計(jì)劃中選擇最優(yōu)方案,以決定資源開(kāi)銷和查詢時(shí)延,是決定數(shù)據(jù)庫(kù)查詢性能的核心環(huán)節(jié)。
但是在海量大數(shù)據(jù)和復(fù)雜查詢的場(chǎng)景下,傳統(tǒng)數(shù)據(jù)庫(kù)優(yōu)化器的局限就暴露了出來(lái)。
以10表關(guān)聯(lián)查詢?yōu)槔?,需要搜索的?zhí)行計(jì)劃數(shù)量達(dá)到362萬(wàn)至176億種!
優(yōu)化器要在有限時(shí)間里挑一個(gè)執(zhí)行計(jì)劃,會(huì)大量“剪枝”,結(jié)果就是最佳方案可能直接被錯(cuò)過(guò)了!
另外優(yōu)化器主要靠過(guò)去的經(jīng)驗(yàn)來(lái)估算,但每個(gè)業(yè)務(wù)場(chǎng)景都不一樣,結(jié)果很難做到“因地制宜”,遇到數(shù)據(jù)傾斜,或者多列之間有關(guān)聯(lián)時(shí),優(yōu)化器就很難準(zhǔn)確判斷數(shù)據(jù)分布。這樣一來(lái),索引怎么選、JOIN 順序怎么排,常常會(huì)出錯(cuò),執(zhí)行效率大打折扣。
騰訊云 TDSQL-C 通過(guò)結(jié)合騰訊混元大模型的能力,建立了可自我反思演進(jìn)的全鏈路優(yōu)化器能力,成為業(yè)界首個(gè)推出 AI 自學(xué)習(xí)數(shù)據(jù)庫(kù)的廠商。
有了騰訊混元大模型的加持,極大地?cái)U(kuò)展了搜索空間,避免陷入局部最優(yōu)解,通過(guò)可量化的數(shù)據(jù)反饋,突破了傳統(tǒng)獨(dú)立性假設(shè),減少了估算偏差。
騰訊還自研了一個(gè)“AI代價(jià)對(duì)比模型”,在線推理不同計(jì)劃的代價(jià),能夠更準(zhǔn)確地度量每個(gè)執(zhí)行計(jì)劃的質(zhì)量。最后基于歷史執(zhí)行效果,持續(xù)反饋深度優(yōu)化模型,實(shí)現(xiàn) “越用越準(zhǔn)” 的智能優(yōu)化。
AI自學(xué)習(xí)優(yōu)化器的效果也非常驚人,在 TPC-DS 測(cè)試中,復(fù)雜查詢總時(shí)延可降幅80%以上。
在一個(gè)騰訊數(shù)據(jù)庫(kù)客戶的實(shí)際業(yè)務(wù)案例中,通過(guò) AI 自學(xué)習(xí)優(yōu)化器的自動(dòng)調(diào)優(yōu),擁有超16萬(wàn)張表、600多種SQL語(yǔ)句、Top7慢查詢一天耗時(shí)13000多秒的客戶,在零人力投入的情況下,直接讓7類慢查詢總耗時(shí)下降80%+,查詢耗時(shí)壓縮到了3000秒內(nèi)。
04
總結(jié)
現(xiàn)在回頭來(lái)看,數(shù)據(jù)庫(kù)的這些年發(fā)展路線很清晰:
(1)從本地到云端
(2)從單機(jī)到分布式
(3)從人工調(diào)優(yōu)到智能化
但是,海量的數(shù)據(jù)和高并發(fā)也讓程序員為了分庫(kù)分表的設(shè)計(jì),為了降低那么一點(diǎn)點(diǎn)查詢時(shí)間而絞盡腦汁,數(shù)據(jù)庫(kù)甚至成了程序員半夜被叫醒的“定時(shí)炸彈”。
而今天,騰訊云TDSQL-B 這樣的分布式數(shù)據(jù)庫(kù)、TDAI 和AI自學(xué)習(xí)優(yōu)化器,正在把這些煩惱一一解決掉。它不僅解決了開(kāi)發(fā)者和 DBA 最痛的點(diǎn),還為未來(lái)的數(shù)據(jù)庫(kù)打開(kāi)了一個(gè)全新的方向:數(shù)據(jù)庫(kù)不再只是一個(gè)被動(dòng)的“黑盒”,而是能主動(dòng)學(xué)習(xí)、主動(dòng)優(yōu)化、主動(dòng)守護(hù)的“智能伙伴”。
未來(lái)的程序員和 DBA 可以輕裝上陣,把精力真正放在業(yè)務(wù)創(chuàng)新上,而不是疲于救火。這是程序員,也是IT界最大的福音。
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺(tái)“網(wǎng)易號(hào)”用戶上傳并發(fā)布,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.