什么时候不使用Cassandra？

最近有很多关于卡桑德拉的话题。

Twitter，Digg，Facebook等都使用它。

什么时候有意义：

• 使用Cassandra，
• 不使用Cassandra，并且
• 使用RDMS代替Cassandra。

没有什么比这更重要的了，一切都是为了解决特定的问题而建立的，各有利弊。取决于您，您拥有什么问题陈述，什么是最适合该问题的解决方案。

我将尝试按照您询问的顺序依次回答您的问题。由于Cassandra基于NoSQL数据库家族，因此在回答问题之前，您必须了解为什么要使用NoSQL数据库，这一点很重要。

为什么要使用NoSQL

对于RDBMS，选择非常容易，因为该类别中的所有数据库（如MySQL，Oracle，MS SQL和PostgreSQL）都提供面向ACID属性的几乎相同类型的解决方案。当涉及到NoSQL时，决策变得困难，因为每个NoSQL数据库都提供不同的解决方案，并且您必须了解哪种解决方案最适合您的应用程序/系统要求。例如，MongoDB适用于系统需要无模式文档存储的用例。HBase可能适合搜索引擎，分析日志数据或需要扫描巨大的二维无联接表的任何地方。Redis的构建是为了在内存中搜索各种数据结构，例如树，队列，链表等，并且非常适合制作实时排行榜，发布子类系统。同样，该类别中还有其他数据库（包括Cassandra）适用于不同的问题陈述。现在，让我们转到原始问题，然后一个个地回答。

何时使用Cassandra

作为NoSQL家族的一部分，Cassandra为问题提供了一种解决方案，其中您的要求之一是拥有一个非常沉重的写入系统，并且您希望在该存储的数据之上具有一个响应能力强的报表系统。考虑一下Web分析的用例，其中为每个请求存储了日志数据，并且您希望围绕它构建一个分析平台，以每小时，浏览器，IP等实时计数命中次数。您可以参考此博客文章，以了解有关Cassandra适合的用例的更多信息。

何时使用RDMS代替Cassandra

Cassandra基于NoSQL数据库，不提供ACID和关系数据属性。如果您对ACID属性（例如财务数据）有很高的要求，那么在这种情况下，Cassandra不适合。显然，您可以为此解决问题，但是最终您将编写大量应用程序代码来模拟ACID属性，并且会严重浪费产品上市时间。另外，使用Cassandra管理这种系统对于您来说将是复杂而又乏味的。

何时不使用Cassandra

如果上述说明有意义，我认为不需要回答。

在评估分布式数据系统时，必须考虑CAP定理-您可以选择以下两项：一致性，可用性和分区容限。

Cassandra是一个可用的，支持分区的系统，它支持最终的一致性。有关更多信息，请参见我写的这篇博客文章：NoSQL Systems可视指南。

卡桑德拉（Cassandra）是解决特定问题的答案：当您拥有太多数据而无法在一台服务器上容纳时，该怎么办？您如何将所有数据存储在许多服务器上，又不会破坏您的银行帐户，又不会使开发人员发疯？Facebook每天都会获得4 TB的新压缩数据。而且这个数字很可能会在一年内增长两倍以上。

如果您没有这么多数据，或者您有数百万美元需要支付Enterprise Oracle / DB2集群安装费用，并且需要专家来设置和维护它，那么使用SQL数据库就可以了。

但是，Facebook不再使用cassandra，现在几乎完全使用MySQL来将分区移至应用程序堆栈中，以实现更快的性能和更好的控制。

NoSQL的一般想法是，应使用最适合您的应用程序的数据存储。如果您有财务数据表，请使用SQL。如果您有需要复杂/缓慢查询才能映射到关系架构的对象，请使用对象或键/值存储。

当然，您遇到的任何现实世界问题都在这两个极端之间，并且两种解决方案都不完美。您需要考虑每个商店的功能以及使用一个商店的后果，这与您要解决的问题非常相关。

除了上面给出的有关何时使用和何时不使用Cassandra的答案外，如果您决定使用Cassandra，则可能要考虑不使用Cassandra本身，而是其中的许多表亲之一。

