SQLite 是非常優秀的數據庫，能夠在真實的生產環境中完成一些真正的工作。本文將列出五個我認為在2016年應當選用 SQLite 的原因。
　　
　　便于管理
　　不知你是否管理過 Postgres 數據庫？想要確保數據庫服務器正確配置，需要了解不少東西，比如共享緩存、有效緩存大小、work mem、work mem 的維護以及 wal 緩存等等。此外升級的過程也很恐怖，使用者需要先將數據庫離線，運行程序來升級，然后祈禱在重新打開時能正常運作。另外，postgres 數據庫具體在哪里呢？你能否指著某個地方說：“那就是我的數據庫？”
　　雖然我們都知道，在很多情況下只有 Postgres（或 MySQL、Oracle、SQL Server 等）對應用的某些需求很有效果，不過這不是本文的討論范圍，本文只想強調管理 SQLite 數據庫與傳統數據庫服務器之間的區別。
　　SQLite 便于管理——只有單個文件（有時候是一個文件+事務日志），這個文件的格式在多個主要版本中都是通用的，也就是說如果我有一個3.0.0版本（2004年）的 SQLite 數據庫文件，便可以在最新的 SQLite 3.10.0上使用。如果想要在別處使用這個數據庫文件，也只需復制到U盤里，甚至存放到云存儲中。如果想要每天晚上進行備份，只需將此數據庫文件同步到 S3。如果想要與同事分享我的數據分析，也只需給他們發送一份數據庫文件備份即可。這個數據庫的一大特性就是只有單文件，且文件格式多年以來非常穩定。
　　此外，SQLite 配置起來也很簡單，其功能有兩種管理方式：編譯標識以及編譯指示語句（運行時配置）。沒有什么配置文件，只需使用想要的功能來構建相應的庫，然后在建立數據庫連接時配置運行時選項即可。
　　穩定性堅如磐石，且還在不斷提高
　　目前有一些優秀的大牛工程師正在積極地進行 SQLite 的開發，使得 SQLite 新增高質量新功能的速度十分驚人。就在最近，SQLite 還加入了 json1 擴展程序以支持 JSON 數據，想要了解如何在 Python 中使用它，請查看這篇文章。SQLite 還發布了一個全文搜索擴展包的改進版，其中包括使用 BM25 算法對結果進行排序。
　　除了新增功能之外，SQLite 的開發者也在努力改進 library 的性能，在3.8.11版本的發布說明中，包含這些宣傳內容：
　　新版本 SQLite，運行速度是3.8.0版本的兩倍，是3.3.9版本的三倍。
　　盡管一直在更新和改進，SQLite 卻很少有新增的 bug。SQLite 的測試套件公認是業內最好的測試套件之一，而“ SQLite 是如何測試的”相關文檔也被頻繁推薦到 HackerNews 上。
　　可擴展性與可控性
　　筆者最喜愛 SQLite 的地方是它的可擴展性，SQLite 是應用嵌入式的，它與應用運行在同一個地址空間中，并能代表你執行應用代碼。在 Python 標準庫中，無論是 SQLite 驅動的 pysqlite ，還是可選驅動 apsw 都為自定義 SQL 函數、聚合函數與排序規則提供了相應的 API；apsw 更進一步，為定義虛擬表和虛擬文件系統提供了相應的 API。
　　在實際案例中，假設表格中有一列用于存儲 URL，你還想確定最常見的主機名是哪些——如果使用不同的數據庫，就必須編寫復雜的正則表達式（字符串操作函數組），或者將數據從應用中抽出來，然后在代碼中進行計算。使用 SQLite 的話，就可以在 Python 中定義主機名，并使用它來創建簡單的 COUNT 查詢：
　　fromurlparse importurlparse defhostname（url）：returnurlparse（url）.netloc conn = sqlite3.connect（‘my-database.db’） conn.create_function（‘hostname’， 1， hostname） # name， num_params， func
　　SELECThostname（mytable.url）， COUNT（mytable.id） ASct FROMmytable GROUPBYhostname（mytable.url） ORDERBYct DESC;
　　還可以創建聚合函數，輸入0……n的值，生成單獨的輸出值。樣例可能包括：計算標準差、通過處理值來生成字符串、進行某種類型的分類等。
　　虛擬表目前僅受 apsw 支持，用戶可以在代碼中定義表格，并將其當作普通的 SQL 表格查詢，即便后臺數據是完全動態的。比如，我編寫了一個簡單的虛擬表格，允許用戶將其當作 SQL 表格來查詢 Redis。
　　你也可以編寫同名函數，返回0……n行結果，比如正則表達式：處理輸出內容，并生成一行行匹配 token。我寫了一個庫叫做 sqlite-vtfunc，用來編寫這類函數非常簡單。
　　實際上，SQLite 的各個方面都可以受應用的控制。
　　快如閃電
　　SQLite 速度非常快，它運行在同一臺機器上，因此在執行查詢或讀取結果時并不產生網絡開銷。由于與應用運行在同一個地址空間中，因此并無連接協議、序列或通過 unix socket 通訊的需求。SQLite 也可以在資源匱乏、要求高效率的移動設備上運行，并支持大量的編譯標記：允許用戶移除沒有計劃使用的功能。
　　SQLite 的速度彌補了它的最大缺點之一：寫入時數據庫文件鎖定。通過快速寫入數據，只有當有大量的并發寫入時，數據庫鎖定才會成為問題。
　　WAL模式
　　SQLite 的3.7.0發布版增加了新的日志記錄方法：使用預寫日志。單獨來看這個消息并不太吸引人，但對于 web 應用開發者來說（或者要應付并發問題的開發者來說），這意味著讀取并不會再阻礙寫入了，反之亦然。或者換句話說，讀取和寫入能夠并發進行。沒有 WAL 模式的話，想要寫入數據庫則要求寫入程序獨占數據庫的訪問權，在寫入完成前無法讀取。
　　下面是一個樣例，說明了兩者的不同。假設我們有兩個進程，一個寫入、一個讀取。寫入程序開啟了獨占事務（表明打算寫入）；讀取程序開啟事務；讀取程序嘗試發布SELECT語句：
　　Journal mode = “delete”（the default）： Writer： BEGIN EXCLUSIVE Reader： BEGIN Reader： SELECT* FROMfoo; Error： database islocked
　　Journal mode = “wal”： Writer： BEGINEXCLUSIVE Reader： BEGINReader： SELECT* FROMfoo;Returns table contents
　　然而值得注意的是：即使不啟用 WAL 模式，寫入通常在幾毫秒中發生。這個時間太短了，用戶只會在并發很高或者寫入事務用時很長時才會注意到這個問題。
　　額外的原因：BerkeleyDB
　　由于只需鎖定單獨頁面，而無需鎖定整個數據庫，集成了 SQLite 的 BerkeleyDB 可以給需求數據庫并發訪問的應用開發者有更好的體驗。而且這樣一來，BerkeleyDB 在并發數據庫負載的情況下也能更高效地擴展，使得各事務無需爭奪同一個頁面內的數據。
　　BerkeleyDB 還支持多版本并發控制（MVCC），使得讀取操作也可以繼續在寫入操作的同一個頁面進行。
　　另外，BerkeleyDB 還有一個優勢就是效率更高。換句話說，它使用的系統資源與調用系統都更少，可以參考這份白皮書及這個簡明技術概覽找到更多細節。
　　BerkeleyDB 的 SQL 接口是作為 SQLite 的簡易替代，所支持的API與功能是相同的。BerkeleyDB 還提供了一些額外的功能，比如復制（SQLite 有備份程序，但在我看來效果不如 BDB 的強大）、加密，當然還有 BerkeleyDB 自身的所有功能。
　　使用 BerkeleyDB 主要的缺點在于：它對配置數值非常敏感，而了解正確的頁面大小、緩存大小以及其他設置參數需要對相關知識有較深的了解。另一個缺點是證書問題：關于 BerkeleyDB 的證書問題請參考 Oracle 的證書頁面。
　　想要查看如何編譯 Python SQLite 驅動以使用 BerkeleyDB，請查看這篇文章。
　　總結
　　我希望你們嘗試一下 SQLite，別相信守舊者的說法：什么不適用于生產環境，或者不適合用在 web 應用中。
?

普通下載普通下載

相關電子資料下載