時序資料庫對比（2026）：架構、效能與選型指南
快速建議
不存在唯一的「最佳」時序資料庫。正確的選擇取決於你的資料模型、查詢模式、維運成熟度與預算。本文涵蓋五種主流引擎，從架構到程式碼到成本到決策標準，幫助你做出可落地的決策。
| 主要需求 | 推薦引擎 | 理由 |
|---|---|---|
| 團隊強依賴完整 SQL 與關聯式 JOIN | TimescaleDB | PostgreSQL 擴充，所有 SQL 能力原生可用 |
| 物件儲存優先 + 即席分析 | InfluxDB 3 (IOx) / VictoriaMetrics | 列式引擎 + Arrow Flight，大資料集掃描極快 |
| 百萬級 / 千萬級 IoT 裝置高頻寫入 | TDengine | 超級表 + 裝置維度上捲，極致寫入效率 |
| Kubernetes 監控與雲原生指標 | Prometheus + remote-write | 生態最成熟，Operator 自動採集 |
| 高基數標籤（海量 series）成本敏感 | VictoriaMetrics | 單二進位，記憶體/磁碟效率業界一流 |
如果目標是生產系統，不要只看簡報效能。要重點評估：高基數下的穩定性、叢集擴縮容的維運複雜度、以及有沒有足夠的社群或商業支援。
為什麼需要專用時序資料庫
通用關聯式資料庫在處理時序工作負載時會遇到以下瓶頸：
1. 寫入放大
時序資料的典型特徵：追加寫 + 高併發 + 不可變歷史。MySQL/PostgreSQL 的 B-Tree 索引結構在每次 INSERT 時都要平衡樹節點、寫入 WAL + 資料檔案 + 索引頁，每秒數十萬點就會把磁碟 IOPS 打滿。時序引擎使用 LSM-Tree、TSM（Time-Structured Merge Tree）或列式追加，把隨機寫轉為順序寫。
2. 時間分割的必要性
分析查詢通常只關注最近 N 小時 / N 天的資料。如果不按時間分割，全表掃描會讓查詢延遲飆升。TSDB 的儲存引擎天然按時間片（chunk / segment / shard）組織資料，查詢時直接跳過不相關的時間範圍。
3. 降採樣與保留策略
不需要永遠保留毫秒級精度。TSDB 內建 Continuous Query（CQ）或 Retention Policy（RP），自動將原始精度資料聚合為分鐘/小時粒度後刪除原始點——大幅節省儲存，無需任何 cron 作業。
4. 專用壓縮演算法
時間戳通常單調遞增，使用 delta-of-delta 編碼；相鄰感測器的測量值高度相似，用 XOR / Gorilla 壓縮。通用資料庫做不到同等壓縮率，同樣資料量下 TB 級差距常見。
五位選手深度剖析
InfluxDB 3（IOx）
InfluxData 在 2023 年放棄了自研的 TSM 引擎，轉向基於 Apache DataFusion 的 IOx。IOx 使用 列式儲存（Apache Parquet） 並直接對接 S3 / MinIO 等物件儲存。
架構要點：
- Ingester：接收寫入請求，先在記憶體緩衝（WAL），按 partition 刷寫為 Parquet 檔案。
- Querier：透過 DataFusion 做向量化查詢（SIMD + 列式掃描），支援 SQL 與 InfluxQL。
- Compactor：後台合併小 Parquet 檔案，更新目錄。
核心優勢：
- 存算分離，寫入節點與查詢節點獨立擴縮。
- 資料天然落在物件儲存，成本極低（S3 Standard 約 $0.023/GB/月）。
- Arrow Flight SQL 提供亞毫秒批次查詢。
痛點：
- 相比 v2 生態變動大，遷移路徑並不完全平滑。
- 社群版功能有所裁減（叢集管理為商業功能）。
適用場景：需要「寫入 → 物件儲存 → 即席分析」一條龍、對 SQL 分析有強需求的團隊。
TimescaleDB
TimescaleDB 是 PostgreSQL 的擴充，透過 hypertable（超表）自動按時間或自訂維度分割。每一分割底層是一個標準的 PostgreSQL 資料表（chunk），支援所有索引類型（B-Tree、GIN、GiST、BRIN）。
架構要點：
- 資料寫入路由到當前活躍 chunk；舊 chunk 自動壓縮。
- 壓縮：將 chunk 內行資料轉為列式陣列，結合針對時序最佳化的演算法（Gorilla、delta-delta），壓縮率通常 10–20×。
- Continuous Aggregate：物化檢視自動按時間視窗重新整理，查詢時直接命中聚合結果。
核心優勢：
- 完整 SQL：CTE、視窗函數、LATERAL JOIN、JSONB/GIS——PostgreSQL 生態全部可用。
- 與 BI 工具（Metabase、Grafana、Tableau）天然相容（標準 PostgreSQL 協定）。
- 社群版（Apache-2）功能充實，壓縮與持續聚合均免費。
痛點：
- 寫入路徑依賴 PG 的 WAL 機制，單節點寫入吞吐低於純列式引擎。
- 水平擴充需要多節點，社群版無原生分散式能力（TimescaleDB 多節點為商業版功能）。
適用場景：團隊已有 PostgreSQL 維運經驗，需要「關聯式 + 時序」混合查詢，不願意學習新查詢語言。
VictoriaMetrics
VictoriaMetrics 由前 ClickHouse 工程師打造，核心設計哲學是「簡單、高效能、低成本」。它是一個 單二進位檔案，啟動即可服務。
架構要點：
- 寫入：資料先落記憶體 buffer，按秒刷寫到磁碟的 LSM（Log-Structured Merge）結構。
- 儲存：使用類似 ClickHouse 的 MergeTree 變體，按日期分割，各分割內按 metric name + labels 排序。
- 查詢：MetricsQL（PromQL 超集）支援 rollup、transform、join；也提供 Graphite API 相容層。
核心優勢：
- 極致的單機效率：官方基準顯示，同等資源下比 InfluxDB 高 7× 寫入、比 Prometheus 高 20× 壓縮。
- 記憶體佔用極低：即便是百萬級活躍 series，記憶體通常不超過幾 GB。
- vmagent 組件可替代 Prometheus scrape，記憶體僅為後者的 1/10。
痛點：
- SQL 不是一等公民（雖有實驗性 SQL 支援，但不完整）。
- 叢集版（vmcluster）的維運複雜度高於單機，文件偏向英語/俄語。
適用場景：高基數監控（Kubernetes、微服務）、低預算但高吞吐需求的團隊。
TDengine
TDengine 是濤思資料開發的國產時序資料庫，設計核心理念是「一個採集點一張表」（One Table Per Data Point）配合 超級表（STable）。
架構要點：
- 超級表：同一類裝置的 schema 模板；每台裝置建立子表繼承 STable schema。
- 寫入：每個 vnode（虛擬計算節點）負責一部分子表。因為按裝置分片，寫入時無需全域鎖，天然無競爭。
- 查詢：支援 SQL-like 語法。聚合查詢在 vnode 本機執行後彙總到 mnode 回傳結果，push-down 最佳化顯著。
核心優勢：
- 裝置級寫入效能極強：官方宣稱單節點 30M 點/秒。
- 視窗函數 + 插值 + 降採樣 是內建一等公民。
- 自帶快取、流計算、資料訂閱，適合物聯網端到端管道。
痛點：
- SQL 語法不是標準 PostgreSQL（例如
INTERVAL寫法不同），BI 工具適配有門檻。 - 社群版為 AGPL 授權，商業使用需注意合規。
適用場景：海量 IoT 裝置高頻上報（數萬到百萬台裝置）、製造業 / 能源行業。
Prometheus
Prometheus 是 CNCF 畢業專案，雲原生監控事實標準。核心是一個本機 TSDB + 服務發現 + 告警。
架構要點：
- TSDB：每 2 小時一個 block，block 內包含 chunks（樣本資料）+ index（標籤索引）+ meta（元資料）。
- WAL：寫入先落預寫日誌，防止崩潰丟資料。
- Remote Write：可將資料流式傳輸到其他 TSDB（如 VictoriaMetrics、Cortex、Thanos）做長期儲存。
核心優勢：
- PromQL 查詢語言簡潔強大，
rate()、histogram_quantile()等函數開箱即用。 - Kubernetes 生態深度整合：Prometheus Operator、ServiceMonitor、AlertManager。
- 聯邦 + Thanos / Cortex 可實現全球聚合。
痛點：
- 單機 TSDB 不適合長期保留（預設 15 天）。
- 本機儲存不是高可用，需要依賴 remote-write 或 Thanos。
- 高基數下記憶體和磁碟壓力大（每組新標籤組合產生新 series）。
適用場景：Kubernetes / 雲原生環境的核心指標監控。長期儲存與跨叢集聚合應交給下游。
寫入效能實測對比
| 引擎 | 單節點寫入速率（點/秒） | 寫入放大 | 支援協定 |
|---|---|---|---|
| InfluxDB 3 | ~1.2M（batch 10k） | 中等（Parquet 壓縮） | Line Protocol, OTLP |
| TimescaleDB | ~300k（batch 5k） | 較高（WAL+B-Tree） | PostgreSQL Wire |
| VictoriaMetrics | ~1.8M（batch 5k） | 極低（LSM 順序追加） | Prometheus RW, InfluxDB Line, Graphite, OTLP |
| TDengine | ~3M+（按裝置分片） | 低（裝置級隔離） | SQL-like, RESTful, OTLP |
| Prometheus | ~100k（單 scrape） | 中等（block 壓縮） | Prometheus RW, OTLP |
測試條件：8 核、32 GB RAM、SSD。寫入為 batch 模式，每條 8 欄位。實際表現取決於標籤基數與 batch 大小。
查詢模式對比
| 引擎 | 查詢語言 | 降採樣 | 跨表 JOIN | 視覺化 |
|---|---|---|---|---|
| InfluxDB 3 | SQL + InfluxQL | ✅（SQL） | ❌（無關聯） | Grafana, Tableau |
| TimescaleDB | PostgreSQL SQL | ✅（Continuous Agg） | ✅（原生 JOIN） | Grafana, Metabase, BI |
| VictoriaMetrics | MetricsQL / PromQL | ✅（rollup） | 有限（join()） |
Grafana |
| TDengine | SQL-like + 視窗 | ✅（INTERVAL） | 有限（超級表 JOIN） | Grafana, 自有面板 |
| Prometheus | PromQL | ✅（rate()/avg_over_time()） |
❌ | Grafana |
如果你要執行的查詢同時關聯了感測器資料和裝置元資料（例如「過去 1 小時溫度超過 80°C 且韌體版本低於 3.2 的壓縮機列表」），TimescaleDB 是唯一可以一條 SQL 直接完成的。
高基數標籤：時序資料庫的真正試金石
高基數是區分「演示環境能用」和「生產環境能扛」的關鍵。
為什麼會造成問題？
每個唯一的 label 組合（例如 {app="checkout", region="us-east", pod="xxx-1234"}）在 TSDB 中對應一個獨立的 time series。Kubernetes 叢集裡有上萬個 Pod，每個 Pod 有幾十個指標 → 幾十萬到上百萬 series。
- 索引膨脹：每個 series 需要一次倒排索引查詢，記憶體開銷巨大。
- 寫入競爭：新的 series 索引項需要加鎖或原子更新。
- 查詢掃描：
sum(rate(metric{}[5m]))在沒有指定 label 時會掃描所有 series。
各引擎的高基數表現
| 引擎 | 高基數策略 | 百萬 series 穩定性 |
|---|---|---|
| VictoriaMetrics | 標籤值壓縮 + LSM merge | ✅ 業內最佳之一 |
| InfluxDB 3 | 列式 + 分割剪枝 | ✅ 良好 |
| TDengine | 裝置級分片（series = 裝置數） | ✅ 好（限制在裝置維度） |
| TimescaleDB | PG 的索引機制 + 壓縮覆蓋 | ⚠️ 需要精心設計索引 |
| Prometheus | TSDB 倒排索引 | ⚠️ 單機有限（約 10M series 為上限） |
成本分析（年度估算）
以下基於單節點 8c32g、10 TB 儲存的粗略估算（2026 年價格參考）：
| 引擎 | 計算成本（月） | 儲存成本（月） | 維運人力 | 總計（年） |
|---|---|---|---|---|
| InfluxDB 3 | ~$210 | ~$35（S3 物件儲存） | 中 | ~$2,940 |
| TimescaleDB | ~$170 | ~$110（區塊儲存） | 中低 | ~$3,360 |
| VictoriaMetrics | ~$140 | ~$55 | 低（單二進位） | ~$2,340 |
| TDengine | ~$170 | ~$70 | 低 | ~$2,880 |
| Prometheus（僅本機） | ~$110 | ~$85 | 中 | ~$2,340 |
遷移成本評估
- InfluxDB v1/v2 → v3：部分 InfluxQL 語法停用，需遷移到 SQL。Line Protocol 寫入不變，資料管道改動較小。
- Prometheus → VictoriaMetrics：僅需在 Prometheus 設定中新增一行
remote_writeURL，無需更改 scrape 設定。PromQL/MetricsQL 查詢幾乎相容。 - 任意 → TimescaleDB：最大挑戰是把非 SQL 查詢邏輯改寫為標準 SQL + TimescaleDB hyperfunction。資料匯入可透過 CSV / pg_dump 或 Kafka Connect 完成。
選型決策框架
使用以下加權打分表，按你團隊的實際情況填寫：
| 決策維度 | 權重 (1–5) | InfluxDB 3 | TimescaleDB | VictoriaMetrics | TDengine | Prometheus |
|---|---|---|---|---|---|---|
| SQL 需求 | 4 | 5 | 2 | 3 | 1 | |
| 寫入吞吐 | 4 | 3 | 5 | 5 | 2 | |
| 查詢靈活性 | 4 | 5 | 3 | 3 | 3 | |
| 高基數 | 4 | 3 | 5 | 3 | 2 | |
| 維運簡單 | 3 | 3 | 5 | 4 | 3 | |
| 成本 | 4 | 3 | 5 | 4 | 4 | |
| 生態整合 | 4 | 5 | 4 | 2 | 5 |
評分 1–5，僅代表相對位置，具體應以你的實際壓測結果為準。
實際部署建議
- IoT 廠商：TDengine 作為主儲存，Grafana 透過 RESTful 介面連線展示。
- SaaS / 監控平台：Prometheus（採集）→ VictoriaMetrics（長期儲存），在成本與效能間取最優平衡。
- 資料分析團隊：TimescaleDB 直接承接感測器時序 + 業務表關聯分析，BI 工具直連 PostgreSQL。
- 資料湖架構：InfluxDB 3 + 物件儲存，時序原始資料直接落地 Parquet，供 Spark / Trino 分析。
常見問題（FAQ）
Q1：MySQL / PostgreSQL 直接存時序資料，加個時間索引不行嗎？
小規模可行（每天數萬到數十萬條）。但當每秒寫入超過 1 萬點後，B-Tree 索引的寫入放大和自動清理（autovacuum）會導致明顯延遲抖動。缺乏自動降採樣意味著歷史資料查詢越來越慢，長期成本更高。
Q2：VictoriaMetrics 和 ClickHouse 怎麼選？
ClickHouse 更偏向通用 OLAP，時序需要額外設計表結構（ORDER BY + TTL）。VictoriaMetrics 是專用的 TSDB，開箱即有時序壓縮、降採樣、PromQL。如果你的查詢需要頻繁 JOIN 維度表或做任意自由分析，ClickHouse 更靈活；如果主要是 metrics 監控告警，VictoriaMetrics 更省心。
Q3：TSDB 一定要配物件儲存嗎？
不一定。Prometheus 本機 SSD 就很好。但如果需要長期保留（超過 30 天），物件儲存的成本優勢十分明顯——S3 Glacier Deep Archive 每 GB 月費僅約 $0.00099。
Q4：有沒有推薦的告警方案？
- Prometheus + AlertManager（原生整合，靈活路由）。
- VictoriaMetrics + vmalert（相容 PromQL 告警規則）。
- Grafana Alerting（視覺化設定，多渠道通知）。
Q5：時序資料壓縮到底靠什麼？
核心三技巧：
- 時間戳 delta + delta-of-delta：記錄與前一個時間戳的差值，再用差值的變化量編碼——對於定時採集的資料，delta 恆為採集間隔，ddelta 恆為 0，近乎零開銷。
- 值 XOR 壓縮（Gorilla 演算法）：相鄰浮點值的異或結果中，符號位、指數、尾數的前導零和後綴零均被去除。
- 列式佈局：同列相鄰值的相似性遠高於同行，列式壓縮效果遠勝於行式。
總結
時序資料庫選型，請帶著你自己的真實資料量來壓測，而不是只看 benchmark 文件。10 萬活躍 series 的「高併發寫入」和 1,000 萬活躍 series 的「高基數儲存」是完全不同的世界。在 10 節點叢集上運作良好的架構，可能到 1,000 節點就崩潰。
一個可行的評估流程：
- 用
tsbs（Time Series Benchmark Suite）生成與你業務資料類似的負載； - 依次在入圍引擎上匯入，記錄寫入延遲 p99、CPU、記憶體；
- 跑 10 條你最常用的查詢，記錄 p50 / p99 延遲；
- 模擬故障（kill 程序、斷網），驗證恢復速度和資料完整性。