azure-service-fabric - 具有 100 万个键的 Service Fabric 可靠的字典性能

Question

我正在使用大约 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 万个小键，无值，持久事务更新)

Answer 1

好的，对于它的值(value):

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

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

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

考虑一种解决方法，这是我想到的:

分 block 我试图做同样的事情，将记录拆分为字符串数组，上限为 10 个元素(IReliableDictionary< 字符串，字符串 [] >)。所以本质上它是相同数量的数据，但时间范围从 5 秒减少到 7 毫秒。 我想如果您将项目保持在 80KB 以下，从而减少往返次数并保持 LOH 较小，您应该会看到性能有所提高。

筛选 CreateEnumerableAsync有一个重载，允许您指定一个委托(delegate)以避免从磁盘中检索与过滤器不匹配的键的值。

状态序列化器 如果您超越了简单的字符串，您可以开发自己的 Serializer并尝试减少针对您的类型产生的 I/O。

希望这是有道理的。