sqlite之WAL模式_ZenDei技術網路在線

鏈接概述在3.7.0以後，WAL(Write-Ahead Log)模式可以使用，是另一種實現事務原子性的方法。WAL的優點在大多數情況下更快並行性更高。因為讀操作和寫操作可以並行。文件IO更加有序化，串列化（more sequential）使用fsync()的次數更少，在fsync()調用時好時壞的... ...

鏈接

概述
在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
原理

回滾日誌的方法是把為改變的資料庫文件內容寫入日誌里，然後把改變後的內容直接寫到資料庫文件中去。在系統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。
激活和配置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模式。
只讀資料庫
如果資料庫需要恢復，而你只有讀許可權，沒有寫許可權，那麼你不能讀取這個資料庫，因為進行讀操作的第一步就是恢複數據庫。
類似的，因為WAL模式下的資料庫進行讀操作時，需要類似資料庫恢復的操作，因此如果只有讀許可權，也不能對打開資料庫。
WAL的實現需要有一個基於WAL文件的哈希表在共用記憶體中。在Unix和Windows的VFS實現中，是基於MMap的。將共用記憶體映射到同目錄下的"-shm"文件中。因此即使是對WAL模式下的資料庫文件進行讀操作，也需要寫許可權。
為了把資料庫文件轉化為只讀的文件，需要先把這個資料庫的日誌模式改為"delete".
避免過大的WAL文件
WAL-index的共用記憶體實現
在WAL發佈之前，曾經嘗試過將wal-index映射到臨時目錄，如/dev/shm或/tmp。但是不同的用戶看到的目錄是不同的，所以此路不通。
後來嘗試將wal-index映射到匿名的虛擬記憶體塊中，但是無法在不用的Unix版本中保持一致。
最終決定採用將wal-index映射到同目錄下。這樣子會導致不必要的磁碟IO。但是問題不大，是因為wal-index很少超過32k，而且從不會調用sync操作。此外，最後一個資料庫連接關閉以後，這個文件會被刪除。
如果這個資料庫只會被一個進程使用，那麼可以使用heap memory而不是共用記憶體。
不用共用記憶體實現WAL
在3.7.4版本以後，只要SQLite的lock mode被設為EXCLUSIVE，那麼即使共用記憶體不支持，也可以使用WAL模式。
換句話說，如果只有一個進程使用SQLite，那麼不用共用記憶體也可以使用WAL。
此時，將lock mode改為normal是無效的，需要實現取消WAL模式。