总览

这是OpenHFT的SharedHashMap和流行的键值存储Redis之间的比较。

任何供应商都会告诉您他们的产品多么出色，因此，在我告诉您为什么它对于高性能应用程序来说是“必备”之前，我将首先概述为什么您不使用SharedHashMap。

为什么要使用Redis？

Redis是一个更成熟的数据库，使用相对广泛，包括：

  • 支持多种语言。
  • 通过TCP访问远程客户端。
  • 命令行管理工具。
  • 它执行许多其他键值存储。

为什么要使用OpenHFT的SharedHashMap？



您需要最大化Java性能。 在Java中，它的性能优于Redis和许多其他流行的键值存储。



为什么SharedHashMap可以执行Redis？



它从一开始就是为了性能而设计的，它尽可能地轻巧。



  • 它甚至可以跨多个进程充当嵌入式数据存储。 您无需为通过内核的TCP消息传递付出任何代价。
  • 它被设计为以无中断，无垃圾的方式在Java中使用。
  • 它是用Java编写的，用于Java。

但是C比Java快吗？



比较 ，则嵌入式数据存储要快得多。



有什么区别？



基准可以弯曲以适应任何论点。 供应商基准测试往往会为您提供最乐观的数字，因为他们知道自己产品的最佳性能。 键值存储的最简单基准是相同的，其中一个基准是从一个空的数据存储开始并设置许多小的键值，这至少为您提供了理想的理想选择。 您的用例可能会更慢，要求更复杂。

在具有128 GB内存的16核心服务器上设置数百万个键值。



雷迪斯

SharedHashMap

单螺纹

每秒更新约10K

每秒约3M次更新

多线程

每秒约10万次更新

每秒约30M次更新



这些数字是近似值，但它们是在同一台计算机上以Java（使用Jedis连接到Redis）进行相同操作的YMMWV

结论

准确而公正的基准是一个神话，但是它们确实可以准确地为您提供供应商对产品的看法。 OpenHFT对SharedHashMap的看法是，它是为Java设计的，并且以许多流行的键值存储无法匹配的方式执行。 如果需要最大程度地提高Java系统的效率，则应考虑使用OpenHFT的数据管理产品。