隨著 IoT 技術(shù)的快速發(fā)展，物聯(lián)網(wǎng)設(shè)備產(chǎn)生的數(shù)據(jù)呈爆炸式增長，數(shù)據(jù)的總量(Volume)、數(shù)據(jù)類型越來越多(Variety)、訪問速度要求越來越快(Velocity)、對數(shù)據(jù)價值(Value)的挖掘越來越重視。物聯(lián)網(wǎng)產(chǎn)生的數(shù)據(jù)通常都具備時間序列特征，時序數(shù)據(jù)庫是當前針對物聯(lián)網(wǎng) IoT、工業(yè)互聯(lián)網(wǎng) IIoT、應(yīng)用性能監(jiān)控 APM 場景等垂直領(lǐng)域定制的數(shù)據(jù)庫解決方案，本文主要分析物聯(lián)網(wǎng)場景海量時序數(shù)據(jù)存儲與處理的關(guān)鍵技術(shù)挑戰(zhàn)及解決方案。

在商洛等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供網(wǎng)站建設(shè)、網(wǎng)站設(shè)計 網(wǎng)站設(shè)計制作按需定制網(wǎng)站,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,全網(wǎng)整合營銷推廣,外貿(mào)網(wǎng)站建設(shè),商洛網(wǎng)站建設(shè)費用合理。

一 時序數(shù)據(jù)存儲挑戰(zhàn)

1 典型時序應(yīng)用場景

隨著 5G/IoT 技術(shù)的發(fā)展，數(shù)據(jù)呈爆炸式增長，其中物聯(lián)網(wǎng) (IoT) 與應(yīng)用性能監(jiān)控 (APM) 等是時序數(shù)據(jù)最典型的應(yīng)用領(lǐng)域，覆蓋物聯(lián)網(wǎng)、車聯(lián)網(wǎng)、智能家居、工業(yè)互聯(lián)網(wǎng)、應(yīng)用性能監(jiān)控等常見的應(yīng)用場景，海量的設(shè)備持續(xù)產(chǎn)生運行時指標數(shù)據(jù)，對數(shù)據(jù)的讀寫、存儲管理都提出了很大的挑戰(zhàn)。

2 時序數(shù)據(jù)的特征

在典型的物聯(lián)網(wǎng)、APM 時序數(shù)據(jù)場景里，數(shù)據(jù)的產(chǎn)生、訪問都有比較明顯的規(guī)律，有很多共同的特征，相比當前互聯(lián)網(wǎng)典型的應(yīng)用特征有比較大的區(qū)別。

• 數(shù)據(jù)按時間順序產(chǎn)生，一定帶有時間戳，海量的物聯(lián)網(wǎng)設(shè)備或者被監(jiān)控到應(yīng)用程序，按固定的周期或特定條件觸發(fā)，持續(xù)不斷的產(chǎn)生新的時序數(shù)據(jù)。
• 數(shù)據(jù)是相對結(jié)構(gòu)化的，一個設(shè)備或應(yīng)用，產(chǎn)生的指標一般以數(shù)值類型(絕大部分)、字符類型為主，并且在運行過程中，指標的數(shù)量相對固定，只有模型變更、業(yè)務(wù)升級時才會新增/減少/變更指標。
• 寫多讀少，極少有更新操作，無需事務(wù)能力支持，在互聯(lián)網(wǎng)應(yīng)用場景里，數(shù)據(jù)寫入后，往往會被多次訪問，比如典型的社交、電商場景都是如此;而在物聯(lián)網(wǎng)、APM 場景，數(shù)據(jù)產(chǎn)生存儲后，往往在需要做數(shù)據(jù)運營分析、監(jiān)控報表、問題排查時才會去讀取訪問。
• 按時間段批量訪問數(shù)據(jù)，用戶主要關(guān)注同一個或同一類類設(shè)備在一段時間內(nèi)的訪問趨勢，比如某個智能空調(diào)在過去1小時的平均溫度，某個集群所有實例總的訪問 QPS 等，需要支持對連續(xù)的時間段數(shù)據(jù)進行常用的計算，比如求和、計數(shù)、最大值、最小值、平均值等其他數(shù)學函數(shù)計算。
• 近期數(shù)據(jù)的訪問遠高于歷史數(shù)據(jù)，訪問規(guī)律明顯，歷史數(shù)據(jù)的價值隨時間不斷降低，為節(jié)省成本，通常只需要保存最近一段時間如三個月、半年的數(shù)據(jù)，需要支持高效的數(shù)據(jù) TTL 機制，能自動批量刪除歷史數(shù)據(jù)，最小化對正常寫入的影響。
• 數(shù)據(jù)存儲量大，冷熱特征明顯，因此對存儲成本要求比較高，需要有針對性的存儲解決方案。

