概述

Sqlite是一个很优秀的数据库,不仅体积小,多平台支持,而且数据库具有单个文件,方便在不同平台上快速部署等很多优势。

关于Sqlite的性能,总是最具有争议的地方。不过之前也在网上看到过有人把sqlite和Mysql做过对比,然后呢,在配置相似的情况下得出的结果是sqlite和mysql的IO性能实际上相差无几。

得到这样的结论也不难想象,因为sqlite和mysql都是基于文件的数据库,IO性能最终还要受到磁盘的IO速度的限制。因此,在mysql没有使用各种加速引擎的情况下,两者的性能的确不相上下。

在之前的一片文章中提到,给sqlite的字段增加索引可以大大提高查找的速度。今天这里再引入另外一个方法,就是使用Sqlite自带的全文分词索引。

这里说的全文分词索引并不是指给sqlite的某个表上的某个列建立索引(index),而是指类似与谷歌、百度、微软bing 类似的搜索引擎的“全文分词索引”(full-text index),虽然它们使用了相似的技术,但它们本身是完全不同的东西。

测试

Sqlite官方文档(http://www.sqlite.org/fts3.html)就描述了使用Sqlite自带的FTS3 和 FTS4 虚拟表模型来进行全文分词检索的方法。并且举了一个例子,在一个具有50万左右条目的表中来对比全文索引和普通表的like搜索法的对比:

首先是建立两个表:地一个是虚拟表,第二个是普通的表

CREATE VIRTUAL TABLE en1 USING fts3(content TEXT); /* FTS3 table */
CREATE TABLE en2(content TEXT); /* Ordinary table */

第二步,这时候这个数据库中已经有了超过50万的数据条目

然后分别从两个表中匹配相同的数据

SELECT count(*) FROM en1 WHERE content MATCH 'linux'; /* 0.03 seconds */
SELECT count(*) FROM en2 WHERE content LIKE '%linux%'; /* 22.5 seconds */

结果

结果是,使用了虚拟表的全文检索用了0.03s,而普通的表则用了22.5秒。性能差了将近一千倍。

但是值得注意的一个结果是使用Match 语句匹配出来的结果和使用like ‘%%’ 匹配出的结果完全不同,很典型的匹配结果是,like语句可以匹配出像”linuxophobe” 或 “EnterpriseLinux”这样的结果,而使用match 语句只能匹配出包含 linux 这样单词的结果。

但是在数据量很大的时候,检索的速度反而更加重要。

提高数据库查询的速度的方法有很多种,本文介绍的全文检索只是一种思路。更加复杂的系统必须使用更加独立的方法实现全文检索。