時(shí)序數(shù)據(jù)的特點(diǎn)是什么？

1. 時(shí)間戳：每個(gè)數(shù)據(jù)點(diǎn)都帶有時(shí)間戳，這個(gè)時(shí)間戳對于數(shù)據(jù)的計(jì)算和分析十分重要。
2. 結(jié)構(gòu)化：與來自網(wǎng)絡(luò)爬蟲、微博、微信的海量數(shù)據(jù)不同，聯(lián)網(wǎng)設(shè)備或監(jiān)控系統(tǒng)生成的數(shù)據(jù)都是結(jié)構(gòu)化的。這些數(shù)據(jù)都具有預(yù)定義的數(shù)據(jù)類型或固定長度，比如智能電表采集的電流、電壓就可以用 4 字節(jié)的標(biāo)準(zhǔn)的浮點(diǎn)數(shù)來表示。
3. 流式：數(shù)據(jù)源以近似恒定速率生成數(shù)據(jù)，如音頻或視頻流。這些數(shù)據(jù)流彼此獨(dú)立。
4. 流量平穩(wěn)可預(yù)測：與電商平臺或社交媒體網(wǎng)站的數(shù)據(jù)不同，時(shí)序數(shù)據(jù)的流量在一段時(shí)間內(nèi)是穩(wěn)定的，并且可以根據(jù)數(shù)據(jù)源的數(shù)量和采樣周期來進(jìn)行計(jì)算和預(yù)測。
5. 不變性：時(shí)序數(shù)據(jù)一般都是 append-only，類似于日志數(shù)據(jù)，一般不容許而且也沒有修改的必要。很少有場景，需要對采集的原始數(shù)據(jù)進(jìn)行修改。

時(shí)序數(shù)據(jù)處理的挑戰(zhàn)

時(shí)序數(shù)據(jù)通常用于比較當(dāng)前數(shù)據(jù)與歷史數(shù)據(jù)、檢測異常、生成實(shí)時(shí)警報(bào)以及預(yù)測未來趨勢。時(shí)序數(shù)據(jù)解決方案一般考慮以下問題：

• 時(shí)序數(shù)據(jù)量通常很大，因此在執(zhí)行存儲、索引、查詢、分析等操作時(shí)變得更加困難。
• 時(shí)序數(shù)據(jù)需要實(shí)時(shí)計(jì)算和分析，以便于實(shí)時(shí)檢測異常并告警。 延遲可能會導(dǎo)致故障和業(yè)務(wù)影響。
• 通常需要關(guān)聯(lián)來自不同傳感器和其他源的數(shù)據(jù)，這使情況變得更復(fù)雜。
• 不管是原始數(shù)據(jù)查詢、還是聚合數(shù)據(jù)查詢，時(shí)序數(shù)據(jù)的查詢一般都會帶上查詢時(shí)間范圍，一方面是根據(jù)時(shí)間范圍計(jì)算聚合時(shí)間窗口，另一方面是為了更高效的檢索數(shù)據(jù)，提高查詢效率，避免大量無效數(shù)據(jù)的掃描。
• 數(shù)據(jù)在一段時(shí)間內(nèi)的變化趨勢比單個(gè)數(shù)據(jù)點(diǎn)重要得多。例如，考慮到網(wǎng)絡(luò)不可靠性或傳感器讀數(shù)異常，我們可能會在一段時(shí)間內(nèi)的某個(gè)平均值超過閾值時(shí)設(shè)置警報(bào)，而不是在單個(gè)數(shù)據(jù)點(diǎn)上這樣做。

TDengine 這類時(shí)序數(shù)據(jù)庫，是基于時(shí)序數(shù)據(jù)的特點(diǎn)以及應(yīng)用的特點(diǎn)進(jìn)行優(yōu)化和設(shè)計(jì)的，專為解決上述問題而生。這類專業(yè)的數(shù)據(jù)庫使時(shí)序數(shù)據(jù)的處理變得更加高效，性能也比通用數(shù)據(jù)庫更好。

為什么需要時(shí)序數(shù)據(jù)庫