結(jié)合時序的特征，要滿足大規(guī)模時序數(shù)據(jù)存儲需求，至少面臨如下的幾個核心挑戰(zhàn)：

• 高并發(fā)的寫入吞吐：在一些大規(guī)模的應(yīng)用性能監(jiān)控、物聯(lián)網(wǎng)場景，海量的設(shè)備持續(xù)產(chǎn)生時序數(shù)據(jù)，例如某省域電網(wǎng)用電測量數(shù)據(jù)，9000萬的電表設(shè)備，原來每個月采集一次，后續(xù)業(yè)務(wù)升級后15分鐘采集一次，每秒的時序數(shù)據(jù)點數(shù)達到數(shù)百萬甚至千萬時間點，需要數(shù)十到上百臺機器的集群規(guī)模來支撐全量的業(yè)務(wù)寫入;時序數(shù)據(jù)存儲需要解決大規(guī)模集群的橫向擴展，高性能平穩(wěn)寫入的需求。
• 高效的時序數(shù)據(jù)查詢分析：在典型的監(jiān)控場景，通常需要對長周期的數(shù)據(jù)進行查詢分析，比如針對某些指標最近1天、3天、7天、1個月的趨勢分析、報表等;而在物聯(lián)網(wǎng)場景，有一類比較典型的斷面查詢需求，例如查詢某個省指定時間所有電表的用電量量明細數(shù)據(jù)，查詢某個品牌空調(diào)的某個時間的平均運行溫度;這些查詢都需要掃描大量的集群數(shù)據(jù)才能拿到結(jié)果，同時查詢的結(jié)果集也可能非常大;時序數(shù)據(jù)存儲需要支持多維時間線檢索、并具備流式處理、預計算等能力，才能滿足大規(guī)模 APM、IoT 業(yè)務(wù)場景的典型查詢需求，并且針對時序大查詢要最小化對寫入的影響。
• 低成本的時序數(shù)據(jù)存儲：某典型的車聯(lián)網(wǎng)場景，僅20000輛車每小時就產(chǎn)生近百GB的車輛指標數(shù)據(jù)，如果要保存一年的運行數(shù)據(jù)就需要PB級的數(shù)據(jù)存儲規(guī)模;由于數(shù)據(jù)規(guī)模巨大，對存儲的低成本要求很高，另外時序數(shù)據(jù)的冷熱特征明顯。時序數(shù)據(jù)存儲需要充分利用好時序數(shù)據(jù)量大、冷熱訪問特征明顯、做好計算、存儲資源的解耦，通過低成本存儲介質(zhì)、壓縮編碼、冷熱分離、高效 TTL、Servereless 等技術(shù)將數(shù)據(jù)存儲成本降低到極致。
• 簡單便捷的生態(tài)協(xié)同：在物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)等場景，時序數(shù)據(jù)通常有進一步做運營分析處理的需求，在很多情況下時序數(shù)據(jù)只是業(yè)務(wù)數(shù)據(jù)的一部分，需要與其他類型的數(shù)據(jù)組合來完成查詢分析;時序數(shù)據(jù)存儲需要能與生態(tài) BI 分析工具、大數(shù)據(jù)處理、流式分析系統(tǒng)等做好對接，與周邊生態(tài)形成協(xié)同來創(chuàng)造業(yè)務(wù)價值。

