詳細了解SQLITE 優缺點 性能測試

什麼是SQLITE：

SQLite是一個開源免費的資料庫，一般用于嵌入系統或者小規模的應用軟體開發中，你可以像使用Access一樣使用它，你可以免費用于任何應用，包括商業應用，另外，它還支援各種平台和開發工具，這點是某些資料庫（比如Access、DBISAM）。

SQLite是一種嵌入式資料庫，它跟微軟的Access差不多，隻是一個.db格式的檔案。但是與Access不同的是，它不需要安裝任何軟體，非常輕巧。很多軟體都有用到這個家夥，包括騰訊QQ、迅雷(你在迅雷的安裝目錄裡可以看到有一個sqlite3.dll的檔案，就是它了)，以及現在大名鼎鼎的android等。SQlite3是它的第三個主要版本。就是SQLite3.0的意思。對了，金山詞霸也有用到SQLite，其實太多軟體用那玩意兒了。

sqlite的主要優點：

 　零配置(Zero Configuration)

SQlite3不用安裝，不用配置，不用啟動，關閉或者配置資料庫執行個體。當系統崩潰後不用做任何恢複操作，再下次使用資料庫的時候自動恢複。

　緊湊（compactness）：

　　SQLite是被設計成輕量級，自包含的。一個頭檔案，一個lib庫，你就可以使用關系資料庫了，不用任何啟動任何系統程序。一般來說，整個SQLITE庫小于225KB。

　可移植(Portability)

　它是運作在Windows,Linux,BSD,Mac OSX和一些商用Unix系統，比如Sun的Solaris,IBM的AIX，同樣，它也可以工作在許多嵌入式作業系統下，比如QNX,VxWorks,PalmOS, Symbin和Windows CE。

　　最大特點：采用無資料類型，是以可以儲存任何類型的資料，SQLite采用的是動态資料類型，會根據存入值自動判斷。SQLite具有以下五種資料類型：

1.NULL：空值。

2.INTEGER：帶符号的整型，具體取決有存入數字的範圍大小。

3.REAL：浮點數字，存儲為8-byte IEEE浮點數。

4.TEXT：字元串文本。

5.BLOB：二進制對象。

但同樣的，這樣的做法會導緻在插入和修改時，要花去更多的時間。

SQLITE的缺點：

１：SQLITE不可儲存過多的資料庫，它的性能發揮最好隻能在存放較小的資料量情況下。不要把它當做MYSQL甚至ORACLE來使用。它隻是一個200K的資料庫。

2：sqlite3不像MYSQL那樣使用固定日志檔案，所有使用insert、update、delete的運作效率隻是一般，sqlite3的一個事務，需要調用4次fsync()操作，而一般的大型資料庫，如mysql隻用到了2次。sqlite3對每個事務都建立一個臨時檔案來記錄日志，這個日志建立、更新和删除竟然使用了3次fsync()！為什麼不用一個固定的日志檔案呢？實在難以了解設計者的思路。可能他們把重點放在"Select" 性能上吧。通過閱讀sqlite3-3.5.1的源代碼，發現作者也試圖對這個問題進行修正，可能由于可靠性的原因，一直沒有正式公布。

操作資料庫有主要有三種途徑，

１.根據ANDROID的API編的相關程式

２.SQLITE指令符形式，WINDOWS,和LINUX下都可以。

３.第三方GUI管理程式。

LevelDB、TreeDB、SQLite3性能對比測試

下面是對LevelDB、TreeDB、SQLite3這幾個資料庫的性能對比測試，分别使用了LevelDB (revision 39) SQLite3 (version 3.7.6.3)及 Kyoto Cabinet’s (version 1.2.67)這三個版本的資料庫。

測試機器配置：six-core Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, with 12288KB of total L3 cache and 12 GB of DDR3 RAM at 1333 MHz

檔案系統：測試腳本分别跑在兩台機器上，其檔案系統一台為ext3（磁盤為 SATA HitachiHDS721050CLA362），一台為ext4（配備磁盤 SATA Samsung HD502HJ）

