编年史地图vs Redis vs Koloboke

Question

我们有一个在50台服务器上使用相同数据集（键值对）的系统。对该数据集的更新数量约为每小时1000次，并且必须在这50台服务器上复制。我们有一个主系统接收这些更新，并负责将这些更新传播到其他服务器。目前，我们每小时以文件的形式将整个数据集（而不是增量更新）同步到所有服务器。然后将这些数据加载到不可变的Koloboke映射中。每个服务器每秒处理大约25000个请求，每个请求对这个映射进行30次查找。在这些服务器上接收的请求的平均响应延迟最大约为3毫秒，因此内存中的koloboke映射可以很好地维护这个响应时间。

但是，当前跨服务器同步此数据的系统会导致以下问题：

Redis：Redis支持复制和持久化。然而，在使用它的基准测试实用程序时，我发现它所能支持的查找数量仅略高于我们的平均用例（0.8-110万请求vs.75万，即我们每秒的查找数量）。此外，对redis的呼叫将通过网络进行，这将损害我们平均3ms的响应时间。

Chronicle Maps：在进一步研究这个问题时，我发现Chronicle Maps支持复制、持久化，并且每秒可以处理多达3000万个请求。乍一看，这似乎是一个很好的选择，但后来我发现它们不能很好地与多拍档一起工作，我们在应用程序中生成它们。此外，它们在堆外存储数据，因此数据反序列化的代价会导致性能下降。

Koloboke：它的性能很好，适合我们的用例，但不支持复制和持久性。

Answer 1

这个用例可以在Aerospike中轻松处理。Aerospike可以配置为运行这些服务器的方式。当您对服务器集群进行任何一次更新时，Aerospike将为您更新所有服务器。乍一看，你的阅读延迟要求对Aerospike也是合理的。此外，Aerospike可以为您提供来自RAM的数据，并同时存储在固态硬盘或HDD上，以便持久化。好像是为塞穗器量身定做的案子。您可以使用Aerospike社区版免费运行概念验证。或者如果你想做一个3个月的企业版试用许可证，并有Aerospike解决方案架构团队帮助你，联系Aerospike销售。要成功地执行此操作，必须正确地为数据容量和数据延迟设置Aerospike群集。如果配置错误，您可能会立即放弃对您有效的解决方案。