為了應(yīng)對海量時序數(shù)據(jù)的存儲與處理的挑戰(zhàn)，從2014年開始，陸續(xù)有針對時序數(shù)據(jù)存儲設(shè)計的數(shù)據(jù)庫誕生，并且時序數(shù)據(jù)庫的增長趨勢持續(xù)領(lǐng)先，時序數(shù)據(jù)庫結(jié)合時序數(shù)據(jù)的特征，嘗試解決時序數(shù)據(jù)存儲在高寫入吞吐、橫向擴展、低成本存儲、數(shù)據(jù)批量過期、高效檢索、簡單訪問與時序數(shù)據(jù)計算等方面面臨的挑戰(zhàn)。

3 業(yè)界時序數(shù)據(jù)庫發(fā)展

時序數(shù)據(jù)庫經(jīng)過近些年的發(fā)展，大致經(jīng)歷了幾個階段：

• 第一階段，以解決監(jiān)控類業(yè)務(wù)需求為主，采用時間順序組織數(shù)據(jù)，方便對數(shù)據(jù)按時間周期存儲及檢索，解決關(guān)系型數(shù)據(jù)庫存儲時序數(shù)據(jù)的部分痛點，典型的代表包括 RDDTool、Wishper(Graphite)等，這類系統(tǒng)處理的數(shù)據(jù)模型比較單一，單機容量受限，并且通常內(nèi)嵌于監(jiān)控告警解決方案。
• 第二階段，伴隨大數(shù)據(jù)和Hadoop生態(tài)的發(fā)展，時序數(shù)據(jù)量開始迅速增長，業(yè)務(wù)對于時序數(shù)據(jù)存儲處理擴展性方面提出更高的要求?；谕ㄓ每蓴U展的分布式存儲專門構(gòu)建的時間序列數(shù)據(jù)庫開始出現(xiàn)，典型的代表包括 OpenTSDB(底層使用 HBase)、KairosDB(底層使用 Cassandra)等，利用底層分布式存儲可擴展的優(yōu)勢，在 KV 模型上構(gòu)建定制的時序模型，支持海量時序的倒排檢索與存儲能力。這類數(shù)據(jù)庫的數(shù)據(jù)存儲本質(zhì)仍然是通用的 KV 存儲，在時序數(shù)據(jù)的檢索、存儲壓縮效率上都無法做到極致，在時序數(shù)據(jù)的處理支持上也相對較弱。
• 第三階段，隨著 Docker、Kubernetes、微服務(wù)、IoT 等技術(shù)的發(fā)展，時間序列數(shù)據(jù)成為增長最快的數(shù)據(jù)類型之一，針對時序數(shù)據(jù)高性能、低成本的存儲需求日益旺盛，針對時序數(shù)據(jù)定制存儲的數(shù)據(jù)庫開始出現(xiàn)，典型的以InfluxDB 為代表，InfluxDB 的 TSM 存儲引擎針對時序數(shù)據(jù)定制，支持海量時間線的檢索能力，同時針對時序數(shù)據(jù)進行壓縮降低存儲成本，并支持大量面向時序的窗口計算函數(shù)，InfluxDB 目前也是 DB Engine Rank 排名第一的時序數(shù)據(jù)庫。InfluxDB 僅開源了單機版本，高可用集群版僅在企業(yè)版和云服務(wù)的版本里提供。
• 第四階段，隨著云計算的高速發(fā)展，云上時序數(shù)據(jù)庫服務(wù)逐步誕生，阿里云早在2017年就推出了 TSDB 云服務(wù)，隨后 Amazon、Azure 推出 Amazon TimeStream、Azure Timeseires Insight 服務(wù)，InfluxData 也逐步往云上轉(zhuǎn)型，推出 InfluxDB 云服務(wù);時序數(shù)據(jù)庫云服務(wù)可以與云上其他的基礎(chǔ)設(shè)施形成更好的協(xié)同，云數(shù)據(jù)庫已是不可逆的發(fā)展趨勢。

二 Lindorm TSDB 背后的技術(shù)思考

1 Lindorm 云原生多模數(shù)據(jù)庫

