本文由 PingCAP 聯合創始人兼 CTO 黃東旭撰寫，基於親身經歷的資料庫行業，深度總結過去一年資料庫發展的重要趨勢，以及展望 2023 年資料庫新方向，希望對更多的行業從業者有所啟發。

在他看來，資料庫未來的發展趨勢必然是以「省人、省時、省事、省錢」為主要目標，在雲原生趨勢下，其不單單是作為一種軟體，而是一種服務來成為加快科技發展的重要引擎。

2022 年，我們被太多的技術熱詞所圍繞，也讓很多企業和開發者對未來的科技世界越來越迷茫。

今年我有很長一段時間在北美技術圈，有一些切身感受：**一個是大環境下影響下的經濟變差**。經濟不好的時候就要去省錢，會採取比如降低 Infra 投入等措施，這多少都會影響公司的決策。如果你是一個解決方案提供商，要去賣產品時，倘若在產品的價值或者故事中沒有體現能幫客戶省多少錢，基本上對方可能看都不會看你一眼；**第二個是缺人**。用另外一個說法表達就是“從業者門檻降低”。比如說你原來可能是一個 Infra 工程師，現在可能要被迫變成一個全棧工程師，就相當於一專多能，或者說對於開發業務應用的門檻需要被降得更低。現在大家都希望用更少的人，更快的時間去進入市場。

那針對上面痛點，對映到資料庫技術上有哪些趨勢變化？

1. 對於新一代的資料庫來說，HTAP 是必選的技術路線，我有一個預言：**未來的資料庫都會是 HTAP 資料庫**。只有純 AP 對於業務來說是不完整的，TP 非常重要。
2. 資料庫要用雲原生的方式進行架構改造，不僅是存算分離，而是能分離的都分離，因**為現在資料庫要做的已經不再是一個軟體，而是一個服務**，使用者也不會關心服務背後的東西。使用者希望使用起來越簡單越好，最好把所有基礎設施的細節都隱藏掉，極低的心智負擔帶來極低的上手體驗和價值確認。
3. **Serverless 將成為資料庫最終的產品形態**（注意：Serverless 並不是技術，而是產品形態）。

## 未來的資料庫都會是 HTAP 資料庫

2022 年，HTAP 一詞越來越火。雖然從考古上來講， HTAP 最早是在 2014 年由分析機構 Gartner 提出，但直到現在其實它還是一個很新的概念，不少人還是持有偏懷疑的態度，然而，這個需求又是存在的。大家未必會去定義它到底是哪個名詞，但是大家都會去用。很多人現在還不太想說把 HTAP 變成一個專有的類別，而是想先用一些新型的資料庫或者新型的產品解決業務問題。我認為 HTAP 的普及還需要一定的時間，不過，當前已經能夠看到星星之火開始成燎原之勢。

2022 年 5 月，Google Cloud 釋出了最新的資料庫產品 AlloyDB，HTAP 能力便是其中最顯著的亮點；6月，當紅 Data Cloud 廠商 Snowflake 首次釋出了 HTAP 產品 Unistore 。

至此，全球三大雲廠商 AWS、微軟、GCP 和 Data Cloud 領導者 Snowflake，以及正在加速雲轉型的資料庫巨頭 Oracle （MySQL Heatwave）都已經發布了以 HTAP 為主要架構亮點的資料庫產品。

如果細看這些產品，你會發現 MySQL 在 2021 年釋出的 Heatwave 雖然在分析能力上是個 MPP 的架構，但 MySQL 本身還是單機版的，Google AlloyDB 參考了 AWS Aurora 的架構，做到了青出於藍的效果。NewSQL 的分支鼻祖是 Google Spanner，但同為 NewSQL 架構的 TiDB 持續在 Real Time HTAP 投入巨大，TiDB 早期解決了 MySQL 分庫分表的問題，就面臨使用者的線上分析需求。在 2018 年 TiSpark 的引入，2020 年 TiFlash 架構完成了 HTAP 架構的閉環，再到 2021 年 TiDB 5.0 版本的 MPP 能力，這個能力也透過 TiDB Cloud 向所有云上使用者輸出，在 5 年時間 TiDB 完成了 Real Time HTAP 產品能力的四連跳。

