我正在寻找建议，因为我之前不必处理大文件解析，并且如果已经存在开源解决方案，我希望避免重新发明轮子。这是我的情况：
在我工作的实验室中，我通过自动化机器流程将大约200-300个大型XML和文本文件放在目录中。这种情况经常发生。这些文件的大小范围可以从几百MB到多GB。这些文件会定期修改（每周几次），其中旧文件只是被修改后的文件覆盖。
我需要能够搜索这些文件并提取符合特定条件的记录。在文件中的大约2千万到3千3百万条记录中（合并），我们实际上可能会使用＆lt;其中有100,000个，但在搜索之前我们无法分辨哪些。
我首先想到设置一种常规文件处理作业，该作业检测更新并将文件处理到可以搜索的数据库中。我唯一担心的是，随着记录越来越大，插入和更新记录的速度可能会越来越慢。
有没有人对可能更适合我情况的方法有任何建议？在我脑海中，我正在考虑一些像Lucene这样的文本搜索系统，但从未使用过它我不是肯定的，如果它比数据库更有用......
非常感谢任何帮助。
答案 0 :(得分：0)
有很多很多选择。 Lucene可能是一个很好的解决方案 - 或者是一个糟糕的选择。
答案是“这取决于......”
您没有提供项目环境或约束的许多细节。
特别是：什么是操作系统，什么是存储介质，最重要的是，您使用的是DB2或SQL Server等RDBMS吗？
例如，如果您的应用程序已经在使用DB2，为什么不利用它的内置XML和文本搜索功能呢？
答案 1 :(得分：0)
这取决于您的查询的具体程度。 Lucene和Xapian是编制索引的好例子。 一般来说，您应该查看索引方法，而不是数据挖掘（我将此问题重新考虑在内）。
常规数据库可能太慢，因为它需要确保ACID属性并优化在线更新。对于您的情况，批量更新可能就足够了。
所以从本质上讲，我建议看看Xapian或Lucene（我更喜欢xapian），并考虑使用它来构建数据索引。您可能不会将所有数据放入索引（以使其更易于管理），但实质上只是将交叉引用放入现有的XML文件中。
根据您的搜索查询的内容，更简单的方法可能会有所帮助。想一下存储key->filename,linenumber引用的大型低级btree。