為了迎接 5g/IoT 時代的數(shù)據(jù)存儲挑戰(zhàn)，阿里云推出云原生多模數(shù)據(jù)庫 Lindorm ，致力于解決海量多類型低成本存儲與處理問題，讓海量數(shù)據(jù)存得起、看得見。

Lindorm 支持寬表、時序、搜索、文件等多種模型，滿足多類型數(shù)據(jù)統(tǒng)一存儲需求，廣泛應(yīng)用于物聯(lián)網(wǎng)、車聯(lián)網(wǎng)、廣告、社交、應(yīng)用監(jiān)控、游戲、風控等場景。其中 Lindorm TSDB 時序引擎提供高效讀寫性能、低成本數(shù)據(jù)存儲、時序數(shù)據(jù)聚合、插值、預測等計算能力，主要應(yīng)用于物聯(lián)網(wǎng)(IoT)、工業(yè)互聯(lián)網(wǎng)(IIoT)、應(yīng)用性能監(jiān)控(APM)等場景。

2 Lindorm TSDB 核心設(shè)計理念

Lindorm TSDB 做為下一代時序數(shù)據(jù)庫，在架構(gòu)升級過程中，我們認為時序數(shù)據(jù)庫的發(fā)展會有如下趨勢：

• 多模融合：未來時序數(shù)據(jù)庫與通用KV數(shù)據(jù)庫、關(guān)系型數(shù)據(jù)庫等的配合聯(lián)系會越來越緊密，例如在物聯(lián)網(wǎng)場景，設(shè)備元數(shù)據(jù)的存儲、運行時數(shù)據(jù)的存儲、業(yè)務(wù)類數(shù)據(jù)的存儲通常會使用不同的數(shù)據(jù)模型來存儲。
• 云原生：隨著云計算的發(fā)展，未來時序數(shù)據(jù)庫的存儲要基于云原生技術(shù)，充分利用云上的基礎(chǔ)設(shè)施，形成相互依賴或協(xié)同，進一步構(gòu)建出時序存儲的競爭力。
• 時序原生：未來時序數(shù)據(jù)庫的存儲引擎是針對時序數(shù)據(jù)高度定制化的，保證高效的時序多維檢索能力，高寫入吞吐及高壓縮率，支持冷熱數(shù)據(jù)自動化管理。
• 分布式彈性：未來時序數(shù)據(jù)庫要具備分布式擴展的能力，應(yīng)對大規(guī)模的時序數(shù)據(jù)庫存儲，在時序的典型應(yīng)用場景，例如物聯(lián)網(wǎng)、工業(yè)電網(wǎng)、監(jiān)控、都有海量設(shè)備數(shù)據(jù)寫入和存儲的需求，必須要做到彈性擴展，通過分布式、Serverless 等技術(shù)實現(xiàn)規(guī)模從小到大的彈性伸縮。
• 時序 SQL：未來時序數(shù)據(jù)庫的訪問要支持標準 SQL(or SQL Like 表達方式)，一方面使用上更加便捷，降低數(shù)據(jù)庫的使用門檻，同時也能基于 SQL 提供更加強大并有時序特色的計算能力。
• 云邊一體：未來時序數(shù)據(jù)庫在邊緣設(shè)備端不再是孤立的數(shù)據(jù)存儲，邊緣側(cè)會不斷加深與云端協(xié)同，形成一體化的時序存儲解決方案。

基于以上判斷，我們構(gòu)建了云原生多模數(shù)據(jù)庫 Lindorm，支持寬表、時序、搜索、文件等多種常用模型，解決物聯(lián)網(wǎng)/互聯(lián)網(wǎng)海量數(shù)據(jù)存儲的常見需求，其中 Lindorm TSDB 采用計算存儲分離的架構(gòu)，充分利用云原生存儲基礎(chǔ)設(shè)施，定制時序存儲引擎，相比業(yè)界的解決方案更具競爭力。

