如果您需要具有SQL语义的完全一致的数据库,Cassandra不适合您。 Cassandra支持键值查找。它不支持SQL查询。 Cassandra的数据“最终是一致的”。并发查找数据可能不一致,但最终查找是一致的。
如果您需要严格的语义并需要SQL查询支持,请选择其他解决方案,如MySQL,PostGres,或将Cassandra与Solr结合使用。
NoSQL的一般概念是你应该使用最适合你的应用程序的数据存储。如果您有财务数据表,请使用SQL。如果您的对象需要复杂/慢速查询以映射到关系模式,请使用对象或键/值存储。
当然,您遇到的任何现实世界问题都介于这两个极端之间,并且两种解决方案都不是完美的。您需要考虑每个商店的功能以及使用其中一个的后果,这将非常具体地解决您要解决的问题。
Cassandra是一个很好的选择,如果:
您不需要数据库中的ACID属性。
数据库上会有大量的大量写入。
需要与Big Data,Hadoop,Hive和Spark集成。
需要实时数据分析和报告生成。
需要具有令人印象深刻的容错机制。
需要同质系统。
调整需要大量定制。
根据DataStax,Cassandra并不是最需要的用例
1-高端硬件设备。 2- ACID兼容无回滚(银行交易)
没有像银弹一样的东西,一切都是为解决具体问题而建立的,并且各有利弊。这取决于你,你有什么问题陈述,以及什么是最适合该问题的解决方案。
我将按照您提出的相同顺序逐一回答您的问题。由于Cassandra基于NoSQL系列数据库,因此在我回答您的问题之前,了解为何使用NoSQL数据库非常重要。
的 为什么要使用NoSQL 强>
对于RDBMS,做出选择非常简单,因为此类别中的所有数据库(如MySQL,Oracle,MS SQL,PostgreSQL)都提供了几乎与ACID属性相同的解决方案。在NoSQL方面,决策变得困难,因为每个NoSQL数据库都提供不同的解决方案,您必须了解哪一个最适合您的应用程序/系统要求。例如,MongoDB适用于系统需要无架构文档存储的用例。 HBase可能适合搜索引擎,分析日志数据,或任何需要扫描巨大的二维无连接表的地方。 Redis旨在为各种数据结构(如树,队列,链表等)提供内存搜索,并且非常适合制作实时排行榜,pub-sub类型的系统。同样,此类别中的其他数据库(包括Cassandra)适用于不同的问题陈述。现在让我们转到原始问题,然后逐一回答。
的 什么时候使用Cassandra 强>
作为NoSQL系列的一部分,Cassandra提供了一个解决问题的解决方案,其中一个要求是拥有一个非常繁重的写入系统,并且您希望在存储的数据之上拥有一个响应迅速的报告系统。考虑Web分析的用例,其中为每个请求存储日志数据,并且您希望围绕它构建分析平台,以实时方式按浏览器,IP等计算每小时的点击次数。你可以参考 这个 博客文章了解更多关于Cassandra适合的用例。
的 何时使用RDMS而不是Cassandra 强>
Cassandra基于NoSQL数据库,不提供ACID和关系数据属性。如果您对ACID属性有强烈要求(例如财务数据),那么Cassandra就不适合。显然,你可以为此做一个解决方法,但是你最终会编写大量的应用程序代码来模拟ACID属性,并且会很快失去市场。使用Cassandra管理这种系统对你来说既复杂又乏味。
的 何时不使用Cassandra 强>
如果上述解释有意义,我认为不需要回答。
另一种使选择更容易的情况是当你想使用sum,min,max,etcetera等综合函数和复杂查询(比如上面提到的金融系统)时,关系数据库可能比nosql数据库更方便,因为两者都是除非你使用了很多反向索引,否则在nosql数据库上是不可能的。当你使用nosql时,你必须在代码中执行聚合函数或者将它们单独存储在它自己的columnfamily中,但这会使它变得非常复杂并降低使用nosql所获得的性能。
在评估分布式数据系统时,您必须考虑CAP定理 - 您可以选择以下两项:一致性,可用性和分区容差。
Cassandra是一个可用的分区容错系统,支持最终的一致性。有关更多信息,请参阅我写的这篇博文: NoSQL系统的可视指南 。
的 重单查询与gazillion轻查询 强> 除了这里的其他答案之外,负载是另一个要考虑的问题。在NoSql风格的DB中自动优化单个查询本身就更难。在尝试计算复杂查询时,我使用过MongoDB并遇到性能问题。我没有使用Cassandra,但我希望它有同样的问题。
另一方面,如果您的负载预计是很多小查询的负载,并且您希望能够轻松扩展,那么您可以利用大多数NoSql DB提供的最终一致性。请注意,最终的一致性实际上并不是非关系数据模型的一个特性,但它更容易实现并在基于NoSql的系统中进行设置。
对于单个非常繁重的查询,任何现代RDBMS引擎都可以在并行化部分查询方面做得不错,并利用您在其上投入的尽可能多的CPU和内存(在一台机器上)。 NoSql数据库没有足够的有关数据结构的信息,无法做出允许真正智能并行化大查询的假设。它们允许您轻松扩展更多服务器(或核心),但一旦查询达到复杂程度,您基本上不得不手动将其拆分为NoSql引擎知道如何智能处理的部分。
根据我使用MongoDB的经验,最终由于查询的复杂性,Mongo无法对其进行优化并在多个数据上运行部分内容。 Mongo并行化多个查询 但是优化单一的并不是那么好。
Cassandra是一个特定问题的答案:当你拥有如此多的数据而不适合一台服务器时,你会怎么做?如何将您的所有数据存储在许多服务器上,不要破坏您的银行帐户,不要让您的开发人员疯狂? Facebook每天都会获得4TB的新压缩数据。这个数字最有可能在一年内增长两倍以上。
如果您没有这么多数据,或者您有数百万美元需要支付Enterprise Oracle / DB2集群安装以及设置和维护它所需的专家,那么您可以使用SQL数据库。
然而Facebook不再使用cassandra,现在使用MySQL几乎专门在应用程序堆栈中移动分区,以实现更快的性能和更好的控制。
Mongodb具有非常强大的聚合函数和富有表现力的聚合框架。它具有许多开发人员习惯使用的关系数据库世界的功能。例如,它的文档数据/存储结构允许比Cassandra更复杂的数据模型。
所有这一切都伴随着权衡。因此,当您选择数据库(NoSQL,NewSQL或RDBMS)时,请查看您尝试解决的问题以及可扩展性需求。没有一个数据库可以做到这一切
除了上面给出的关于什么时候使用以及什么时候不使用Cassandra的答案,如果你决定使用Cassandra,你可能想要考虑不使用Cassandra本身,而是使用其中的许多表兄弟之一。
上面的一些答案已经指出各种“NoSQL”系统与Cassandra共享许多属性,有一些小的或大的差异,并且可能比Cassandra本身更适合您的特定需求。
此外,最近(最初问过这个问题几年后),一个叫做Scylla的Cassandra克隆(参见 https://en.wikipedia.org/wiki/Scylla_(database) )被释放了。 Scylla是Cassandra在C ++中的一个开源重新实现,它声称具有比原始Java Cassandra更高的吞吐量和更低的延迟,同时与它大多兼容(在功能,API和文件格式中)。所以,如果你已经在考虑Cassandra,你可能也想考虑Scylla。
@Paco很抱歉破坏了你的泡沫,特别是财务数据,交易一致性很重要。正如Cassandra等数据库所强调的那样,失败的脚本可能会产生副作用,其中可能包括一个表已更新而另一个表未更新。一个例子:100英镑从用户1的帐户转移到用户2的帐户。针对每个帐户记录交易,显示从一个帐户中删除并添加到另一个帐户。当然这取决于你的设计。在另一种情况下,向银行付款。资金必须从一个帐户中删除并添加到另一个帐户。缺乏一致性会使资金从系统中“失踪”或被重复计算。无论哪种方式,银行发现自己陷入困境。
在许多此类情况下,事务一致性对业务至关重要。应用程序以安全有效的方式处理它,或者数据库必须完全自己处理它,后者是“安全”选项。
缺少通过cassandra的加入支持也限制了它的使用,除非使用合适的其他应用程序。在那个注意事项上,缺少触发功能,外键等等。这最终归结为你所需要的。如果你是一个搜索提供商,并拥有庞大的客户群,Cassandra可能是一个完美的选择。另一方面,对于OLTP和一些报告案例,或者较小的负载量,它可能与需求完全不匹配。
Apache cassandra是一个分布式数据库,用于管理许多商用服务器上的大量结构化数据,同时提供高可用性服务而且没有单点故障。
archichecture完全基于cap定理,即可用性和分区容差,有趣的是最终的一致性。
不要使用它,如果你不在集群机架中存储大量数据, 如果您不存储时间序列数据,请不要使用, 如果你不打扰你的服务器,请不要使用, 如果您需要强大的一致性,请不要使用。
在部署Cassandra的过程中与某人交谈时,它并不能很好地处理多对多的问题。他们正在做一个黑客工作来进行初步测试。我和一位Cassandra顾问谈过这件事,他说如果你有这个问题,他就不会推荐它。