總體來看，雖然各產品的具體實現有所不同，但新一代 HTAP 架構有一些明顯的共性追求：以開源打底，藉助了雲端擴充套件性，追求一個入口，一套資料棧，可以將 OLTP 資料和 OLAP 資料實時同步，部分廠商 OLAP 的實現採用了類似 MPP 下推方式，達到 No Application Change、No Schema Change、No ETL，No data move 的四不效果，最大化減少對應用程式的改動。

任何一種資料庫潮流都是“**需求變化**✖️**技術變革**✖️**架構創新**“ 三者融合的產物，HTAP 也不例外。

首先，在需求變化側，推動新一代 HTAP 的資料庫廠商在提到 HTAP 的時候都不約而同地用到 **Operation** 這個詞，藉助熱資料實現運營級別的實時分析，獲得實時的洞察以支援運營動作的反饋，這是推動新一代 HTAP 走上舞臺中央的最大需求側變化。

其次，在技術變革與架構創新側，雲基礎設施的發展帶來了存算分離更為徹底的變化，這是技術變革帶來的新可能性。分散式理論與雲端計算、AI 演演算法的融合帶來了新一代的架構創新，這些都使得 HTAP 在雲端可以支援不同的雲端儲存，AI 等新技術，打造更有成本競爭力的創新。

我認為**真正 HTAP 的形態其實在雲上做意義才大，因為 it's all about balance，只有在雲上才能去打破 AP 跟 TP 之間對於資源的不平衡**。比如像 TP，其實要求的是一個穩定、高效能、低延遲的一些硬體資源，但對於 AP，可能是短時間海量的計算資源，因為要做高效能的 AP，你會發現在雲下這個東西怎麼擺都彆扭，我為什麼要去買這麼高配的伺服器，我為什麼每天就跑三次大的全表掃描，但是 99% 的時間 CPU 都壓不上去。雲原生已經開始進入下一個階段。今年在北美看到的情況是幾乎所有公司都在做雲 / 雲原生方向的轉型，這並不是需要討論的事情，而是已經完備的狀態。

第三，這一輪 HTAP 的使用者群體和上一代記憶體資料庫 HTAP 的小眾貴族非常不同，這一代 HTAP 的使用者非常大眾化，**幾乎採用 MySQL 和 PG 開源資料庫的所有企業都可以藉助新一代 HTAP 架構擴充 OLTP 和 OLAP 的能力範圍**，都能用上一種不用修改應用，不用增加額外資料系統且擁有強大分析能力的資料庫。

## 要用雲原生的方式進行架構改造

今天做資料庫，如果不提供雲服務，出門都不太好意思和人打“招呼”（很快就會是 Serverless）。有很多人（尤其是資料庫核心開發者）會低估做一個雲服務的複雜性，經典的論調：“不就是在雲上的自動化部署嗎？“或者“支援一下 Kubernetes Operator？“

其實並不是，甚至目標都應該反過來：**我們要做的並不是一個資料庫軟體，而是一個資料庫服務**，當我們用更長的眼光去看的時候就會發現，後者是包含前者的。這個認知的轉變是做好資料庫雲服務第一步，也是最重要的一步。

過去我們開發程式，不同的模組看到的環境是同構且確定的，例如：開發一個單機上執行的軟體，不同的模組雖然可以有邏輯上的邊界，但是連結到一起之後，執行起來看到的還是這臺計算機的一畝三分地，「Everything is a trade-off」。即使近幾年分散式系統的興起，但對於經典的分散式軟體而言，大致還是單機軟體設計思路的延伸，只是透過 RPC 將多臺計算機連線在一起，環境是相對確定的，儘管很多軟體對於底層的環境變化做了一些適配：例如分散式資料庫的動態擴容，資料重均衡 Re-balance 等，但是本質並未變化，只是能夠操控和排程的資源變多了。

然而，在雲上，這些假設都發生了變化：

1. 多樣且幾乎無限的資源透過 Service API 的形式提供，對於資源的排程和分配可以透過程式碼完成，這是革命性的變革。
2. 一切資源明碼標價，所以程式最佳化的方向從過去的一維的榨取最好的效能（因為硬體的成本已經事先支付），變成一個動態的問題：儘量花小錢辦大事。

假設的變化帶來技術上的變化：**雲上的資料庫，首先應該是多個自治的微服務組成的網路**。這裡的微服務並非一定是在不同的機器上，在物理上可能在一臺機器上，但是需要能在遠端訪問，另外這些服務應該是無狀態的（無副作用），方便快速的彈性擴充套件，這個帶來對於開發者的轉變就是：**放棄對於同步語義的堅持，這個世界是非同步化且不可靠的**。我很高興我的偶像 Amazon 的 CTO Werner Vogels 在 2022 年 ReInvent Keynote 上也強調了這一點。

