无码人妻精品一区二区三18禁,影音先锋男人AV橹橹色,污污污污污污www网站免费,日韩成人av无码一区二区三区,欧美性受xxxx狂喷水

查詢速度提升兩倍，TDengine 在 GPS 服務中的應用

南京津(jin)馳(chi)健康 孫衛(wei)衛(wei)

2022-02-25 /

小 T 導讀：隨著(zhu)業務的(de)(de)(de)發展(zhan)及數據量的(de)(de)(de)增長，南京(jing)津馳(chi)選擇將(jiang) TDengine Database 的(de)(de)(de)社區版搭建在 GPS 服(fu)務中，替代原來的(de)(de)(de) Redis+MySQL+CSV 存儲技(ji)術(shu)方(fang)案(an)，以解決查詢(xun)效率(lv)低、數據安全性低、數據占用空間大等(deng)問題(ti)。本文詳(xiang)細闡(chan)述了(le)其(qi)在技(ji)術(shu)選型、數據建模、數據遷移、效果(guo)展(zhan)示等(deng)多方(fang)面的(de)(de)(de)實踐思路與經(jing)驗匯總。

公司簡介

南京津馳健康科技(ji)有限公(gong)司是(shi)一(yi)家專(zhuan)業從事互聯(lian)網(wang)技(ji)術(shu)服(fu)(fu)務、計算機軟件開發及應用于一(yi)體的(de)(de)(de)互聯(lian)網(wang)營銷(xiao)服(fu)(fu)務的(de)(de)(de)創新型(xing)企業。在競爭激(ji)烈的(de)(de)(de)互聯(lian)網(wang)行業中，始(shi)終堅持以技(ji)術(shu)為(wei)核心，組建(jian)強大的(de)(de)(de)技(ji)術(shu)開發團隊，希(xi)望通過發揮我們的(de)(de)(de)專(zhuan)業知識(shi)，以客戶的(de)(de)(de)利(li)益最大化為(wei)目標，為(wei)企業提供(gong)線(xian)上線(xian)下全方(fang)位的(de)(de)(de)信息(xi)技(ji)術(shu)服(fu)(fu)務。

一、現狀及痛點

目前我(wo)們的(de) GPS 服(fu)務采用的(de)存(cun)(cun)(cun)儲技術方案是(shi) Redis + MySQL + CSV，實時數(shu)據(ju)存(cun)(cun)(cun)儲到 Redis 隊(dui)列，經過服(fu)務消(xiao)費后將原始(shi)(shi)數(shu)據(ju)存(cun)(cun)(cun)儲到 MySQL，凌晨(chen)執行(xing)定(ding)時任務將前一天 MySQL 中的(de)原始(shi)(shi)數(shu)據(ju)存(cun)(cun)(cun)儲到 CSV 文件。

當前系統中有 726 臺設備，每臺設備每秒上傳 1 條數據，假設每臺設備每年施工 200  天，預計一臺設備一年有 60*60*24*200=17,280,000 條數據，那726 臺設備就有 726*17,280,000=12,545,280,000 條數據。

隨著(zhu)業(ye)務(wu)的發展以(yi)及數據量的增長，各種問題(ti)也逐漸凸顯，開始影(ying)響工作效率，具(ju)體(ti)可(ke)以(yi)歸納(na)為以(yi)下幾方面：

  • 查詢效率低

CSV 是文(wen)件存儲(chu)，在(zai)讀取(qu)數(shu)(shu)據時只(zhi)能一個文(wen)件一個文(wen)件地讀取(qu)，且需要(yao)讀取(qu)全部數(shu)(shu)據后再做處理(li)，查詢效率比較低(di)。

  • 數據安全性低

最終(zhong)的數(shu)據是(shi)保存到 CSV 文(wen)件(jian)(jian)中(zhong)，并且是(shi)單文(wen)件(jian)(jian)保存，數(shu)據丟失將無法找回(hui)。雖然也可以手(shou)動保存多(duo)份(fen)文(wen)件(jian)(jian)，但這(zhe)將增加運(yun)維(wei)成(cheng)本。

  • 數據占用空間大

