检查800万条目的哈希映射是否包含元素

Question

我有一个包含约8亿个条目（字符串）的散列图。它实际上被序列化为一个我已经进入hashmap的文件。

现在我有另一个巨大的字符串列表，大小约为3500万。我需要逐个读取这些3500万个字符串并以特定的方式对它们进行格式化，这是一种单独的方法（这是一个非常轻的处理）。

然后我需要检查列表中一个字符串上的格式化结果是否已经存在于hashMap中。

在Java中执行此操作的最有效方法是什么？

Answer 1

您可以尝试使用

的Bloom过滤器

  

节省空间的概率数据结构，用于测试元素是否是集合的成员。假阳性检索结果是可能的，但假阴性不是;即查询返回“内部设置（可能是错误的）”或“绝对不设置”。

（引自wikipedia）

Google Guava提供an implementation in java。

Answer 2

如果必须将其存储在内存中，我首先要改进散列函数的开发方式。可以在article dzone

中找到有用的资源

如果您不关心维护排序结构所引入的可能延迟，那么更进一步的是使用另一个implementation Map接口

Answer 3

如果你的大型数据集已经在你正在从磁盘反序列化的哈希表中而你无法改变它，那么我怀疑你会做的比做一件明显的事情并检查哈希要好得多直接表。将大型哈希表转换为另一种格式可能比仅按原样在表上执行所有查找更加昂贵。 （大约3500万个固定时间操作，而不是至少8亿+3500万个恒定时间操作，另一个常数可能不会更好，可能更多取决于你想要使用的新格式。）

如果存储大型数据集的表已经是线程安全的，并且运行该程序的计算机有多个内核，则每个内核运行一个查找线程可能会获得加速，但即便如此由于协调开销以及每个单独操作相当便宜的事实，不会加快速度（或者实际上可能会减慢速度）。

您是否有能力更改大数据集的准备方式？例如，不是把它写成哈希集，你可以把它写成别的东西吗？你能改变默认的哈希函数吗？你知道关于你可以用来构建更便宜的哈希函数的字符串属性吗？它们会在输入文件中以特定顺序出现吗？这些类型的东西可能会被用来加快查找速度，但是天真方法的大幅加速可能依赖于更多地了解问题的具体细节。