✦ ✦ ✦

This project is dedicated to my wife LanLan.

The traveler who met me in the boundless time and space.

Time is an illusion. 時間,只是一個錯覺。

TimeSpaceDB

時間 × 空間 × 版本,三維資料時光機

這是一個能讓你問「2024 年 3 月 15 日下午 3 點,我們的帳本長什麼樣?
並且能同時保留「真實版本」與「如果當時做了不同決定的版本」的資料庫。

📖 30 秒看懂這是什麼

想像你的公司有一本永遠不能撕頁的帳本——但這本帳本有三個超能力:

📚不可竄改

每一筆紀錄一旦寫進去,就永遠不會被改掉。修改?那是新增一筆「修改紀錄」,舊的還在那邊。就像國稅局看到你的帳本一樣安心。

時光倒流

「如果想看三個月前任何一天、任何一個小時、任何一秒的帳本狀態」——直接問,立刻回答。不用備份檔、不用復原作業。

🌌平行宇宙

「如果當時我們選了另一家供應商呢?」——可以開一個分岔版本去推演,不影響真實帳本。要的話,還能比較兩個版本的差異。

💭 為什麼會做這個?真正的起點

這個專案不是從「我想做資料庫」開始的——是三個獨立的思緒,在某個瞬間撞在一起。

💰 1. 工程現場的痛點

長期跟 IoT 設備打交道,最頭痛的事就是儲存成本——感測器資料量大到爆,傳統資料庫存不起、雲端費用付不起。

每個 IoT 專案啟動前,第一個問題永遠是:「歷史資料要存多久?多久後刪?怎麼壓縮?」

核心需求:能把同類型時序資料壓得極省。

🌊 2. "Sea of Sensors" 的視野

跳出單一感測器的觀點:當你把全城市、全廠區、全國的感測器看成「時空中的場」,你不再問「這個感測器 t 時刻幾度?」

而是問「2024-08-15 14:00 全城市的溫度分佈是怎樣?

資料不是孤立的時間點,是時空中的場域。

📚 3. 索緒爾的語言學二分

偶然讀到結構主義語言學的歷時性 vs 共時性

歷時性:研究事物隨時間演變(傳統時序 DB 都是這個視角)

共時性:研究某一時刻的整體狀態(這正是傳統 DB 缺的)

當下的領悟:那資料庫為什麼不該有共時性的維度?

🌌 三個思緒撞在一起的瞬間

把這三件事疊起來——

這就是為什麼這個資料庫叫 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 通過。

寫入吞吐量(每秒能塞幾筆資料)

單執行緒
18 萬筆/秒
4 執行緒並行
49 萬筆/秒(提升 2.3 倍)
TSBS 真實工作負載
11 萬事件/秒(含 1000 台 IoT 裝置)

查詢延遲(問一題多久回答)

查詢類型延遲白話說明
區間範圍查詢5.1 µs千分之 5 毫秒,眨一次眼能查 5 萬次
x 軸視圖(時間欄)11M ops/s每秒 1100 萬次操作
多條件交集104 µs0.1 毫秒,比 SQL 一般 JOIN 快 100 倍
稽核驗證8.7M ops/s檢查 870 萬筆 CRC 只要 1 秒

持久化優化成果(這版本相比早期版本)

項目改善前改善後進步幅度
標籤資料每筆大小1064 B28 B38 倍
檢查點後檔案大小36 KB0100% 縮減
群組提交吞吐基準2.84 倍2.84 倍
範圍查詢延遲1179 µs142 µs8.3 倍

⚖ 跟其他資料庫比一比

不假裝自己每項都最強。誠實對比:

能力 TimeSpaceDB InfluxDB TimescaleDB Datomic
寫入吞吐量 中等(11 萬/秒) 高(50–100 萬/秒) 高(50 萬/秒) 低(數千/秒)
查詢延遲 微秒級 毫秒級 毫秒級 毫秒~秒級
時光倒流查詢 ✅ 原生支援 ❌ 無 ❌ 無 ✅ 有
分岔 / 平行版本 ✅ 原生支援 ❌ 無 ❌ 無 ❌ 無
4D 查詢(時間×分支×版本×標籤) ✅ 一句話搞定 ❌ 拼湊 ❌ 拼湊 部分
不可竄改 / 稽核強度 高(CRC + Append-only) 需自行設計 需自行設計
授權成本 開源 開源 / 商用混合 開源 商用授權
定位:如果只要記錄 IoT 感測器、追求極致寫入速度,InfluxDB 還是首選。
但若需要「事後能查任何時點的狀態」「能做 what-if 分析」「監管要求完整稽核」——TimeSpaceDB 是目前極少數同時把這三件事做進核心、又開源的選擇。