隨著物聯(lián)網(wǎng)IoT平臺和云的出現(xiàn)，時(shí)序數(shù)據(jù)的量開始以前所未有的方式呈指數(shù)級增長：1. 連接設(shè)備和物聯(lián)網(wǎng)的興起，儀表、汽車、電梯、甚至自行車等設(shè)備都在源源不斷地生成數(shù)據(jù)；2. IT 基礎(chǔ)設(shè)施在高速增長，物理服務(wù)器、虛擬機(jī)、容器、微服務(wù)等等都會生成海量時(shí)序數(shù)據(jù)。龐大的時(shí)序數(shù)據(jù)集是關(guān)系數(shù)據(jù)庫和 NoSQL 數(shù)據(jù)庫面臨的主要挑戰(zhàn)，大體分為以下幾個(gè)方面：

1. 時(shí)序數(shù)據(jù)積累得非?？?，每秒產(chǎn)生數(shù)百萬條數(shù)據(jù)，通用數(shù)據(jù)庫并不是為處理這種規(guī)模的數(shù)據(jù)而設(shè)計(jì)的。關(guān)系數(shù)據(jù)庫在非常大的數(shù)據(jù)集上表現(xiàn)很差，NoSQL 數(shù)據(jù)庫雖然解決了擴(kuò)展能力，但是其通用的數(shù)據(jù)組織方式并不完全適用于對時(shí)序數(shù)據(jù)存儲和查詢需求，用戶必須根據(jù)實(shí)際應(yīng)用場景，進(jìn)行特殊設(shè)計(jì)甚至大量數(shù)據(jù)冗余存儲才能較好的利用資源處理請求。
2. 隨著數(shù)據(jù)量的增加，訪問速度越來越慢。同時(shí)，大多數(shù)通用數(shù)據(jù)庫為了提升查詢性能，針對大量數(shù)據(jù)建立索引，由此消耗大量的系統(tǒng)資源。對于海量的時(shí)序數(shù)據(jù)，通用數(shù)據(jù)庫無法高速加載并滿足實(shí)時(shí)處理需求。
3. 設(shè)備和應(yīng)用在 7*24 小時(shí)不間斷地生成數(shù)據(jù)——有時(shí)一天的數(shù)據(jù)量就超過 1 TB。關(guān)系數(shù)據(jù)庫和 NoSQL 數(shù)據(jù)庫沒有針對時(shí)序數(shù)據(jù)的特點(diǎn)來壓縮這些數(shù)據(jù)，因此，存儲成本會變得很高。

上述問題主要是處理大數(shù)據(jù)集的效率問題，但通用實(shí)時(shí)數(shù)據(jù)庫往往連時(shí)序數(shù)據(jù)應(yīng)用的一些基本需求都無法支持：

1. 數(shù)據(jù)生命周期管理：時(shí)序數(shù)據(jù)具有時(shí)效性，超過一定時(shí)長的數(shù)據(jù)通常不再具有價(jià)值，時(shí)序數(shù)據(jù)一旦老化，就需要對超過保存時(shí)長的數(shù)據(jù)進(jìn)行批量刪除處理，而不是針對單條數(shù)據(jù)的刪除。
2. Roll-up：用戶定時(shí)聚合歷史數(shù)據(jù)保存至新的數(shù)據(jù)表。原始數(shù)據(jù)和 rolled-up 的數(shù)據(jù)可能具有不同的生命周期和保留策略。
3. 特殊的分析功能：除了一般數(shù)據(jù)庫提供的功能外，數(shù)據(jù)庫還要針對時(shí)序數(shù)據(jù)的處理進(jìn)行擴(kuò)展，提供累計(jì)求和、時(shí)間加權(quán)平均、移動平均、變化率等眾多時(shí)序數(shù)據(jù)分析功能。
4. 插值：時(shí)間序列分布會在一些時(shí)間線上，且序列會隨著時(shí)間的增長往后發(fā)展。本質(zhì)上是在一個(gè)固定的時(shí)間點(diǎn)記錄數(shù)據(jù)，但如果要檢查某個(gè)具體時(shí)間的設(shè)備采集的某個(gè)量，而傳感器實(shí)際采集的時(shí)間不是這個(gè)時(shí)間點(diǎn)，這就要求數(shù)據(jù)庫能夠根據(jù)相鄰的數(shù)據(jù)點(diǎn)和規(guī)則對數(shù)據(jù)進(jìn)行插值。
5. 連續(xù)查詢：在時(shí)序應(yīng)用的場景下，對于依照時(shí)間推進(jìn)順序?qū)懭氲膶?shí)時(shí)數(shù)據(jù)，用戶有時(shí)會希望每隔一段固定時(shí)間，就能夠按照一定的查詢條件對該時(shí)間范圍內(nèi)的時(shí)序數(shù)據(jù)做一次計(jì)算（例如：對該時(shí)間范圍內(nèi)的數(shù)據(jù)求一次聚合計(jì)算），并將計(jì)算結(jié)果另行保存下來。因此，數(shù)據(jù)庫需要提供連續(xù)查詢（即一種簡化的流計(jì)算能力），能夠在時(shí)間窗口結(jié)束后對窗口內(nèi)的數(shù)據(jù)進(jìn)行計(jì)算。
6. 窗口查詢：時(shí)序數(shù)據(jù)常常需要根據(jù)采集時(shí)間對數(shù)據(jù)進(jìn)行查詢，本質(zhì)上是在時(shí)間軸上劃分出時(shí)間窗口，并對窗口內(nèi)的數(shù)據(jù)進(jìn)行聚合和查詢計(jì)算。在實(shí)際生產(chǎn)應(yīng)用中，業(yè)務(wù)場景要求的查詢條件往往比這個(gè)更復(fù)雜，需要數(shù)據(jù)庫能夠按照不同規(guī)則、沿時(shí)間軸進(jìn)行窗口劃分，并對各個(gè)窗口內(nèi)的時(shí)序數(shù)據(jù)分別進(jìn)行聚合、選擇計(jì)算等操作。

