什么是SQLITE：
<wbr></wbr>
SQLite是一個開源免費的數據庫，一般用于嵌入系統或者小規模的應用軟件開發中，你可以像使用Access一樣使用它，你可以免費用于任何應用，包括商業應用，另外，它還支持各種平臺和開發工具，這點是某些數據庫（比如Access、DBISAM）。
SQLite是一種嵌入式數據庫，它跟微軟的Access差不多，只是一個.db格式的文件。但是與Access不同的是，它不需要安裝任何軟件，非常輕巧。很多軟件都有用到這個家伙，包括騰訊QQ、迅雷(你在迅雷的安裝目錄里可以看到有一個sqlite3.dll的文件，就是它了)，以及現在大名鼎鼎的android等。SQlite3是它的第三個主要版本。就是SQLite3.0的意思。對了，金山詞霸也有用到SQLite，其實太多軟件用那玩意兒了。
sqlite的主要優點：
<wbr></wbr>
<wbr><span style="font-size:18px"> 零配置(Zero Configuration)</span></wbr>
SQlite3不用安裝，不用配置，不用啟動，關閉或者配置數據庫實例。當系統崩潰后不用做任何恢復操作，再下次使用數據庫的時候自動恢復。
<wbr></wbr>
緊湊（compactness）：
SQLite是被設計成輕量級，自包含的。一個頭文件，一個lib庫，你就可以使用關系數據庫了，不用任何啟動任何系統進程。一般來說，整個SQLITE庫小于225KB。
<wbr></wbr>
可移植(Portability)
<wbr></wbr>
它是運行在Windows,Linux,BSD,Mac OSX和一些商用Unix系統，比如Sun的Solaris,IBM的AIX，同樣，它也可以工作在許多嵌入式操作系統下，比如QNX,VxWorks,PalmOS, Symbin和Windows CE。
<wbr></wbr>
最大特點：采用無數據類型，所以可以保存任何類型的數據，SQLite采用的是動態數據類型，會根據存入值自動判斷。SQLite具有以下五種數據類型：
1.NULL：空值。
2.INTEGER：帶符號的整型，具體取決有存入數字的范圍大小。
3.REAL：浮點數字，存儲為8-byte IEEE浮點數。
4.TEXT：字符串文本。
5.BLOB：二進制對象。
但同樣的，這樣的做法會導致在插入和修改時，要花去更多的時間。
<wbr></wbr>
<wbr></wbr>
SQLITE的缺點：
１：SQLITE不可儲存過多的數據庫，它的性能發揮最好只能在存放較小的數據量情況下。不要把它當做MYSQL甚至ORACLE來使用。它只是一個200K的數據庫。
<wbr></wbr>
2：sqlite3不像MYSQL那樣使用固定日志文件，所有使用insert、update、delete的運行效率只是一般，sqlite3的一個事務，需要調用4次fsync()操作，而一般的大型數據庫，如mysql只用到了2次。sqlite3對每個事務都創建一個臨時文件來記錄日志，這個日志創建、更新和刪除竟然使用了3次fsync()！為什么不用一個固定的日志文件呢？實在難以理解設計者的思路。可能他們把重點放在"Select" <wbr><span style="font-size:18px">性能上吧。通過閱讀sqlite3-3.5.1的源代碼，發現作者也試圖對這個問題進行修正，可能由于可靠性的原因，一直沒有正式公布。</span></wbr>
<wbr></wbr>
<wbr></wbr>
操作數據庫有主要有三種途徑，
１.根據ANDROID的API編的相關程序
２.SQLITE命令符形式，WINDOWS,和LINUX下都可以。
３.第三方GUI管理程序。
<wbr></wbr>
<wbr></wbr>
LevelDB、TreeDB、SQLite3性能對比測試
<wbr></wbr>
下面是對LevelDB、 TreeDB 、 SQLite 3這幾個數據庫的性能對比測試，分別使用了LevelDB (revision 39) SQLite3 (version 3.7.6.3)及 <wbr><span style="font-size:18px">Kyoto Cabinet’s (version 1.2.67)這三個版本的數據庫。</span></wbr>
測試機器配置：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 引擎稍快一些。
在幾種不同策略下進行寫操作測試
A. Values為長數據（數據長度為100,000字節）
LevelDB在Value較長時性能比較低，這是由于LevelDB對每一次寫操作都會至少進行兩次寫動作，一次是寫數據文件，另一次是寫日志文件。這里慢的主要原因是LevelDB在進行這些操作時對值進行了過多的Copy。
B. 批量寫操作
一次寫操作寫1000條100字節的數據，由于TreeDB不支持批量寫入，故未對其進行對比測試
上面結果是由于LevelDB數據的組織方式，導致順序寫和隨機寫在性能上都變化不大。
C. 同步進行寫操作
- 對 LevelDB, 設置 WriteOptions.sync = true.
- 對 TreeDB, 將 TreeDB’s OAUTOSYNC 選項開啟.
- 對 SQLite3, 設置 “PRAGMA synchronous = FULL”.
如果你看一下ext4文件系統下的測試數據，你會發現ext3和ext4在表現上非常不同。
D. 無壓縮的寫操作
LevelDB 和 TreeDB 都支持相應的數據壓縮算法(LevelDB使用的是 <wbr><span style="font-size:18px">Snappy , TreeDB 使用的是</span><wbr><span style="font-size:18px">LZO)，由于SQLite不支持壓縮，所以這里的測試數據只是從上面的基本測試結果copy過來的。</span></wbr></wbr>
LevelDB開啟壓縮比不開啟壓縮效率更高，而TreeDB則相反，這可能是由于TreeDB采用的壓縮算法（LZO）與LevelDB采用的壓縮算法（Snappy）相比計算代價更高。
E. 使用更大內存
將每個獨立庫的內存增大到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 的性能提升原因是由于其數據庫的更大部分被映射到內存中了。
在幾種不同策略下進行讀操作測試
A. 大的Cache空間
我們分配128MB給每個數據庫，對LevelDB來說，我們分配8MB給 writebuffer，120MB給cache，對另外兩個數據庫，由于它們不支持區分 write buffer 和cache，所以統一將cache size設置成128MB。
從結果可以看到，增大Cache在數據庫讀性能上都有所提升，其中最為顯著的是TreeDB，其隨機讀性能大幅提升。主要是由于有足夠的內存使得其所有讀操作都幾乎是在內存中進行。
B. 無壓縮的讀操作
下面結果是我們對預先無壓縮狀態寫入的100萬條key為16字節、value為100字節的數據后進行的讀性能測試。同樣的SQLite 由于不支持壓縮，所以下面數據是直接從其基本測試上copy過來的。
結果可以看到，取消壓縮對讀取性能提升不是特別大，當然，如果你的數據都在內存中的話，執行解壓操作也不會對性能造成太大影響。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