🏗 架構長這樣(白話版)

資料進來之後,會經過三道關卡——就像銀行櫃台、保險庫、檔案室。

資料怎麼進到 TimeSpaceDB? 你的應用 (網站 / App / 感測器 / ERP) HTTP tsdbd 伺服器 REST API + 4D 查詢引擎 ① 即時層 Runtime(記憶體中) ★ 像銀行櫃台:客戶剛遞單,立刻看得到、立刻能查 最近的資料放在這,查詢飛快 分成 16 個格子,多人同時寫不打架 速度:寫入 ~49 萬筆/秒(4 執行緒並行) 寫入同時 ② 保險庫 WAL(防斷電) ★ 像保險庫日誌:每筆交易先抄一份在這 斷電了?開機後從這裡把資料重建回來,一筆不漏 每寫一筆都有 CRC 校驗,發現損壞會自動修復 定期整理 ③ 檔案室 Persistent(長期儲存) ★ 像國稅局檔案室:分類歸檔、永久保存 資料按「時間軸 / 數值軸 / 版本軸」三個角度分別存 查「3 月 15 日下午」用時間軸,查「金額大於 100 萬」用數值軸 查「分岔版本」用版本軸——挑最快的那一條走 壓縮率 ~ 38 倍(標籤資料對比 v1) 三層各司其職: ① 快(即時查詢) ② 穩(斷電不丟) ③ 省(長期壓縮) 分岔版本: 就像 Git, 改動只佔新空間, 沒改的共用舊檔。
會計師類比:就像分錄 → 日記簿 → 總帳的三層流程。客戶剛遞發票(即時層)、會計小姐先抄到日記簿(保險庫)、月底再整理到總帳(檔案室)。差別是 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 內部怎麼處理

  1. 看「時間範圍」→ 直接跳到那 30 分鐘對應的記憶體區塊(不用掃全表)
  2. 看「主分支」→ 走 z 軸版本選擇器,過濾掉測試分支
  3. 看「北部」→ 從標籤索引取出符合的訂單清單
  4. 三組結果取交集 → 排序 → 拿前 50 筆
  5. 整個流程約 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 + CloudSnowflake、MongoDB Atlas、Timescale Cloud
企業導入 + 顧問Enterprise ServicesDatabricks、Confluent
垂直 SaaS(金融稽核專版)Vertical SaaS類似 Anaplan、Workiva
嵌入式授權OEM LicensingSQLite、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 工具
SDKTypeScript / 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-ready43/43 測試通過、TSan/ASan 全綠、可以給人試用
下一站:Beta / 1.0SDK 推出、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 / 易遊網訂機票時,背後資料怎麼流?哪個資料庫負責什麼?

✈️ 線上訂機票:資料怎麼流?資料庫各負責什麼? 👤 使用者瀏覽器 / 手機 App 「找 1/15 台北 → 東京」 🌐 CDN 邊緣節點(靜態資源 / 圖片) 🚪 API Gateway + 負載均衡 微服務集群(每個動作獨立服務) ① 搜尋班次 查可用班次 + 即時票價 ② 暫鎖座位 「我要這個 2A 位」 ③ 付款 刷卡 / 第三方支付 ④ 確認出票 電子票寄信件 📦 PostgreSQL — 主資料庫 回答「現在是什麼狀態?」 • 用戶資料(姓名、會員等級) • 航班資訊(班次、起降時間) • 當前票價、當前座位佔用 • 訂單最新狀態 特點:CRUD、SQL JOIN、強型別關聯 缺點:覆蓋寫,沒有歷程 ⏰ TimeSpaceDB — 流水 + 歷史 回答「過去發生過什麼?」 • 每次搜尋事件(誰、時間、查什麼) • 每次嘗試訂位(成功/失敗) • 票價變動全紀錄 • 付款狀態演變(pending→done→refund) 特點:append-only、時光倒流、4D 查詢 優點:完整歷程都在 💡 客戶情境:「為什麼我兩小時前看到 NTD 8,500,現在變 9,200?是不是動態調價坑我?」 傳統做法:客服推給 RD,RD 翻 log 三小時,客戶下次不再光顧 → TSDB:一句查詢「14:00 那班票價歷史」秒回變動曲線 + 變動原因(庫存、需求、規則變更)