對于通用數(shù)據(jù)庫，研發(fā)人員需要投入精力通過編寫代碼來實(shí)現(xiàn)這些功能。不同場景，不同數(shù)據(jù)量都需要不同的解決方案，極大增加了研發(fā)成本。因此，無論數(shù)據(jù)集的大小如何，使用專門構(gòu)建的時(shí)序數(shù)據(jù)庫都是最好的選擇。

為什么時(shí)序數(shù)據(jù)庫（TSDB）變得流行？

時(shí)序數(shù)據(jù)庫（Time Series Database）并不是一個(gè)新興的概念。追溯其歷史，1999 年問世的 RRDtool 應(yīng)該是最早的專用時(shí)序數(shù)據(jù)庫了。在著名的數(shù)據(jù)庫排行網(wǎng)站 DB-engines 上面，時(shí)序數(shù)據(jù)庫的逐步流行起始于 2015 年，而在過去的兩年，隨著物聯(lián)網(wǎng)的快速增長，時(shí)序數(shù)據(jù)庫成為流行度最高的數(shù)據(jù)庫。

越來越多的設(shè)備連接到互聯(lián)網(wǎng)并不斷將時(shí)序數(shù)據(jù)發(fā)送到云端，越來越多的行業(yè)開始對專門構(gòu)建的時(shí)序數(shù)據(jù)庫感興趣。

從技術(shù)上講，較舊的時(shí)序數(shù)據(jù)解決方案通常是使用過時(shí)架構(gòu)的封閉系統(tǒng)，擴(kuò)展能力不足，無法支持不斷增長的數(shù)據(jù)量。在過去，一百萬個(gè)數(shù)據(jù)點(diǎn)似乎是一個(gè)巨大的數(shù)字，但現(xiàn)在數(shù)百萬甚至數(shù)十億個(gè)數(shù)據(jù)點(diǎn)已經(jīng)不足為奇了。

此外，運(yùn)營數(shù)據(jù)往往被鎖在封閉的傳統(tǒng)系統(tǒng)中，這阻礙了業(yè)務(wù)的創(chuàng)新和發(fā)展，與現(xiàn)代的數(shù)據(jù)分析工具（如人工智能和機(jī)器學(xué)習(xí)框架）相結(jié)合非常困難，數(shù)據(jù)的價(jià)值難以被進(jìn)一步挖掘。并且，將傳統(tǒng)系統(tǒng)遷移到云端或其他現(xiàn)代技術(shù)棧中，需要付出巨大成本。

不斷增長的市場需求和舊時(shí)序數(shù)據(jù)解決方案的局限性為新一代時(shí)序數(shù)據(jù)庫留出了空間。在過去的 10 年里，至少有 20 個(gè)新的時(shí)序數(shù)據(jù)庫發(fā)布，其中開源時(shí)序數(shù)據(jù)庫尤其受歡迎。

Q&A

