我们正在尝试找到一个支持索引的内存数据库，我们可以将其用于我们的应用程序。我们正在研究 Aerospike、Apache Ignite、Geode、Voltdb。没有什么可区分的，每个人都声称速度很快并且有很大的社区支持。
其中，Aerospike 和 VoltDB 是基于 C/C++ 的，Apache Ignite 和 Geode 是基于 java 的。
考虑到数据库之间在性能方面几乎没有选择，而且很难测试哪个数据库在生产中更适合我们，试图找出内存数据库的性能是否也取决于它是否是基于 java 还是基于 c/c++。考虑到垃圾收集问题非常频繁，并且很难针对您的用例进行适当的调整（一段时间后可能会发生变化），基于 java 的 dbs 是否确实处于劣势。
谢谢
您不能仅仅因为它是用 X 语言和 Y 语言编写的，就真的得出结论说一个 db 比另一个快。数据库是一个非常复杂的产品，具有许多特性。一个数据库中的某些查询可能更快，另一个数据库中的其他查询可能更快。
找出答案的唯一方法是测试您的特定用例。
我想我会成为逆向者。
在其他条件相同的情况下，编译后的代码比 JVM 更快，而且没有垃圾收集需要采用策略来避免。
eXtremeDB（我公司的产品）是用 C/C++ 编写的，能够完全避免使用 C 运行时内存管理。完全在数据库软件中管理内存区域可以使用高效且特定用途的内存管理器，并消除内存泄漏的可能性（从整个系统的角度来看，例如，如果为内存数据库留出 200GB , 它永远不会超过 200GB)。 eXtremeDB 在这方面并不是独一无二的；其他用 C/C++ 编写的内存 DBMS 也能够避免 C 运行时 malloc/free 或 C++ new/delete。所以请不要因为我做产品宣传而责备我，我不是。我指出了一个 C/C++ 实现可能的功能，而 JVM 可能不具备这种功能。
其他回答者是正确的：针对给定查询的 SQL 执行计划的糟糕实现可能会压倒编译代码与 JVM 的任何优势，但在某些时候，您必须确信您的 DBMS 供应商知道他们在做什么（如果计划明显低效/错误，他们有兴趣改进他们的产品）。如果您不使用 SQL，那么 SQL 优化器的优劣不是等式的一部分，这实际上取决于数据库系统的索引方法的编写情况，以及针对不同搜索需求的不同类型索引的可用性（例如，对于精确匹配查找，散列索引通常比 b 树更好，但散列索引不支持部分键（通配符）搜索或有序检索）。
您可以查看一些公开的（独立的、经过审计的）基准。我们参加了一些 STAC-M3，尽管只有一个其他 DBMS 也参加了（您具体列出的 DBMS 没有）。
对于像 Geode 一样保持一致性的内存数据库（即在释放客户端线程之前同步复制到其他节点），您的网络将比热点编译器更受关注。尽管如此，这里有两点输入可以让您达到语言无关紧要的地步：
1）如果您在读取上进行大量创建/更新：在服务器上使用堆外内存。这最大限度地减少了 GC。
2）使用Geode的C/C++和Java对象之间的序列化映射来避免JNI。具体来说，使用 DataSerializer http://gemfire.docs.pivotal.io/geode/developing/data_serialization/gemfire_data_serialization.html 如果您打算广泛使用查询而不是gets/puts，请使用PDXSerializer：http ://gemfire.docs .pivotal.io/geode/developing/data_serialization/use_pdx_serializer.html