探索 NanoTDB：使用 Go 編寫的極簡主義僅限追加時間序列資料庫

NanoTDB 是使用 Go 編寫的輕量級、僅限追加（append-only）的時間序列資料庫（TSDB）。其設計重點在於高吞吐量寫入與簡潔性，利用僅限追加的架構來優化時間序列數據常見的模式——即數據僅寫入一次，且極少甚至從不更新。這種方法簡化了設計，並與歷史時間序列記錄的穩定性保持一致。

The Architecture of Append-Only Storage

NanoTDB 的核心是利用了僅限追加模型。在時間序列工作負載中，大部分操作是寫入（插入）以及隨後對特定時間範圍的讀取。透過將儲存引擎視為類似日誌的結構，NanoTDB 避免了複雜 B-Tree 更新或傳統關聯式資料庫中常見的同頁更新（same-page updates）所帶來的開銷。

這種僅限追加設計的主要優點之一是循序寫入（sequential writes）的效率。循序 I/O 比隨機 I/O 快得多，循序寫入允許資料庫以匹配底層儲存媒介性能的速度來攝取數據。這使其成為需要從感測器、系統指標或金融 Tick 資料進行高頻率數據收集的應用程式的理想選擇。

Community Perspectives and Technical Trade-offs

雖然該專案提供了一種精簡的儲存方法，但社群對於實作方式以及僅限追加系統固有的權衡（trade-offs）提出了幾點看法。

The "Log File" Comparison

開發者提出的一個常見問題是，這樣的系統與標準日誌文件（log file）有何不同。雖然兩者都是僅限追加的，但像 NanoTDB 這樣的 TSDB 提供必要的索引與查詢能力，以便在不掃描整個文件的情況下檢索特定時間範圍的數據。日誌文件通常用於除錯或文本表示，而 TSDB 提供了一種結構化的方式來高效管理與查詢時間索引的數據。

The Challenge of Deletions

A 在資料庫設計歷史中，一個不斷出現的主題是與數據刪除的掙扎。正如社群成員所指出的，許多僅限追加的資料庫最初都採用嚴格的「不刪除」哲學以簡化設計，但最終會發現現實世界的需求——例如 GDPR 合規性或數據修正——使得實作複雜的刪除機制變得必要。

"the history of every append only database: * we will make it append only, the type of data makes sense for it and it will simplify the design * whoops, devs fucked something up and added a bunch of nonsense that have to be removed, let's figure out how to make at least occasional deletes work"

Integration and Alternatives

以家庭自動化為例，有些用戶建議，類似的輕量級 TSDB 架構可以解決 Home Assistant 等平台中看到的性能問題。對於需要更強大、企業級功能的使用者，則提到了 Clickhouse 或 DuckDB 等替代方案，儘管後者常因缺乏對排序或有序數據的原生理解而受到批評，這可能在時間序列查詢時導致讀取放大（read amplification）。

Conclusion

NanoTDB 是如何透過專注於特定數據模式——僅限追加的時間序列——來打造一個高效且極簡主義工具的一個引人注目的範例。雖然它是高攝取量工作負載的強大選擇，但開發者必須考慮數據的長期維護以及潛在的數據移除需求，這是僅限追加系統設計中的一個常見陷阱。