• 多模融合、統(tǒng)一存儲：Lindorm TSDB 引擎與寬表、搜索、文件等形成配合，解決用戶多類型數(shù)據(jù)的統(tǒng)一存儲處理需求。
• 云原生低成本存儲，計算存儲分離：Lindorm TSDB 引擎基于云原生分布式存儲平 LindormStore，提供高可靠的數(shù)據(jù)存儲，并支持彈性擴展，提供標準型、性能型、容量型等多種存儲形態(tài)，滿足不同場景的需求，同時支持冷熱數(shù)據(jù)一體化管理的能力。
• 時序定制存儲引擎：Lindorm TSDB 引擎針對時序數(shù)據(jù)的特征，定制基于 LSM Tree 結(jié)構(gòu)的時序引擎，在日志寫入、內(nèi)存組織結(jié)構(gòu)、時序數(shù)據(jù)存儲結(jié)構(gòu)以及 Compaction 策略上都針對時序特征優(yōu)化，保證極高的寫入吞吐能力。在引擎內(nèi)部支持內(nèi)置的預處理計算引擎，支持對時序數(shù)據(jù)進行預降采樣、預聚合，來優(yōu)化查詢效率。
• 多維數(shù)據(jù)分片、彈性伸縮：Lindorm TSDB 引擎支持橫向擴展，通過對時間線進行 Hash 分片，將海量時間線數(shù)據(jù)分散到多個節(jié)點存儲;在節(jié)點內(nèi)部，支持按時間維度進一步切分，支持集群的無縫擴容，同時也能解決云原生監(jiān)控場景時間線膨脹的問題;通過 Serverless 形態(tài)實現(xiàn)任意規(guī)模的彈性伸縮。
• 定制時序 SQL 查詢：Lindorm TSDB 引擎提供時序 SQL 訪問能力，針對時序場景定制特色計算算子，用戶學習、使用成本低。
• 邊云同步一體化：Lindorm TSDB 引擎提供輕量級邊緣部署的版本，解決邊緣時序存儲需求，并支持邊緣側(cè)數(shù)據(jù)與云端無縫同步，以便充分利用云上基礎(chǔ)設(shè)施來進一步挖掘數(shù)據(jù)價值。

三 Lindorm TSDB 關(guān)鍵技術(shù)

1 時序定制存儲引擎

Lindorm 基于存儲計算分離架構(gòu)設(shè)計，以適應(yīng)云計算時代資源解耦和彈性伸縮的訴求，其中云原生存儲分布式存儲 Lindorm Store 為統(tǒng)一的存儲底座，向上構(gòu)建各個垂直專用的多模引擎，包括寬表引擎、時序引擎、搜索引擎、文件引擎。LindormStore 是面向公共云基礎(chǔ)存儲設(shè)施(如云盤、DBFS、OSS) 設(shè)計、兼容 HDFS 協(xié)議的分布式存儲系統(tǒng)，并同時支持運行在本地盤環(huán)境，以滿足部分專有云、專屬大客戶的需求，向多模引擎和外部計算系統(tǒng)提供統(tǒng)一的、與環(huán)境無關(guān)的標準接口。

基于云原生分布式存儲 LindomStore，Lindorm TSDB 采用針對寫入優(yōu)化的 LSM Tree 結(jié)構(gòu)來存儲時序數(shù)據(jù)，并結(jié)合時序數(shù)據(jù)的特征，在日志寫入、內(nèi)存組織結(jié)構(gòu)、時序數(shù)據(jù)存儲結(jié)構(gòu)進行時序壓縮，最大化內(nèi)存利用效率、磁盤存儲效率;同時在 Compaction 策略上也針對數(shù)據(jù)通常有序產(chǎn)生的特征進行優(yōu)化。通過引擎自帶的 WAL 日志，Lindorm TSDB 能非常方便的支持實時的數(shù)據(jù)訂閱，以及在引擎內(nèi)部對數(shù)據(jù)進行針對性的降采樣、聚合等預處理操作。

Lindorm TSDB 針對時序數(shù)據(jù)的查詢，支持豐富的處理算子，包括降采樣、聚合、插值、過濾等。用戶的查詢請求經(jīng)過 Parser 解析后，通常分為多個主要的處理階段，以 Pipeline 的形式高效處理。