放棄掉對於同步和單機的幻想，得到了什麼？我們看一些例子：

第一，**最近幾年被“聊爛”的存算分離**。在雲上，計算的單位價格比儲存要高得多，如果計算和儲存繫結，那麼就沒有辦法利用儲存的價格優勢，另外對於一些特定的請求，如對計算的需求很可能與儲存節點的物理資源是完全不對等的（想象一下重型的 OLAP 請求的 Resuffle 和分散式聚合）。另外，對於分散式資料庫來說，擴容速度是一個重要的使用者體驗指標，當存算分離後，原則上擴容速度是能做到極快的，因為擴容變成了：一是啟動新的計算節點，二是快取預熱；反之亦然。

第二，**對於資料庫來說，一些內部元件的微服務化**，例如：DDL-as-a-Service。傳統資料庫的 DDL 對於線上業務是有影響的（即使用了 Online DDL），例如新增索引時候，不可避免的需要進行資料回填，這對於正在服務 OLTP 負載儲存節點來說會引起抖動。如果我們仔細思考一下 DDL 就會發現它是一個：全域性的、偶發的、重計算、可離線進行，可重入的模組，如果有一個共享的儲存層（例如 S3），這類模組非常適合剝離出來變成一個 Serverless 的服務，透過 S3 與 OLTP 的儲存引擎共享資料。帶來的好處毋庸置疑：

- 對線上業務也是幾乎沒有效能影響。
- 因為按需執行，帶來成本下降。

類似的例子還有很多：日誌（CPU 使用少，但是對於儲存要求高）、LSM-Tree 儲存引擎的 Compaction、資料壓縮、元資訊服務、連線池、CDC等等，都是可以且很適合被剝離的物件。在新的 Cloud-native 版本的 TiDB 中，我們使用了 Spot Instances 進行儲存引擎的 Remote Compaction，帶來的成本下降是驚人的。

在設計雲資料庫的時候，另一個重要的要思考的問題是：QoS(Quality of service)，具體到細節大概是：

- 需要定義 WCU 和 RCU，作為控制的單位，如果沒有辦法定義它，你將沒辦法進行資源的分配和排程，乃至定價。
- 多租戶是必選項，租戶之間一定要可以共享硬體甚至叢集資源，大租戶也可以獨佔資源（單租戶模式是多租戶的一種特化），帶來的問題：如何避免 Noisy Neiberhood 問題？如何設計 Throttling 策略？如何避免共享的元資訊服務 Overwhelm？如何應對極端的熱點？
- 挑戰還有很多，我就不一一列舉了。

另一個很重要的話題是：雲上哪些服務可以依賴？這是因為對於一個第三方廠商來說，跨雲（甚至是跨雲下，類似混合雲）的產品體驗是天然的優勢，如果對於特定的雲服務依賴得太深太緊，將會讓你喪失這份靈活性。所以選擇依賴的時候需要非常小心，下面是一些原則：

- **依賴介面和協議**，而不是具體實現，服務內部可以隨便自己搞，但是給其他服務暴露的介面要通用且不要做過多假設，簡單來說，就是被呼叫者心智負擔最小化（UNIX 時代留存下來的古老智慧）。一個很好的例子是：VPC Peering 和 PrivateLink，如果按照這個原則，肯定選擇 PrivateLink，因為 VPC Peering 傾向於暴露更多的細節給被使用者。
- **有行業標準就 Follow 行業標準**（S3，POSIX 檔案系統），每個雲上都有物件儲存，而且每個雲的物件儲存 API 大概都會相容 S3 協議，這就是好的。
- 唯一的例外是安全。**如果沒辦法做到跨雲的抽象，也別自己強行造輪子**，雲有什麼就用什麼，例如金鑰管理、IAM 等，千萬不要自己發明。

下面舉幾個例子說明一下，對於 Cloud-Native TiDB 來說，在選擇依賴的時候做出如下選擇：

### 儲存

