sqlite之WAL模式

鏈接

1. 概述
   在3.7.0以后，WAL(Write-Ahead Log)模式可以使用，是另一種實現事務原子性的方法。
   
   • WAL的優點
     1. 在大多數情況下更快
     2. 並行性更高。因為讀操作和寫操作可以並行。
     3. 文件IO更加有序化，串行化（more sequential）
     4. 使用fsync()的次數更少，在fsync()調用時好時壞的機器上較為未定。
        
   • 缺點
     1. 一般情況下需要VFS支持共享內存模式。(shared-memory primitives)
     2. 操作數據庫文件的進程必須在同一台主機上，不能用在網絡操作系統。
     3. 持有多個數據庫文件的數據庫連接對於單個數據庫時原子的，對於全部數據庫是不原子的。
     4. 進入WAL模式以后不能修改page的size。
     5. 不能打開只讀的WAL數據庫(Read-Only Databases)，這進程必須有"-shm"文件的寫權限。
     6. 對於只進行讀操作，很少進行寫操作的數據庫，要慢那么1到2個百分點。
     7. 會有多余的"-wal"和"-shm"文件
     8. 需要開發者注意checkpointing

2. 原理
   
   回滾日志的方法是把為改變的數據庫文件內容寫入日志里，然后把改變后的內容直接寫到數據庫文件中去。在系統crash或掉電的情況下，日志里的內容被重新寫入數據庫文件中。日志文件被刪除，標志commit着一次commit的結束。
   
   WAL模式於此此相反。原始為改變的數據庫內容在數據庫文件中，對數據庫文件的修改被追加到單獨的WAL文件中。當一條記錄被追加到WAL文件后，標志着一次commit的結束。因此一次commit不必對數據庫文件進行操作，當正在進行寫操作時，可以同時進行讀操作。多個事務的內容可以追加到一個WAL文件的末尾。

   1. checkpoint
      最后WAL文件的內容必須更新到數據庫文件中。把WAL文件的內容更新到數據庫文件的過程叫做一次checkpoint。
      回滾日志的方法有兩種操作：讀和寫。WAL有三種操作，讀、寫和checkpoint。
      默認的，SQL會在WAL文件達到1000page時進行一次checkpoint。進行WAL的時機也可以由應用程序自己決定。
   2. 並發性
      當一個讀操作發生在WAL模式的數據庫上時，會首先找到WAL文件中最后一次提交，叫做"end mark"。每一個事務可以有自己的"end point"，但對於一個給定額事務來說，end mark是固定的。
      當讀取數據庫中的page時，SQLite會先從WAL文件中尋找有沒有對應的page，從找出離end mark最近的那一條記錄；如果找不到，那么就從數據庫文件中尋找對一個的page。為了避免每次事務都要掃描一遍WAL文件，SQLite在共享內存中維護了一個"wal-index"的數據結構，幫助快速定位page。
      寫數據庫只是把新內容加到WAL文件的末尾，和讀操作沒有關系。由於只有一個WAL文件，因此同時只能有一個寫操作。
      checkpoint操作可以和讀操作並行。但是如果checkpoint把一個page寫入數據庫文件，而且這個page超過了當前讀操作的end mark時，checkpoint必須停止。否則會把當前正在讀的部分覆蓋掉。下次checkpoint時，會從這個page開始往數據庫中拷貝數據。
      當寫操作時，會檢查WAL文件被拷貝到數據庫的進度。如果已經完全被拷貝到數據庫文件中，已經同步，並且沒有讀操作在使用WAL文件，那么會把WAL文件清空，從其實開始追加數據。保證WAL文件不會無限制增長。
   3. 性能
      寫操作是很快的，因為只需要進行一次寫操作，並且是順序的（不是隨機的，每次都寫到末尾）。而且，把數據刷到磁盤上是不必須的。（如果PRAGMA synchronous是FULL，每次commit要刷一次，否則不刷。）
      讀操作的性能有所下降，因為需要從WAL文件中查找內容，花費的時間和WAL文件的大小有關。wal-index可以縮短這個時間，但是也不能完全避免。因此需要保證WAL文件的不會太大。
      為了保護數據庫不被損壞，需要在把WAL文件寫入數據庫之前把WAL文件刷入磁盤；在重置WAL文件之前要把數據庫內容刷入數據庫文件。此外checkpoint需要查找操作。這些因素使得checkpoint比寫操作慢一些。
      默認策略是很多線程可以增長WAL文件。把WAL文件大小變得比1000page大的那個線程要負責進行checkpoint。會導致絕大部分讀寫操作都是很快的，隨機有一個寫操作非常慢。也可以禁用自動checkpoint的策略，定期在一個線程或進程中進行checkpoint操作。
      高效的寫操作希望WAL文件越大越好；高效的讀操作希望WAL文件越小越好。兩者存在一個tradeoff。
      

3. 激活和配置WAL模式
   PRAGMA journal_mode=WAL;，如果成功，會返回"wal"。

   1. 自動checkpoint
      可以手動checkpoint

      sqlite3_wal_checkpoint(sqlite3 *db, const char *zDb)
      

      配置checkpoint

      sqlite3_wal_autocheckpoint(sqlite3 *db, int N);
      

   2. Application-Initiated Checkpoints
      可以在任意一個可以進行寫操作的數據庫連接中調用sqlite3_wal_checkpoint_v2()或sqlite3_wal_checkpoint()。

   3. WAL模式的持久性
      當一個進程設置了WAL模式，關閉這個進程，重新打開這個數據庫，仍然是WAL模式。
      如果在一個數據庫連接中設置了WAL模式，那么這個數據庫的所有連接都將被設為WAL模式。

4. 只讀數據庫
   如果數據庫需要恢復，而你只有讀權限，沒有寫權限，那么你不能讀取這個數據庫，因為進行讀操作的第一步就是恢復數據庫。
   類似的，因為WAL模式下的數據庫進行讀操作時，需要類似數據庫恢復的操作，因此如果只有讀權限，也不能對打開數據庫。
   WAL的實現需要有一個基於WAL文件的哈希表在共享內存中。在Unix和Windows的VFS實現中，是基於MMap的。將共享內存映射到同目錄下的"-shm"文件中。因此即使是對WAL模式下的數據庫文件進行讀操作，也需要寫權限。
   為了把數據庫文件轉化為只讀的文件，需要先把這個數據庫的日志模式改為"delete".

5. 避免過大的WAL文件

6. WAL-index的共享內存實現
   在WAL發布之前，曾經嘗試過將wal-index映射到臨時目錄，如/dev/shm或/tmp。但是不同的用戶看到的目錄是不同的，所以此路不通。
   后來嘗試將wal-index映射到匿名的虛擬內存塊中，但是無法在不用的Unix版本中保持一致。
   最終決定采用將wal-index映射到同目錄下。這樣子會導致不必要的磁盤IO。但是問題不大，是因為wal-index很少超過32k，而且從不會調用sync操作。此外，最后一個數據庫連接關閉以后，這個文件會被刪除。
   如果這個數據庫只會被一個進程使用，那么可以使用heap memory而不是共享內存。

7. 不用共享內存實現WAL
   在3.7.4版本以后，只要SQLite的lock mode被設為EXCLUSIVE，那么即使共享內存不支持，也可以使用WAL模式。
   換句話說，如果只有一個進程使用SQLite，那么不用共享內存也可以使用WAL。
   此時，將lock mode改為normal是無效的，需要實現取消WAL模式。