作者丨 Trace

譯者丨明知山

策劃丨李冬梅

Trace 從一開始就使用 SQLite 將所有數據存儲在用戶設備上。這是一個非常不錯的選擇—— SQLite 高度可靠，并且多種編程語言都提供了廣泛支持。畢竟，它是全球部署最廣泛的數據庫之一。

Trace 是一款 macOS 時間追蹤應用，可以監控你在 Mac 上的時間使用情況。鑒于它的功能，Trace 需要處理大量的數據，因此是一款數據密集型應用。盡管 SQLite 表現不錯，但我們仍然面臨兩個關鍵挑戰：

• 隨著時間的推移，SQLite 數據庫文件體積會顯著增大。

• 隨著數據集的增長，聚合查詢響應速度開始變慢。

我們嘗試了許多優化 SQLite 的方法，最好發現了 DuckDB：一個類似于 SQLite 的可嵌入式數據庫系統，專為分析工作負載進行了優化。經過一段時間的測試，證明 DuckDB 比 SQLite 更適合我們的時間追蹤應用。

為什么選擇 DuckDB

我們需要一個能夠嵌入到應用中，同時又快速且可靠的數據庫系統。SQLite 和 DuckDB 都可以滿足這些要求，但我們發現 DuckDB 在執行分析查詢時比 SQLite 快 3 到 5 倍，而且隨著數據量的增加，這種優勢更加明顯。

我們最復雜的查詢涉及多個大表和視圖的連接，并且大量依賴聚合 SQL 函數。在這種工作負載下，DuckDB 在這方面超越了 SQLite 也就不足為奇了。

DuckDB 的文檔寫道：

DuckDB 是為支持分析查詢工作負載（即在線分析處理，OLAP）而設計的。 為了高效地支持這種工作負載，縮短每個單獨值所消耗的 CPU 時間至關重要。在數據管理領域，實現這一目標的最新技術是矢量化或即時查詢執行引擎。DuckDB 使用了列存儲矢量化查詢執行引擎。雖然查詢仍為解釋執行，但會一次性處理大量值（一個“向量”）。這大大降低了傳統系統（如 PostgreSQL、MySQL 或 SQLite）中逐行處理數據的開銷。矢量化查詢執行在 OLAP 查詢中表現出更好的性能。

SQLite 逐行處理數據，而 DuckDB 使用列存儲矢量化執行引擎，同時處理大量值。這種處理方式特別適合我們的分析工作負載。

ClickBench 基準測試顯示，在某些分析查詢中，DuckDB 的性能比 SQLite 快了多達 1200 倍。

盡管 DuckDB 在我們的工作流程中讀取性能顯著優于 SQLite，但在單行操作方面，它不如 SQLite。在我們的測試中，SQLite 在這些場景下比 DuckDB 快大約兩倍。

盡管如此，另一個促使我們選擇 DuckDB 的關鍵因素是它的自動磁盤壓縮功能，這個功能大大減少了存儲空間。

我們創建了一個張表，與我們應用中使用的表類似，包含了兩個時間戳列、一個主鍵整數 ID 和一個布爾列。插入 100 萬行數據后，SQLite 數據庫文件大小為 101.6MB，而 DuckDB 僅需 23.1MB，體積減少了 77%。

遷移過程

遷移過程并非一帆風順。SQLite 的編程語言生態系統支持比 DuckDB 要好得多。Trace 的大部分代碼是用 Rust 編寫的，我們使用 Diesel ORM 來處理數據庫交互。

DuckDB 也有自己的 Rust 包，即 duckdb-rs，但它并不是 ORM。因此，我們不得不重寫代碼庫的核心部分，并自己實現了一個數據庫遷移系統。

在重寫過程中，我們還遇到了 DuckDB 的一些并發限制。以前使用 SQLite 時，我們可以打開多個并發連接，對同一張數據庫表執行操作。而使用 DuckDB 時，這種情況會導致大量數據丟失——一個連接的數據會被保存，另一個連接的數據則完全丟失。解決這個問題并不難，我們只需要確保在任何給定時間只有一個線程可以修改一張表。

另外需要注意的是，將 DuckDB 包含在我們的應用中幾乎使應用包的體積翻倍，從 26MB 增加到 44MB。雖然體積變大了，但對我們來說絕對值得。

我們是否完全放棄了 SQLite

沒有。盡管 DuckDB 在分析工作負載方面表現出色，但我們仍然依賴 SQLite 來執行一些核心操作。SQLite 更適合處理頻繁的小事務，因為它輕量，對簡單查詢速度更快，并且更有效地支持并發連接。

總 結

自從遷移到 DuckDB 以來：

• 讀取查詢至少快了 3 到 5 倍（這也讓我們的儀表盤更快了）

• 數據庫文件占用的存儲空間減少了約 80%

• 應用包體積幾乎翻倍（從 26MB 增加到 44MB）

總體而言，我們對這次遷移非常滿意，并且期待繼續使用 DuckDB。

https://trytrace.app/blog/migrating-from-sqlite-to-duckdb/

聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。