• Index Scan：根據(jù)用戶指定的查詢條件，基于正排索引 + 倒排索引找出所有滿足條件的時間線 ID 集合。
• Data Scan：基于第1階段找出的時間線 ID，從 TSFile 讀取對應(yīng)時間范圍的數(shù)據(jù)。
• Aggregation/Filter: 針對第2階段的掃描結(jié)果，對時間線數(shù)據(jù)進一步的處理，包括在一條時間線上對數(shù)據(jù)按一定周期進行降采樣，或?qū)Χ鄺l時間線相同時間點上的數(shù)據(jù)進行聚合(sum、count、avg、min、max等)操作等。

2 分布式彈性

Lindorm TSDB 具備橫向擴展的能力，海量的時間線數(shù)據(jù)會被分散存儲到多個 Shard 中，Shard 是集群中獨立的數(shù)據(jù)管理單元，Shard 內(nèi)部是一個自治管理的 LSM Tree 存儲引擎(參考2.2)，包含單獨的 WAL、TPI、TSFile 等文件。

在水平方向，時間序列數(shù)據(jù)會根據(jù) metric + tags 組成的時間線標識，采用 Hash 分片的策略，將數(shù)據(jù)分到多個節(jié)點;在垂直方向(時間軸維度)，分到同一個節(jié)點的數(shù)據(jù)，可按照時間維度進行切分，這樣每個 Shard 就負責一部分時間線在一定時間范圍內(nèi)的數(shù)據(jù)管理。

水平方向的分片能保證集群的負載均分到各個節(jié)點，后續(xù)還會結(jié)合業(yè)務(wù)特征，支持業(yè)務(wù)自定義的分片策略，優(yōu)化讀寫效率;垂直方向(按時間范圍)的分片，對于膨脹型時間線場景(比如云原生監(jiān)控的場景，容器頻繁上下線導致大量老時間線的消亡，新時間線的創(chuàng)建)非常有幫助，同時在集群擴容時，也可以借助時間分片策略來盡可能的減小對寫入的影響。

3 TSQL 時序查詢

Lindorm TSDB 提供 SQL 訪問能力，Lindorm TSDB 的數(shù)據(jù)模型針對物聯(lián)網(wǎng)場景高度優(yōu)化定制，概念上盡量保留開發(fā)者對數(shù)據(jù)庫的普遍理解，一個實例包含多個數(shù)據(jù)庫，一個數(shù)據(jù)庫包含多張表，表里存儲多個設(shè)備的時序數(shù)據(jù)，每個設(shè)備包含一組用于描述設(shè)備的 Tag、設(shè)備包含多個 Field 指標，新的指標數(shù)據(jù)隨時間持續(xù)不斷的產(chǎn)生。除了支持常規(guī)的 SQL 基礎(chǔ)能力，Lindorm TSDB 還定制了 sample by、latest 等算子，用于方便的表達時序降采樣、時序聚合、最新點查詢等常見的時序操作，簡化使用的同時，增強了時序 SQL 的表達能力，讓用戶使用時序數(shù)據(jù)庫更加簡單、高效。

基于 TSQL 查詢接口，Lindorm TSDB 還能針對時序數(shù)據(jù)進行一系列的拓展分析，包括時序數(shù)據(jù)預測、異常檢測等，讓應(yīng)用能更好的發(fā)揮時序數(shù)據(jù)價值。

4 Serverless

Lindorm TSDB 通過時序定制的存儲引擎、結(jié)合分布式擴展的能力，能很好的滿足大規(guī)模時序場景的業(yè)務(wù)需求。但對于一些業(yè)務(wù)訪問較小的應(yīng)用場景起步成本相對較高，例如在平臺級的應(yīng)用監(jiān)控、IoT 場景，平臺需要管理大量用戶的時序數(shù)據(jù)，而大部分用戶的數(shù)據(jù)規(guī)模初期都相對較小，為了進一步降低用戶的使用成本，適應(yīng)從小到大任意規(guī)模的時序存儲需求，更好的賦能上層的應(yīng)用監(jiān)控、物聯(lián)網(wǎng)類 SaaS 平臺服務(wù)，未來 Lindorm 將會沿著多租戶 Serverless 服務(wù)模式持續(xù)演進，提升彈性能力。

