替换 .net 字典

Question

给定（简化描述）

我们的一项服务在内存中有很多实例。大约 85% 是独一无二的。 我们需要对这些项目非常快速的基于键的访问，因为它们在单个堆栈/调用中经常被查询。这个单一上下文的性能得到了极大的优化。

所以我们开始将它们放入字典中。表现还可以。

在这种情况下，尽可能快地访问项目是最重要的。保证读的时候没有写操作。

问题

与此同时，我们达到了字典可以存储的项目数量的限制。

Die Arraydimensionen haben den unterstützten Bereich überschritten. 
  bei System.Collections.Generic.Dictionary`2.Resize(Int32 newSize, Boolean forceNewHashCodes)
  bei System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)

翻译成The array dimensions have exceeded the supported range。

在这种特定情况下，像 Memcached 这样的解决方案太慢了。它是一个封装在单个服务中的孤立的非常具体的用例

因此，我们正在寻找针对这种特定场景的字典替代品。

目前我找不到支持这一点的人。我错过了什么吗？有人可以指点我吗？

作为替代方案，如果不存在，我们正在考虑自行实施。

我们考虑了两种可能性。从头开始构建或包装多个字典。

包装多个字典

当搜索一个项目时，我们可以查看键 HasCode 并使用它的起始编号作为包装器字典列表的索引。虽然这似乎很容易，但我觉得这很容易，这意味着哈希码被计算了两次（一次由我们计算一次，一次由内部字典计算）（这种情况真的对性能至关重要）。

我知道像字典一样交换基本类型是绝对最后的可能性，我想避免它。但目前似乎没有办法让对象更加独特，或者从数据库中获取字典的性能，或者在其他地方保存性能。

我也知道“注意优化”，但较低的性能会严重影响其背后的业务需求。

Answer 1

在我读完你的问题之前，我想到了简单的多字典。但是你已经知道这个解决方案了。我假设您确实达到了字典中的最大项目数，而不是任何其他限制。

我会说去吧。我认为您不应该担心计算哈希值两次。如果它们的键有点长并且获取哈希确实是一个耗时的操作（我对此表示怀疑，但不能确定，因为您没有提到键是什么），您不需要为您的哈希函数使用整个键.只需拿起您可以在自己的散列中处理的任何部分，然后根据它分发项目。

您唯一需要确保的是在您的多个词典中均匀分布项目。实现这一目标的难度实际上取决于您的密钥是什么。如果它们是完全随机数，您可以只使用第一个字节就可以了（除非您需要超过 256 个字典）。如果它们不是随机数，您必须考虑其域中的分布，并以实现均匀分布目标的方式编写您的第一个哈希函数。

Answer 2

我查看了 .Net Dictionary 的实现，看来您应该能够在字典中存储 2^32 个值。 （在存储桶列表旁边，它们本身就是链表，有一个存储所有项目的数组，可能是为了快速迭代，这可能是限制因素）。

如果您没有添加 2^32 个值，则可能是存储桶中的项目存在限制（它是一个链表，因此可能限制为最大堆栈帧大小）。在这种情况下，您应该仔细检查您的散列函数是否将项目均匀地分布在字典中。有关更多信息，请参阅此答案What is the best algorithm for an overridden System.Object.GetHashCode?