數(shu)據在 CSV 文件中沒有(you)進行任何的壓縮技術處理，數(shu)據占用硬盤空(kong)間比較大。

  • 數據運用不夠靈活

由于(yu)數據(ju)既有存儲在(zai) MySQL 中(zhong)的(de)，也有存儲在(zai) CSV 文(wen)件(jian)中(zhong)的(de)，導致(zhi)查(cha)詢(xun)數據(ju)時得從兩(liang)個數據(ju)源(yuan)進行(xing)查(cha)詢(xun)。且由于(yu) CSV 是文(wen)件(jian)存儲，從中(zhong)查(cha)詢(xun)數據(ju)還需要先從文(wen)件(jian)中(zhong)讀取數據(ju)，也不方便加搜索條件(jian)進行(xing)數據(ju)過(guo)濾。

二、技術選型

時序數據是指時間(jian)序(xu)列數(shu)(shu)據(ju)(ju)，是按時間(jian)順序(xu)記(ji)錄(lu)的數(shu)(shu)據(ju)(ju)列，在同一(yi)數(shu)(shu)據(ju)(ju)列中的各個數(shu)(shu)據(ju)(ju)必(bi)須是同口徑的，要求具(ju)(ju)有可比性。時序(xu)數(shu)(shu)據(ju)(ju)可以是時期數(shu)(shu)，也可以時點數(shu)(shu)。對以上業務所產生的數(shu)(shu)據(ju)(ju)進行分(fen)析，完全具(ju)(ju)備時序(xu)數(shu)(shu)據(ju)(ju)的特點。基于業務場景的需(xu)求，我們決定選擇時序(xu)數(shu)(shu)據(ju)(ju)庫(ku)作為(wei) GPS 服務平臺的核(he)心組件。


時序數據庫全稱時間(jian)序(xu)列數(shu)據庫(ku)(Time Series Database)，是用(yong)于存儲和管理時間(jian)序(xu)列數(shu)據的專(zhuan)業(ye)(ye)化數(shu)據庫(ku)，具(ju)備寫多讀少、冷熱(re)分(fen)明、高并發寫入、無事務要求、海(hai)量數(shu)據持續(xu)寫入等特點，支持基于時間(jian)區間(jian)的聚合分(fen)析和高效檢索，廣泛應用(yong)在物聯(lian)網、經濟金融(rong)、環(huan)境監控(kong)(kong)、工業(ye)(ye)制造、農業(ye)(ye)生產、硬(ying)件(jian)和軟件(jian)系(xi)統監控(kong)(kong)等場景。


為了(le)更好地(di)實現業務場景的需求，我們調研了(le)以下幾(ji)款時序數據庫產品：InfluxDB、OpenTSDB 和 TDengine。

  • InfluxDB：單機性能有問題，且集群不開源，未來擴展很成問題，無法令人信任。
  • OpenTSDB：不是獨立的服務組件，還要依賴 HBase、HDFS、ZooKeeper，體積龐大，學習成本高，運維困難。
  • TDengine：性能強大，單機就可以扛住我們目前的業務寫入量，節約大量成本。且集群開源，通過社群反饋與資料顯示可以看到，集群版性能依然穩定，未來擴展方便。

