小T導讀：北京智能建筑科技有限公司作為北京市在智能建筑和智慧城市領域的創新平臺，是冬奧科技平臺公司、智慧冬奧國家重點項目設計單位和核心實施單位，同時，北智建作為國家高新技術企業，致力于打造中國最大的智能建筑AIoT平臺。

在云計算模式中，采集的數據必須要傳到云上進行集中式的存儲、歸檔及分析，依托云端計算資源進行復雜的計算，再將所得到的指導性結論通過網絡下發給終端。而對于邊緣計算，即把一部分的存儲和計算的能力下沉到邊緣側（即設備側），由于終端設備可以較獨立地進行數據存儲、計算、決策和應用，因此邊緣側會更加智能，對云端依賴更小，數據處理的時效性也更高，且不再受網絡影響。

一般來說，邊緣側往往是一些能夠大量鋪設的小型智能終端，出于成本考慮，其配置的內存、CPU等硬件資源和計算能力都很有限。邊緣計算的難點就在于能否能在有限的計算資源下，實現最高效的數據存儲、分析和計算。總結下來，邊緣計算對數據庫能力的要求主要反映在以下幾個方面，這也是我們在選擇數據庫時的重點考量維度：

• 超高讀寫性能
• 低硬件開銷
• 通用接口，適配邊緣側多樣計算需求
• 實時數據的緩存能力、流式計算能力
• 歷史數據持久化存儲、高效壓縮能力
• 歷史數據回溯能力、按時間窗口的統計聚合能力

一、技術選型

整體而言，時序數據庫具備上述各項能力，也是邊緣側采集數據存儲的最佳選擇。但市面上時序數據庫產品眾多，如何篩選也是一個難點。

如OpenTSDB（底層基于HBase改造）、InfluxDB等一類的時序數據庫，其運行起來的硬件資源開銷過高，對于邊緣側來說還是太重了。后來我們觀察到了一個極輕量化的開源時序數據庫——TDengine，當時它的整個安裝包只有2MB多，使用C語言完全自主研發，核心功能就是一個高性能分布式時序數據庫。具體優勢匯總如下：

• TDengine社區已經發布了支持ARM64處理器的版本，可以順暢地運行在樹莓派等主流的邊緣側硬件上，同時提供對實時數據的緩存、歷史數據的回溯、按時間段進行聚合計算等多種能力。
• TDengine ARM版本支持的接口也有很多種，與正常集群版幾乎沒有區別。同時，它還提供了一個 taos shell客戶端，讓調試人員可以方便地去查看TDengine的運行狀態。
• 支持包括C/C++、JAVA、Python、RESTful、Go在內的多種語言，學習成本低
• 安裝超級簡單，無任何依賴

• 使用便捷

1.1 SQLite VS TDengine

另外提起邊緣側、嵌入式設備中的數據存儲，那就不得不提SQLite。SQLite是一個不需要后臺的超輕量級數據庫，即插即用的特點也讓它成為世界上裝機量最高的數據庫。SQLite甚至在官網上將自身定位與fopen()對標，而不再是作為一款數據庫。SQLite提供的一系列API都是對標關系型數據庫的，它甚至還支持了事務，因此業界常常把它用作嵌入式關系型數據庫。其與TDengine的各項對比如下：

從上面的比較中我們可以看到，TDengine和SQLite要處理的問題側重點不同，各有所長。從我們自身業務的切實需求出發，兩者并非必須要進行取舍，而是可以根據業務需求靈活搭配使用——由TDengine處理時序數據，由SQLite處理關系數據，以此更好地實現邊緣側的數據自治。基于此，在存儲方面我們決定采用TDengine+SQLite的組合形式。

二、架構與具體實現

2.1 技術架構

• 物理視圖

• 邏輯視圖

在邊緣端日志功能（為邊緣端的設備提供日志上報）的設計上，我們采用TDengine對日志進行存儲，該功能的設計是為出現異常狀況的設備提供溯源依據，在與告警功能配合下可以讓開發人員快速定位到問題，及時進行解決。此外在邊緣端進行日志處理，就能利用邊緣端的算力減輕中臺的壓力，還可以支撐2萬設備異常情況下的日志并發寫入。

對于設備的采集值，我們同樣采用TDengine進行存儲和檢索。以往采用關系型數據庫進行存儲時，在設備比較多、數據量龐大的情況下，查詢會非常的慢，體驗感極差。反觀TDengine高壓縮算法能提升10到20倍的壓縮性能，降低存儲壓力的同時也解決了數據存儲成本高的問題，還達到了降低硬件成本的效果。

2.2 建表建庫思路

• 直接輸入taos進入TDengine界面
• SHOW DATABASES 查看數據庫
• USE db_name; 選擇數據庫
• SHOW TABLES; 查看表
• CREATE DATABASE 創建庫
• CREATE TABLE 創建表
• INSERT INTO 插入數據
• SELECT 查詢數據

三、落地效果

在產品開發初期階段，我們也嘗試過其他類型的數據庫解決方案，但都因為各種問題而擱置了。因為研發團隊精力人力有限，我們沒有考慮過自己搭建一套大數據處理平臺，畢竟要充分整合Kafka、HBase、Hadoop、Spark這一系列開源框架不僅意味要花費大量人力，還需要更多的時間去調試開源框架本身的問題，融合及聯調不同框架也存在著很多數據一致性的問題，同時也意味著后期運維成本的大幅度增加，穩定性也是個不小的未知數。

所幸遇到了TDengine，它幫助我們在邊緣側解決了一個很大的問題，即邊緣存儲的問題。因為很多時候邊緣是布署在資源比較少的機器上面，甚至是ARM的工業盒子上面，在資源使用上非常的苛刻，而現在得益于TDengine超強的壓縮算法，我們使用非常小的存儲空間就存儲了幾千萬數據，壓縮率遠超1/20，在單機上面布署一個TDengine服務器就可以輕輕松松地存儲上億的數據。

此外它還擁有超強的計算能力，占用的資源也非常小，在我們的業務中千萬級數據檢索時間達到了毫秒級，從用戶角度來說產品體驗非常好。在運維層面，TDengine提供標準的SQL語法，有過SQL使用經驗的同學基本上很快就能上手，學習成本接近于零。

四、寫在最后

事實上，TDengine這款產品我已經關注很久了，我也和濤思的同學們提出過一些在使用過程中發現的Bug，從最初的版本到現在的產品，TDengine變得更加強大和成熟。作為它的“老朋友”，我在此也提出兩個改進優化建議，以便幫助它更好的成長：

• 現在安裝TDengine Server時要向下兼容TaosClient，如果在升級Server時，我不需要再在自己的服務器上面同時升級TaosClient，可以減少一些部署步驟。
• 如果我們用kubernetes進行部署，POD刪掉重啟后服務就無法啟動了，還需要在掛載的數據文件夾里面手動去修改配置，非常地不靈活。

我們與TDengine的合作不會止于此，未來等到TDengine更加成熟穩定后，不僅我們的邊緣計算存儲要使用它，甚至我們的中臺數據也要遷移到上面。