假设我正在设计一个将代码片段保存在 PostgreSQL/MySQL 数据库或文件系统中的工具。我想搜索这些片段。使用像 Sphinx 这样的搜索引擎似乎并不实用，因为我们在搜索代码时需要代码的精确文本匹配。
grep并且ack一直工作得很好，但是将内容存储在数据库中会使大量内容在某些方面更易于管理。我想知道在grep目录树上递归运行的相对性能与在具有 TEXT blob 的同等数量的记录上运行 SQL 的 LIKE 或 MySQL 的 REGEXP 函数之类的查询相比。
3648 次
4 回答
3
如果您有 1M 文件要通过 grep，您将（最好我知道）使用正则表达式遍历每个文件。
出于所有意图和目的，如果您使用 LIKE 运算符或正则表达式对表行进行大规模查询，您最终将对表行执行相同的操作。
我自己对 grep 的经验是，我很少寻找不包含至少一个完整单词的内容，因此您可以利用数据库来减少您正在搜索的集合。
MySQL 具有原生的全文搜索功能，但我建议不要这样做，因为它们意味着您没有使用 InnoDB。
您可以在此处阅读来自 Postgres 的内容：
http://www.postgresql.org/docs/current/static/textsearch.html
在 tsvector 列上创建索引后，您可以分两步执行“grep”，一个是立即查找可能含糊不清的行，然后是另一个根据您的真实条件的行：
select * from docs where tsvcol @@ :tsquery and (regexp at will);
这将比 grep 可以做的任何事情都要快得多。
于 2011-05-08T17:58:48.243 回答
1
我无法比较它们，但两者都需要很长时间。我的猜测是 grep 会更快。
但是 MySQL 支持全文索引和搜索，这将比 grep 更快——我又猜了。
另外，我不明白，Sphinx 或 Lucene 有什么问题。无论如何，这是MySQL、Sphinx 和 Lucene 的基准
于 2011-05-08T11:59:47.167 回答
0
互联网似乎猜测grep使用 Boyer-Moore，这将使查询时间加法（而不是乘法）取决于查询大小。不过，这并不重要。
我认为这是一次性搜索的最佳选择。但是在您的情况下，您可以做得更好，因为您有重复的搜索，您可以利用它的结构（例如，通过索引查询中的某些常见子字符串），正如 bpgergo 所暗示的那样。
另外我不确定您正在考虑使用的正则表达式引擎是否针对非特殊查询进行了优化，您可以尝试一下。
您可能希望将所有正在搜索的文件保存在内存中，以避免基于硬盘的减速。除非您搜索大量文本，否则这应该有效。
于 2011-05-08T12:22:47.430 回答
0
如果您想要代码的全文索引，我会推荐 Russ Cox 的代码搜索工具 https://code.google.com/p/codesearch/
这就是 Google 代码搜索的工作原理 http://swtch.com/~rsc/regexp/regexp4.html
于 2013-02-06T20:03:56.713 回答