S3，就像上面提到的，每個雲都會有 S3 協議的物件儲存服務。在資料庫中使用類似 LSM-Tree 的分層儲存，帶來的好處是能夠透過一套 API 來利用不同層次的儲存介質，例如上層的熱資料可以使用本地磁碟，下層的資料在 S3 上，透過非同步的 Compaction 來將上層的資料交換到 S3 上。這是 TiDB 存算分離的基礎，只有資料在 S3 之後，才能解鎖 Remote Compaction 等操作。但是帶來的問題是：S3 的高延遲註定了它不能出現在主要的讀寫鏈路上（上層快取失效，會帶來極高的長尾延遲）。對於這個問題，我是比較樂觀的：

- 如果我們考慮 100% 本地快取的場景，就退化成經典的 Shared-Nothing 的設計，用於支撐最極端的 OLTP 場景我認為是沒問題的（參考現在的 TiKV），額外付出代價只是 S3 上的儲存成本哪一個是很低。
- 如果分片做得足夠細，快取和熱點問題是好解決的。
- 分層儲存中還可以加入 EBS（分散式塊儲存）來作為二級快取，進一步削峰（削弱本地快取失效帶來的延遲突變）

我在 2020 年的一次分享中提到，**對於雲原生的資料庫而言，如何能利用好 S3 會是關鍵**。這個觀點到現在還沒有變化。

### 計算

容器 + Kubernetes，和 S3 一樣，每個雲都有 K8s 的服務，就像 Linux 一樣，K8s 是雲的作業系統，雖然存算分離做完後，計算相對好管理一點，但是像一些計算資源池的管理，例如 Serverless 叢集需要的快速啟動（冬眠喚醒），從 0 開始啟動建新 Pod 肯定來不及，需要有一些預留的資源，又例如使用 Spot Instance 來處理 Compaction 任務，萬一某個 Spot Instance 被回收，能否再快速找個機器繼續工作，又例如負載均衡和 Service Mesh…

雖然 S3 幫你把最難搞的狀態問題解決了，但是這些純計算節點的排程問題是很瑣碎的，如果你選擇自己造輪子，那麼大機率最後你會重新發明一個 K8s，所以不如直接擁抱。

在雲上，還有一個很大的設計問題：**檔案系統是一個好抽象嗎**？這個問題來自於在哪層抽象之下遮蔽雲的基礎設施。在 S3 普及之前，各個大型的分散式系統儲存系統，尤其是 Google 的 BigTable、Spanner 等都選擇了一個分散式檔案系統作為底座（我認為這裡面有很深的 Plan9 的痕跡，畢竟 Google 內部這些 Infra 大神很多都是從貝爾實驗室來的）。

那麼問題來了，如果有了 S3，我們還需不需要一層檔案系統的抽象？我目前還沒有想清楚，我傾向於有，理由仍然是儲存的快取，如果有一層檔案系統，在檔案系統層能夠根據檔案的訪問熱度做進行一層快取，提升擴容時候的預熱速度；另一個好處是基於檔案系統，生態工具相容性會更好，很多 UNIX 的工具能直接複用，運維複雜度降低。

我在 2022 年的 PingCAP DevCon 的 Keynote 中提到了一點：雲上的資料庫如何與現代的開發者體驗融合？這個是一個很有意思的話題，因為資料庫那麼多年了，幾乎還是這個樣子，**SQL is still the king**。但是另一方面現在開發者開發的應用以及使用的工具已經和幾十年前大不一樣了，作為一個從 UNIX 時代過來的老程式設計師，看到現在年輕一代的開發者使用的眼花繚亂的先進開發工具和理念，只能感嘆一代比一代強，雖然運算元據 SQL 仍然是標準，但是資料庫軟體能否做更多，去融入這些現代的應用開發體驗中？

## Serverless 將成為資料庫最終的產品形態

我認為雲原生的下一個階段，其本身會越來越自洽，並會逐漸形成全棧的雲原生，這種全棧的雲原生將會催生 Serverless 的發展。Serverless 的本質其實很簡單，依舊是幫助開發者更進一步地隱藏基礎設施的複雜性。**總結來看，未來幾乎所有在雲上的軟體都會形成一個自洽的 Serverless 生態**。

Serverless ，很多人認為的 Serverless 是一個技術名詞。我認為不是，Serverless 更重要的是從使用者體驗角度定義了什麼是更好的雲上軟體的產品形態。或者這本來就應該是理所應當的：為什麼作為使用者需要關心你有幾個節點？為什麼需要關心內部的引數和配置？為什麼我點了啟動，你要讓我再等半小時？