TDengine 的(de)(de)模(mo)塊之一是時(shi)序數據庫(ku)。但除此(ci)之外，為減(jian)少(shao)研發的(de)(de)復雜度、系統維(wei)護的(de)(de)難度，TDengine 還(huan)提(ti)供緩(huan)存、消息(xi)隊列、訂閱、流式(shi)計算等功能。與 Hadoop 等典型的(de)(de)大數據平臺相比，TDengine 具有如下鮮明的(de)(de)特點：

  • 10 倍以上的性能提升：定義了創新的數據存儲結構，單核每秒能處理至少 2 萬次 請求，插入數百萬個數據點，讀出一千萬以上數據點，比現有通用數據庫快十倍以 上。
  • 硬件或云服務成本降至 1/5：由于超強性能，計算資源不到通用大數據方案的 1/5；通過列式存儲和先進的壓縮算法，存儲占用不到通用數據庫的 1/10。
  • 全棧時序數據處理引擎：將數據庫、消息隊列、緩存、流式計算等功能融為一體， 應用無需再集成 Kafka/Redis/HBase/Spark/HDFS 等軟件，大幅降低應用開發和維護的復雜度成本。
  • 強大的分析功能：無論是十年前還是一秒鐘前的數據，指定時間范圍即可查詢。數據可在時間軸上或多個設備上進行聚合。即席查詢可通過 Shell、Python、 R、 MATLAB 隨時進行。
  • 高可用性和水平擴展：通過分布式架構和一致性算法，通過多復制和集群特性， TDengine 確保了高可用性和水平擴展性以支持關鍵任務應用程序。
  • 零運維成本、零學習成本：安裝集群簡單快捷，無需分庫分表，實時備份。類似標準 SQL，支持 RESTful，支持 Python/Java/C/C++/C#/Go/Node.js, 與 MySQL 相似，零學習成本。
  • 核心開源：除了一些輔助功能外，TDengine 的核心是開源的。企業再也不會被數據庫綁定了。這使生態更加強大，產品更加穩定，開發者社區更加活躍。

從開(kai)源免費、社(she)區活躍、迭代(dai)更新、性能高、開(kai)銷低、支(zhi)持集群等(deng)多方面考(kao)慮， TDengine 成(cheng)為了我們的首選解決(jue)方案。

目前，我們使用的是單機。根據建表的數據類型估算，整個服務寫入量大約為每秒接近 400M 左右，TDengine 可以輕松抗住這個級別的寫入壓力，并且壓縮率喜人。1 億條數據硬盤資源占用對比如下，存儲空間降為原方案的 3%，單位兆：

CSV文件和新方案硬盤占用資源對比 TDengine Database

而查詢方面也能給出了很優秀的答卷，查詢速度提升了兩倍多，單位毫秒：

老方案和新方案查詢速度對比 TDengine Database

三、數據建模

由于是既有系統的升級改造，必須符合現有系統架構，不能影響現有功能。因此，數據建模必須(xu)限(xian)(xian)定(ding)在一(yi)定(ding)的范圍內，有一(yi)定(ding)的約束和限(xian)(xian)制(zhi)，不像設計一(yi)個(ge)新(xin)系統一(yi)樣有很大(da)的自(zi)由度。

1.建庫

創建一個(ge)名(ming)為 gps 的庫，這個(ge)庫的數據將保留 36500 天(tian)(超過 36500 天(tian)將被自動刪除)，每 10 天(tian)一個(ge)數據文件，內存塊數為 4，允(yun)許(xu)更新數據。

CREATE DATABASE gps KEEP 36500 DAYS 10 BLOCKS 4 UPDATE 1;

2.創建超級表

CREATE TABLE gps_history (gps_time timestamp,
sn   nchar(20),
pile_no int,
lon binary(20),
lat binary(20),
speed float,
temperature int,
status int,
road_float int,
data_status int,
warn_status int,
upload_time timestamp,
create_time timestamp,
remark   nchar(100)
 ) TAGS (
pid nchar(64),
bid nchar(64)
);

3.自動創建子表

insert into gps.gps_10001 using gps.gps_history tags ('10001','10002') values (
now,'CY10001',1000,125.91014472833334,45.8548872365,0.01,120,4,1,0,1,
now,
 now,'備注' );

4.刪除表

DROP TABLE gps_history;

四、代碼改造與數據遷移

在 GPS 服(fu)務平臺(tai)現(xian)有(you)的(de)架構(gou)中(zhong)，有(you)一個數(shu)據接收服(fu)務專門對(dui)外提(ti)(ti)供時序數(shu)據的(de)寫入，數(shu)據分析(xi)服(fu)務進(jin)行計算(suan)并提(ti)(ti)供查詢服(fu)務。

數據遷移架構設計

