详细了解SQLITE　优缺点　性能测试

http://blog.sina.com.cn/s/blog_8cfbb9920100zetj.html

什么是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 OS X和一些商用Unix系统，比如Sun的Solaris,IBM的AIX，同样，它也可以工作在许多嵌入式操作系统下，比如QNX,VxWorks,Palm OS, 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性能对比测试

顶 0 踩

下面是对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 12288 KB of total L3 cache and 12 GB of DDR3 RAM at 1333 MHz

文件系统：测试脚本分别跑在两台机器上，其文件系统一台为ext3（磁盘为 SATA Hitachi HDS721050CLA362），一台为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 在性能上都遥遥领先，在随机读上面
Kyoto Cabinet 引擎稍快一些。

在几种不同策略下进行写操作测试

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 使用的是 Snappy , TreeDB 使用的是 LZO)，由于SQLite不支持压缩，所以这里的测试数据只是从上面的基本测试结果copy过来的。





LevelDB开启压缩比不开启压缩效率更高，而TreeDB则相反，这可能是由于TreeDB采用的压缩算法（LZO）与LevelDB采用的压缩算法（Snappy）相比计算代价更高。

E. 使用更大内存

将每个独立库的内存增大到128MB，对LevelDB来说，其中120MB用来做 write buffer，另外8MB用来做 cache（原来是2MB的 write buffer 和2MB的cache），对SQLite来说，我们不改变其page size，还是保持为1kb，但是我们增大其page数量从4k增加到128k，对TreeDB来说，我们同样不改变其page大小，也只是增大其 cache，从4MB增大到128MB。





SQLite 在采用了大内存后性能变化并不大，而 LevelDB 和 TreeDB 的随机写性能却有显著提高。LevelDB 在增大内存后性能提升的原因是其write buffer 更大，从而减少了创建的sorted file的次数。减少了磁盘IO。而 TreeDB 的性能提升原因是由于其数据库的更大部分被映射到内存中了。

在几种不同策略下进行读操作测试

A. 大的Cache空间

我们分配128MB给每个数据库，对LevelDB来说，我们分配8MB给 write buffer，120MB给cache，对另外两个数据库，由于它们不支持区分 write buffer 和cache，所以统一将 cache size设置成128MB。





从结果可以看到，增大Cache在数据库读性能上都有所提升，其中最为显著的是TreeDB，其随机读性能大幅提升。主要是由于有足够的内存使得其所有读操作都几乎是在内存中进行。

B. 无压缩的读操作

下面结果是我们对预先无压缩状态写入的100万条key为16字节、value为100字节的数据后进行的读性能测试。同样的 SQLite 由于不支持压缩，所以下面数据是直接从其基本测试上copy过来的。





结果可以看到，取消压缩对读取性能提升不是特别大，当然，如果你的数据都在内存中的话，执行解压操作也不会对性能造成太大影响。