這些在我們行業裡面過去看起來似乎理所應當的事情，其實仔細想想都覺得挺可笑的，舉個例子：假設你去買個車，賣車的先送給你一本發動機維修指南，告訴你讀完才能上路，車跑得不快，然後告訴你某個發動機引數需要你調一下，每次啟動汽車都要等半小時…這是不是很奇怪？

對於 Serverless 的產品來說，從使用者體驗來說，最大的意義在於三件事情：

1. 遮蔽掉配置，降低了使用者的心智負擔；
2. 極其快速的啟動時間，這點擴充套件了使用場景和易用性；
3. Scale-to-Zero，在多數場景中降低了使用的成本（當有明顯波峰波谷，且你沒法預測的場景），在小規模時甚至可以免費。

有了以上三點，才能很好地將資料庫嵌入到其他的應用開發框架中，這是構建更大的生態的基礎。

除了 Serverless 之外，現代的開發者體驗（DX）中還包含很多其他的關鍵要素，例如：

- **Modern CLI**：對於開發者來說，CLI 的效率比圖形介面高得多，而且更容易透過 Shell 指令碼組合其他工具實現自動化。
- **雲端 - 本地統一的開發 / 除錯 / 部署體驗**：沒有人想天天碰伺服器，本地能搞定的事情，就不要讓人 SSH。尤其對於雲服務來說，如何在雲下開發和除錯，目前是一個有很多痛點的市場。
- **Example Code / Demo / 腳手架**：新一代的偏向 PLG 的服務提供商。例如：Vercel、Supabase 這一套玩的很溜，想想這也是合理的，對於普通的 CRUD 應用來說，基本的程式碼框架都是相似的，提供一些快速上手的例子，能夠讓開發者更快的體會到你的產品價值，也幫助開發者更快的構建他們的應用。

因此，通常而言 Serverless 資料庫應該具備如下四點關鍵特性：

1. **按量計費且費用透明**。在 Serverless 資料庫服務形態下，使用者僅需為每次事務處理或查詢分析所消耗的 CPU、儲存、網路頻寬、磁碟 I/O 等資源使用量而付費，不用則不產生費用。這為使用者節約了大量成本，尤其是在執行負載不穩定或不可預測的應用程式時。此外， Serverless 資料庫的計費方式完全透明，使用者可以清晰瞭解資源消耗量，並計算準確的投入產出比，即 ROI。
2. **極致彈性**。Serverless 資料庫可以跟隨業務複雜變化自動匹配所需資源，在很短的時間內大幅擴充套件應對流量和負載高峰，也可以在沒有需求時縮到 0。從而幫助使用者的應用程式總是能擁有合適的資源以保持最佳執行狀態，而不用過度配置。
3. **使用簡單**。Serverless 資料庫遮蔽了基礎設施的複雜性，使用者使用時不用做資源選型和容量預估，也不用再去關心底層的基礎設施的管理維護。使用者因此可以從繁瑣的資源管理工作中徹底解放出來。
4. **高可用**。Serverless 資料庫能夠在任何計算例項、網路，或者硬體發生故障時，透過多副本以及自動故障切換能力，保障使用者的的資料始終可用，並且資料總是正確無誤。

聽起來很美好，Does it even possible？經過大半年的時間，我們終於把首個原型做出來了，並在 11 月 1 號上線公測，它就是 TiDB Serverless Tier。

我自己寫了一個小程式，在一個全新的環境下，透過程式碼啟動一個 TiDB 的 Serverless Tier 例項。在整個過程裡，我只是告訴這個程式，要啟動一個叢集，這個叢集叫什麼名字，然後把密碼一輸，20 秒之後可以直接拿一個 MySQL 客戶端連上去了，這個時間未來會進一步縮短。想象一下，如果縮短到三五秒鐘，這會極大地改變開發應用的使用流程和體驗。而且不用關心它的擴充套件性，即使上線以後，業務流量變得巨大無比的時候，它也能夠很好地擴容上去，沒有流量的時候，它還能縮回來。

它背後其實有很多很多的技術細節，本文就不一一細說了。其中我們有一個原則，就是怎麼利用好雲提供的不同的服務，比如 Spot Instances、S3、EBS、彈性的 Load Balancer。TiDB 的 Serverless Tier 背後對於雲上所有的彈性資源都進行了很好的整合，以及巧妙的排程，提供了一個極致彈性的使用者體驗。這個使用者體驗比原來的雲原生資料庫更往前跨越了一步，細節更少，抽象程度更高。