5 邊云同步

隨著 IoT 技術(shù)的發(fā)展，邊緣計算需求日益明顯，在智能家居、工業(yè)工控、智慧園區(qū)、交通大腦等場景，考慮到網(wǎng)絡(luò)帶寬成本等原因，數(shù)據(jù)通常需要先就近本地存儲，并周期性的同步到云端進行進一步分析處理。為了方便邊緣側(cè)的部署，Lindorm TSDB 支持邊緣輕量級部署的版本，并支持數(shù)據(jù)全量、增量同步到云端，形成邊云一體化的解決方案。

四 時序存儲解決方案

1 物聯(lián)網(wǎng)設(shè)備數(shù)據(jù)存儲

Lindorm TSDB 是物聯(lián)網(wǎng)設(shè)備運行數(shù)據(jù)存儲的最佳選擇，無縫與阿里云 IoT 平臺、DataHub、Flink 等進行連接，極大的簡化物聯(lián)網(wǎng)應(yīng)用開發(fā)流程。例如通過 Lindorm TSDB，你可以收集并存儲智能設(shè)備的運行指標，通過自帶的聚合計算引擎或BI類工具進行智能分析，深入了解設(shè)備運行狀態(tài)。

2 工業(yè)邊緣時序存儲

Lindorm TSDB 邊緣版非常適合工業(yè)互聯(lián)網(wǎng)場景，在邊緣側(cè)輕量化輸出，與工業(yè)設(shè)備就近部署，同時支持將數(shù)據(jù)同步到 Lindorm 云端。例如通過 Lindorm TSDB，你可以實時采集工業(yè)生產(chǎn)線設(shè)備的運行指標，對產(chǎn)線的運行狀況進行分析及可視化，從而優(yōu)化產(chǎn)線運行效能。

3 應(yīng)用監(jiān)控數(shù)據(jù)存儲

Lindorm TSDB 非常適合應(yīng)用監(jiān)控數(shù)據(jù)存儲，無縫對接 Prometheus、Telegraf、ARMS 等監(jiān)控生態(tài)，提供針對監(jiān)控指標的高效讀寫與存儲，同時提供聚合分析、插值計算等能力。例如通過 Lindorm TSDB，你可以收集應(yīng)用程序的 CPU、內(nèi)存、磁盤等指標的使用情況，并進行分析及可視化，實時監(jiān)測應(yīng)用運行情況。

五 總結(jié)

從互聯(lián)網(wǎng)&大數(shù)據(jù)時代的分布式，到云計算、5G/IoT時代的云原生多模，業(yè)務(wù)驅(qū)動是Lindorm不變的演進原則。面對資源按需彈性和數(shù)據(jù)多樣化處理的新時代需求，Lindorm以統(tǒng)一存儲、統(tǒng)一查詢、多模引擎的架構(gòu)進行全新升級，并借助云基礎(chǔ)設(shè)施紅利，重點發(fā)揮云原生彈性、多模融合處理、極致性價比、企業(yè)級穩(wěn)定性的優(yōu)勢能力，全力承載好經(jīng)濟體內(nèi)部和企業(yè)客戶的海量數(shù)據(jù)存儲處理需求。

Lindorm TSDB 時序引擎面向物聯(lián)網(wǎng)、工業(yè)互聯(lián)網(wǎng)、應(yīng)用性能監(jiān)控等領(lǐng)域的時序數(shù)據(jù)存儲需求，全面擁抱云原生，并充分利用云原生基礎(chǔ)設(shè)施，定制時序存儲引擎，構(gòu)建海量低成本的時序數(shù)據(jù)存儲與處理能力，提供邊云一體化的時序存儲解決方案。未來 Lindorm 引擎將繼續(xù)在彈性伸縮、低成本海量存儲、多模融合、時序流計算等方向持續(xù)突破，構(gòu)建萬物互聯(lián)的數(shù)據(jù)底座。

網(wǎng)頁題目：物聯(lián)網(wǎng)海量時序數(shù)據(jù)存儲有哪些挑戰(zhàn)？
當前路徑：http://uogjgqi.cn/article/cccsoji.html