上面的一些答案已经指向了各种“ NoSQL”系统，这些系统与Cassandra共享许多属性，但有一些小或大的差异，并且在满足您的特定需求方面可能比Cassandra更好。

此外，最近（最初提出此问题已有数年），一个名为Scylla的Cassandra克隆（请参阅https://en.wikipedia.org/wiki/Scylla_(database））已发布。Scylla是Cs中Cassandra的开源重新实现，声称与原始Java Cassandra相比，它具有显着更高的吞吐量和更低的延迟，同时又与Java Cassandra兼容（在功能，API和文件格式上）。因此，如果您已经在考虑Cassandra，则可能还需要考虑Scylla。

在部署Cassandra期间与某人交谈时，它不能很好地处理多对多问题。他们正在做黑客工作来进行初始测试。我与Cassandra顾问进行了交谈，他说如果您遇到此问题，他将不建议这样做。

您应该问自己以下问题：

1. （音量，速度）您是否正在编写和读取大量信息，以至于没有任何一台计算机可以处理这些信息。
2. （全球）您是否需要在全球范围内具有这种读写能力，以便在世界另一部分可以访问世界某个地方的文字？
3. （可靠性）您是否需要该数据库一直保持运行状态，并且无论哪个云，哪个国家（无论是VM，Container还是Bare metal）都永远不会停机？
4. （可伸缩性）您是否需要此数据库才能继续轻松增长并线性扩展
5. （一致性）您是否需要TUNABLE一致性，以便某些写入可以异步发生，而其他写入则需要认证？
6. （技能）您愿意做些什么来学习这项技术以及创建全球分布的数据库所需要的数据模型吗？

如果对于这些问题中的任何一个您认为“可能”或“否”，则应该使用其他内容。如果您对所有这些答案都回答“是”，则应使用Cassandra。

当您可以在一台机器上完成所有操作时，请使用RDBMS。它可能比大多数人容易，而且任何人都可以使用它。

除了此处的其他答案之外，单重查询与轻量级查询的负载是要考虑的另一点。在NoSql风格的数据库中自动优化单个查询从本质上来说更加困难。我使用过MongoDB并在尝试计算复杂查询时遇到性能问题。我没有用过Cassandra，但我希望它有同样的问题。

另一方面，如果预期您的负载是很多小查询的负载，并且希望能够轻松扩展，则可以利用大多数NoSql数据库提供的最终一致性。请注意，最终一致性实际上并不是非关系数据模型的功能，但是在基于NoSql的系统中实现和设置起来要容易得多。

对于单个非常繁琐的查询，任何现代RDBMS引擎都可以使查询的各个部分并行化，并可以充分利用您在单个计算机上投入的CPU和内存。NoSql数据库没有足够的有关数据结构的信息，因此无法做出能够真正实现大查询智能并行化的假设。它们的确使您可以轻松地扩展更多服务器（或核心），但是一旦查询达到复杂性级别，您基本上就不得不手动将其拆分为NoSql引擎知道如何智能处理的部分。

根据我在MongoDB上的经验，最后，由于查询的复杂性，Mongo不能做很多事情来优化它并在多个数据上运行它的一部分。Mongo可以并行处理多个查询，但是在优化单个查询方面并不是很好。

让我们阅读一些实际案例：

http://planetcassandra.org/apache-cassandra-use-cases/

本文内容如下：http : //planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra

他们详细说明了为什么不选择MySql的原因是因为数据库同步太慢。

（也由于两阶段提交，FK，PK）

Cassandra基于Amazon Dynamo纸张

特征：

稳定性

高可用性

备份执行良好

读写优于HBase（Java中的BigTable克隆）。

Wiki http://en.wikipedia.org/wiki/Apache_Cassandra

他们的结论是：

We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.

截至2018年，

如果需要支持，我建议使用ScyllaDB代替经典的cassandra。

Postgres kv插件也比cassandra快。怎么会没有多实例可伸缩性。

