Apache Cassandra应用广泛，是一个开源的、分布式的、键值存储列模式NoSQL数据库，支撑了很多大公司的关键业务，比如Netflix、eBay以及Expedia，对于Cassandra的用户来说，如果他对Cassandra很满意，但是又需要高级的SQL查询功能，那么Ignite对于Cassandra来说，是一个增强，如果他对Cassandra的速度不满意，或者希望在分布式键值存储数据库中执行SQL，那么Ignite会是Cassandra的一个强有力替代者。
Cassandra的优势和限制
Cassandra的优势包括：
- 全分布式、对等架构：Cassandra无单点故障，因此适用于高可用场景。它支持多数据中心复制，比如，可以将数据存储于多个AWS可用区域中，以获得更大的弹性；
- 大规模和线性扩展：在任意数据中心的任意Cassandra集群中，可以添加/删除任意数量的节点，使得用户可以可靠地存储不断增长的结构化和非结构化数据；
- 柔性建模：Cassandra的分布式系统技术来源于亚马逊的Dynamo键值存储以及Google的BigTable列数据模型，使其可以对相对于传统关系型数据库更复杂的数据结构进行建模；
- 可调一致性：用户可以配置复制来平衡速度和可靠性；
- 开源社区：Cassandra用户受益于一个庞大而活跃的社区，社区对Cassandra进行持续地改进，并且通过一些网站提供技术支持。
Cassandra的常规用途包括从应用日志和传感器获得大量数据，然后进行存储和分析，还有就是高可用地存储键值数据，这对于面向Web的应用，或者IT监控非常有用，他们需要对大量数据进行高速的统计。
虽然强大，但是Cassandra也有一些限制：
- 基于磁盘，因此限制了某些操作的速度，因为需要对磁盘进行读写；
- 不支持ANSI-99 SQL，因此无法执行特定的SQL查询；
- Cassandra是最终一致的，因此事务数据可能丢失，这对于事务敏感的应用来说，是个挑战。
Cassandra和Ignite一起使用的好处
在已有的数据层和应用层之间，Ignite可以充当一个内存计算层，在Cassandra和已有的应用层之间，可以插入一个Ignite集群，这样在Ignite集群保持的数据中可以提供ANSI-99 SQL支持以及ACID事务支持。
SQL查询
Ignite包含了一个兼容ANSI-99 SQL的引擎，它可以在Ignite集群持有的数据中，执行SQL以及对数据进行索引，使用Ignite的ODBC/JDBC API，可以向Ignite发送标准的SQL命令，对于Ignite持有的Cassandra数据，也可以执行SQL查询，从而为Cassandra中存储的数据提供高性能和高灵活性的SQL支持。
ACID事务
Ignite为分布式事务提供了用户可定义的事务保证，可以从最终一致调整为强一致，Ignite会将任何变化写入内存数据集以及后面的Cassandra，保证两者间的数据一致性。
数据无需重建模
加入Ignite，不需要修改Cassandra中已有的数据，和处理传统关系型数据库一样，Ignite可以从Cassandra及其他的NoSQL数据库中读取数据。也不需要修改模型，这些都会被直接迁移到Ignite中。
Ignite不需要推倒重来，因此如果希望从关系型数据库迁移到Cassandra，这会是一个捷径，因为无需为了匹配Cassandra的约束而对数据重新建模。为了解决移植需要对数据重新建模的问题，可以在关系型数据库上使用Ignite，然后将编程接口切换为Ignite，然后将关系型数据库移植到Cassandra，通过Ignite，应用无法感知到前后有什么不同。
Ignite可以很好地与NoSQL、RDBMS以及Hadoop存储协同，因此Ignite可以用于对它们进行加速和扩展。Ignite也可以与Spark一起工作，Ignite文件系统还可以用于将弹性分布式数据集（RDD）或者DataFrames移入内存，使SparkRDD可变，并且可以在多个Spark作业间共享状态。
成熟的代码库
虽然Ignite对于Apache基金会（ASF）来说非常新，但是它有一个很成熟的代码库。它以前在2007年时，是一个私有的项目，在2014年捐赠给ASF。然后一年后毕业成为ASF的顶级项目，毕业速度在Apache项目中第二快（在Spark之后）。Ignite有一个活跃的全球社区，有超过100万行代码，有健壮的特性集。
方案集成
从架构上来说，Ignite与Cassandra的集成是非常简单的。Cassandra的用户，通常来说需要对Cassandra集群进行读写（可能使用Kafka或者其他的客户端）。Ignite会嵌入应用和Cassandra之间，使用Ignite的Cassandra连接器进行集成。应用以后就不需要对Cassandra进行读写，而是对Ignite进行读写，因此他就会访问内存而不是磁盘中的数据，而Ignite会对Cassandra进行读写。
单一的选择可能更好
虽然将Ignite和Cassandra整合可以创建一个强大的方案，但是对于某些场景来说，未必是最佳的。比如，对于新的应用来说，需要执行SQL查询的功能，Ignite包含了一个内存数据库，它可以作为一个独立的、分布式的内存RDBMS，支持ACID事务以及ANSI-99 SQL，包括DML和DDL。兼容ANSI-99的SQL引擎支持带索引的内存级SQL，可以以内存计算的速度执行SQL查询。Ignite还支持ACID事务的强一致，可以满足对事务有强需求的应用。
对于受限于Cassandra的SQL能力和最终一致性的用户，会发现迁移到Ignite（而不是添加）后有了他们需要的数据库功能和内存级的性能，而只需要维护一个简单的应用/数据库两层架构。
对于读密集型应用来说，Ignite会比Cassandra快3-6倍，而Cassandra会有更好的写入性能。因此如果一个应用写入负载很重，而对SQL查询以及ACID事务要求不高，那么Cassandra仍然是独立方案的最佳选择。然而，对于任何需要高速读或者混合性能的关键应用，独立的Ignite部署会是最佳选择。
下一步
对于正在使用或者考虑使用Cassandra的用户，面对当前的面向Web的应用，也会关心极限OLTP和OLAP负载下的性能需求，应该考虑利用Ignite内存计算平台的优势，将两个方案结合，会使应用在内存中而不是磁盘上访问数据，这是一个比磁盘快1000倍的方法。在Cassandra之上加入Ignite，在维持Cassandra的高可用和水平扩展之外，还提供了其他的好处，包括更灵活的兼容ANSI-99的SQL查询，以及更健壮的一致性，这些都不需要对数据进行重新建模。但是，如果对SQL查询、强一致、或者要求主要是读或者混合读写的性能最大化，那么会发现将Cassandra替换成Ignite或者最初就选择Ignite可能会更好。
如果要入门，可以访问Apache Ignite的官方网站了解更多信息，社区也会通过Apache Ignite用户列表提供技术支持。
本文译自GridGain公司创始人和CTO尼基塔 伊万诺夫的博客。