如何加快对大量文本文件 (1TB) 的搜索

Mat*_*ins 15 database linux grep elasticsearch

我有一组包含匿名医疗数据(年龄、国家、症状、诊断等)的文本文件。这个数据至少可以追溯到 30 年前,所以你可以想象我有一个相当大的数据集。我总共有大约 20,000 个文本文件。1TB。

我将需要定期搜索这些文件以查找特定字符串(不是正则表达式)的出现。搜索这些数据的最快方法是什么?

我尝试使用 grep 并递归搜索目录,如下所示:

LC_ALL=C fgrep -r -i "searchTerm" /Folder/Containing/Files
Run Code Online (Sandbox Code Playgroud)

执行上述操作的唯一问题是搜索这些数据需要几个小时(有时是半天!)。

有没有更快的方法来搜索这些数据?此刻我对不同的方法持开放态度,例如数据库、elasticsearch 等。如果我沿着数据库路线走下去,我将有大约。10 亿条记录。

我唯一的要求是:

1) 搜索将在我的本地计算机上进行(双核 CPU 和 8GB RAM)

2)我将搜索字符串(不是正则表达式)。

3) 我需要查看所有出现的搜索字符串和它所在的文件。

Ami*_*wal 5

已经有很多答案了,我只想补充两点:

  1. 拥有如此庞大的数据(1 TB)和仅 8 GB 的内存对于任何方法来说都不够好,无论是使用 Lucene 或 Elasticsearch(内部使用 Lucene)还是一些 grep 命令(如果您想要更快的搜索),原因是非常简单地说,所有这些系统都将数据保存在最快的内存中,以便能够更快地提供服务,并且超过 8 GB(您应该为操作系统保留 25%,至少为其他应用程序保留另外 25-50%),您只剩下很少的 GB内存。
  2. 升级 SSD、增加系统上的 RAM 会有所帮助,但这非常麻烦,而且如果遇到性能问题,将很难对系统进行垂直扩展。

建议

  1. 我知道您已经提到您想在您的系统上执行此操作,但正如我所说,它不会带来任何真正的好处,您可能最终会浪费大量时间(基础设施和代码方面(各种答案中提到的许多方法) )),因此建议您采用我的另一个答案中提到的自上而下的方法来确定正确的容量。它将帮助您快速确定您选择的任何方法的正确容量。
  2. 关于实施方面,我建议使用 Elasticsearch(ES) 来实现,因为它非常容易设置和扩展,您甚至可以使用 AWS Elasticsearch,它也可以免费使用,稍后可以快速扩展,尽管我我不是 AWS ES 的忠实粉丝,它节省了大量设置时间,如果您对 ES 非常熟悉,您可以快速上手。

  3. 为了使搜索更快,您可以将文件拆分为多个字段(标题、正文、标签、作者等)并仅对重要字段建立索引,这将减少倒排索引的大小,并且如果您仅查找精确的字符串匹配(没有部分或全文搜索),那么您可以简单地使用keyword索引和搜索速度更快的字段。

  4. 我可以继续讨论为什么 Elasticsearch 很好以及如何优化它,但这不是关键,底线是任何搜索都需要大量的内存、CPU 和磁盘,任何一个成为瓶颈都会阻碍您的本地系统搜索和其他应用程序,因此建议您真正考虑在外部系统上执行此操作,Elasticsearch 确实因其对于分布式系统和当今最流行的开源搜索系统的意义而脱颖而出。