我将在这里重点介绍一些重要方面，这些方面可以帮助您确定是否真的需要Cassandra。这份清单并不详尽，只是我最想知道的一些要点-

• 当您对关系有严格要求时（在整个数据集中），不要将Cassandra视为首选。

• Cassandra默认为AP系统（CAP）。但是，它支持可调一致性，这意味着可以将其配置为也支持CP。因此，不要仅仅因为您在某处读到它是AP并且正在寻找CP系统而忽略它。Cassandra更准确地称为“可调整的一致性”，这意味着您可以轻松地确定所需的一致性级别以及可用性级别。

• 如果规模不大或可以处理非分布式数据库，请不要使用Cassandra。

• 如果您的团队认为如果使用像Cassandra这样的分布式数据库，那么所有问题都将得到解决，请多加思考。从这些数据库开始非常简单，因为它具有许多默认值，但是为解决特定问题而对其进行优化和掌握将需要大量（如果不是很多的话）工程工作。

• Cassandra是面向列的，但同时每一行都有唯一的键。因此，将其视为索引的，面向行的存储可能会有所帮助。您甚至可以将其用作文档存储。

• Cassandra不会强迫您预先定义字段。因此，如果您处于启动模式或功能正在发展（如敏捷），Cassandra会接受它。更好的是，首先考虑查询，然后考虑数据来回答它们。

• Cassandra经过优化，可实现很高的写入吞吐量。如果您的用例是重载（例如缓存），那么Cassandra可能不是理想的选择。

另一种使选择更加容易的情况是，当您想使用汇总函数（例如sum，min，max等）和复杂查询（例如在上述财务系统中）时，关系数据库可能比nosql数据库更方便，因为两者都是除非您确实使用了很多反向索引，否则在nosql数据库上是不可能的。当您确实使用nosql时，您将不得不在代码中执行聚合函数或将它们分别存储在其自己的列族中，但这会使它们变得相当复杂，并降低了使用nosql获得的性能。

如果您需要具有SQL语义的完全一致的数据库，那么Cassandra并不是您的解决方案。Cassandra支持键值查找。它不支持SQL查询。Cassandra中的数据“最终是一致的”。并发的数据查找可能不一致，但最终查找是一致的。

如果需要严格的语义并需要对SQL查询的支持，请选择其他解决方案，例如MySQL，PostGres，或将Cassandra与Solr结合使用。

如果满足以下条件，Cassandra是一个不错的选择：

1. 您不需要数据库中的ACID属性。

2. 数据库上会有大量的写入操作。

3. 需要与大数据，Hadoop，Hive和Spark集成。

4. 需要实时数据分析和报告生成。

5. 需要令人印象深刻的容错机制。

6. 需要同质系统。

7. 需要进行大量的自定义调整。

Mongodb具有非常强大的聚合函数和表达性聚合框架。它具有关系数据库世界中开发人员习惯使用的许多功能。例如，它的文档数据/存储结构允许使用比Cassandra更复杂的数据模型。

当然，所有这些都需要权衡取舍。因此，当您选择数据库（NoSQL，NewSQL或RDBMS）时，请查看您要解决的问题以及可伸缩性需求。没有一个数据库能做到这一切。

根据DataStax的说法，当需要使用Cassandra时，它不是最佳用例

1-高端硬件设备。2- ACID兼容，无回滚（银行交易）

• 它不支持跨表的完整事务管理。
• 不支持二级索引。
• 必须依靠Elastic search / Solr作为次要索引，并且必须编写自定义同步组件。
• 不符合ACID的系统。
• 查询支持是有限的。

Apache cassandra是一个分布式数据库，用于管理许多商用服务器上的大量结构化数据，同时提供高可用性服务且没有单点故障。

架构纯粹基于上限定理，即可用性和分区容限，并且有趣的是最终始终如一。

不要使用它，如果您不存储跨集群机架的数据量，请不要使用，如果您不存储时间序列数据，请不要使用，如果您不对服务器进行分区则不要使用，如果需要强一致性，请不要使用。