1.寫在前面

本文針對物聯(lián)網(wǎng)數(shù)據(jù)存儲提供解決方案的思路，項目特點：結(jié)構(gòu)化數(shù)據(jù)、傳感器節(jié)點多(>100)、傳感器類型多（>30）、采樣頻率高（1HZ），在此背景下，一般的關(guān)系型數(shù)據(jù)庫已經(jīng)不能夠支撐數(shù)據(jù)存儲，基于免費開源的軟件完成數(shù)據(jù)存儲工作，提高數(shù)據(jù)的讀寫能力。

2.物聯(lián)網(wǎng)數(shù)據(jù)特點

1）多源異構(gòu)

? ? ? ? 物聯(lián)網(wǎng)數(shù)據(jù)來源于各種傳感器設(shè)備，包括溫度、風(fēng)向風(fēng)速、路燈信號、視頻等等，設(shè)備廠家還不一定一致，導(dǎo)致形成數(shù)據(jù)源多源異構(gòu)的局面，其通信協(xié)議還包括很多中，包括TCP、UDP、串口等等。

2）節(jié)點多

? ? ? ? 物聯(lián)網(wǎng)大多服務(wù)于智慧城市、智慧交通，傳感器節(jié)點能達(dá)到成千上萬

3）采樣頻率高

????????物聯(lián)網(wǎng)節(jié)點的數(shù)據(jù)生成頻率高，如地震數(shù)據(jù)200HZ的采樣，其他傳感器也能達(dá)到秒級采樣，另外傳感器節(jié)點多數(shù)處于全時工作狀態(tài)，數(shù)據(jù)流源源不斷。

3.項目說明

????????傳感器的采樣頻率普遍在1HZ，1個月數(shù)據(jù)量60*60*24*30=259.2萬條，一個傳感器的半年數(shù)據(jù)量即可達(dá)到1500萬條。同時也有8HZ采樣傳感器，一個月數(shù)據(jù)2000萬條，12個月差不多2.4億條。

其實傳感器種類多，相對可以多設(shè)計相應(yīng)的表即可，不存在影響數(shù)據(jù)庫性能。節(jié)點多，針對不同節(jié)點也可設(shè)計相應(yīng)的節(jié)點表進(jìn)行存儲，故也可不考慮

????????目前需要數(shù)據(jù)庫能長期穩(wěn)定的運行，另DBA的專注方向主要在MySQL、免費開源

4.方案思考

4.1.初始方案MySQL

第一次遇到的同學(xué)，一般不信邪，單機MySQL擼

尤其對于部分寬表而言，這里的寬表并不是數(shù)據(jù)倉庫中冗余的寬表，而是字段多，一張表涉及幾百上千各字段。時間久了，數(shù)據(jù)庫查詢性能會受到極大影響，慢查詢增多。

通過個人實測，不一定具有代表性，常規(guī)表1000萬行以下，性能優(yōu)異

1000萬-3000萬性能下降，但是不明顯，查詢依舊可以在1s內(nèi)響應(yīng)

3000-5000萬性能下降明顯，查詢時間2-10s不等

>1億條，查詢時間普遍>10s

針對物聯(lián)網(wǎng)的時序數(shù)據(jù)，采樣沒達(dá)到1HZ，MySQL是可以對付一兩年的，沒什么問題

4.2 MyCat+MySQL集群

既然單機MySQL已經(jīng)滿足不了，那第一個想到的是分庫分表，利用集群來分?jǐn)侻ySQL的壓力。

其實同樣是計算題，即通過分?jǐn)偙M量將單臺MySQL的單表控制在3000萬行以下

這里可以理解資源來支撐，例如，將分庫分表部署在10臺機器，那單表總行數(shù)在3億條之前沒什么問題（前提：切片合理），另外可能丟失部分原有的MySQL指令功能，MyCat在做分庫分表中，子查詢功能會部分確實。如果考慮高可用的話，資源還需要翻倍。具體配置方法可參照：

教小白30分鐘實現(xiàn)分庫分表_數(shù)據(jù)庫分表怎么實現(xiàn)_百老的博客-CSDN博客

分庫分表分為垂直分庫、垂直分表、水平分庫、水平分表

時序數(shù)據(jù)大多以水平分表為主

• 將一張表的數(shù)據(jù)按照某種規(guī)則分到不同的數(shù)據(jù)庫中
• 需確定分片的規(guī)則
• 使用分片的字段查詢時，科確定實體庫，其他字段查詢，查詢所有表

優(yōu)點：

