什么时候不使用Cassandra？

Question

最近有很多关于Cassandra的讨论。

Twitter，Digg，Facebook等都使用它。

什么时候才有意义：

• 使用Cassandra，
• 不使用Cassandra，
• 使用RDMS而不是Cassandra。

Answer 1

没有像银弹一样的东西，一切都是为解决具体问题而建立的，并且各有利弊。这取决于你，你有什么问题陈述以及解决这个问题的最佳解决方案。

我会按照你问他们的顺序逐个回答你的问题。由于Cassandra基于NoSQL系列数据库，因此在您回答问题之前了解为何使用NoSQL数据库非常重要。

为什么要使用NoSQL

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

何时使用Cassandra

作为NoSQL系列的一部分，Cassandra为您提出了一个问题的解决方案，其中一个要求是拥有一个非常繁重的写入系统，并且您希望在存储的数据之上拥有一个响应迅速的报告系统。考虑Web分析的用例，其中为每个请求存储日志数据，并且您希望围绕它构建分析平台，以实时方式按浏览器，IP等计算每小时的点击次数。您可以参考this博文，了解更多有关Cassandra适用的用例的信息。

何时使用RDMS代替Cassandra

Cassandra基于NoSQL数据库，不提供ACID和关系数据属性。如果您对ACID属性有强烈要求（例如财务数据），那么Cassandra就不适合。显然，你可以为此做一个解决方法，但是你最终会编写大量的应用程序代码来模拟ACID属性，并且会很快失去市场。使用Cassandra管理这种系统对你来说既复杂又乏味。

何时不使用Cassandra

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

Answer 2

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

Cassandra是一个可用的分区容错系统，支持最终的一致性。有关更多信息，请参阅我撰写的这篇博文：Visual Guide to NoSQL Systems。

Answer 3

Cassandra是特定问题的答案：如果您拥有的数据太多而无法在一台服务器上运行，您会怎么做？如何将您的所有数据存储在许多服务器上，不要破坏您的银行帐户，不要让您的开发人员疯狂？ Facebook每天都会获得4TB的新压缩数据。这个数字很可能会在一年内增长两倍以上。

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

然而，Facebook不再使用cassandra，现在使用MySQL几乎专门在应用程序堆栈中移动分区，以实现更快的性能和更好的控制。

Answer 4

NoSQL的一般概念是您应该使用最适合您的应用程序的数据存储。如果您有财务数据表，请使用SQL。如果您的对象需要复杂/慢速查询以映射到关系模式，请使用对象或键/值存储。

当然，您遇到的任何现实世界问题都处于这两个极端之间，并且两种解决方案都不是完美的。您需要考虑每个商店的功能以及使用其中一个的结果，这将非常具体地解决您要解决的问题。

Answer 5

除了上面给出的关于何时使用以及何时不使用Cassandra的答案，如果你决定使用Cassandra，你可能会考虑不使用Cassandra本身，而是使用Cassandra中的众多堂兄弟之一。

上面的一些答案已经指出了各种＆＃34; NoSQL＆＃34;与Cassandra共享许多属性的系统，存在一些小的或大的差异，并且可能比Cassandra本身更适合您的特定需求。

此外，最近（最初提出这个问题几年后），一个名为Scylla的Cassandra克隆（见https://en.wikipedia.org/wiki/Scylla_(database)）被释放。 Scylla是Cassandra在C ++中的一个开源重新实现，它声称具有比原始Java Cassandra更高的吞吐量和更低的延迟，同时与它大多兼容（在功能，API和文件格式中）。所以，如果您已经考虑过Cassandra，您可能也想考虑Scylla。

Answer 6

在部署Cassandra的过程中与某人交谈时，它并没有处理多对多的问题。他们正在做一个黑客工作来进行初步测试。我和一位Cassandra顾问谈过这件事，他说如果你有这个问题，他就不会推荐它。

Answer 7

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

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

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

根据我对MongoDB的体验，最终由于查询的复杂性，Mongo无法对其进行优化并在多个数据上运行部分内容。 Mongo parallelizes multiple queries但不是很擅长优化单个。

Answer 8

@Paco很抱歉破坏了你的泡沫，尤其是财务数据，交易一致性很重要。正如Cassandra等数据库所强调的那样，失败的脚本可能会产生副作用，其中可能包括一个表已更新而另一个表未更新。一个例子：100英镑从用户1的帐户转移到用户2的帐户。针对每个帐户记录交易，显示从一个帐户中删除并添加到另一个帐户。当然这取决于你的设计。在另一种情况下，向银行付款。资金必须从一个帐户中删除并添加到另一个帐户。缺乏一致性会使资金从系统中“失踪”或被重复计算。无论哪种方式，银行都陷入了困境。

在许多此类案例中，事务一致性对业务至关重要。应用程序以安全有效的方式处理它，或者数据库必须完全自己处理它，后者是“安全”选项。