我幾乎可以很肯定的說，**對於新創的所有資料庫公司，如果說前兩年你的門票是雲原生的話，你今年的門票就變成 Serverless**，沒有 Serverless 基本上不了牌桌。現在，Serverless 資料庫也成了國內外各家公有云廠商，以及獨立資料庫廠商開始爭相佈局的領域。如 AWS、Azure、GCP、阿里雲、騰訊雲，以及 MongoDB、PingCAP、CockroachDB、Snowflake，最近一年來都在加速投入 Serverless 資料庫服務。

## 2023 年展望：新產品形態、商業模式、研發組織、AI 體驗

未來，資料庫技術還是有很多事情可以做。不過，我個人覺得有一條主線，這條主線就是貼著**應用開發者**，最後不管是企業級應用還是其他各種應用，這些應用都是程式設計師寫出來的，都是程式碼開發者開發出來的。

在 ChatGPT 出來之前，我一直認為 AI 存在過度炒作的成分，但 ChatGPT 真的讓我感到驚喜，讓我體會到 AI 的價值，它並非直接取代工程師，而是提升工程師的生產效率。這類工具與企業內部現有業務的結合將會是接下來非常值得關注的趨勢。

本質上，行業如何提升應用開發者的效率，這可能是一個大的發展方向，有可能這個主線發展到未來，會發現資料庫技術在做很多事情上都不是資料庫技術了，比如一個更好用的 Serveless 資料庫怎麼做？我用一大堆負載均衡或者彈性計算的技術，甚至接下來我在想是不是 SQL 對於應用開發者來說還是太複雜了，有沒有更好的離使用者更近的資料產品表現形態？TiDB Cloud Serverless Tier 最近推出了一個 AI 工具 Chat2 Query beta 版，它可以讓使用者用自然語言生成 SQL 去做相應的資料查詢，從而讓每一個使用者都可以以非常容易的方式從資料中獲取洞察。

我覺得接下來未來的資料庫技術，**技術本身不重要，最後的方向是提升每一個應用開發者的幸福指數**。資料庫技術一定會往更簡單、更加好用、更加方便地讓大家寫出新的應用，向加速進入市場的方向去努力。

以下面一段作為結尾，列一部分有意思的挑戰，雖然肯定不完備，希望能對你有所啟發：

1. 新的產品形態。當不同租戶的儲存引擎上的資料都在 S3 之後，理論上可以解鎖一個更大的基於資料共享和交換的市場（想象一下 Google Docs），又或者在 S3 上 + MVCC 理論上可以實現類似 Git 似的對於資料的版本控制，想象一下 git checkout 的順滑體驗，只是不同的是，你切換的是你的資料庫映象（我知道已經有云上的資料庫產品開始探索該種產品形態），這會帶來很多新的應用場景和獨特的價值。
2. 新的商業模式。雲是新的計算機，但世界上應該不會只有幾臺計算機，除了標準的 SaaS 模式外，還有沒有可能將 DBaaS 作為一個整體進行輸出，這可能又是一種全新的商業模式（尤其是在和一些二線或者私有云合作的時候），此時資料庫廠商會變成輸出資料庫服務產品的廠商（有點繞）。
3. 新的研發組織。對於一個資料庫廠商來說，過去研發和產品的需求幾乎只限於核心開發，但是在做雲服務的過程中，你不僅是開發者，還會是運維和運營者，而且開發雲服務對於研發人員的技術棧的要求和資料庫核心是完全不一樣的，其中裡面必然涉及巨大的組織變革和人事調整。
4. 資料庫的互動體驗會被 AI 完全重塑。當我們把 Serverless、HTAP、AI 結合在一起時，它們會完全改變我們與資料庫互動方式的可能性。現在我們已經可以利用 AI 的能力將自然語言轉化為標準的 SQL 程式碼，任何人，即使他不怎麼懂 SQL 也可以輕鬆實現複雜的資料查詢分析，讓人人都有機會成為資料分析師，這就是未來資料庫的樣子，而這一天即將到來。

最後，過去一年，我們已經看到中國的很多技術、專案、開發者在全球產生了一定影響力，我也看到了廣闊的全球市場在向中國企業招手。未來，越來越多來自中國的技術會逐漸走向全球，構建屬於自己的全球影響力。

PingCAP 黃東旭萬字長文剖析資料庫發展新趨勢：脫離應用開發者的資料庫，不會成功

相關文章