引言
如果你正在執行一個使用 SQLite 資料庫的 Rails 應用程式（生產環境），那麼很可能也在將 SQLite 用作快取資料庫。相較於 Redis 或 Memcached，SQLite 能夠提供更大的快取空間和更高的讀取效能，這兩點在快取處理中至關重要。此外，基於 SQLite 的快取功能還有一個重要優勢，那就是它能利用底層檔案系統（filesystem）或卷管理器（volume manager ）的特性，比如 transparent compression 功能。
本文將探討兩款基於 SQLite 的 Rails 快取儲存方案：Litecache（Litestack SQLite 資料元件庫的一部分）；以及 SolidCache（一種新的、基於 ActiveRecord 的 Rails 快取儲存方案，支援配置為使用 SQLite）。
Litecache
Litecache 是基於 Litestack 提供的抽象層構建在 SQLite 之上的，因此擁有一個經過精細調整的、直接的 SQLite 連線，能夠自動檢測並適應 thread/fiber 環境，並且具備良好的 fork resilience 能力（譯者注：在 Unix-like 系統中，程序可以透過 fork 操作建立子程序，而 Litecache 能夠在這樣的操作後保持穩定執行，不會因為程序分支而產生問題。）。
要將 Litecache 配置到 Rails 應用中，需要往 Gemfile 檔案裡新增以下這行程式碼：
gem “litestack”
接著執行以下命令：
bundle update
然後，在 environments/production 配置檔案裡，加入以下配置行：
config.cache_store = :litecache
此外，我們還可以選擇執行安裝程式來配置 litestack 的其他元件：
rails generate litestack:install
一旦上述配置步驟完成並正確設定，就可以在 Rails 應用程式中使用快取功能了。而且，這個快取功能將會透過 Litecache 來實現，而 Litecache 是利用 SQLite 作為其儲存機制的。
Solid Cache
Solid Cache 為 Rails 提供了一個基於 ActiveRecord 構建的快取儲存方案，因此它繼承了 ActiveRecord 的所有功能，比如支援多種資料庫系統（包括 PostgreSQL、SQLite、MySQL 和 MongoDB）。此外，它還提供了支援資料庫分片和使用主從資料庫架構所需的基礎設施。這些高階功能可以直接在 Solid Cache 中得以應用，對於大規模部署尤為有用。
要啟用 Solid Cache，首先需要將相應的 gem 新增到 Gemfile 中：
gem “solid_cache”
接著執行以下命令進行更新：
bundle update
需要確保已經為資料庫配置了 SQLite（可以透過 sqlite3 介面卡或 Litestack 的 Litedb 介面卡完成）：
production: adapter: sqlite3
接下來，為目標環境生成必要的資料庫遷移檔案：
RAILS_ENV=production rails solid_cache:install:migrations
然後，執行遷移命令：
RAILS_ENV=production rails db:migrate 在config/environments/production
配置檔案中，設定配置內容如下：
config.cache_store = :solid_cache_store
完成以上步驟後，就可以直接使用 Solid Cache 了。有關 Solid Cache 的更多資訊和更多配置選項，請參閱 github 上的 Solid Cache gem 頁面。
並非所有的 SQLite 快取方案都是一樣的
儘管 Litestack 和 Solid Cache 都採用了 SQLite，但它們在功能集合和效能表現上卻大相徑庭。是因為它們各自採用了不同的方式來抽象化處理底層的物理快取儲存，這些抽象層決定了它們如何與底層的物理儲存（在這個案例中是 SQLite）互動。抽象化的方式會影響到快取的效率、效能以及可用的功能。
Litecache，追求極致效率的直連策略
Litecache 儘可能以最高效的方式使用原始資料庫連線，儘量避免建立不必要的顯式事務（explicit transactions），並儘可能依賴預處理語句（prepared statements）來降低延遲。因此，Litecache 效能表現卓越，讀取快取的速度甚至比 Redis 和其他基於網路的解決方案還要快。
Solid Cache，站在巨人的肩膀上
如前文所述，Solid Cache 是在 ActiveRecord 的基礎上深度構建而成的。這使得它成為一個非常靈活的解決方案，可以將快取操作對映到可能非常複雜的分片、分散式和複製的資料庫設定中。然而，這種靈活性是以在快取操作和物理儲存之間增加多層抽象層為代價的。
可以這麼說，在生產環境中使用 SQLite 的應用程式，通常會被限制在單個伺服器上。這樣的應用程式需要採用複雜的快取設定，使用多個 SQLite 資料庫，以規模換取延遲的可能性非常小，甚至可以說是微乎其微。
效能基準比較
接下來，我們將對比Litecache與Solid Cache這兩種方案在不同資料負載下的讀寫操作表現。
所有基準測試均採用各庫的預設配置進行，但爲了提升Solid Cache中SQLite連線的讀寫效率，我們對相關引數進行了最佳化。具體調整的引數如下：
PRAGMA journal_mode = WAL; PRAGMA synchronous = 1; PRAGMA mmap_size = 134,217,728;
這些測試在一臺配置了AMD Ryzen 8740HS處理器的裝置上執行。
從結果中可以看出，Litecache的寫入速度顯著快於Solid Cache，最快時可達到後者速度的5倍。當然，在高併發測試環境下，兩種方案的表現都會有所影響，但Litecache由於操作更快，相較於需要長時間持有寫入鎖的Solid Cache，其出現寫入衝突的可能性會更低。
在執行讀取操作時，Litecache依舊保持著對Solid Cache的領先優勢，儘管這種優勢不像在寫入操作中那麼突出，但依舊顯著，最高可達3倍以上。隨著資料負載的增加，這一優勢有所下降，降至大約2倍。這一變化是可以理解的，因為隨著資料量的增加，ActiveRecord的額外開銷相對於大資料記錄的傳輸開銷而言，變得不再那麼突出。
總結
Litecache和Solid Cache均為基於SQLite的Rails應用程式提供了適用於生產環境的快取解決方案。由於設計理念的不同，Litecache在效能上顯著優於Solid Cache。儘管Solid Cache基於ActiveRecord帶來了眾多便利功能，但這些功能在採用SQLite進行生產的Rails應用中，其實用性並不高。
