快速搜索不断增长的大型平面文件的最佳方法是什么？ [关闭]答案

【问题标题】：What is the best approach to quickly search through a large growing flat file? [closed]快速搜索不断增长的大型平面文件的最佳方法是什么？ [关闭]
【发布时间】：2013-02-11 01:30:19
【问题描述】：

我还没有交出详细信息，但我正准备用 Java 实现一个命令行搜索工具，用于搜索包含两个字段（docid、orgid）的文件。我了解到这个文件一开始很小，而且一直在变大。我需要能够传入 docid 并取回 orgid。

谁能告诉我 - 像我上面提到的那样搜索平面文件的最佳技术可能是什么？

目前，我们只处理文件中 50,000 行（超过两个月）的数据，但一旦系统到位，它会增长得更快。

似乎将其存储在可搜索的二进制系统中，但我不确定要从什么开始。

我可以将其转储到数据库中，但这似乎有点矫枉过正。另外要做到这一点，我必须在服务器上安装数据库，这会很困难。

【问题讨论】：

为什么会矫枉过正？
您会偶尔进行一次搜索，还是将其作为一项有望为多个查询提供快速答案的服务？如果 a) 看看您是否不能使用 grep、egrep 或 awk，在第二种情况下，请考虑数据库 - 因为这正是最初发明数据库的原因。
我认为提供更多细节会有所帮助。多久添加一次，添加多少？一天一次？一天几千块？连续，在白天每秒几次？像那样的东西。然后，一天有多少次搜索？ 10, 1000, 100000？是搜索单项还是组？它可能有多大？百万？数十亿？什么？
好的，谢谢。每月运行一次主应用程序，该应用程序将为每条记录附加 docid 和 orgid 到此文件（猜测约 25,000）。在此主应用程序运行后，我的应用程序。将回顾所有这些记录中的至少 1%，并需要根据 docid 找出 orgid 是什么。理想情况下，我希望这尽可能快。问题是，如果可以避免的话，我不想引入 3rd 方应用程序。就个人而言，我不喜欢这样的结果，但随着我了解更多，我会尝试做出更好的过程。 :-)
我要感谢大家的回答/cmets。我正在与另一位同事交谈，我们讨论了序列化和反序列化哈希图的过程。我原本以为 hashmap 不能处理大量元素，但现在我发现它可以了。我相信我可以在必要时管理序列化文件的大小。我可以在每个月运行后序列化不断增长的数据。然后将文件反序列化为哈希图，以便我可以搜索 orgid。感谢您推荐 h2 和 hsqldb。我对它们做了一些研究，如果我目前的想法不起作用，我可能会选择 hsqldb。

标签： java file search binary hashmap

【解决方案1】：

如果可能的话，我会从一开始就在某个数据库中插入数据（也许像 hsqldb 或 h2 这样的轻量级的东西。

您的数据的行为类似于 Map，所以也许像 mapdb 这样的东西会更好（但您必须确保您的架构不太可能改变）。

如果您仍然需要使用这个平面文件，也许 Grep 是最好的主意（它是搜索平面文件的最快工具）

【讨论】：

【解决方案2】：

好吧，根据 docid 和 orgid 的大小以及您可以使用的 ram 数量，您可以简单地使用哈希表。将所有内容读入哈希表，然后针对哈希表进行查询。当然，不知道您必须对该文件进行多少次查找，也不知道它必须运行的频率，以及它是否需要驻留在内存中。

其他选项（如前所述）是使用预置数据库。最有效的方法是将文件读入数据库并截断文件，以便后续读取不必重新读取现有记录。此外，您的文件仍然易于管理。当然，如果您尝试这样做，就会出现很多问题。例如：你可以截断文件吗？另一个进程是否期望该文件存在？当您尝试截断时如何管理竞争条件？等等

使用hsqldb 或h2 之类的东西会很棒，因为它们可以嵌入到您的应用程序中，您不必担心要独立安装它们。当然，您需要为它们提供一个持久化空间，否则它不会起到很大的帮助。

【讨论】：

好的，谢谢。我最终解决了服务器问题并使用了 hsqldb，谢谢您的建议。