• 解決了單庫大數(shù)據(jù)、高并發(fā)的性能瓶頸
• 拆分規(guī)則封裝好，對應(yīng)用端幾乎透明，開發(fā)人員無需關(guān)心拆分細(xì)節(jié)
• 提高了系統(tǒng)的穩(wěn)定性和負(fù)載能力

缺點：

• 拆分規(guī)則很難抽象
• 分片事務(wù)一致性難以解決
• 二次擴展時，數(shù)據(jù)遷移、維護難度大

4.3 開源時序數(shù)據(jù)庫

事物的發(fā)展總是從一個未知向已知發(fā)展的過程，在經(jīng)歷關(guān)系型數(shù)據(jù)庫MySQL解決不了物聯(lián)網(wǎng)時序數(shù)據(jù)的時候，下一步的方案往往是時序數(shù)據(jù)庫。下圖2022年12月排名

? ? ? ? TDengine已經(jīng)霸榜很久了，物聯(lián)網(wǎng)的數(shù)據(jù)是結(jié)構(gòu)化的，因此TDengine采取的是結(jié)構(gòu)化存儲，而不是流行的KV存儲。物聯(lián)網(wǎng)場景里，每個數(shù)據(jù)采集點的數(shù)據(jù)源是唯一的，數(shù)據(jù)是時序的，而且用戶關(guān)心的往往是一個時間段的數(shù)據(jù)，而不是某個特殊時間點。基于這些特點，TDengine要求對每個采集設(shè)備單獨建表。如果有1000萬個設(shè)備，就需要建1000萬張表。

????????基于這樣的設(shè)計，任何一臺設(shè)備采集的數(shù)據(jù)在存儲介質(zhì)里可以是一塊一塊連續(xù)的存放的，而且按照時間排序。因此查詢單個設(shè)備一個時間段的數(shù)據(jù)，查詢性能就有數(shù)量級的提升。另外一方面，雖然不同設(shè)備由于網(wǎng)絡(luò)的原因，到達(dá)服務(wù)器的時間無法控制，是完全亂序的，但對于同一個設(shè)備而言，數(shù)據(jù)點的時序是保證的。一個設(shè)備一張表，就保證了一張表插入的數(shù)據(jù)是有時序保證的，這樣數(shù)據(jù)插入操作就變成了一個簡單的追加操作，插入性也能大幅度提高。

? ? ? ? 很多單位結(jié)合時序數(shù)據(jù)庫存儲時序數(shù)據(jù)，關(guān)系型數(shù)據(jù)庫存儲業(yè)務(wù)數(shù)據(jù)已經(jīng)能夠很好的解決碰到的大部分場景。

4.4 離線數(shù)倉

? ? ? ? (Hive+HBase+Kettle+Kylin+Azkaban)+MySQL

????????時序數(shù)據(jù)不僅有實時可視化場景，同時也具備長周期趨勢分析，而針對長周期的數(shù)據(jù)查詢，對于任何數(shù)據(jù)庫來說，都是比較棘手的。這時候離線數(shù)倉的優(yōu)勢就比較明顯了，通過數(shù)據(jù)倉庫的分層思想，可以提前將數(shù)據(jù)進(jìn)行預(yù)處理.

? ? ? ? 同時Apache Kylin令使用者僅需三步，即可實現(xiàn)超大數(shù)據(jù)集上的亞秒級查詢。

? ? ? ? 1）定義數(shù)據(jù)集上的一個星形或雪花形模型

? ? ? ? 2）在定義的數(shù)據(jù)表上構(gòu)建cube

? ? ? ? 3）使用標(biāo)準(zhǔn) SQL 通過 ODBC、JDBC 或 RESTFUL API 進(jìn)行查詢，僅需亞秒級響應(yīng)時間即可獲得查詢結(jié)果

?Kylin 提供與多種數(shù)據(jù)可視化工具的整合能力，如 Tableau，PowerBI 等，令用戶可以使用 BI 工具對 Hadoop 數(shù)據(jù)進(jìn)行分析。

? ? ? ? 基于此，對于時序數(shù)據(jù)的長周期分析可以使用數(shù)倉方案。

寫在最后：正熵表示更無序,負(fù)熵表示更有序。?熵增和熵減只指趨向無序和趨向有序的過程。 一切事物都會自然“熵增”——趨向無序的過程。需要各位的智慧讓復(fù)雜多變的條件來完成趨于有序的需求。

????????文章來源地址http://www.zghlxwxcb.cn/news/detail-410613.html

到了這里，關(guān)于20分鐘了解物聯(lián)網(wǎng)開源數(shù)據(jù)庫部署解決方案的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！