Hashbrown项目中的外部存储HashMap实现方案

背景介绍

在Rust生态系统中，hashbrown作为高性能的哈希表实现被广泛应用。近期hashbrown项目移除了raw_entry API，转而推荐使用entry_ref和Equivalent trait的组合方案。这一变化虽然提高了代码安全性，但也带来了一些特殊场景下的实现挑战。

问题场景

在arrow-rs项目中存在一个典型的使用场景：需要实现字符串的驻留(interning)功能，其中驻留字符串分配在连续缓冲区中。更一般化地说，这是一种常见的模式：在某个独立数据结构上建立索引，而不复制实际数据。

传统做法是维护一个记录列表(Vec)和多个基于不同键的HashMap，其中HashMap的值是记录在Vec中的索引。这种方法虽然可行，但会导致键数据的重复存储，在数据量大时可能成为性能瓶颈。

技术挑战

移除raw_entry API后，原先通过该API实现的"外部存储"模式变得难以实现。具体来说，原先可以利用raw_entry_mut在查询时动态提供哈希和相等性判断函数，从而避免将键数据存储在HashMap内部，而是引用外部存储的数据。

解决方案探索

hashbrown项目维护者指出，未来将在HashTable API中支持这种"仅存储控制缓冲区"的使用模式。但作为当前过渡方案，推荐借鉴indexmap的实现方式：

1. 使用HashTable作为底层存储
2. 手动提供哈希值和相等性判断方法
3. 通过索引关联外部数据

这种方案相比原始实现有几个优势：

• 类型安全性更好，避免误用
• 不需要存储冗余数据
• 可以支持多键查找

实现建议

对于类似arrow-rs的需求，可以采用以下实现策略：

1. 创建主数据存储结构（如Vec）
2. 为每个需要建立索引的键类型创建独立的HashTable
3. 在查询时通过闭包提供自定义的哈希和相等性判断
4. 存储索引值而非实际数据

这种模式特别适合以下场景：

• 需要基于同一数据集建立多个不同索引
• 键数据较大，需要避免重复存储
• 需要精确控制内存布局

未来展望

hashbrown项目计划进一步改进HashTable API，使其成为唯一的标准实现。开发者可以关注该API的演进，特别是对控制缓冲区单独使用场景的支持。对于现有项目，建议逐步迁移到新的HashTable API，以获得更好的性能和安全性。

总结

在hashbrown中实现外部存储的HashMap需要转变思维，从传统的键值存储模式转向索引+外部数据的模式。虽然API有所变化，但新的HashTable提供了更安全、更灵活的解决方案。理解这一模式对于实现高性能、内存高效的数据结构至关重要。