缺少通过cassandra的加入支持也限制了它的使用，除非使用合适的其他应用程序。在那个注意事项上，缺少触发功能，外键等等。这最终归结为你所需要的。如果你是一个搜索提供商，并拥有庞大的客户群，Cassandra可能是一个完美的选择。另一方面，对于OLTP和一些报告案例，或者较小的负载量，它可能与需求完全不匹配。

Answer 9

让我们阅读一些现实世界的案例：

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是因为db同步太慢了。

（也是由于2短语提交，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快。如何获得多实例可扩展性。

Answer 10

您应该问自己以下问题：

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

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

在一个框内可以完成所有操作时，请使用RDBMS。它可能比大多数人容易，而且任何人都可以使用它。

Answer 11

另一种使选择更容易的情况是当你想使用sum，min，max等等聚合函数和复杂查询（比如上面提到的金融系统）时，关系数据库可能比nosql数据库更方便因为在nosql数据库中都不可能，除非你真的使用了很多反向索引。当您使用nosql时，您必须在代码中执行聚合函数或将它们单独存储在自己的列中，但这会使它非常复杂并降低使用nosql所获得的性能。

Answer 12

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

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

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

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

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

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

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

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

Answer 13

对。当您拥有大量数据，大量查询但几乎没有各种查询时，使用Cassandra才有意义。 Cassandra基本上通过分区和复制来工作。如果您所有的查询都基于相同的分区键，那么Cassandra就是您的最佳选择。如果对不是分区键的属性进行查询，则Cassandra允许您使用新的分区键复制整个数据。因此，现在您具有两个具有相同分区键的相同数据的2个副本。

这带给我我的下一个问题。 不使用Cassandra时。如前所述，Cassandra通过为每个新分区键复制完整的数据库来进行扩展。但是您不能一次又一次地制作新副本。因此，如果您的查询种类繁多，即每个查询的where子句中都有不同的列，那么Cassandra并不是一个好选择。

现在是第三个问题。使用RDBMS的全部目的是要使用 ACID 属性。如果您要建立类似支付服务的业务，并且希望将每笔交易都隔离开来，那么每笔交易要么完成，要么根本不发生，尽管系统出现故障，更改仍将持续进行，并且交易前后各银行帐户的资金必须保持一致完成后，RDBMS是唯一可以帮助您实现这一目标的选项。

本文实际上解释了整个过程，尤其是问题的一部分-> Choosing the best Database中，何时使用Cassandra（相对于其他NoSQL选项而言）。请检查一下。

编辑：要回答proximab的评论中的问题，当我们想到银行系统时，我们立即认为“ ACID是最佳解决方案”。但是，即使银行系统也由几个子系统组成，这些子系统甚至可能无法处理任何与交易相关的数据，例如帐户持有人的个人信息，帐户对帐单，信用卡详细信息，信用记录等。

所有这些信息都需要存储在某个数据库或另一个数据库中。现在，如果您存储诸如帐户余额之类的与帐户相关的信息，则需要始终保持一致。例如，如果您尝试从帐户A向帐户B汇款，那么从帐户A消失的资金应立即显示在帐户B中，并且不能同时存在于两个帐户中。该系统在任何时候都不能不一致。这是ACID最为重要的地方。

反之，如果您要保存信用卡详细信息或信用历史记录，那应该不会落入他人之手，那么您需要一些仅允许授权用户访问的内容。我相信卡桑德拉（Cassandra）的支持。也就是说，像信用记录和信用卡交易这样的数据，我认为这是一个不断增长的数据。此外，您只能对这个数据进行查询，即查询数量非常有限。这两个条件使Cassandra成为完美的解决方案。

Answer 14

Cassandra是一个不错的选择：

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

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

3. 需要与Big Data，Hadoop，Hive和Spark集成。

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

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

6. 需要同质系统。

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

Answer 15

如果您需要具有SQL语义的完全一致的数据库，Cassandra不适合您。 Cassandra支持键值查找。它不支持SQL查询。 Cassandra的数据是＆＃34;最终是一致的＆＃34;。并发查找数据可能不一致，但最终查找是一致的。

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

Answer 16

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

结构基本上是基于上限定理，它是可用性和分区容差，有趣的是最终一致。

  

如果您没有在群集机架中存储大量数据，请不要使用它   如果您不存储时间序列数据，请不要使用，   如果你不打扰你的服务器，请不要使用，   如果您需要强大的一致性，请不要使用。

Answer 17

• 它不支持完整的事务管理 表。
• 不支持二级索引。
• 必须依赖Elastic search / Solr for Secondary index，并且必须编写自定义同步组件。
• 不符合ACID标准的系统。
• 查询支持有限。

Answer 18

根据DataStax，Cassandra不是最需要的用例

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

Answer 19

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

所有这一切都伴随着权衡取舍。因此，当您选择数据库（NoSQL，NewSQL或RDBMS）时，请查看您尝试解决的问题以及可扩展性需求。没有一个数据库可以做到这一切。