这是我遇到的问题，我拥有一组可以快速增长的日志。每天将它们拆分成单独的文件，这些文件可以很容易地扩展到一个演出大小。为了缩小尺寸，清除了超过30天左右的条目。

问题是当我想在这些文件中搜索某个字符串时。目前，Boyer-Moore搜索的速度实在太慢了。我知道像dtSearch这样的应用程序可以使用索引提供真正快速的搜索，但是我不确定如何在不占用日志已占用空间两倍的情况下实现该功能。

有什么我可以检查出的资源可以吗？我真的在寻找一种标准算法，该算法将说明如何建立索引并使用它进行搜索。

编辑：
Grep无法使用，因为此搜索需要集成到跨平台应用程序中。我不可能将任何外部程序都包含进去。

它的工作方式是有一个带有日志浏览器的Web前端。这与自定义C ++ Web服务器后端有关。该服务器需要在合理的时间内搜索日志。目前，搜索几份原木需要很长时间。

编辑2：
其中一些建议很棒，但我必须重申，我不能集成另一个应用程序，它是合同的一部分。但是要回答一些问题，日志中的数据与接收到的特定于医疗保健格式的消息或者与此相关的消息有所不同。我希望依靠索引，因为重建索引可能需要一分钟的时间，但是搜索目前需要很长时间(我发现它需要花费2.5分钟的时间)。同样，很多数据在记录之前就被丢弃了。除非打开某些调试日志记录选项，否则将忽略一半以上的日志消息。

搜索基本上是这样的：向Web表单上的用户显示最新消息的列表(滚动时从磁盘流式传输，是Ajax)，通常，他们希望在其中搜索包含某些信息的消息。它，可能是患者ID或者他们发送的一些字符串，这样他们就可以将字符串输入搜索中。搜索被异步发送，并且自定义Web服务器一次一次线性搜索日志1MB，以获得某些结果。日志变大时，此过程可能需要很长时间。这就是我要优化的东西。

解决方案

grep通常对于大型日志(有时12G +)对我来说效果很好。我们也可以在此处找到适用于Windows的版本。

有关我们正在执行的搜索类型的更多详细信息肯定会有所帮助。为什么特别要依赖索引，因为当日志翻转时，我们每天都必须重建索引？这些日志中包含哪些信息？是否可以在记录之前就将其丢弃？

这些搜索现在需要多长时间？

我们很可能希望将某种类型的索引搜索引擎集成到应用程序中。那里有几十个地方，Lucene似乎很受欢迎。检查以下两个问题，以获取更多建议：

与自定义Web应用程序集成的最佳文本搜索引擎？

如何在网站中实现搜索功能？

Splunk非常适合搜索大量日志。可能出于目的而过分杀伤。我们根据要处理的数据量(日志大小)付款。我很确定他们有一个API，因此如果我们不想使用它们的前端，则不必使用它们。

查看Lucene用来完成其工作的算法。不过，它们不太可能很简单。我不得不一次研究其中一些算法，其中一些算法非常复杂。

如果我们可以在要索引的文本中识别"单词"，则只需构建单词的大型哈希表，即可将单词的哈希映射到每个文件中的出现。如果用户频繁重复相同的搜索，请缓存搜索结果。搜索完成后，我们可以检查每个位置以确认搜索词是否落在该位置，而不仅仅是带有匹配哈希值的单词。

另外，谁真正在乎索引是否大于文件本身？如果系统真的这么大，并且有这么多的活动，那么索引的几十个演出是否会结束？

我们可能想查看BSDgrep的源代码。我们可能无法依靠grep在那里，但是没有任何东西说我们不能重新创建类似的功能，对吗？