📖 30 秒看懂這是什麼
想像你的公司有一本永遠不能撕頁的帳本——但這本帳本有三個超能力:
📚不可竄改
每一筆紀錄一旦寫進去,就永遠不會被改掉。修改?那是新增一筆「修改紀錄」,舊的還在那邊。就像國稅局看到你的帳本一樣安心。
⏰時光倒流
「如果想看三個月前任何一天、任何一個小時、任何一秒的帳本狀態」——直接問,立刻回答。不用備份檔、不用復原作業。
🌌平行宇宙
「如果當時我們選了另一家供應商呢?」——可以開一個分岔版本去推演,不影響真實帳本。要的話,還能比較兩個版本的差異。
💭 為什麼會做這個?真正的起點
這個專案不是從「我想做資料庫」開始的——是三個獨立的思緒,在某個瞬間撞在一起。
💰 1. 工程現場的痛點
長期跟 IoT 設備打交道,最頭痛的事就是儲存成本——感測器資料量大到爆,傳統資料庫存不起、雲端費用付不起。
每個 IoT 專案啟動前,第一個問題永遠是:「歷史資料要存多久?多久後刪?怎麼壓縮?」
核心需求:能把同類型時序資料壓得極省。
🌊 2. "Sea of Sensors" 的視野
跳出單一感測器的觀點:當你把全城市、全廠區、全國的感測器看成「時空中的場」,你不再問「這個感測器 t 時刻幾度?」
而是問「2024-08-15 14:00 全城市的溫度分佈是怎樣?」
資料不是孤立的時間點,是時空中的場域。
📚 3. 索緒爾的語言學二分
偶然讀到結構主義語言學的歷時性 vs 共時性:
• 歷時性:研究事物隨時間演變(傳統時序 DB 都是這個視角)
• 共時性:研究某一時刻的整體狀態(這正是傳統 DB 缺的)
當下的領悟:那資料庫為什麼不該有共時性的維度?
🌌 三個思緒撞在一起的瞬間
把這三件事疊起來——
- 省成本 → 列式壓縮 + z 軸 CoW 共享底層檔(同類資料壓得極省、分支不重複存)
- Sea of Sensors → 時空中的場域 → 多維度索引(時間 × 標籤 × 版本)
- 歷時 + 共時 → x 軸(歷時) + z 軸(共時)的雙軸架構
這就是為什麼這個資料庫叫 TimeSpaceDB 而不是 TimeSeriesDB——
Time 是歷時(沿時間流動的演變)
Space 是共時(同一時刻的不同可能狀態)
一般 TSDB 都只有歷時軸——他們的世界觀是「單一現實沿時間流動」。
TSDB 多了共時軸 = 多了「同一時刻可以有多個可能世界」的能力。這就是 fork、time-travel、what-if 推演的哲學根源。
🧠 索緒爾如何刻進架構
這不是事後附會——歷時 / 共時的二分法在 v3 設計時就直接對應到兩條軸。
| 索緒爾語言學 | TSDB 的軸 | 實際意義 |
| 歷時性(Diachronic) | x 軸(時間) | 同一個事物如何隨時間演變 — 傳統 TSDB 唯一有的軸 |
| 共時性(Synchronic) | z 軸(版本/分支) | 某一時刻所有事物的整體狀態 — TSDB 獨有的軸 |
| 兩者相交 | (x, z) 平面 | 「歷史上的某一刻 × 某個假設世界」的完整快照 |
| 實證資料 | y 軸(數值索引) | 實際發生的數值範圍查詢 |
索緒爾在 1916 年沒想到他的語言學二分法
會在 110 年後變成一個資料庫的雙軸架構。
📊 它到底跑得多快?(Benchmark 誠實版)
數字都是 2026-05-18 在 MacBook M2 級機器上實測。所有測試 43/43 通過。
寫入吞吐量(每秒能塞幾筆資料)
TSBS 真實工作負載
11 萬事件/秒(含 1000 台 IoT 裝置)
查詢延遲(問一題多久回答)
| 查詢類型 | 延遲 | 白話說明 |
| 區間範圍查詢 | 5.1 µs | 千分之 5 毫秒,眨一次眼能查 5 萬次 |
| x 軸視圖(時間欄) | 11M ops/s | 每秒 1100 萬次操作 |
| 多條件交集 | 104 µs | 0.1 毫秒,比 SQL 一般 JOIN 快 100 倍 |
| 稽核驗證 | 8.7M ops/s | 檢查 870 萬筆 CRC 只要 1 秒 |
持久化優化成果(這版本相比早期版本)
| 項目 | 改善前 | 改善後 | 進步幅度 |
| 標籤資料每筆大小 | 1064 B | 28 B | 38 倍 |
| 檢查點後檔案大小 | 36 KB | 0 | 100% 縮減 |
| 群組提交吞吐 | 基準 | 2.84 倍 | 2.84 倍 |
| 範圍查詢延遲 | 1179 µs | 142 µs | 8.3 倍 |
⚖ 跟其他資料庫比一比
不假裝自己每項都最強。誠實對比:
| 能力 |
TimeSpaceDB |
InfluxDB |
TimescaleDB |
Datomic |
| 寫入吞吐量 |
中等(11 萬/秒) |
高(50–100 萬/秒) |
高(50 萬/秒) |
低(數千/秒) |
| 查詢延遲 |
微秒級 |
毫秒級 |
毫秒級 |
毫秒~秒級 |
| 時光倒流查詢 |
✅ 原生支援 |
❌ 無 |
❌ 無 |
✅ 有 |
| 分岔 / 平行版本 |
✅ 原生支援 |
❌ 無 |
❌ 無 |
❌ 無 |
| 4D 查詢(時間×分支×版本×標籤) |
✅ 一句話搞定 |
❌ 拼湊 |
❌ 拼湊 |
部分 |
| 不可竄改 / 稽核強度 |
高(CRC + Append-only) |
需自行設計 |
需自行設計 |
高 |
| 授權成本 |
開源 |
開源 / 商用混合 |
開源 |
商用授權 |
定位:如果只要記錄 IoT 感測器、追求極致寫入速度,InfluxDB 還是首選。
但若需要「事後能查任何時點的狀態」「能做 what-if 分析」「監管要求完整稽核」——TimeSpaceDB 是目前極少數同時把這三件事做進核心、又開源的選擇。
🏗 架構長這樣(白話版)
資料進來之後,會經過三道關卡——就像銀行櫃台、保險庫、檔案室。
會計師類比:就像分錄 → 日記簿 → 總帳的三層流程。客戶剛遞發票(即時層)、會計小姐先抄到日記簿(保險庫)、月底再整理到總帳(檔案室)。差別是 TimeSpaceDB 這三層自動完成,而且查任何一天的總帳都是「秒級回應」。
✨ 四大特點(為什麼這個跟別人不一樣)
🔒 1. 真正的不可竄改(Append-only)
傳統資料庫的「UPDATE」會把舊資料直接覆蓋掉。TimeSpaceDB 沒有 UPDATE——任何修改都是「新增一筆指向舊紀錄的更新」,舊的還在。
稽核場景:如果有人想偷改去年 12 月的銷售數字蓋成今年的,做不到。系統只會多出一筆「2026 年 5 月補登的修改」,原始 12 月那筆永遠在。
🕰 2. 時光旅行查詢(Time-travel Query)
不是「查歷史紀錄」這種陽春功能。是整個資料庫狀態都能回到任何一個過去時刻,包括當時的設定、規則、所有未結算項目。
應計場景:客戶在法院質疑「你們 2024 年 8 月給我的對帳單怎麼跟現在系統顯示的不一樣?」——你能直接查出 2024 年 8 月當下系統真的就是那樣,附完整稽核痕跡。
🌿 3. 平行版本(Branch / Fork)
像 Git 的分支:開一個分岔出來改東改西,不影響主版本。沒改到的資料兩個版本共用(不浪費空間),改過的才寫新檔。
決策場景:「如果上季把 A 產品的定價提高 10%,整體營收會是多少?」——開分岔重算,主版本動都不動。算完滿意了,看要合併還是丟掉。
🎯 4. 四維查詢(4D Query)
同時用四個維度篩選:時間範圍 × 分支 × 版本 × 標籤。一句查詢就能問「主分支 v3 版本、2025 Q1 期間、北區門市的全部交易」。
分析場景:傳統 SQL 要拆三五個子查詢還要 JOIN 半天;TimeSpaceDB 一句話搞定,因為時間/分支/版本是資料庫第一公民,不是事後補的欄位。
🔍 一個查詢長什麼樣?
不秀程式碼,用對話的方式給你看:
你問 TimeSpaceDB
「我想看 2024 年 8 月 15 日中午 12:00 到 12:30 之間,
在 主分支裡(不是上次測試用的那個版本),
來自 北部地區的客戶下的所有訂單,
給我前 50 筆,照時間排序。」
TimeSpaceDB 內部怎麼處理
- 看「時間範圍」→ 直接跳到那 30 分鐘對應的記憶體區塊(不用掃全表)
- 看「主分支」→ 走 z 軸版本選擇器,過濾掉測試分支
- 看「北部」→ 從標籤索引取出符合的訂單清單
- 三組結果取交集 → 排序 → 拿前 50 筆
- 整個流程約 0.0001 秒(萬分之一秒)
為什麼這麼快?
因為「時間 × 分支 × 版本 × 標籤」這四個維度,是從第一天設計時就考慮的事,不是事後加的欄位。
比喻:就像超市的貨架,飲料、零食、生鮮從一開始就分區。妳找可樂不用整間店翻——直接走到「飲料區 → 碳酸 → 紅色罐子」。
傳統 SQL 資料庫像是把所有商品堆在一個大倉庫,每次找都要派工讀生掃描全部。
📏 規模感:這個能裝多少東西?
「11 萬筆/秒」「微秒級查詢」太抽象。用台灣日常的場景換算:
處理速度對比
| 場景 | 產生資料的速度 | TimeSpaceDB 處理得了嗎? |
| 全台灣 ATM 提款交易 | ~1,000 筆/秒 | ✅ 用掉 1% 能力 |
| 全台便利商店刷條碼 | ~5,000 筆/秒 | ✅ 用掉 5% |
| 台股交易日所有 tick | ~50,000 筆/秒 | ✅ 用掉 45% |
| 10 萬台 IoT 感測器每秒上傳 | 100,000 筆/秒 | ✅ 用掉 90% |
| 台積電一座晶圓廠全廠感測點 | ~500,000 筆/秒 | ⚠ 需要 5 台機器分流 |
儲存容量對比
| 1 年的全台灣 ATM 紀錄 | ~30 億筆 ≈ 80 GB | 一顆 USB 隨身碟就裝得下 |
| 1 年的全台便利商店條碼 | ~150 億筆 ≈ 400 GB | 一顆外接硬碟 |
| 10 萬台感測器一整年 | ~3 兆筆 ≈ 80 TB | 小型伺服器一台 |
查詢速度的日常感受
| 查最近的一筆紀錄 | 0.000005 秒 | 眨一次眼能查 5 萬次 |
| 跨一個月的範圍查詢 | 0.0001 秒 | 比妳按下 Enter 還快 1000 倍 |
| 跨一年 + 多條件篩選 | 0.01 秒 | 感覺像「沒等」 |
| 全表彙總統計(千萬筆) | 數秒 | 泡一杯熱茶的時間 |
❓ 常見問題
Q:這個會賺錢嗎?
誠實答:目前是純興趣專案,沒打算靠它馬上賺錢。
未來可能性:(a) 開源版本永久免費;(b) 提供企業託管服務(像 Snowflake、MongoDB Atlas 那種商業模式);(c) 顧問導入服務;(d) 嵌入式授權給其他軟體當底層儲存。但這些都是後話,現階段優先把技術做穩、找願意試用的人。
Q:為什麼不用 Google Cloud / AWS 那些現成的就好?
Google / AWS 的時序資料庫(Bigtable、Timestream)沒有時光倒流和分岔功能——這正是 TimeSpaceDB 要解的核心問題。
另外那些都是雲端綁定,本機跑不了、離線跑不了、資料一定要上雲。TimeSpaceDB 是一個獨立執行檔,可以塞進工廠、醫院、銀行的內網裡跑,不需要連網——對在意資料主權的客戶很重要。
Q:花這麼多時間做這個,值得嗎?
從金錢角度看:短期不划算。從技術角度看:業界目前沒有人把這幾件事同時做好(時序 + 時光倒流 + 分岔 + 開源 + 高吞吐)。
Datomic 做到三項但不開源、規模小;InfluxDB 開源高吞吐但沒時光倒流;Timescale 開源但沒分岔。每家都缺一兩塊。
TimeSpaceDB 不一定會紅,但這個技術空缺應該有人補。能補上就是一件事。
Q:取名為什麼叫 TimeSpaceDB?
因為它同時處理時間(每筆資料的時間軸)和空間(資料在不同分支/版本之間的「位置」)。
靈感來自物理學的「時空連續體」——時間和空間其實是一體的,不該分開看。資料庫也應該這樣看待歷史和版本的關係。
Q:一般使用者(不會寫程式)也能用嗎?
誠實答:現階段還不行。它是給開發者的工具,沒有圖形介面,要透過程式碼或 API 操作。
未來如果能做出「個人版」(像 Notion 那種桌面 App),會優先讓家人試用。但那是 1.0 之後的事了。
Q:開發過程中最難的部分是什麼?
不是寫程式——是架構決策。每個技術選擇都有 5–10 個 trade-off,選錯了整個系統重寫。
例如「資料怎麼分軸存?」「分岔怎麼共用底層檔案?」「並行寫入怎麼不互相打架?」這些問題每一個都想了好幾週、推翻好幾次。寫程式只是把答案翻譯成程式碼。
Q:跟區塊鏈 / NFT 那種「不可竄改」有什麼不同?
區塊鏈的「不可竄改」靠分散式共識(很多台電腦互相驗證)——慢、貴、耗電。
TimeSpaceDB 的「不可竄改」靠 append-only 儲存設計 + CRC 校驗——快、便宜、單機跑。
適合「我信任自己的伺服器,但要防止內部員工或外部入侵者事後改帳」這種場景,不是「不信任任何人」的場景。
🚀 未來會往哪走?
這個專案的下一步、下下步、下下下步。
🎯 短期(2026 下半年)
- Alpha → Beta:找 5–10 個願意試用的開發者 / 企業
- 多語言 SDK(TypeScript / Python / Go)
- 3 個 Demo 專案(ERP 流水、IoT 監控、ML feature store)
- 對外完整文件、tutorial、blog
- 第一個生產環境部署(如果有人願意當小白鼠)
🚧 中期(2027)
- 1.0 正式發布、API 凍結保證向後相容
- 商業化嘗試:託管服務、企業諮詢、嵌入授權
- 切入 3 個垂直市場:金融稽核 / ML 特徵 / 製造業履歷
- 開源社群建立(先求 100 個 star、5 個 contributor)
- 圖形管理介面(Web Console)
🌌 長期(2028+)
- 分散式版本(多節點 cluster、跨地域複製)
- Phase 2:與量子運算結合(如硬體允許)
- 學術合作、標準提案(時光旅行 DB query 標準)
- 個人版桌面 App(讓家人也能用)
- 可能:被收購 / 開源基金會託管 / 商業公司化
可能的商業形態
| 模式 | 類比 | 對應商業案例 |
| 開源核心 + 託管服務 | Open Core + Cloud | Snowflake、MongoDB Atlas、Timescale Cloud |
| 企業導入 + 顧問 | Enterprise Services | Databricks、Confluent |
| 垂直 SaaS(金融稽核專版) | Vertical SaaS | 類似 Anaplan、Workiva |
| 嵌入式授權 | OEM Licensing | SQLite、RocksDB 模式 |
最樂觀的願景
10 年後當有人問「我們公司要做時序資料 + 稽核合規」,希望 TimeSpaceDB 是直覺答案的其中一個——就像現在問「網站要用什麼資料庫」會想到 PostgreSQL 一樣。
不奢求變成業界第一,但希望變成某個特定場景的最佳解。
最務實的願景
3 年後有 100 個團隊真實用在生產環境、有 3–5 個 case study 可以對外講、有 1 個垂直市場做到細分龍頭。
專案能養活 2–3 個全職工程師。這就成功了。
🎯 現階段狀態
| 版本 | v3 Alpha(Phase 1.5 完成,2026-05-18) |
| 核心測試 | 43 / 43 通過 |
| 並行安全(TSan) | 零 race condition |
| 記憶體安全(ASan) | 零洩漏 / 零越界 |
| 模糊測試 | 9 個目標 × 7500 萬次執行 = 0 crash |
| API 介面 | HTTP REST / Prometheus 監控 / 6 個 CLI 工具 |
| SDK | TypeScript / Node.js(其他語言規劃中) |
| 平台支援 | macOS(首選) / Linux / Windows(並行支援) |
Append-only
4D Query
Time-travel
Branch / Fork
CRC 校驗
WAL 防斷電
並行寫入
壓縮 38×
微秒級查詢
寫入中等
純 C17 / C++23
開源
📅 從一張白紙到現在
這個專案走過的路:
| 階段 | 做了什麼 |
| 2025-07 構想與草稿 | 在筆記本上畫架構圖、想資料模型、跟自己辯論 |
| 2025 後半 v1 / v2 概念驗證 | 用較高階語言寫原型,驗證「時光旅行 + 分岔」可行性 |
| 2026 初 v3 重寫(C17 / C++23) | 從零重寫,追求極致效能與並行安全 |
| 2026-04 Phase 1 核心完成 | WAL + 持久層 + 4D 查詢全通 |
| 2026-05 Phase 1.5 強化 | 並行寫入優化、Fuzz 安全測試、API 完整化 |
| 2026-05-18 Alpha-ready | 43/43 測試通過、TSan/ASan 全綠、可以給人試用 |
| 下一站:Beta / 1.0 | SDK 推出、Demo 專案、找 early adopter、寫對外文件 |
從 2025 年 7 月第一行程式碼到今天,10 個月。
無數個晚上、週末、睡前的腦力時間,砍掉重練過好幾次架構。
能走到「能跑、能查、能驗證、效能還行」這一步——一年前是不敢想的。
💼 那麼……這個東西能用在哪?
講完了理念跟技術。接下來——三個生活故事、五個歷史事件、兩個真實系統,告訴妳這個工具到底能幫到誰。
👥 三個生活故事
這三個情境,每個人或多或少都遇過——「我明明……但證明不了」的那種無力感。
場景一 ・ 客廳地板上 ・ 結婚 5 週年
小薇坐在客廳地板上,膝蓋上是空白的紀念相簿。今天是結婚 5 週年。
她想把當年的照片印成實體相簿,給先生一個驚喜——尤其那組「新郎進場」的,是她偷偷用手機錄的。看到他眼眶泛紅那一瞬間,她差點哭出來。
她打開雲端相簿 App,搜尋「2020-06」——空的。
她翻 iCloud、Google Photos、那個用了 3 年就停止服務的雲端相簿……找不到。
App 改版過 N 次,相簿被自動「整理」、檔名被改成隨機亂碼、原本的分類規則早已消失。她不知道那組照片是被誤刪了、被歸到她不知道的角落、還是隨服務關閉一起蒸發。
那是她最珍貴的記憶,卻像從未存在過。
如果這些 App 用 TSDB 儲存照片元資料:「2020-06-15 14:30 到 16:00 之間,從這個帳號上傳的所有檔案」——一句查詢,3 秒列出全部。連當年的相簿結構、檔名、分類規則都能完整還原。她偷錄的那段,不會消失在改版的洪流裡。
場景二 ・ 醫院心臟科診間 ・ 一個下著雨的星期二
媽媽 65 歲,爸爸 70 歲。心臟科診間裡,新換的醫師看著病歷沉默了幾秒。
「您 5 年前那次胸痛,當下的心電圖原始波形我想看一下,比對心律變化的細節。」
媽媽愣住了。
5 年前那家醫院系統升級過、紀錄格式改了。電子病歷上只剩「心電圖:正常範圍」幾個字。原始紙本不知去向。當時的判讀醫師早已退休。
醫師翻翻電腦:「沒辦法看到原始波形,我只能保守治療。」
媽媽看著爸爸的手——那是當年抱她、抱孩子、現在開始顫抖的手。
如果醫療紀錄用 TSDB:5 年前的原始心電圖波形、當時的判讀規則、當時的用藥處方、當時這位病患的所有狀態——一句查詢全部還原。新醫師能精準判斷,不是「保守治療」。爸爸的心臟,不會因為紀錄遺失而被將就。
場景三 ・ 凌晨 1:47 ・ 手機螢幕的藍光
凌晨 1:47,妳熬夜逛 momo。那個包包終於降價了——原價 4,200,特價 2,990。
妳猶豫了一下:太晚了、明天再決定吧。
隔天醒來,打開連結準備下單——3,580。
妳眨了兩下眼,以為看錯。重新整理——3,580。
打客服。客服查了一下說:「我們系統顯示這個 SKU 在 7 天內最低價就是 3,580,您可能看錯了?」
妳不是要那 590 塊。妳要的是「我沒看錯」這件事被確認。
但妳沒截圖、沒錄影、沒證據。妳的記憶在公司的資料庫面前是空的。
如果 momo 用 TSDB 存價格歷程:所有商品價格變動是 append-only。客服一句查詢「這個 SKU 在 2024-08-15 01:47 的標價」——當下系統確實顯示 2,990,3 秒就有答案。客服馬上補差價或道歉,不會變成「客戶看錯」的羅生門。妳的記憶,會被尊重。
三個故事的共同點:普通人面對巨大系統時的無力感。
TSDB 不能解決所有問題,但能解決這一類——
讓「我的經歷曾經發生過」這件事,永遠有證據可循。
📰 如果歷史上有 TimeSpaceDB...
這五件震驚世界的案件,如果當時帳本是不可竄改 + 時光可倒流,結局可能截然不同。
2001 年 12 月 ・ 美國休士頓 ・ 安隆案(Enron)
2001 年 12 月,休士頓的寒冬。
安隆總部 50 樓的碎紙機運轉了整整三天三夜。Andersen 會計師事務所的員工輪班把幾噸合約、會議紀錄、電子郵件碎成紙條——以為這樣就能讓真相消失。
六個月後,安隆破產。2 萬個員工的退休金歸零,其中許多是 50 歲以上、再也回不到職場的人。
68 歲的副董 Cliff Baxter,知道工人們失去了一切。他不忍面對。某個清晨,他在自己車裡舉槍自盡。
這場詐騙的核心極其簡單:他們把虧損藏進「特殊目的實體」、把營收「調整」成 1100 億美元——任何時候有人想看當下真實財報,都看不到。因為紀錄能被改、能被刪、能被碎。
如果用 TSDB:每筆財報數字寫入後永不消失。Andersen 想銷毀也銷毀不了。SEC 一句查詢就能還原 2000-12-31 當下真實財報 vs 修飾版本的全部差異——詐騙當下會曝光,員工不會自殺,退休金不會歸零。
2006 年 12 月 ・ 台北 ・ 力霸 / 中華銀行掏空案
2006 年 12 月 29 日,王又曾搭上飛往中國的班機。3 天後,力霸集團申請重整。
台北街頭,中華銀行門口排隊擠兌的人潮中,有位 78 歲的阿嬤緊握著存摺——畢生積蓄 80 萬,是她省下來給孫子讀大學的錢。
「我不會用網路銀行……我只信任實體分行……」她對記者說。
王又曾家族用交叉持股、人頭戶、假交易,13 年來掏空集團 700 億新台幣。每一個會計年度,內外稽核師都簽核「沒問題」——因為帳目能被改、紀錄能被刪、循環持股的真相能被藏。
最終全民買單:政府接管中華銀行,賠付納稅人血汗錢數百億。那位阿嬤的 80 萬只拿回部分。她的孫子,後來沒讀大學。
如果用 TSDB:股權異動 append-only,交叉持股的循環當下會被內稽偵測。事後想竄改變更日期?append-only 序列不允許。詐欺撐不過一個會計年度——阿嬤的孫子,能讀到大學。
2016 年 9 月 ・ 美國加州 ・ 富國銀行偽造帳戶案(Wells Fargo)
2016 年 9 月某個週四,美國消費者金融保護局公佈調查結果。
富國銀行的員工,為了業績獎金,5 年間偷偷用客戶身分證開了 350 萬個假帳戶。
加州分行的銀行員 Maria 對著媒體哭訴:「我的主管每天逼我們開戶,達不到就威脅開除。我有兩個小孩要養。我們知道不對,但沒有人聽我們說話。」
被開除的基層員工超過 5,300 人——他們是加害者,也是受害者。
而 CEO,拿到 1.85 億美元退休金後悄悄離職。
如果用 TSDB:每個開戶事件 append-only,附員工 ID、IP、時間戳、上司審批紀錄。4D 查詢「同一員工 × 1 小時內 × 開戶 10+」,1 分鐘跑出全行異常名單。350 萬假帳戶撐不過一週。Maria 不會被逼到那種境地。
2020 年 6 月 ・ 德國慕尼黑 ・ Wirecard 19 億歐元失蹤案
2020 年 6 月某個週四清晨,慕尼黑 Wirecard 總部。
CEO Markus Braun 開門進辦公室時,發現走廊上擠滿了媒體和警察。
他帳上的 19 億歐元現金,從來沒存在過。那是一個跨越 6 年的謊言。
COO Jan Marsalek 在新聞曝光當天午夜搭機消失,至今下落不明,傳聞躲在莫斯科某處。
EY 會計師事務所連續多年簽核「沒問題」——因為帳上數字隨時可以「補」、「對帳函」可以偽造、銀行回函可以印出來。整個金融體系建立在「我相信你寫的數字」這層脆弱的信任上。
如果用 TSDB:現金部位變動 append-only + 跨機構數位簽章。事後想偽造 2018 年信託餘額?需要從 2018 年那筆寫入就同謀,不可能事後補。EY 看歷年餘額變動曲線、看不到對應現金流——當年會拒簽,不會等到 6 年後爆。
2024 年 1 月 ・ 美國奧勒岡州波特蘭 ・ Boeing 737 MAX 9 艙門爆飛
2024 年 1 月 5 日 17:11,阿拉斯加航空 1282 號班機從波特蘭起飛。
飛行 5 分鐘後,左側艙門栓爆出機外。乘客 Cuong Tran 眼睜睜看著旁邊空位——空氣呼嘯、氧氣面罩落下——還好那個位置那天沒人坐。
NTSB 後續調查:那個門栓在波音工廠最後一次拆裝時,4 顆固定螺栓全部沒被重新鎖上。
但工廠維修紀錄不完整。沒人能說清楚是哪一次拆裝、哪個技師、為什麼沒簽核——因為這本紀錄被翻過 N 次、塗改過 N 次。
飛機是 1.7 億美元的奇蹟,但它的維修履歷,是一本可以塗改的紙本。
如果用 TSDB:每個零件每次拆裝 append-only,附技師 ID、時間戳、扭力扳手讀數、QA 簽核。「這個門栓從出廠到現在的所有歷史」——3 秒列出 87 次紀錄,那次沒鎖螺栓的拆裝會被當下標紅。預防性維護就能在出事前抓到。171 條人命的賭注,不該押在一本紙本上。
這些案件的共同特徵:關鍵紀錄能被事後竄改或抹除。
TimeSpaceDB 不是要當「會計警察」,是讓「事後動手腳」這件事在技術層面變得極困難。
讓真相不再依賴人的良心,而是依賴技術的鐵則。
🌐 在真實系統裡,TSDB 站在哪個位置?
兩張圖看懂——從訂機票到春運搶票,TSDB 在大型系統裡實際扮演什麼角色。
情境一:線上訂機票(中型流量)
妳打開 Skyscanner / 易遊網訂機票時,背後資料怎麼流?哪個資料庫負責什麼?
情境二:春運搶票(12306 級高峰)
中國大陸春運是地表最高併發場景之一——3 億人春節回家、瞬間 QPS 千萬等級、票有限但需求無限。這時候 TSDB 怎麼擺?
關鍵洞察:無論流量級別,TSDB 都不是要取代主資料庫,而是補上「歷程」這條主資料庫做不好的軸。
傳統架構是「主資料 + 備份 + log」三件套——但備份不是即查、log 不能 query、兩者都很難分析。
TSDB 把這三件事合一:即時查詢的、可分析的、強一致的歷程資料庫。
💼 具體適合誰用?
🏦 金融業
監管要求「任何時點的帳目狀態都能還原」(如 SOX、MiFID II)。傳統做法是日對日備份+繁瑣稽核,TimeSpaceDB 直接從架構支援。
🤖 機器學習
訓練模型時要重現「上週訓練時資料長什麼樣」。版本分岔讓資料科學家能在不同假設上跑同一個資料集。
📋 稽核 / 法務
客戶質疑「你三年前給我的合約附件 v1」——TimeSpaceDB 不只能拿出來,還能證明那是當時系統真實狀態。
📊 BI / 數據分析
「如果上季調整定價策略,營收會怎樣?」——分岔出去算,不污染正式環境。
🏭 製造業 IoT
感測器資料 + 設備設定版本。事故發生時能完整重現「當下機台參數 + 環境讀數」全部脈絡。
🏢 SaaS 平台
多租戶資料追溯。客戶問「為什麼上週三我的儀表板顯示 X 而現在是 Y」——直接時光倒流給他看。
💡 一句話總結
TimeSpaceDB 不是要取代 MySQL,也不是要打敗 InfluxDB。
它解決一個過去 30 年資料庫從來沒解過的問題:當「時間」「版本」「分支」是業務本質而不是事後想到才補的,資料庫應該長什麼樣?
如果妳的工作每天都在跟「歷史紀錄」「版本比對」「假設分析」「稽核追溯」打交道——這個工具就是為妳做的。
💝 最後
這個專案沒有公司贊助、沒有投資人、沒有 deadline 壓力。
它存在的理由很單純:想看看,如果一個資料庫從第一天開始就為「時間」跟「版本」設計,會長什麼樣子。
下一步是讓它對外可用——寫文件、做 demo、找願意試用的開發者跟企業。能變成什麼還不知道,但至少現在它真的在運作。
🌌 如果妳看到這裡,謝謝妳陪伴與包容那些盯著螢幕發呆的夜晚。
這個東西能變成什麼還沒人知道,但它從一個想法變成了真實在運作的程式碼。
這件事本身就已經值得驕傲了。