在今年的第七屆中國(guó)開源年會(huì)上，StoneDB 團(tuán)隊(duì)在大數(shù)據(jù)分論壇發(fā)表了《HTAP 的下一步？SoTP 初探》主題演講，在本次演講中，我們首次正式對(duì)外闡釋了“SoTP 數(shù)據(jù)庫(kù)”的技術(shù)理念，本系列是演講實(shí)錄+小編補(bǔ)充版，權(quán)當(dāng)拋磚引玉，供大家批評(píng)指正。由于內(nèi)容比較多，本文為第一章節(jié)，主要講講我們提 SoTP 的背景：From Big to Small and Wide Data。
一、HTAP 的起源、流派和迷思
HTAP 起源
我們首先從起源講起，不過由于是公開演講，考慮到一些聽眾是小白，所以這里主要是從一個(gè)比較宏觀的關(guān)系型數(shù)據(jù)庫(kù)行業(yè)發(fā)展歷史視角來看的，關(guān)于 HTAP 更具體的技術(shù)和商業(yè)的起源背景，可以看看 StoneDB 首席架構(gòu)師李浩老師寫的這篇文章：HTAP 的背景。
眾所周知，圖靈獎(jiǎng)（Turing Award）算是計(jì)算機(jī)領(lǐng)域里最高的一個(gè)獎(jiǎng)項(xiàng)，截至今日，因?yàn)樵跀?shù)據(jù)庫(kù)領(lǐng)域有杰出貢獻(xiàn)而獲得圖靈獎(jiǎng)的只有四位，分別是：
- 查爾斯·巴赫曼（CharlesW. Bachman），1973 年獲獎(jiǎng)，設(shè)計(jì)并開發(fā)了網(wǎng)狀數(shù)據(jù)庫(kù)管理系統(tǒng) IDS，推動(dòng)了數(shù)據(jù)庫(kù)標(biāo)準(zhǔn)的制定，包括網(wǎng)狀數(shù)據(jù)庫(kù)模型、數(shù)據(jù)定義和數(shù)據(jù)操縱語言的規(guī)范說明（通俗來講，是他第一次提出了數(shù)據(jù)庫(kù)這么個(gè)東西，可以說是咱們的祖師爺）；
- 埃德加·弗蘭克·科德（Edgar Frank Codd），1981 年獲獎(jiǎng)，提出了關(guān)系數(shù)據(jù)庫(kù)模型（關(guān)系型數(shù)據(jù)庫(kù)經(jīng)久不衰，目前依然占據(jù)市場(chǎng)最多的份額）；
- 詹姆斯·古瑞（James Gray），1998 年獲獎(jiǎng)，主要是在大型數(shù)據(jù)庫(kù)和事務(wù)處理技術(shù)上的突破（重點(diǎn)研究如何保障數(shù)據(jù)的完整性、安全性、并行性，以及故障恢復(fù)，曾擔(dān)任 VLDB 期刊的主編）；
- 邁克爾·斯通布雷克（Michael Stonebraker），2014 年獲獎(jiǎng)，現(xiàn)代數(shù)據(jù)庫(kù)系統(tǒng)的概念和實(shí)踐方面的基礎(chǔ)性貢獻(xiàn)（領(lǐng)導(dǎo)了影響力巨大的奠基性數(shù)據(jù)庫(kù) Ingres 的開發(fā)，也是最早提倡發(fā)展列存數(shù)據(jù)庫(kù)的大佬之一）。
除了這四位數(shù)據(jù)庫(kù)界公認(rèn)的大佬外，也有其他大牛，比如：
- 1988 年，為解決數(shù)據(jù)集成問題，IBM 的 2 位研究員 Barry Devlin 和 Paul Murphy，創(chuàng)造性地提出了數(shù)據(jù)倉(cāng)庫(kù)（Data Warehouse）的概念；
- 1992 年，比爾·恩門（Bill Inmon）給出了數(shù)據(jù)倉(cāng)庫(kù)的定義。數(shù)據(jù)倉(cāng)庫(kù)是一個(gè)面向主題的、集成的、相對(duì)穩(wěn)定的、反映歷史變化的數(shù)據(jù)集合，用于支持管理中的決策制定；
- 1993 年，E.F.Codd 提出 OLAP，以及 OLAP 12 條準(zhǔn)則。
- ......
能看到，早些年的數(shù)據(jù)庫(kù)界名人們，并沒有太多中國(guó)人士，和操作系統(tǒng)一樣，中國(guó)在這類基礎(chǔ)軟件上的起步和投入都不算太早，這也是數(shù)據(jù)庫(kù)領(lǐng)域目前成為我國(guó) 35 個(gè)“卡脖子”技術(shù)之一的原因吧。
我這里要指出的是——相信那些在數(shù)據(jù)庫(kù)界深耕數(shù)十年的朋友們應(yīng)該早就感受到了——仿佛，自從上述這些大佬奠定了關(guān)系型數(shù)據(jù)庫(kù)發(fā)展的總基調(diào)后，后續(xù)的幾十年里，就再?zèng)]看到什么轟動(dòng)一時(shí)的創(chuàng)新了，或者說，影響力能達(dá)到以上這些人士的數(shù)據(jù)庫(kù)專家學(xué)者也沒那么多了。那段時(shí)間，關(guān)系型數(shù)據(jù)庫(kù)的熱點(diǎn)話題好像從百家爭(zhēng)鳴陷入了一個(gè)相對(duì)沉寂的時(shí)期，當(dāng)然，后面也斷斷續(xù)續(xù)有一些新的技術(shù)熱點(diǎn)，不過，能像上面這些大佬一樣直接奠定一個(gè)學(xué)科或者理論的，就比較少了。
萬籟“俱寂”時(shí)，一家知名 IT 研究與顧問咨詢機(jī)構(gòu)的發(fā)聲，給關(guān)系型數(shù)據(jù)庫(kù)這個(gè)平靜的池塘丟了顆巨石：2014 年，Gartner 正式提出了 HTAP 這個(gè)概念。
Gartner’s definition in 2014: utilizes in-memory computing technologies to enable concurrent analytical and transaction processing on the same in-memory data store.<br /><br />
Gartner’s new definition in 2018: supports weaving analytical and transaction processing techniques together as needed to accomplish the business task.
可以看到，Gartner 重點(diǎn)強(qiáng)調(diào)了使用內(nèi)存技術(shù)實(shí)現(xiàn) HTAP 的可行性，并表示 HTAP 將為巨大的業(yè)務(wù)創(chuàng)新創(chuàng)造機(jī)會(huì)，增量市場(chǎng)空間巨大。
一石卷起千層浪，陷入半沉寂的關(guān)系型數(shù)據(jù)庫(kù)技術(shù)，好像迎來了春天。那個(gè)時(shí)候，商業(yè)智能（BI）已經(jīng)開始廣泛滲入到眾多企業(yè)的營(yíng)銷業(yè)務(wù)體系里了，處理數(shù)據(jù)的業(yè)務(wù)分析部門對(duì)實(shí)時(shí)處理和運(yùn)維最簡(jiǎn)化的需求越來越重要，HTAP 方案的提出自然迅速地引起了行業(yè)的強(qiáng)勢(shì)關(guān)注，因?yàn)檫@玩意兒光是聽起來就省心省力，誘惑很大。
我們正在做的 StoneDB，就是對(duì)標(biāo) Oracle MySQL HeatWave 的一款開源版實(shí)時(shí)一體化 HTAP 數(shù)據(jù)庫(kù)。
HTAP 流派
上圖是清華大學(xué)李國(guó)良教授團(tuán)隊(duì)梳理的 HTAP 數(shù)據(jù)庫(kù)的發(fā)展時(shí)間線。我們這里再舉幾個(gè)大家耳熟能詳?shù)钠髽I(yè)：像數(shù)據(jù)庫(kù)巨頭 Oracle 去年就推出了 MySQL HeatWave，沒錯(cuò)，Oracle 官方已經(jīng)明確表示了，做 HeatWave 的目的就是為了支持 HTAP，在最近的 Oracle CloudWorld 大會(huì)上還官宣了 MySQL HeatWave Lakehouse；Google 在 HTAP 上也動(dòng)作頻頻，除了搞 F1 Lightning 以外，在今年 5 月 12 日的 Google I/O 2022 開發(fā)者大會(huì)還宣布了云原生 HTAP 數(shù)據(jù)庫(kù) AlloyDB for PostgreSQL；緊接著，所有云數(shù)倉(cāng)都想打的知名廠商 SnowFlake 也在 6 月 14 日的用戶大會(huì) Snowflake Summit 2022 上官宣正式推出 HTAP 存儲(chǔ)引擎 Unistore；數(shù)據(jù)庫(kù)獨(dú)角獸SingleStore（前身為 MemSQL） 也早就在 HTAP 領(lǐng)域上頻頻發(fā)聲，頂會(huì)論文都發(fā)了。國(guó)際上的這些大廠和獨(dú)角獸都在搞 HTAP，國(guó)內(nèi)的更不用說了，阿里、百度、騰訊、華為、字節(jié)和眾多新興創(chuàng)業(yè)公司（包括咱們 StoneDB），以及老牌數(shù)據(jù)庫(kù)廠商都開始宣傳自己的一些產(chǎn)品可以實(shí)現(xiàn)或者主攻 HTAP。Gartner 之前在報(bào)告里預(yù)測(cè)說，到 2024 年，HTAP 數(shù)據(jù)庫(kù)會(huì)被廣泛用到各行各業(yè)中，現(xiàn)在看來，真的是有這種勢(shì)頭了。
顯而易見，HTAP 這倆馬車的車輪已經(jīng)壓在了數(shù)據(jù)庫(kù)行業(yè)的歷史軌跡上，正在滾滾向前，勢(shì)不可擋。但是，隨著越來越多的廠商正式加入賽道，對(duì)于 HTAP 架構(gòu)的技術(shù)實(shí)現(xiàn)，自然產(chǎn)生了一些分化。
我們之前在文章《深度干貨！一篇 Paper 帶您讀懂 HTAP》中有做介紹，這篇報(bào)告里提到，至少有四種不同的架構(gòu)方式可以實(shí)現(xiàn) HTAP。
目前 HTAP 大致有四種實(shí)現(xiàn)方式：
方案 1（一套系統(tǒng)一套存儲(chǔ)）：在一個(gè)系統(tǒng)里用一種數(shù)據(jù)格式滿足兩種業(yè)務(wù)需求；
方案 2（一套系統(tǒng)兩套存儲(chǔ)）：一個(gè)系統(tǒng)里同時(shí)存在行存儲(chǔ)和列存儲(chǔ)，行存儲(chǔ)上的更新會(huì)定期導(dǎo)入到列存儲(chǔ)里轉(zhuǎn)換成列存儲(chǔ)格式；
方案 3（兩套系統(tǒng)兩套存儲(chǔ)）：系統(tǒng)里同時(shí)存在 OLTP 與 OLAP 兩套引擎，分別寫入和讀取行存儲(chǔ)和列存儲(chǔ)；
方案 4（多套系統(tǒng)松耦合）：不同的異構(gòu)系統(tǒng)之間，通過獨(dú)立的插件服務(wù)對(duì)數(shù)據(jù)進(jìn)行準(zhǔn)實(shí)時(shí)同步，對(duì)外呈現(xiàn) HTAP 能力。
下面這張表圖是我們對(duì)這四種架構(gòu)方案的一個(gè)簡(jiǎn)單的綜合盤點(diǎn)。
HTAP 迷思
隨著一些 HTAP 產(chǎn)品功能能夠?qū)崿F(xiàn)落地了，在 HTAP 架構(gòu)的選擇上引起了不少爭(zhēng)議（我們講叫技術(shù)口水戰(zhàn)），這很正常，大家都想說 HTAP 是自己做得比較好嘛。比如 StoneDB 這邊就比較支持完全一體化的混合負(fù)載架構(gòu)（我們稱之為真正的 HTAP 面臨的挑戰(zhàn)）；也有的團(tuán)隊(duì)比較想搞那種兩套系統(tǒng)疊加的架構(gòu)；還有更猛的，直接說要基于 GPU/CPU 搞 HTAP，就是 RateupDB，據(jù)說是全球唯一一個(gè)基于 GPU/CPU 和并行的 HTAP 數(shù)據(jù)庫(kù)，還發(fā)了一篇 VLDB，不過好像現(xiàn)在銷聲匿跡了，創(chuàng)始人目前應(yīng)該是投身一家勢(shì)頭較猛的云數(shù)倉(cāng)創(chuàng)業(yè)公司去了。
由此可見，HTAP 雖然引起了一陣狂歡，但是，對(duì) HTAP 數(shù)據(jù)庫(kù)架構(gòu)選擇目前業(yè)界還是沒有一套特別稱得上成熟的方案，大家也都是在打磨產(chǎn)品中。有的走的稍微早了一些；有的還在孵化打磨；有的已經(jīng)倒在半路上了，但是一個(gè)不可否認(rèn)的事實(shí)是，大家都開始說自己能或者即將能支持 HTAP 了，就和數(shù)據(jù)庫(kù)領(lǐng)域另外一個(gè)爆火的“云原生”關(guān)鍵字一樣，這真可謂是“二四八月亂穿衣”了，這也算是現(xiàn)在 HTAP 領(lǐng)域上存在的迷思吧。
新的趨勢(shì)：From Big to Small and Wide data
所以，在這個(gè)時(shí)候，作為率先提出要做 MySQL 開源 HTAP 數(shù)據(jù)庫(kù)的 StoneDB，想要稍微冷靜一下。
不是說我們不做 HTAP 了，而是有了一個(gè)新的思路。這個(gè)思路，也同樣來自于咱們的老朋友、好伙伴，大家都巴不得上他們報(bào)告的權(quán)威機(jī)構(gòu)——Gartner。
Gartner 在去年發(fā)布的《Gartner 2021 十大數(shù)據(jù)和分析趨勢(shì)》報(bào)告里，特別提到了一個(gè)重要的趨勢(shì)：。From Big to Small and Wide data
據(jù) Gartner 預(yù)測(cè)，到 2025 年 70% 的組織會(huì)把重點(diǎn)從“大”數(shù)據(jù)轉(zhuǎn)向“小”數(shù)據(jù)和“寬”數(shù)據(jù)，為分析提供更多的場(chǎng)景，使人工智能（AI）減少對(duì)數(shù)據(jù)量的需求（原文是 making artificial intelligence (AI) less data hungry）。
當(dāng)然，這個(gè)趨勢(shì)的調(diào)研結(jié)論是有背景的，那就是突如其來的新冠疫情。面對(duì)新冠，很多數(shù)據(jù)幾乎是一夜式爆發(fā)式變化增長(zhǎng)，導(dǎo)致了基于大量歷史數(shù)據(jù)的機(jī)器學(xué)習(xí)和人工智能模型變得不那么可靠，隨著智能決策變得更加復(fù)雜和嚴(yán)格，數(shù)據(jù)和分析領(lǐng)導(dǎo)者應(yīng)選擇能夠更加有效利用現(xiàn)有數(shù)據(jù)的分析技術(shù)。
如何更加有效利用數(shù)據(jù)分析？那就是我們講的用“小”而“寬”的數(shù)據(jù)取代“大”數(shù)據(jù)來解決問題。小數(shù)據(jù)——顧名思義，指的是能夠使用所需數(shù)據(jù)量較少，但仍能提供實(shí)用洞見的數(shù)據(jù)模型。寬數(shù)據(jù)——可以理解為多模數(shù)據(jù)，即使用寬數(shù)據(jù)分析各種小而多樣化的非結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)源并發(fā)揮它們的協(xié)同效果，從而增強(qiáng)情景態(tài)勢(shì)感知（contextual awareness，情境感知）和決策。
下面就來詳細(xì)講解一下 Small Data 和 Wide Data 的定義。
Small data 概念
小數(shù)據(jù)的方法是指使用相對(duì)較少的數(shù)據(jù)，但仍能提供有見解的分析技術(shù)。其中包括了有針對(duì)性地使用數(shù)據(jù)要求比較低的模型，比如一些時(shí)間序列分析的技術(shù)，而不是用一刀切的方式去使用數(shù)據(jù)量要求較高的深度學(xué)習(xí)技術(shù)。
通俗地來講，使用 AI 或者 ML 技術(shù)，往往需要大量的數(shù)據(jù)源作為分析的訓(xùn)練模型，但并不是數(shù)據(jù)量越多越好，特別是那些過時(shí)的歷史數(shù)據(jù)，對(duì)分析毫無意義，如果可以及時(shí)地找到一些比較精準(zhǔn)的小數(shù)據(jù)進(jìn)行分析，往往能獲得更有價(jià)值的效果。總之，小數(shù)據(jù)側(cè)重于應(yīng)用分析技術(shù)，在小量的、單獨(dú)的數(shù)據(jù)集中尋找有用的信息。
Wide data 概念
寬數(shù)據(jù)允許分析師檢查和組合各種大小、非結(jié)構(gòu)化和結(jié)構(gòu)化數(shù)據(jù)。具體來說，寬而廣泛的數(shù)據(jù)就是將各種來源的不同數(shù)據(jù)源捆綁在一起，以進(jìn)行有意義的分析。
基于寬數(shù)據(jù)的數(shù)據(jù)分析技術(shù)圍繞著結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)的分析和協(xié)同，而不管數(shù)據(jù)集是否直接相關(guān)。寬數(shù)據(jù)最大的特征是可以提取或識(shí)別異構(gòu)數(shù)據(jù)集之間的聯(lián)系。
Small and Wide data 結(jié)合的作用
Gartner 知名研究副總裁 Rita Sallam 表示：“使用‘小’而‘寬’的數(shù)據(jù)能夠提供強(qiáng)大的分析和 AI，同時(shí)降低企業(yè)機(jī)構(gòu)對(duì)大型數(shù)據(jù)集的依賴性。企業(yè)機(jī)構(gòu)可以使用‘寬’數(shù)據(jù)獲得更豐富、更完整的態(tài)勢(shì)感知或 360 度視圖，這將使企業(yè)機(jī)構(gòu)能夠使用分析技術(shù)做出更好的決策?！?/p>
Gartner 高級(jí)研究總監(jiān)孫鑫表示：“隨著企業(yè)逐漸認(rèn)識(shí)到大數(shù)據(jù)作為分析和人工智能關(guān)鍵推動(dòng)者的局限性，被稱為小數(shù)據(jù)和寬數(shù)據(jù)的方法正在慢慢涌現(xiàn)，小數(shù)據(jù)的方法拋開了對(duì)于大型單體數(shù)據(jù)的依賴，實(shí)現(xiàn)了對(duì)于小型、大型、結(jié)構(gòu)化、非結(jié)構(gòu)化的數(shù)據(jù)源的分析和協(xié)同?！?/p>
同時(shí)，據(jù) Gartner 預(yù)測(cè)，到 2025 年，超過 85% 的技術(shù)供應(yīng)商，將在人工智能解決方案當(dāng)中加入讓數(shù)據(jù)變得更豐富的方法和模型訓(xùn)練技術(shù)，以提高模型的彈性和敏捷性，而在 2020 年，這樣做的供應(yīng)商只有不到 5%。 由此可見，小數(shù)據(jù)和寬數(shù)據(jù)的市場(chǎng)增量巨大。
Small and Wide data 核心場(chǎng)景
說了這么多“小”數(shù)據(jù)和“寬”數(shù)據(jù)，這兩個(gè)到一塊兒究竟能落地到什么應(yīng)用場(chǎng)景上？
從一個(gè)具體的場(chǎng)景為例，現(xiàn)在電商以及社交媒體都在做一個(gè)實(shí)時(shí)推薦的業(yè)務(wù)場(chǎng)景，而實(shí)時(shí)推薦的標(biāo)準(zhǔn)流程是首先通過大數(shù)據(jù)系統(tǒng)對(duì)客戶的購(gòu)買歷史進(jìn)行分析，要關(guān)注客戶購(gòu)買產(chǎn)品的生命周期，客戶與企業(yè)之間的交互歷史；同時(shí)要去通過各種渠道去了解，目前客戶正在什么環(huán)境，聽到了什么？ 正在瀏覽什么信息？結(jié)合各種數(shù)據(jù)進(jìn)行分析，最后產(chǎn)生 Top10 的產(chǎn)品推薦，然后通過 App 或者其他手段推送給客戶。
在這個(gè)過程中，需要收集的數(shù)據(jù)非常龐大，包括各種結(jié)構(gòu)化數(shù)據(jù)，例如歷史訂單，客戶個(gè)人信息等，另外客戶的上網(wǎng)日志，網(wǎng)頁(yè)瀏覽歷史，客戶的位置信息， 行動(dòng)軌跡，這些數(shù)據(jù)的體量都非常大，而一旦涉及到千萬乃至上億的用戶，同時(shí)上萬種產(chǎn)品的場(chǎng)景下，這個(gè)數(shù)據(jù)量就是天文數(shù)字，而等待所有這些數(shù)據(jù)都收集完整并進(jìn)行 AI 建模預(yù)測(cè)，則很可能是 1-2 天之后的事情了。
所以，為了盡可能快地對(duì)客戶當(dāng)前狀況進(jìn)行反饋，并推出相應(yīng)的推薦方案，必須把數(shù)據(jù)鏈條縮短：首先通過在生產(chǎn)系統(tǒng)端，貼合用戶的購(gòu)買歷史和行為，對(duì)整個(gè)場(chǎng)景進(jìn)行約束，從海量數(shù)據(jù)分析，變成小數(shù)據(jù)量的分析，把推薦產(chǎn)品從幾萬，縮小到幾十的范圍，這個(gè)時(shí)候，就是從大數(shù)據(jù)到“小”數(shù)據(jù)的過程。然后在此基礎(chǔ)之上，通過補(bǔ)足其他渠道的信息，包括圖像、聲音、瀏覽日志等等，對(duì)幾十的范圍進(jìn)行進(jìn)一步的精準(zhǔn)化定位。這個(gè)時(shí)候，則體現(xiàn)了“寬”數(shù)據(jù)的價(jià)值。
預(yù)計(jì)小數(shù)據(jù)和寬數(shù)據(jù)技術(shù)將產(chǎn)生積極的結(jié)果，即：
- 零售需求預(yù)測(cè)（Retail demand forecasting）
- 實(shí)時(shí)行為智能（ Real time behavioral intelligence）
- 超個(gè)性化和整體客戶體驗(yàn)的改善（ Hyper personalization and improvement of the overall customer experience）
- 人生安全
- 欺詐檢測(cè)
- 自適應(yīng)自動(dòng)系統(tǒng)（比如自適應(yīng) AI）等等
雖然“小”數(shù)據(jù)和“寬”數(shù)據(jù)技術(shù)的確切結(jié)果還沒有出現(xiàn)，但這個(gè)概念肯定是未來可期的，因?yàn)檫@些技術(shù)能夠在過去或歷史趨勢(shì)不再相關(guān)的領(lǐng)域提供卓有成效的洞察分析能力。
對(duì)于從“大”數(shù)據(jù)到“小”數(shù)據(jù)的過程，一個(gè)趨勢(shì)就是，數(shù)據(jù)分析不必一定從數(shù)倉(cāng)開始， 而是從前端業(yè)務(wù)系統(tǒng)，結(jié)合一定的場(chǎng)景，首先發(fā)起快捷的數(shù)據(jù)分析， 解決場(chǎng)景定位，方案范圍初篩等數(shù)據(jù)的初步處理，讓后繼的分析盡可能地聚焦在指定的領(lǐng)域，一方面減少計(jì)算量，同時(shí)加速后繼決策的速度。
所以業(yè)務(wù)系統(tǒng)在承擔(dān)業(yè)務(wù)交易的時(shí)候，必須增加一定的數(shù)據(jù)分析和篩選的能力， 這個(gè)和傳統(tǒng)的業(yè)務(wù)系統(tǒng)是純粹 OLTP 系統(tǒng)的定義不一樣， 將來業(yè)務(wù)系統(tǒng)的能力將會(huì)從 OLTP 向 HTAP 逐步變遷。
這一塊還有很多東西可以講，后續(xù)我們繼續(xù)探討，今天就先點(diǎn)一下。作為在數(shù)據(jù)分析領(lǐng)域耕耘多年的數(shù)據(jù)庫(kù)團(tuán)隊(duì)，我們對(duì)這個(gè)觀點(diǎn)是非常認(rèn)可的。因?yàn)?，?jīng)常做數(shù)據(jù)分析的人都知道，隨著使用數(shù)據(jù)的場(chǎng)景越來越多，數(shù)據(jù)支撐運(yùn)營(yíng)的場(chǎng)景也越來越多，很多情況下，數(shù)據(jù)驅(qū)動(dòng)運(yùn)營(yíng)需要的是近期的熱數(shù)據(jù)，而不是長(zhǎng)時(shí)間的數(shù)據(jù)。而這個(gè)“熱數(shù)據(jù)”，再更精確一些講，就應(yīng)該是“熱”的“小”而“寬”數(shù)據(jù)。
這恰恰和 StoneDB 提倡的基于 MySQL 的 HTAP 數(shù)據(jù)庫(kù)要能夠支持實(shí)時(shí)與中小數(shù)據(jù)量場(chǎng)景不謀而合（正常 10T 左右，最高不超過 100T，當(dāng)然了，要是擴(kuò)展成 LakeHouse，支持的數(shù)據(jù)量會(huì)更多）。也和 SingleStore 講的觀點(diǎn)很類似：沒有 HTAP，機(jī)器學(xué)習(xí)和人工智能都是不切實(shí)際的。
基于此，我們提出一個(gè) idea，即 StoneDB 這種強(qiáng)調(diào)對(duì)熱數(shù)據(jù)實(shí)時(shí)分析的 HTAP 數(shù)據(jù)庫(kù)，也可以叫做 SoTP 數(shù)據(jù)庫(kù)。
SoTP 初探
SoTP，即 Serving over TP。
Serving 是什么？SoTP 的定義和驅(qū)動(dòng)又是什么？這個(gè)留給我們下一篇文章繼續(xù)解讀，歡迎關(guān)注 StoneDB簡(jiǎn)書賬號(hào)。
StoneDB 2.0 云原生分布式實(shí)時(shí) HTAP 架構(gòu)詳細(xì)設(shè)計(jì)以 RFC 形式持續(xù)進(jìn)行，歡迎大家關(guān)注我們最新進(jìn)展，更歡迎給我們開源協(xié)作的模式和方法提出改進(jìn)意見，一起通過開源的方式共建 StoneDB ~
https://github.com/stoneatom/stonedb/issues/436
- StoneDB 代碼已完全在 Github 開源：
https://github.com/stoneatom/stonedb
- StoneDB 官網(wǎng)：
