Aerospike DB - 在高写入负载下适合大尺寸的列表/映射？

Question

概述

通过UDF的Aerospike列表/地图操作是写时复制（一次修改导致整个重写）。因此，随着列表/映射大小的增加，基于UDF的附加变得越来越昂贵。

按UDF列出操作，测试结果

Time required to append 100 values to a list (each append persisted to disk independently)
Time measured at the Java client
Each result is the average of 10 measurements.
Initial list size = 1      -> 19.6ms
Initial list size = 1000   -> 43.4ms
Initial list size = 10000  -> 237.3ms

问题

在高写入负载下，单个记录中的列表/映射是否可以建议（1000的值，总共约200kB）？

Answer 1

Aerospike服务器版本3.7.0增加了对使用客户端API直接操作列表的支持。检查您最喜欢的客户端语言的最新版本以获得支持（Java 3.1.8 +，Go 1.9.0 +，C 3.1.25+）。这种操纵地图的功能将随之而来。

通过本机API修改列表比通过UDF更有效。首先，不需要支付UDF执行的开销。如果数据在内存中，则列表将以非常有效的格式在内存中维护，以执行增量操作。它可以轻松地承受繁重的读/写负载，延迟更短。不过，您应该始终为您的工作量进行基准测试

Answer 2

可以通过本机客户端API 有效地操作单记录列表/地图。

问题中的测试结果是基于使用UDF，因为UDF会产生开销（并且可能无法在内存中进行本机修改？）。

在Ronen的建议之后，我更新了我的客户端/服务器以获取新列表API并使用com.aerospike.client.cdt.ListOperation编写了一个新测试。无论列表大小如何，新测试的结果都非常快。