一个被频繁提出的问题就是，Apache Cassandra和Apache Ignite之间的区别是什么，这很正常，因为这两个数据库有很多的共同之处，比如水平扩展性、高可用和持久化。在本系列的前四篇文章中，已经介绍了了架构以及从开发角度上的主要区别：

• Apache Cassandra和Apache Ignite: 架构简化思考
• Apache Cassandra和Apache Ignite：关系并置和分布式SQL
• Apache Cassandra和Apache Ignite：强一致和事务
• Apache Cassandra和Apache Ignite：通过Ignite增强Apache Cassandra

在对比Ignite和Cassandra时，还有一个无法回避的问题，现在也需要揭晓答案，问题很简单，就是两者的性能差异如何？从哪里可以得到性能测试结果？

自从Ignite完整支持内存存储之后，两者之间的测试就变得不再对等，因为Ignite可以在内存中持有TB甚至PB级的数据，而Cassandra的内存选项非常有限。但是，不管怎样，测试一下性能指标然后分享出来，还是有价值的。

环境和配置

下面快速浏览一下测试环境以及Ignite和Cassandra配置参数的细节，没什么特别的，这类文章都会有这样的内容。 常规参数

• 硬件：
  • CPU：2x Xeon E5-2609 v4 1.7GHz
  • RAM：96Gb
  • SSD：3x800Gb SSD RAID0 2.4Tb
  • 网络：10Gb/s
• 集群大小：3服务端节点，1客户端节点（应用）
• 测试框架：Yahoo! Cloud Serving Benchmark
• 数据大小：8000万条目/记录

Ignite参数

• 版本：Apache Ignite 2.4
• 内存配置：所有数据都同时存储在内存以及Ignite持久化中
• 缓存模式：ATOMIC
• 复制因子：1主1备
• 写同步模式：FULL_SYNC
• WAL刷新模式：LOG_ONLY

Cassandra参数

• 版本：3.11.1
• 键空间：2副本
• 写一致性：ALL
• 读一致性：ONE
• commitlog_sync：periodic（默认），10s
• JVM_OPTS="-Xm48g -Xmx48g -Xmn1600M -XX:+UseG1GC"
• key_cache_size_in_mb: 4096
• row_cache_size_in_mb: 32768
• caching = { 'rows_per_partition' : 'ALL' }
• bloom_filter_fp_chance = 0.01
• 读测试执行两次，对缓存进行预热

预期结果

首先，使用32个应用线程，模拟小负载访问Ignite和Cassandra，下图是最终的测试结果：

Y轴表示每秒操作数，X轴表示度量的操作类型，总而言之，这一轮测试告诉我们：

• 对于读负载，Ignite显著优于Cassandra（快3倍），对于混合负载（读+更新，快2倍），这很正常，因为Ignite在内存中有数据的完整副本；
• 对于密集的写负载（插入和更新），两者差不多，因为两者都需要将变更持久化到磁盘。

接下来，会使用256个应用线程并行地增加负载：

会发现，两者都发生了明显的变化：

• Ignite保持了在读负载和混合负载下的领先优势，平均快6倍；
• Cassandra在更新操作中领先，这是合理的，因为Cassandra列式存储在架构上对这些操作有利，所以本次测试在预期范围内对其进行了重现，而Ignite继承了大部分关系数据库的原则，比如对一致性和索引数据的处理。

Ignite还是Cassandra？

如果性能需求和严格的SLA影响最终决定，那么对于高负载情况下的写密集应用，Cassandra会是一个好的选择，而对于Ignite，在重度的读或者混合负载下，会有超预期的表现。

此外，作为整个系列的总结，公平地讲，虽然性能对决策有很大的影响，但是还有很多其他的因素需要考虑。比如，因为写密集型负载的性能而选择了Cassandra的，就放弃了分布式事务的强一致性、放弃了规范化架构、放弃了使用SQL进行查询的优势。同时，如果确实需要Ignite中超过Cassandra的功能（简化架构、强一致、并置处理和SQL、内存级性能），那么对于写密集负载考虑使用Ignite也是符合逻辑的，因为从测试结果来说，两者在中等规模写负载情况下，性能差不多。

最后，本文和测试完成于2018年3月15日，谁知道未来会怎么样呢？拭目以待吧。

本文译自社区Denis Magda的博客。