想象一下，如果 WordPress 開發者突然發現下一個版本的 WordPress 放棄了 PHP 支持，改為使用 Ruby，所有的主題和插件都必須重寫，要么被困在舊版本中，永遠無法升級。或者，假設微軟突然決定將 Windows 管理從 PowerShell 轉向 Bash，Windows 管理員們不得不更新所有的腳本，以便在下一個更新中使用 Bash。
如果你已經使用過 InfluxDB，可能就不需要想象這些情景了，因為這實際上已經發生在 InfluxDB 的用戶身上，而且不止一次。
InfluxDB的“三重語言”困境
InfluxDB 最初于 2013 年發布時，使用了 InfluxQL 作為查詢語言。InfluxQL 是一種類似 SQL 的語言，專門為時序數據設計。盡管其語法與 SQL 相似，但靈活性較差，數據聚合和轉換的便捷性也較小。
然而，隨著 2020 年 InfluxDB 2.0 的發布，Flux 語言被引入。Flux 比 InfluxQL 更強大，但也更為復雜。用戶表示，他們需要參加“InfluxDB 大學”課程才能理解這門語言，而且通常要參與三個以上的 Flux 項目才能真正熟悉并運用這門語言。InfluxDB 當時信心十足地認為 Flux 會是未來的方向，許多忠實用戶也紛紛投入時間，翻譯查詢并重寫應用程序，以支持 Flux 語言。
但誰能想到，僅僅四年后，InfluxDB 3.0 發布時，Flux 卻被棄用，取而代之的是 SQL。那些花費時間學習 Flux 并更新項目的用戶，發現自己無法將項目升級到 InfluxDB 3.0，并且意識到他們在 Flux 上投入的時間和精力付之東流。
雖然 TDengine 和 InfluxDB一樣認為 SQL 是時序數據庫的最佳語言選擇，但我們更希望他們能在浪費廣大用戶的時間之前，就得出這個結論。
Flux與SQL查詢對比
以下是 InfluxDB 的 Flux 查詢與 TDengine 的 SQL 查詢對比，直觀展示了兩者的簡潔性和可讀性，給到大家參考。
Flux查詢：
from(bucket:"power")
|> range(start:-1h)
|> filter(fn:(r) =>
r.measurement == "smeter" and
r.field == "voltage" and
r.location == "chicago"
)
|> aggregateWindow(every: 1m, fn: mean)TDengine SQL 查詢：
SELECT AVG(voltage) FROM power.smeter WHERE ts > now - 1h AND location = "chicago" INTERVAL(1m);從這兩段查詢的對比中，我們可以明顯看出 TDengine 的 SQL查詢更簡潔、易讀。
TDengine 對 SQL 的承諾
在經歷了五十年的發展后，SQL 已被證明是最穩固的查詢語言。自其誕生以來，就迅速成為了頂級數據庫管理系統的查詢語言，并且成為了數據庫管理員和用戶的重要工具。如今，可以毫不夸張地說，幾乎所有與數據相關的人——從剛剛畢業、尋求第一份工作的數據科學專業畢業生，到在行業中耕耘數十年的資深專家——都具備一定的 SQL 使用經驗。
而 TDengine 自發布之初就一直支持標準 SQL，并承諾將繼續堅定地支持這一語言。未來，我們將繼續擴展 SQL 的實現，而不會用任何其他查詢語言來替代它。
在支持標準 SQL 的同時，TDengine 還在 SQL 語言上進行了針對時序數據處理特點的功能擴展，比如數據匯總、插值和時間加權平均等功能，這使得用戶不僅能享受 SQL 的靈活性，也能應用到類似 InfluxQL 的專用功能。事實上，TDengine 中的幾乎所有功能——如流處理、數據訂閱、權限管理、集群管理等——都可以通過 SQL 語句來實現。
TDengine 對 SQL 的支持大大減少了新用戶學習曲線的難度，任何曾經使用過其他 SQL 數據庫的用戶，都能輕松上手 TDengine。我們相信，SQL 是時序數據管理的最佳選擇，我們也非常重視開發者的時間，絕不希望他們為了使用我們的產品而學習一門專門的語言。
此外，我們深知，穩定和長期的解決方案對任何工業數據基礎設施都至關重要。客戶希望能擁有一致的產品體驗，而不是每隔幾年就發生一次重大轉型。許多用戶發現，將現有的 InfluxDB 項目升級到 3.0 的工作量，幾乎和遷移到另一個時序數據庫產品相當。因此，我們誠邀這些用戶嘗試 TDengine 的開源版本（OSS）或 TDengine Cloud，親自體驗這一數據庫產品如何輕松上手并快速部署。
