在萬物互聯的時代，大到企業數字化轉型、數字城市建設，小到和生活息息相關的家居生活、智慧駕駛、運動健康等，都離不開智慧物理裝置廣泛的連線和互通。在 IoT 裝置的整體運作過程中，會產生大量的 ，而傳統的資料解決方案不管是在效能還是成本管控上都捉襟見肘。因此，IoT 產品/平臺想要實現快速發展，首要解決的難題就是資料處理痛點。本文優選出幾大 IoT 專案的資料架構改造實踐，給到大家參考。
OPPO x TDengine
“我們寫入 60 萬行資料，到 MySQL（目前部分業務部署在 MySQL 叢集）和 的 4C 12G 容器上，對 CPU/記憶體/磁碟進行觀察。測試發現 CPU 和記憶體消耗基本持平的情況下，TDengine 的落盤資料是 MySQL 環境的1/4左右。”
業務背景
在 OPPO 的穿戴產品的手環/手錶類業務中，產生的資料型別為時序資料，具有寫入量巨大且存在離線/歷史資料補錄（更新）的處理需求。此前使用的 MongoDB/MySQL 叢集方案，後端儲存壓力較大，需要經常擴盤，針對此痛點，OPPO 雲端計算中心智慧物聯雲團隊嘗試調研對比了幾款 （ ， ）產品，試圖尋找一個降本增效的解決方案，最後選中了 TDengine。
叢集部署如下：
搜尋 檢視更多技術細節
京東雲 x TDengine
“在與 TDengine 工程師溝通後， 我們只使用了 3 臺 4C16GB 構成的 TDengine 的叢集，就承載了線上的業務。資料聚合方面，根據 TDengine 的效能、機器配置和前期測試的時間開銷，只需很短的時間就完成了全量裝置的資料聚合。CPU 方面也一直很穩定，在常態下 CPU 低於 10%，由於裝置的資料聚合需要消耗大量的 CPU，因此在每個整點 CPU 會有所上升，但是也不會超過 45% 的負載。”
業務背景
京東雲智慧家居場景維護著大量的智慧裝置，這些裝置聯網後，會根據裝置設定的速率持續產生時序資料，比如有的裝置取樣間隔是 15 秒。京東雲 IoT 團隊結合本公司資料特點與業務需求，對多種工業時序資料庫進行了技術選型，以解決龐大的資料儲存和計算帶來的挑戰，在進行選型時對比了 和 TDengine，最終 TDengine 以明顯優勢勝出。
CPU 消耗圖示
搜尋 檢視更多技術細節
圖撲物聯 x TDengine
“在之前一個版本，平臺底層使用的是 InfluxDB 來儲存時序資料，然而 InfluxDB 在面對海量資料時的讀寫效能存在瓶頸，在深入使用 TDengine 後，我們還發現了諸多優勢。受益於 TDengine 的超高效能和超小體量，我們在山東大禹水處理有限公司中央水機監控專案中的整個平臺架構變得更加簡化，解決了工業物聯網監控分析系統開發成本高、週期長、運維難度大等痛點。”
業務背景
針對海量的裝置上報資料，圖撲 IoT 平臺在做實時顯示的同時還考慮將歷史資料也進行無損儲存，並在 IoT Platform 上還要給使用者提供資料查詢的支援，但這就對底層的時序資料儲存提出了相當高的要求。在對比了包括 InfluxDB 在內的幾個資料庫後，在最新的解決方中，我們選用了 TDengine 作為時序資料的儲存引擎。
架構圖
搜尋
檢視更多技術細節
寫在最後
在合適的時候選擇合適的資料庫是支援業務發展的關鍵，但資料庫的更換也並不是頭腦一熱就能拍板決定的，還需要進行資料庫產品的縝密觀察和調研，希望上述企業實踐能夠給到大家幫助。目前 TDengine 已經運營了幾十個使用者交流群，如果你有要進群溝通了解的需求，可以新增 小T微信：tdengine1 。