經常有人問我，為什么 2017 年在市場上已經有這么多時序數據庫的背景之下，你還敢去開發一款新的時序數據庫？為(wei)什(shen)么你的團隊(dui)都 80 多人(ren)了，五年過去，還在埋頭(tou)研發 TDengine 這一款產品？周末寫篇(pian)博文，與大家分(fen)享一下我的想(xiang)法(fa)。
時(shi)序數(shu)(shu)據(ju)庫(ku)(ku)(ku)(ku)（Time Series Database）并不是(shi)一個新興的(de)概念。追溯(su)其歷(li)史，1999 年問世的(de) RRDtool 應(ying)該是(shi)最(zui)早的(de)專(zhuan)用(yong)時(shi)序數(shu)(shu)據(ju)庫(ku)(ku)(ku)(ku)了(le)。在著(zhu)名的(de)數(shu)(shu)據(ju)庫(ku)(ku)(ku)(ku)排行(xing)網(wang)站 DB-engines 上面，時(shi)序數(shu)(shu)據(ju)庫(ku)(ku)(ku)(ku)的(de)逐步流行(xing)起(qi)始于 2015 年，而在過去的(de)兩年，時(shi)序數(shu)(shu)據(ju)庫(ku)(ku)(ku)(ku)成為(wei)流行(xing)度最(zui)高的(de)數(shu)(shu)據(ju)庫(ku)(ku)(ku)(ku)。
2016 年底，我看到萬(wan)物(wu)互聯的時代已經到來，高(gao)效處(chu)理各種傳(chuan)感器、設備產生的時序數(shu)據(ju)(ju)將(jiang)成為一重要的技術領域，因此(ci)就著手(shou)開(kai)發 TDengine 這個新的時序數(shu)據(ju)(ju)庫系統，2017 年 6 月正式(shi)組建(jian)團隊。
TDengine 面市以來，從(cong) 1.0 到 2.0，從(cong)核(he)心功(gong)能(neng)開源(yuan)到集(ji)群功(gong)能(neng)開源(yuan)，得到了大(da)量商(shang)業客戶和社(she)(she)區用戶的(de)高度認可，全(quan)球安裝的(de) TDengine 運行(xing)實例數已經超過 13 萬，每天克隆源(yuan)代碼的(de)人次都超過 1000，在全(quan)球開發者社(she)(she)區產生了一定的(de)影響力。
剛(gang)開始創(chuang)業(ye)的時候(hou)，我(wo)就進(jin)行了(le)深入的思考：新的時序(xu)數據庫還(huan)有生存空間嗎？換句話說，現(xian)有的這些(xie)數據庫對應用而言是不是已(yi)經(jing)足(zu)夠好(hao)了(le)？它們(men)能滿足(zu)業(ye)務需求嗎？現(xian)在我(wo)也經(jing)常思考，時序(xu)數據庫值得你(ni)死磕嗎？今天我(wo)從技術的角(jiao)度來分析一下(xia)這個問題，與大家分享。
1、可擴展性 / Scalability
由于 IT 基礎設(she)施(shi)的爆(bao)炸性增(zeng)長和(he)物聯(lian)網(wang)（IoT）的出現，數(shu)(shu)(shu)據(ju)的規模正在迅(xun)速增(zeng)長。一(yi)(yi)個(ge)(ge)現代的數(shu)(shu)(shu)據(ju)中(zhong)心可能(neng)需要收集多(duo)(duo)達 1 億個(ge)(ge)指標——從網(wang)絡設(she)備和(he)服(fu)務器到虛擬(ni)機(ji)、容器和(he)微服(fu)務的一(yi)(yi)切(qie)都在不斷地發送時間(jian)序列數(shu)(shu)(shu)據(ju)。再(zai)比如，分布式電網(wang)中(zhong)的每個(ge)(ge)智(zhi)能(neng)電表每分鐘(zhong)至(zhi)少產(chan)生一(yi)(yi)個(ge)(ge)數(shu)(shu)(shu)據(ju)點，而中(zhong)國的智(zhi)能(neng)電表，至(zhi)少有十億個(ge)(ge)。任何一(yi)(yi)臺計算機(ji)都不可能(neng)處理這么(me)多(duo)(duo)的數(shu)(shu)(shu)據(ju)，所以任何旨(zhi)在處理時間(jian)序列數(shu)(shu)(shu)據(ju)的系(xi)統(tong)必須是可擴展(zhan)的。
然而(er)，許(xu)多市場(chang)領(ling)先(xian)的(de)(de)時(shi)序數據(ju)庫并(bing)沒(mei)有提供可擴展的(de)(de)解決方案。就拿 Prometheus 來(lai)說，它可以算是用于 Kubernetes 環境的(de)(de)時(shi)序數據(ju)庫的(de)(de)一個(ge)事實(shi)標準，但它并(bing)沒(mei)有提供分(fen)布(bu)式的(de)(de)設計，而(er)必須依(yi)靠 Cortex、Thanos 或其他(ta)第三方工具來(lai)實(shi)現可擴展性。InfluxDB 有集群功能，但是只(zhi)向(xiang)企業客戶提供，沒(mei)有選(xuan)擇開源(yuan)。
為(wei)了解(jie)決這(zhe)個問(wen)題，很多(duo)開發者的(de)(de)(de)選擇是，在(zai)應用(yong)程(cheng)序和時(shi)序數(shu)據(ju)庫服務(wu)器(qi)（如 InfluxDB 或 Prometheus）之間(jian)(jian)部署一(yi)個代理服務(wu)器(qi)，來建立自己的(de)(de)(de)可擴(kuo)(kuo)展的(de)(de)(de)解(jie)決方案。然(ran)后根據(ju)時(shi)序 ID 的(de)(de)(de)哈(ha)希值，將收集到的(de)(de)(de)時(shi)序數(shu)據(ju)在(zai)多(duo)個時(shi)序數(shu)據(ju)庫服務(wu)器(qi)之間(jian)(jian)分配。從(cong)數(shu)據(ju)寫入角度看，這(zhe)確實解(jie)決了可擴(kuo)(kuo)展性的(de)(de)(de)問(wen)題。但對(dui)于查(cha)詢，代理服務(wu)器(qi)必須(xu)合并來自每個底層節(jie)點的(de)(de)(de)查(cha)詢結(jie)果(guo)，而這(zhe)是一(yi)個很大的(de)(de)(de)技(ji)術挑戰。對(dui)于一(yi)些查(cha)詢，比(bi)如計算標(biao)準(zhun)差，還(huan)不能只是合并結(jie)果(guo)，而是必須(xu)從(cong)每個節(jie)點檢索(suo)原(yuan)始數(shu)據(ju)。這(zhe)意味著(zhu)需要(yao)(yao)重寫整個查(cha)詢引擎，需要(yao)(yao)的(de)(de)(de)工(gong)作(zuo)量相當之大。
進一(yi)(yi)步，仔細研究一(yi)(yi)下 InfluxDB 和(he) TimeScaleDB 的(de)(de)(de)設計，就(jiu)(jiu)會(hui)發現，它們的(de)(de)(de)可擴展性(xing)實際上是相(xiang)當(dang)有(you)限(xian)的(de)(de)(de)。它們將元數據存儲在(zai)一(yi)(yi)個(ge)中(zhong)心位置(zhi)，每個(ge)時間(jian)(jian)(jian)序(xu)(xu)列(lie)(lie)總是會(hui)關聯一(yi)(yi)組標簽(qian)或(huo)標識。這(zhe)意(yi)味著，如果你有(you) 10 億個(ge)時間(jian)(jian)(jian)序(xu)(xu)列(lie)(lie)，系(xi)統就(jiu)(jiu)需(xu)要存儲 10 億組標簽(qian)。看出問題了嗎？當(dang)你要聚(ju)合(he)多個(ge)時間(jian)(jian)(jian)序(xu)(xu)列(lie)(lie)時，系(xi)統需(xu)要首(shou)先確(que)定(ding)哪些時間(jian)(jian)(jian)序(xu)(xu)列(lie)(lie)符(fu)合(he)標簽(qian)過濾條件，而在(zai)一(yi)(yi)個(ge)很大(da)的(de)(de)(de)數據集中(zhong)，這(zhe)會(hui)導(dao)致很大(da)的(de)(de)(de)延(yan)遲。這(zhe)就(jiu)(jiu)是所謂的(de)(de)(de)時間(jian)(jian)(jian)序(xu)(xu)列(lie)(lie)數據庫的(de)(de)(de) High-cardinality 問題。
那么應該如何解決這(zhe)(zhe)個(ge)問題呢？答案就(jiu)是(shi)元(yuan)數據(ju)處理(li)的分(fen)布式設計。元(yuan)數據(ju)不能存儲在一(yi)個(ge)中心位置，否則它很快(kuai)就(jiu)會成為一(yi)個(ge)瓶頸。一(yi)個(ge)簡單的解決方(fang)案是(shi)，使用分(fen)布式關系(xi)(xi)數據(ju)庫來處理(li)元(yuan)數據(ju)，但是(shi)這(zhe)(zhe)會增(zeng)加系(xi)(xi)統(tong)的復(fu)雜度，使得系(xi)(xi)統(tong)更難維護，成本也更高了。
TDengine 1.x 的設計就(jiu)是(shi)將(jiang)所有(you)元(yuan)數據存儲在管理節(jie)點（mnode）上，所以它也(ye)有(you) High-cardinality 的問題。在 TDengine 2.x 中(zhong)，我們做了一些改進，就(jiu)是(shi)將(jiang)標簽(qian)值(zhi)存儲在每個虛(xu)擬節(jie)點（vnode）而(er)不(bu)是(shi)中(zhong)央管理節(jie)點上, 聚合查詢(xun)速(su)度(du)有(you)保證，但系統啟動時(shi)間(jian)在時(shi)間(jian)線超過(guo)千萬后不(bu)可忍受，沒有(you)完(wan)全解決這(zhe)個業(ye)內的難(nan)題。
2、復雜性 / Complex
數(shu)(shu)(shu)(shu)(shu)據(ju)庫(ku)是存儲和(he)分析數(shu)(shu)(shu)(shu)(shu)據(ju)的(de)工(gong)(gong)具(ju)，但時序數(shu)(shu)(shu)(shu)(shu)據(ju)處(chu)理(li)(li)需(xu)要的(de)可不僅僅是存儲和(he)分析。在一個(ge)(ge)典型的(de)時序數(shu)(shu)(shu)(shu)(shu)據(ju)處(chu)理(li)(li)平臺中(zhong)，時序數(shu)(shu)(shu)(shu)(shu)據(ju)庫(ku)總是要與支持(chi)流處(chu)理(li)(li)、緩存、數(shu)(shu)(shu)(shu)(shu)據(ju)訂閱以及(ji)其他功(gong)能的(de)工(gong)(gong)具(ju)集(ji)成，因(yin)此整個(ge)(ge)數(shu)(shu)(shu)(shu)(shu)據(ju)處(chu)理(li)(li)系統是有一定(ding)的(de)復雜度的(de)。
流式處理 / Stream Processing
時序(xu)數(shu)(shu)據就(jiu)是(shi)一個(ge)流(liu)。為了更(geng)快地(di)執行(xing)操作或(huo)者發現錯(cuo)誤，我們需要在(zai)數(shu)(shu)據點到達(da)系(xi)統時就(jiu)進行(xing)分(fen)析(xi)和處(chu)理，所以(yi)流(liu)處(chu)理天(tian)然適合時序(xu)數(shu)(shu)據。流(liu)處(chu)理可(ke)以(yi)是(shi)時間(jian)驅動的，即(ji)在(zai)設定的時間(jian)間(jian)隔內產生新(xin)的結(jie)果（在(zai)時序(xu)數(shu)(shu)據庫中(zhong)一般(ban)稱為連續查詢），也(ye)可(ke)以(yi)是(shi)事件(jian)驅動的，即(ji)只要有新(xin)的數(shu)(shu)據點到達(da)就(jiu)產生新(xin)的結(jie)果。
InfluxDB、Prometheus、TimescaleDB 和 TDengine 都支(zhi)持連續查(cha)詢。這對于監控儀表(biao)(biao)盤是非常有(you)用(yong)的，因(yin)為所有(you)的圖(tu)表(biao)(biao)都可以定期(qi)更新。但連續查(cha)詢并(bing)不能滿足所有(you)的數據處(chu)(chu)理要求，就像(xiang) ETL，復雜事件處(chu)(chu)理，所以時序數據庫需要支(zhi)持事件驅動的流處(chu)(chu)理。
遺憾的(de)(de)是，目前市(shi)面上還(huan)沒有哪款時(shi)序(xu)數(shu)(shu)據(ju)(ju)庫(ku)支持(chi)。一般(ban)的(de)(de)方式是，將時(shi)序(xu)數(shu)(shu)據(ju)(ju)庫(ku)與 Spark、Flink 或其他(ta)流(liu)處理工具(ju)(ju)集成，而這些工具(ju)(ju)并不是為(wei)時(shi)序(xu)數(shu)(shu)據(ju)(ju)處理設(she)計的(de)(de)。這些工具(ju)(ju)很難處理時(shi)間序(xu)列數(shu)(shu)據(ju)(ju)集中的(de)(de)數(shu)(shu)百萬甚至數(shu)(shu)十(shi)億的(de)(de)流(liu)，即使它們能夠勝任(ren)，也要以大量的(de)(de)計算資源(yuan)為(wei)代價(jia)。
緩存 / Caching
對(dui)于(yu)很多時(shi)序(xu)數(shu)據應(ying)用，像應(ying)用性能監控，某個(ge)特(te)定時(shi)間的數(shu)據值并不(bu)重要，這些應(ying)用只關注趨(qu)勢。然而，物聯網場景(jing)是個(ge)例外，應(ying)該(gai)特(te)別注意(yi)。比(bi)如，一(yi)個(ge)車(che)隊管理系統(tong)總(zong)是要知(zhi)道每輛卡車(che)的當前(qian)位(wei)置。對(dui)于(yu)一(yi)個(ge)智能工廠，系統(tong)總(zong)是需要知(zhi)道每個(ge)閥門的當前(qian)狀態和每個(ge)電表的當前(qian)讀(du)數(shu)。
大多數時(shi)序(xu)(xu)數據(ju)(ju)庫，包括 InfluxDB、TimescaleDB 和(he) Prometheus，本身都不能(neng)保證以最小的(de)(de)(de)延遲(chi)返(fan)回時(shi)間序(xu)(xu)列(lie)中最新(xin)的(de)(de)(de)數據(ju)(ju)點。為了使每(mei)個(ge)時(shi)間序(xu)(xu)列(lie)的(de)(de)(de)當(dang)前(qian)值能(neng)夠盡(jin)可能(neng)快地(di)返(fan)回，沒有高延遲(chi)，很多開發(fa)者選擇將這些數據(ju)(ju)平臺與 Redis 集成。當(dang)新(xin)的(de)(de)(de)數據(ju)(ju)點到達(da)系統時(shi)，它們必須被同時(shi)寫入 Redis 以及數據(ju)(ju)庫中。這種解決(jue)方(fang)案確實有效，但增加了系統的(de)(de)(de)復雜性和(he)運維成本。
TDengine 從(cong)其(qi)第(di)一個(ge)版本開(kai)始就支持(chi)緩存了。在 TDengine 的很多用(yong)戶案例中，Redis 可以完全從(cong)系統中移(yi)除，從(cong)而使整(zheng)個(ge)數據平臺的運行更(geng)加簡(jian)單(dan)，成(cheng)本更(geng)低。
數據訂閱 / Data Subscription
消(xiao)(xiao)息(xi)隊(dui)列(lie)在(zai)很多系(xi)統架構中有著重要的作用。傳入(ru)的數(shu)據點(dian)首先被寫(xie)入(ru)消(xiao)(xiao)息(xi)隊(dui)列(lie)，然后被系(xi)統中的其他組件(jian)消(xiao)(xiao)費，包括數(shu)據庫。消(xiao)(xiao)息(xi)隊(dui)列(lie)中的數(shu)據通常(chang)會被保留一段指定的時(shi)間（比如 Kafka 中的 7 天）。這與(yu)時(shi)序數(shu)據庫中的保留策略是一樣的。某個角度上來(lai)看，存儲的設計上，消(xiao)(xiao)息(xi)隊(dui)列(lie)與(yu)時(shi)序數(shu)據庫沒有本(ben)質的區(qu)別。
大(da)多數(shu)(shu)時序(xu)數(shu)(shu)據庫(ku)寫入數(shu)(shu)據的效率非常(chang)高，一秒鐘可以達到數(shu)(shu)百萬個數(shu)(shu)據點。這意味著，如果時序(xu)數(shu)(shu)據庫(ku)能夠提供數(shu)(shu)據訂閱功(gong)能，它們可以完全取代消(xiao)息隊(dui)列，這就再次(ci)簡化了(le)系統的設(she)計，進而降低了(le)成本。
目前市場(chang)上僅(jin)僅(jin) TDengine 提供數據(ju)訂閱(yue)(yue)的功能(neng)，但(dan)現有(you)版本(ben)訂閱(yue)(yue)的性能(neng)不夠，在大部分場(chang)景下，無(wu)法將 Kafka 這類(lei)軟件(jian)從系統(tong)中剔除。
結論：沒(mei)有事件驅動的流(liu)處理、緩存和數據訂閱(yue)這些功能，盡管(guan)時序(xu)數據庫仍然(ran)可以工作，但開發(fa)人員不得不將其(qi)與其(qi)他工具集成(cheng)，來實現所需(xu)的功能。這使得系統設計會相當(dang)復雜，需(xu)要(yao)更(geng)多(duo)資源，也更(geng)難維護(hu)。如(ru)果(guo)時序(xu)數據庫內置了這些功能，整個系統架(jia)構就可以極大(da)(da)簡化，運維成(cheng)本也會大(da)(da)大(da)(da)降低(di)。
3、云原生 / Cloud Native
云(yun)計(ji)算(suan)越來越流行(xing)，云(yun)計(ji)算(suan)最美(mei)妙最吸引人(ren)的地方在(zai)(zai)于(yu)它的彈性——存儲資源和計(ji)算(suan)資源沒有(you)上限(xian)，而我們只需(xu)要(yao)為(wei)實際使用的資源付費。這也(ye)是所有(you)應用程序，包括時序數據庫，都在(zai)(zai)向云(yun)上轉(zhuan)移(yi)的一個(ge)主(zhu)要(yao)原(yuan)因。
遺憾(han)的(de)(de)是(shi)(shi)，大(da)多(duo)數(shu)數(shu)據庫(ku)只是(shi)(shi)“云就緒”（cloud-ready），而非云原生（cloud-native）。當你購買(mai)某些(xie)數(shu)據庫(ku)供(gong)應商(shang)提(ti)供(gong)的(de)(de)云服(fu)務(wu)時(shi)，比如 TimescaleDB，你需(xu)要告訴系(xi)統你想(xiang)要多(duo)少虛擬服(fu)務(wu)器(qi)（包括 CPU 和內(nei)存(cun)配置），以及(ji)多(duo)少存(cun)儲。即使你沒有(you)運(yun)行任(ren)何(he)查(cha)詢(xun)，你仍然不得不為計算資(zi)源付費(fei)，如果(guo)你的(de)(de)數(shu)據規模(mo)增(zeng)長(chang)了，你還需(xu)要決定是(shi)(shi)否(fou)購買(mai)更(geng)多(duo)資(zi)源。這種云解決方案，其實只是(shi)(shi)數(shu)據庫(ku)服(fu)務(wu)提(ti)供(gong)商(shang)在轉售云平(ping)臺。
要(yao)充分利用云平臺提供(gong)的(de)優勢(shi)，時序(xu)數據(ju)庫必須(xu)是云原生的(de)。為(wei)了實現(xian)這(zhe)一點(dian)，時序(xu)數據(ju)庫需(xu)要(yao)重新設計。這(zhe)時候要(yao)重點(dian)考(kao)慮如下(xia)幾點(dian)。
- 計算和存儲分離：在容器化環境中，特定的容器可能在任何時候啟動或關閉，但存儲的數據是持久化的。傳統的數據庫設計無法應對這種情況，因為數據都存儲在本地。此外，為了運行復雜的查詢或執行批處理，需要動態地增加更多計算節點，以加快處理速度。
- 可伸縮性：系統必須能夠根據負載和延遲要求，實現存儲和計算資源的水平擴展或水平伸縮。對于計算資源來說，系統不難做出決定。但是存儲資源就不一樣了。要實現分布式數據庫的伸縮，當數據實時寫入，或者查詢正在執行的時候，數據庫的分片可能需要進行合并或分割。設計一個能夠完成這一任務的系統并不容易。
- 自動化、可觀測性：時序數據庫的狀態必須能與系統的其他組成部分一起被監控，所以一個好的時序數據庫需要提供全面的可觀測性。同時系統必須提供便于在 K8S 下自動化管理的接口，否則運營管理將變得復雜。
現(xian)在這個時(shi)候，任何新開(kai)發的(de)(de)時(shi)序數(shu)據庫都必須(xu)是(shi)云原(yuan)生的(de)(de)。雖然(ran) TDengine 的(de)(de)設計從第一天起就(jiu)是(shi)一個具有水(shui)平(ping)擴展、高可(ke)用、高可(ke)靠的(de)(de)的(de)(de)分布式架構(gou)，但目前的(de)(de) 2.x 還不(bu)能算為(wei)云原(yuan)生數(shu)據庫，因為(wei)它不(bu)支持存算分離，而且在云平(ping)臺的(de)(de)部署和管理(li)還較(jiao)為(wei)欠缺。
4、方便易用 / Ease of use
盡管方(fang)便(bian)易用這(zhe)個詞有點(dian)主觀，但(dan)是(shi)我(wo)們可以嘗試在這(zhe)里(li)列出幾點(dian)，從不同方(fang)面(mian)說(shuo)說(shuo)一個對開發者更(geng)友好的(de)時序數據庫(ku)應(ying)該做到哪些。
- 查詢語言：因為 SQL 仍然是最流行的數據庫查詢語言，能支持 SQL，對開發者而言就沒什么使用門檻了。另一方面，專用的查詢語言需要開發者花費自己寶貴的時間來學習，還會增加向其他數據庫遷移的成本。InfluxDB，OpenTSDB，Prometheus，RRDTool 等都不支持 SQL，但 TDengine 與 TimeScaleDB 支持 SQL。
- 交互式控制臺：對開發者而言，使用一個交互式的控制臺來管理運行的數據庫或執行即席查詢是最方便的。對于部署在云上的時序數據庫也是如此。
- 示例代碼：開發者往往不會花時間把整個文檔通讀一遍，而是直接學習如何使用某個特定的特性或 API。新的數據庫必須用主流的編程語言提供示例代碼，開發者只需要把這些代碼復制粘貼到自己的應用中，如果需要的話再根據自己的具體情況稍加修改即可。
- 數據遷移工具：數據庫管理系統需要提供一到多個方便高效的數據導入導出工具。源頭和目標可能是一個文件、另一個數據庫或者是遠程數據中心中的一個副本。要遷移的數據可能是整個數據庫，一組表，或者是一個指定時間段中的數據點。
技術的挑戰
上面我總結了目前市場上時序數據庫（Time Series Database）幾大亟待解決的問題，包括 Scalability，Complex，Cloud Native 與 Ease of Use。這些問題，從技術上來看，都是硬骨頭，否則早被廠商解決了。有問題，那就有機會。2016 年底，我就是(shi)由(you)于研(yan)究后(hou)，發現 InfluxDB，TimeScaleDB，Prometheus，OpenTSDB 等有各種(zhong)不足，才(cai)開始決定進入這(zhe)個行業的(de)。5 年多過去，我帶領(ling) TDengine 團隊力(li)圖(tu)去解決這(zhe)些問題，版本從(cong)最開始的(de) 1.0，到 1.6，到 2.0、2.6，團隊從(cong) 5 個人發展到了 80 多人，專職研(yan)發都(dou)已經(jing)超過 50 人。TDengine 與(yu)很(hen)多時序數據庫相比，是(shi)一(yi)不錯的(de)產品，但遺憾(han)的(de)是(shi)，上述的(de)問題還只(zhi)是(shi)部分(fen)的(de)解決。
作為一個(ge)(ge)堅信技(ji)(ji)術(shu)(shu)能改(gai)變(bian)世界的(de)(de)創(chuang)始人，不(bu)解決(jue)這些問題難以(yi)(yi)入眠，難以(yi)(yi)證明自己(ji)以(yi)(yi)及整個(ge)(ge)團隊的(de)(de)技(ji)(ji)術(shu)(shu)實力。因此在 2021 年 6 月，我決(jue)定(ding)正式啟動 TDengine 3.0 的(de)(de)研(yan)發(fa)，投入了公(gong)司(si)最(zui)大的(de)(de)資源，讓(rang)所有(you)(you)研(yan)發(fa)同學(xue)專(zhuan)心新(xin)版本(ben)的(de)(de)研(yan)發(fa)，以(yi)(yi)解決(jue)上述技(ji)(ji)術(shu)(shu)難題為目標。TDengine 3.0 不(bu)僅(jin)要(yao)瞄(miao)準未來，成為一個(ge)(ge)云原生時(shi)序數(shu)(shu)據(ju)(ju)庫(ku)，它(ta)還需(xu)要(yao)能支持 100 億(yi)條時(shi)間線，100 個(ge)(ge)節(jie)點，讓(rang)其(qi)具(ju)備(bei)極(ji)強的(de)(de)水(shui)平擴展和伸(shen)縮能力，徹底(di)解決(jue)業內的(de)(de)“High Cardinality”問題。內置的(de)(de)流式計算(suan)、數(shu)(shu)據(ju)(ju)訂閱、緩存等(deng)功能在時(shi)序數(shu)(shu)據(ju)(ju)場(chang)景下(xia)，要(yao)能完(wan)勝 Spark，Kafka，Redis 等(deng)通用場(chang)景下(xia)的(de)(de)工(gong)具(ju)。最(zui)終(zhong)的(de)(de)目標就是降低時(shi)序數(shu)(shu)據(ju)(ju)處理系統的(de)(de)總(zong)擁(yong)有(you)(you)成本(ben)，幫助用戶挖掘出數(shu)(shu)據(ju)(ju)的(de)(de)價值，讓(rang)最(zui)終(zhong)用戶成功；而(er)且讓(rang)開發(fa)者用的(de)(de)順手、用的(de)(de)放心，讓(rang)開發(fa)者成功。
一年多過去，TDengine 的研發同學沒日沒夜的設計、編碼和測試，TDengine 3.0 終于可以揭開面紗。我們決定在 8 月 13 日召開 TDengine 開發者大會，為大家(jia)詳(xiang)細揭秘 TDengine 3.0 的(de)(de)(de)核心設(she)計(ji)，并將 3.0 正式發布，在 GitHub 上公開其核心源代(dai)碼。我們還邀請了業內(nei)的(de)(de)(de)很多技術專家(jia)、投資人(ren)，以(yi)及我們的(de)(de)(de)用(yong)戶(hu)，共同奉(feng)上一整天的(de)(de)(de)精彩分(fen)享(xiang)。
8 月 13 日，我在(zai) TDengine 開(kai)發者大(da)會(hui)上等你。
陶建輝
2022 年 7 月 24 日(ri)于北(bei)京望京