情境二:春運搶票(12306 級高峰)

中國大陸春運是地表最高併發場景之一——3 億人春節回家、瞬間 QPS 千萬等級、票有限但需求無限。這時候 TSDB 怎麼擺?

🚄 春運搶票完整架構(12306 級)— TSDB 在這場景的位置 📈 規模:高峰 30+ 億 PV/天、瞬間 QPS 1500 萬+、3 億用戶 30 天集中爆發 ① 用戶接入層(多渠道、含合法用戶 + 黃牛) 📱 手機 App iOS / Android 原生 💻 Web 瀏覽器 PC / 平板 🛒 第三方代購 智行火車票、攜程、美團 🦠 黃牛機器人(要過濾) 自動化腳本、模擬器集群 ② 邊緣防護層(CDN + DDoS + SSL) 🌐 CDN 全國邊緣節點 🛡 DDoS 防護 阿里雲盾 / Cloudflare 🔐 SSL/TLS 終止 HTTPS 在邊緣解密 🗺 GSLB 智慧路由 就近、健康節點分流 ③ 安全 + 風控層(4 道牆) 🛡 WAF SQL injection / XSS 防護 🤖 反爬蟲 行為分析 + 設備指紋 🧩 人機驗證 圖形 / 滑塊 / 簡訊 OTP 📊 限流 / 熔斷 單 IP/用戶 QPS 配額 ④ API Gateway 層(統一入口) 🚪 API Gateway 路由、版本管理、灰度 🔑 認證 (OAuth / JWT) 每個請求驗 token 📡 服務發現 Nacos / Consul / Eureka ⑤ 消息隊列層(Kafka 多 Topic 削峰填谷) 📦 Kafka 集群 分區複製 Topic: 搶票 ~1000 萬筆/秒 分區 N=256 Topic: 退票 / 改簽 ~100 萬筆/秒 分區 N=64 Topic: 支付 ~50 萬筆/秒 分區 N=32 Topic: 用戶登入 ~10 萬筆/秒 分區 N=16 Topic: 風控 異常事件流 即時告警 ⑥ 微服務層(無狀態、橫向擴展、K8s 部署) 🎫 搶票服務 座位扣減邏輯 先到先得排序 100+ 實例 📋 訂單服務 訂單生命週期 狀態機管理 50+ 實例 👤 用戶服務 實名認證 乘車人管理 30+ 實例 💳 支付服務 微信 / 支付寶 退款處理 20+ 實例 ⚠ 風控服務 黃牛偵測模型 即時封號 10+ 實例 ⑦ 資料儲存層(5 種儲存,各司其職) 💨 Redis Cluster 座位即時快取 3 主 + 3 從 + Sentinel 每張票 1 個 key DECR 原子扣庫存 回應 < 1 ms 記憶體 256 GB+ ⚠ 宕機 = 全丟 RDB 5 min 快照 → 靠 TSDB 兜底 📦 MySQL 分片 主資料(持久) 16 分片 × (1主 2從) 按用戶 ID 雜湊 用戶 / 班次 / 票價 訂單最終狀態 SQL JOIN OK ⚠ 寫入有上限 不適合做高頻流水 → 流水交給 TSDB ⏰ TimeSpaceDB 集群 ★ 流水 + 稽核 + 防黃牛 3 副本 + Raft 共識 append-only WAL 納秒時間戳定序 每秒 100 萬寫入 微秒級查詢 ★ 「誰先按」鐵證 ★ 4D 查黃牛 ★ Redis 宕機重建 ★ 完整退改鏈 🗂 物件儲存 非結構化大檔 S3 / OSS / MinIO 電子票 PDF 電子發票檔 用戶頭像照片 CDN 回源 分層存儲 冷熱資料分離 便宜大容量 🔍 ElasticSearch 全文檢索 + 分析 車次模糊搜尋 「廣州→哈爾濱」 中轉換乘推薦 行銷標籤聚合 Kibana 視覺化 資料源:TSDB CDC 即時同步 索引重建從 TSDB ⑧ 監控 + 運維層(全鏈路可觀測) 📊 Prometheus 指標採集 📈 Grafana 儀表板 📋 ELK Stack log 集中 🔬 Jaeger 分散式追蹤 🚨 AlertManager 告警通知 🔄 CI/CD Jenkins / ArgoCD 💡 TSDB 在這 5 種儲存裡的不可替代性 千萬 QPS 寫入—Redis 不持久、MySQL 撐不住、ES 寫太慢,TSDB 用 append-only + sharded WAL 撐 「誰先按」毫秒級時間戳—append-only 序列就是真相,沒有事後爭議的空間 4D query 揪黃牛:「同一 IP × 1 分鐘 × 100+ 次嘗試」一句搞定,事後封號精準到秒
關鍵洞察:無論流量級別,TSDB 都不是要取代主資料庫,而是補上「歷程」這條主資料庫做不好的軸
傳統架構是「主資料 + 備份 + log」三件套——但備份不是即查、log 不能 query、兩者都很難分析。
TSDB 把這三件事合一:即時查詢的、可分析的、強一致的歷程資料庫

