假设我正在设计一个工具,可以将代码片段保存在PostgreSQL/MySQL数据库或文件系统中。我想通过这些片段进行搜索。使用像Sphinx这样的搜索引擎似乎不实际,因为我们需要在搜索代码时进行精确文本匹配。
grep
和ack
一直表现出色,但是在数据库中存储东西在某些方面使大量内容更易管理。我想知道递归运行grep
在目录树上与在等价数量的记录上运行类似SQL的LIKE或MySQL的REGEXP函数的查询相比,其相对性能如何。
假设我正在设计一个工具,可以将代码片段保存在PostgreSQL/MySQL数据库或文件系统中。我想通过这些片段进行搜索。使用像Sphinx这样的搜索引擎似乎不实际,因为我们需要在搜索代码时进行精确文本匹配。
grep
和ack
一直表现出色,但是在数据库中存储东西在某些方面使大量内容更易管理。我想知道递归运行grep
在目录树上与在等价数量的记录上运行类似SQL的LIKE或MySQL的REGEXP函数的查询相比,其相对性能如何。
select * from docs where tsvcol @@ :tsquery and (regexp at will);
这将比grep能做的任何事情都快得多。
我无法比较它们,但两者都需要很长时间。我猜grep会更快。
但是MySQL支持全文索引和搜索,这将比grep更快--我再次猜测。
此外,我不明白Sphinx或Lucene的问题在哪里。无论如何,这里有一个MySQL、Sphinx和Lucene的基准测试
互联网似乎猜测grep
使用Boyer-Moore算法,这将使查询时间取决于查询大小的加性(而不是乘性)。但这并不那么相关。
我认为对于一次性搜索来说,它已经接近最优了。但在您的情况下,由于您有重复的搜索,因此可以利用其结构(例如通过索引查询中某些常见子字符串),正如bpgergo所暗示的那样,您可以做得更好。
此外,我不确定您考虑使用的正则表达式引擎是否针对非特殊查询进行了优化,您可以尝试并查看结果。
您可能希望将所有要搜索的文件保存在内存中,以避免基于硬盘的减速。除非您正在搜索大量文本,否则这应该有效。
LIKE
和MATCH AGAINST
)。详情请见:http://dev.mysql.com/doc/refman/5.5/en/index-btree-hash.html。如果您使用`LIKE '%string%'`并且字符串长度大于三个字符,MySQL将使用Turbo Boyer-Moore算法来初始化该字符串的模式,然后使用该模式更快地执行搜索。 - Johan
match against
吗?参见:http://dev.mysql.com/doc/refman/5.5/en/fulltext-search.html - Johan