在内存（RAM）中存储数百万/十亿条记录（假设记录包含名称和整数）的最佳数据结构是什么。 最佳 - 最短搜索时间（第一优先级）和内存效率（第二优先级）？是帕特里夏树吗？还有什么比这更好的吗？
搜索关键字是整数（例如32位随机整数）。并且所有记录都在RAM中（假设有足够的RAM可用）。
在C，平台Linux ..
基本上我的服务器程序为用户分配一个32位随机密钥，我想存储相应的用户记录，以便我能够以有效的方式搜索/删除记录。可以假设数据结构将很好地填充。
答案 0 :(得分：4)
取决于
您要搜索名称还是整数？
名称大小是否相同？
所有整数都是32位还是一些大数字？
你确定这一切都符合记忆吗？如果没有，那么你可能受到磁盘I / O的限制，而内存（或磁盘使用）则完全不再受到关注。
索引（名称或整数）是否具有公共前缀或是否均匀分布？只有它们有共同的前缀，patricia树才有用。
您是按顺序查找索引（帮派查找）还是随机查找？如果一切都是统一的，随机的并且没有共同的前缀，那么哈希就已经好了（这很糟糕）。
如果索引是使用帮派查找的整数，则可以查看基数树。
答案 1 :(得分：2)
我受过良好教育的猜测是B-Tree（但我可能错了......）：
B树有很多优点 当替代实施时 节点访问时间远远超过访问 节点内的时间。这通常 在大多数节点进入时发生 二级存储，如硬盘驱动器。 通过最大化孩子的数量 每个内部节点内的节点 树的高度减少， 平衡发生的次数较少，而且 效率提高。通常这个 设置每个节点所需的值 一个完整的磁盘块或类似的 二级存储中的大小。虽然2-3 B树可能在主要用途中很有用 记忆，当然更容易 解释，如果调整节点大小 到磁盘块的大小， 结果可能是257-513 B树 （尺寸与较大尺寸有关 权力2）。
答案 2 :(得分：0)
您可以至少使用基数来开始，而不是哈希。
对于任何特定问题，您可以比btree，哈希表或patricia trie做得更好。更好地描述问题，我们可以建议可行的方法
答案 3 :(得分：0)
如果您只想通过整数键进行检索，那么简单的哈希表就是最快的。如果整数是连续的（或几乎是连续的）且唯一的，则一个简单的数组（指向记录的指针）甚至更快。
如果使用哈希表，您希望为预期的最终大小预先分配哈希表，以便它不会重新散列。
答案 4 :(得分：0)
我们可以使用每个节点为1/0的特里来存储整数值。这样我们就可以确保树的深度为32/64，因此提取时间是恒定的，并且具有亚线性空间复杂度。