基于上圖的(de)(de)架構設(she)計(ji)，代碼改(gai)造工作就變(bian)得非常簡單(dan)。只需(xu)要改(gai)動數(shu)據(ju)接收服(fu)務的(de)(de)寫入、數(shu)據(ju)分析服(fu)務的(de)(de)查詢(xun)，再在現有基礎上增加對 TDengine 的(de)(de)支(zhi)持，就能(neng)將(jiang)寫入和(he)查詢(xun)兩個功能(neng)按照 TDengine 的(de)(de) JDBC 接口(kou)進行接口(kou)適配，將(jiang)時序數(shu)據(ju)的(de)(de)寫入和(he)查詢(xun)切換到 TDengine。

通過這種方式，我們就把 TDengine 的改造遷移屏蔽在了 GPS 服務內部，上層應用無需關心，功能上不受任何影響。

升級改造項目，如何保(bao)(bao)證歷(li)(li)史數(shu)據(ju)的(de)平(ping)滑(hua)遷(qian)移也是一個(ge)重點問(wen)題(ti)。為此(ci)，我們開發了一個(ge)數(shu)據(ju)遷(qian)移工具(ju)，用于將 CSV 文件中的(de)歷(li)(li)史數(shu)據(ju)平(ping)滑(hua)遷(qian)移到 TDengine。為了確保(bao)(bao)海量數(shu)據(ju)的(de)快速遷(qian)移，這個(ge)工具(ju)還進(jin)行了持(chi)續的(de)性能優化(hua)，以(yi)及大(da)數(shu)據(ju)量的(de)壓(ya)力測試。

五、升級上線

第一階段：數據遷移

將(jiang)改(gai)造后(hou)的新版本上(shang)線(xian)，CSV 文件和 TDengine 并(bing)行(xing)運行(xing)，同時向(xiang)兩個數(shu)(shu)據(ju)庫寫入數(shu)(shu)據(ju)，由于 CSV 文件有全量數(shu)(shu)據(ju)，查詢請求全部交給(gei) Redis 與 CSV 文件；與此同時，啟動數(shu)(shu)據(ju)遷(qian)移(yi)工具，將(jiang)歷史數(shu)(shu)據(ju)遷(qian)移(yi)到 TDengine，待數(shu)(shu)據(ju)遷(qian)移(yi)完成后(hou)，進(jin)入到第二階段。

第一階段數據遷移

第二階段：試運行

CSV 文件和 TDengine 并行運行，也同時向兩個(ge)數(shu)據(ju)庫寫(xie)入(ru)數(shu)據(ju)；在數(shu)據(ju)遷移完(wan)全完(wan)成后，TDengine 中已(yi)經具備全量數(shu)據(ju)，此時，將查詢請求全部切換到 TDengine。觀察兩周(zhou)左右的時間，如果沒有發(fa)現(xian)問(wen)題，將進入(ru)到第(di)三階段。

第二階段試運行 TDengine Database

第三階段：正式上線

經過試(shi)運行TDengine 一切正常，功能和(he)性能都沒有問題(ti)，于是我們將 CSV 文件停止運行，數(shu)據只向 TDengine 寫入(ru)，CSV 文件占用(yong)的資源全(quan)部回收。

第三階段正式上線 TDengine Database

六、總結

目前，TDengine 社區版已經(jing)平穩運(yun)行在(zai)(zai) GPS 服務中，其(qi)作為時序數據庫在(zai)(zai)讀寫性能(neng)、存儲(chu)表現(xian)等方面都是(shi)令人滿意(yi)(yi)的。除此之外其(qi)在(zai)(zai)運(yun)維(wei)難度(du)和學習成本(ben)上(shang)也是(shi)意(yi)(yi)想不到(dao)(dao)的低，很輕松就能(neng)搭好(hao)一套可用(yong)的集群，這也是(shi)非常巨大的一個優勢。另外 TDengine 的版本(ben)迭代(dai)速度(du)非常快(kuai)，一些在(zai)(zai)舊版本(ben)遇到(dao)(dao)的問(wen)題很快(kuai)就得到(dao)(dao)了修(xiu)復，并且在(zai)(zai)性能(neng)優化(hua)方面效果也是(shi)十分顯著(zhu)。后期，我們(men)打(da)算(suan)在(zai)(zai)公司內(nei)部的其(qi)他物聯網產品中繼續深(shen)入使用(yong)。