💼 具體適合誰用?

🏦 金融業

監管要求「任何時點的帳目狀態都能還原」(如 SOX、MiFID II)。傳統做法是日對日備份+繁瑣稽核,TimeSpaceDB 直接從架構支援。

🤖 機器學習

訓練模型時要重現「上週訓練時資料長什麼樣」。版本分岔讓資料科學家能在不同假設上跑同一個資料集。

📋 稽核 / 法務

客戶質疑「你三年前給我的合約附件 v1」——TimeSpaceDB 不只能拿出來,還能證明那是當時系統真實狀態。

📊 BI / 數據分析

「如果上季調整定價策略,營收會怎樣?」——分岔出去算,不污染正式環境。

🏭 製造業 IoT

感測器資料 + 設備設定版本。事故發生時能完整重現「當下機台參數 + 環境讀數」全部脈絡。

🏢 SaaS 平台

多租戶資料追溯。客戶問「為什麼上週三我的儀表板顯示 X 而現在是 Y」——直接時光倒流給他看。

💡 一句話總結

TimeSpaceDB 不是要取代 MySQL,也不是要打敗 InfluxDB。

它解決一個過去 30 年資料庫從來沒解過的問題:當「時間」「版本」「分支」是業務本質而不是事後想到才補的,資料庫應該長什麼樣?

如果妳的工作每天都在跟「歷史紀錄」「版本比對」「假設分析」「稽核追溯」打交道——這個工具就是為妳做的。

💝 最後

這個專案沒有公司贊助、沒有投資人、沒有 deadline 壓力。

它存在的理由很單純:想看看,如果一個資料庫從第一天開始就為「時間」跟「版本」設計,會長什麼樣子。

下一步是讓它對外可用——寫文件、做 demo、找願意試用的開發者跟企業。能變成什麼還不知道,但至少現在它真的在運作。

🌌 如果妳看到這裡,謝謝妳陪伴與包容那些盯著螢幕發呆的夜晚。
這個東西能變成什麼還沒人知道,但它從一個想法變成了真實在運作的程式碼。
這件事本身就已經值得驕傲了。

關於這份文件:由 TimeSpaceDB 團隊於 2026-05-18 製作。所有 benchmark 數字皆為實測(MacBook M2 級硬體),未經過行銷加工。對比資料來源為各家官方文件與 TSBS 標準測試結果。

進一步技術細節:請參考專案根目錄 CLAUDE.mdnote/16_持久化儲存層.mdnote/17_z軸COW設計.md

原始碼授權:開源(詳見 LICENSE)。商業諮詢、客製化導入請聯絡團隊。