性能測試源碼：

LevelDB: db/db_bench.cc.

SQLite: doc/bench/db_bench_sqlite3.cc.

Kyoto TreeDB: doc/bench/db_bench_tree_db.cc.

基本測試的條件如下：

每個資料庫使用4GB記憶體

資料庫都處于異步寫模式(LevelDB’s sync option, TreeDB’s OAUTOSYNC option,SQLite3’s synchronous options 都關閉)，也就是說寫操作不用等資料真正寫到磁盤上才傳回。

Key 的長度為16位元組

Value 的長度為100位元組 (這個長度才能讓資料庫的壓縮算法能夠起作用，将資料壓縮至50％大小左右)

順序讀寫時Key值遞增變化

随機讀時生成随機的Key值

測試結果：

結果顯示，在順序讀寫和随機寫上，LevelDB 在性能上都遙遙領先，在随機讀上面 KyotoCabinet 引擎稍快一些。

LevelDB在Value較長時性能比較低，這是由于LevelDB對每一次寫操作都會至少進行兩次寫動作，一次是寫資料檔案，另一次是寫日志檔案。這裡慢的主要原因是LevelDB在進行這些操作時對值進行了過多的Copy。

一次寫操作寫1000條100位元組的資料，由于TreeDB不支援批量寫入，故未對其進行對比測試

上面結果是由于LevelDB資料的組織方式，導緻順序寫和随機寫在性能上都變化不大。

對 LevelDB, 設定 WriteOptions.sync = true.

對 TreeDB, 将 TreeDB’s OAUTOSYNC 選項開啟.

對 SQLite3, 設定 “PRAGMA synchronous = FULL”.

如果你看一下ext4檔案系統下的測試資料，你會發現ext3和ext4在表現上非常不同。

LevelDB 和 TreeDB 都支援相應的資料壓縮算法(LevelDB使用的是 Snappy , TreeDB 使用的是 LZO)，由于SQLite不支援壓縮，是以這裡的測試資料隻是從上面的基本測試結果copy過來的。

LevelDB開啟壓縮比不開啟壓縮效率更高，而TreeDB則相反，這可能是由于TreeDB采用的壓縮算法（LZO）與LevelDB采用的壓縮算法（Snappy）相比計算代價更高。

将每個獨立庫的記憶體增大到128MB，對LevelDB來說，其中120MB用來做 write buffer，另外8MB用來做cache（原來是2MB的 write buffer 和2MB的cache），對SQLite來說，我們不改變其pagesize，還是保持為1kb，但是我們增大其page數量從4k增加到128k，對TreeDB來說，我們同樣不改變其page大小，也隻是增大其cache，從4MB增大到128MB。

SQLite 在采用了大記憶體後性能變化并不大，而 LevelDB 和 TreeDB 的随機寫性能卻有顯著提高。LevelDB在增大記憶體後性能提升的原因是其write buffer 更大，進而減少了建立的sorted file的次數。減少了磁盤IO。而TreeDB 的性能提升原因是由于其資料庫的更大部分被映射到記憶體中了。

我們配置設定128MB給每個資料庫，對LevelDB來說，我們配置設定8MB給 writebuffer，120MB給cache，對另外兩個資料庫，由于它們不支援區分 write buffer 和cache，是以統一将cache size設定成128MB。

從結果可以看到，增大Cache在資料庫讀性能上都有所提升，其中最為顯著的是TreeDB，其随機讀性能大幅提升。主要是由于有足夠的記憶體使得其所有讀操作都幾乎是在記憶體中進行。

下面結果是我們對預先無壓縮狀态寫入的100萬條key為16位元組、value為100位元組的資料後進行的讀性能測試。同樣的SQLite 由于不支援壓縮，是以下面資料是直接從其基本測試上copy過來的。

結果可以看到，取消壓縮對讀取性能提升不是特别大，當然，如果你的資料都在記憶體中的話，執行解壓操作也不會對性能造成太大影響。