使用哈希映射表示极大的数据源

Question

我有一个非常大的可能数据集，我试图立即可视化。集合本身由数十万个段组成，每个段都映射到一个id。

我收到了第二个数据源，为每个段提供了更多的实时信息，但是id与我的id不对应。

我将数据id（9个字符的字符串）的1：1映射到当前的id（长整数）。问题是有很多id，而且进来的数据没有特定的顺序。

我提出的解决方案是使用哈希映射将字符串映射到道路ID。问题是我不知道哈希映射是否足够有效以获得所有166k数据条目。

有没有人可以使用任何建议和/或哈希算法？

Answer 1

Judy Arrays是为这类事情而设计的：“Judy的主要优点是可扩展性，高性能和内存效率。[...] Judy可以取代许多常见的数据结构，例如数组，稀疏数组，哈希表，B树，二叉树，线性列表，跳过列表，其他排序和搜索算法以及计数功能。“

Answer 2

如果你只处理成千上万的数据点，那么采用天真的方式并坚持使用哈希映射可能不会有问题。

即使你有500,000个9个字符的字符串和相同数量的long s，每个项目仍然只有16个字节，或总共8,000,000个字节。即使你将开销增加一倍，16 MB也不会太大而无法在内存中使用。

基本上，首先尝试简单的方法，只有当你的分析告诉你它花了太长时间时才会担心它。

Answer 3

由于对问题的评论表明主要关注点可能是内存使用情况：

• 使用池或其他小型对象优化分配器;假设您有权访问boost，您可以在Pool找到替代版本。使用更好的小对象分配器可能是您将找到的单个最大内存获胜。
• 如果您知道字符串是固定宽度的，则可能需要确保仅分配足够的空间来存储它们。例如，使用自定义比较运算符缠绕固定长度char []的结构可能比std :: string更好。 std :: string附带一个额外的动态分配（并使用相应指针的空间）和一些额外的大小和容量跟踪开销。 （通常，尝试减少分配的数量，它会减少开销。）
• （假设STL）查看std :: map和std :: unordered_map之间的开销差异（后者可能会或者可能暂时不可用）; 基于RBtree的std :: map 可能与您的“hashmap”的查找性能特征足够接近，并且可能（或可能不）具有更高的内存效率，具体取决于您的标准库实现。

您采取的路径应该受到您可以收集的信息的影响 - 尝试获取分配数量和分配大小/对齐开销的图片。

你可以设置你的分配器或插入一些元素，看看你的做法与你认为你应该在内存使用方面的表现相比。

Answer 4

由于你的字符串是预先知道的并且具有固定的长度，理论上和实际上最好的解决方案是完美哈希。您可以使用cmph生成它。

根据维基百科，你的密钥需要2.5比特/密钥，或大约50KB。与价值664KB相比，这是可以忽略不计的。

Answer 5

虽然166k数据条目相当小IMO，但您可以查看google-sparsehash