服务结构具有 100 万个键的可靠字典性能

我正在使用包含约 100 万个键的可靠字典来评估 Service Fabric 的性能。我得到的结果相当令人失望，所以我想检查我的代码或我的期望是否错误。

我有一本初始化的字典dict = await _stateManager.GetOrAddAsync<IReliableDictionary2<string, string>>("test_"+id);

id每次测试运行都是唯一的。

我用一个字符串列表填充它，比如 “1-1-1-1-1-1-1-1-1”， “1-1-1-1-1-1-1-1-2”， “1-1-1-1-1-1-1-1-3”......多达 576,000 项。字典中的值没有被使用，我目前只使用“1”。

将所有项目添加到词典中大约需要 3 分钟。我必须一次将交易拆分为100,000，否则它似乎永远挂起（在需要之前，交易中的操作数量是否有限制）CommitAsync()?)

//take100_000 is the next 100_000 in the original list of 576,000
using (var tx = _stateManager.CreateTransaction())
{
    foreach (var tick in take100_000) {
        await dict.AddAsync(tx, tick, "1");
    }
    await tx.CommitAsync();
}

之后，我需要遍历字典来访问每个项目：

using (var tx = _stateManager.CreateTransaction())
{

    var enumerator = (await dict.CreateEnumerableAsync(tx)).GetAsyncEnumerator();

    try
    {
        while (await enumerator.MoveNextAsync(ct))
        {
            var tick = enumerator.Current.Key;                
            //do something with tick                    
        }
    }
    catch (Exception ex)
    {
        throw ex;
    }
}

这需要 16 秒。

我不太关心写入时间，我知道它必须被复制和持久化。但为什么要花这么长时间来阅读呢？ 576,000 个 17 个字符的字符串键在内存中不应超过 11.5mb，并且值只是单个字符并被忽略。 Reliable Collections 不是缓存在 RAM 中吗？迭代相同值的常规字典需要 13 毫秒。

然后我打电话ContainsKeyAsync空字典上 576,000 次（在 1 个事务中）。这花了 112 秒。在任何其他数据结构上尝试此操作可能需要大约 0 毫秒。

这是在本地 1 节点集群上。当部署到 Azure 时，我得到了类似的结果。

这些结果可信吗？我应该检查任何配置吗？我是否做错了什么，或者我的期望非常不准确？如果是这样，是否有更适合这些要求的东西？ （约 100 万个小键，无值，持续事务更新）

好吧，就其价值而言：

• 并非所有内容都存储在内存中。为了支持大型可靠集合，某些值会被缓存，其中一些值会驻留在磁盘上，这可能会在检索您请求的数据时导致额外的 I/O。我听说有传言说在某个时候我们可能有机会调整缓存策略，但我认为它还没有实施。

• 你一条一条的迭代读取数据记录。恕我直言，如果您尝试对任何数据源发出 50 万个单独的顺序查询，结果不会太乐观。我并不是说每个 MoveNext() 都会导致单独的 I/O 操作，但我想说的是，总的来说，它看起来不像是一次单独的提取。

• 这取决于你拥有的资源。例如，尝试使用单个分区和三个副本在我的本地计算机上重现您的案例，我平均在 5 秒内获得记录。

考虑解决方法时，想到的是：

• Chunking我尝试做同样的事情，将记录拆分为以 10 个元素为上限的字符串数组（IReliableDictionary）。所以本质上是相同数量的数据，但时间范围从 5 秒减少到 7 毫秒。我想如果您将项目保持在 80KB 以下，从而减少往返次数并保持 LOH 小，您应该会看到性能得到改善。

• 过滤 创建枚举异步 https://learn.microsoft.com/en-us/dotnet/api/microsoft.servicefabric.data.collections.ireliabledictionary-2.createenumerableasync?view=azure-dotnet#Microsoft_ServiceFabric_Data_Collections_IReliableDictionary_2_CreateEnumerableAsync_Microsoft_ServiceFabric_Data_ITransaction_System_Func__0_System_Boolean__Microsoft_ServiceFabric_Data_Collections_EnumerationMode_有一个重载，允许您指定委托以避免从磁盘中检索与过滤器不匹配的键的值。

• 状态串行器如果您超越简单的字符串，您可以开发自己的字符串串行器 https://learn.microsoft.com/en-us/dotnet/api/microsoft.servicefabric.data.ireliablestatemanager.tryaddstateserializer?view=azure-dotnet#Microsoft_ServiceFabric_Data_IReliableStateManager_TryAddStateSerializer__1_Microsoft_ServiceFabric_Data_IStateSerializer___0__并尝试减少针对您的类型产生的 I/O。

希望这是有道理的。