Q：什么是時(shí)序數(shù)據(jù)庫（TSDB）？它主要用來處理什么數(shù)據(jù)？

A：時(shí)序數(shù)據(jù)庫（TSDB）是專門用于存儲、處理和分析時(shí)間序列數(shù)據(jù)的數(shù)據(jù)庫管理系統(tǒng)。它處理的時(shí)序數(shù)據(jù)是按時(shí)間維度順序記錄且?guī)饕臄?shù)據(jù)，比如物聯(lián)網(wǎng)設(shè)備傳感器數(shù)據(jù)、智能電表的電流電壓數(shù)據(jù)、證券市場行情數(shù)據(jù)、IT 基礎(chǔ)設(shè)施監(jiān)控?cái)?shù)據(jù)等，這類數(shù)據(jù)通常占世界數(shù)據(jù)總量的 90% 以上。

Q：時(shí)序數(shù)據(jù)庫和關(guān)系數(shù)據(jù)庫、NoSQL 數(shù)據(jù)庫相比，有什么優(yōu)勢？

A：相比關(guān)系數(shù)據(jù)庫和 NoSQL 數(shù)據(jù)庫，時(shí)序數(shù)據(jù)庫的核心優(yōu)勢的在于深度適配時(shí)序數(shù)據(jù)特點(diǎn)：① 寫入和查詢速度更快，無需依賴大量集群資源即可處理海量數(shù)據(jù)；② 數(shù)據(jù)壓縮率更高，大幅降低存儲成本；③ 自帶專屬功能，如數(shù)據(jù)生命周期管理、Roll-up 聚合、連續(xù)查詢、時(shí)序插值等，無需額外編碼開發(fā)，而通用數(shù)據(jù)庫需額外投入資源優(yōu)化，且性能提升有限。

Q：時(shí)序數(shù)據(jù)庫能解決時(shí)序數(shù)據(jù)處理中的哪些核心問題？

A：時(shí)序數(shù)據(jù)庫可針對性解決時(shí)序數(shù)據(jù)處理的四大核心挑戰(zhàn)：① 解決 “數(shù)據(jù)量大” 問題，支持每秒數(shù)百萬條數(shù)據(jù)的高效寫入與檢索，無需擔(dān)心數(shù)據(jù)規(guī)模增長導(dǎo)致的性能下降；② 解決 “實(shí)時(shí)性需求” 問題，支持實(shí)時(shí)計(jì)算、異常檢測與告警，避免延遲引發(fā)業(yè)務(wù)風(fēng)險(xiǎn)；③ 解決 “存儲成本高” 問題，通過高壓縮率降低 TB 級每日數(shù)據(jù)的存儲開銷；④ 解決 “專屬分析需求” 問題，自帶移動平均、累計(jì)求和、窗口查詢等功能，無需額外開發(fā)即可滿足時(shí)序數(shù)據(jù)趨勢分析需求。

Q：為什么近幾年時(shí)序數(shù)據(jù)庫（TSDB）會越來越流行？

A：時(shí)序數(shù)據(jù)庫近年流行的核心原因有三點(diǎn)：① 需求驅(qū)動，物聯(lián)網(wǎng)、云技術(shù)普及使時(shí)序數(shù)據(jù)量呈指數(shù)級增長，通用數(shù)據(jù)庫無法滿足處理需求；② 舊方案局限，傳統(tǒng)時(shí)序數(shù)據(jù)系統(tǒng)架構(gòu)過時(shí)、擴(kuò)展能力差，且數(shù)據(jù)封閉難與 AI / 機(jī)器學(xué)習(xí)工具結(jié)合，無法挖掘數(shù)據(jù)價(jià)值；③ 新一代 TSDB 優(yōu)勢，近 10 年發(fā)布的新一代時(shí)序數(shù)據(jù)庫（含開源產(chǎn)品）支持海量數(shù)據(jù)、適配云端部署，且能低成本與現(xiàn)代技術(shù)棧結(jié)合，契合市場需求。

更多時(shí)序數(shù)據(jù)庫知識點(diǎn)

• 時(shí)間序列數(shù)據(jù)的特點(diǎn)
• 如何選擇一款最佳的時(shí)序數(shù)據(jù)庫
• 數(shù)據(jù)模型對比之 InfluxDB vs TDengine
• TDengine 3.0 是如何解決時(shí)序數(shù)據(jù)庫中的高基數(shù)問題的？