你应该问自己以下问题:

(Volume, Velocity) Will you be writing and reading TONS of information , so much information that no one computer could handle the writes. (Global) Will you need this writing and reading capability around the world so that the writes in one part of the world are accessible in another part of the world? (Reliability) Do you need this database to be up and running all the time and never go down regardless of which Cloud, which country, whether it's VM , Container, or Bare metal? (Scale-ability) Do you need this database to be able to continue to grow easily and scale linearly (Consistency) Do you need TUNABLE consistency where some writes can happen asynchronously where as others need to be certified? (Skill) Are you willing to do what it takes to learn this technology and the data modeling that goes with creating a globally distributed database that can be fast for everyone, everywhere?

如果在这些问题中，你认为“可能”或“不”，你应该用别的词。如果你对所有问题的答案都是“当然”，那么你应该用卡桑德拉。

当你可以在一个盒子上做所有事情时，使用RDBMS。它可能比大多数方法都简单，任何人都可以使用它。

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

当然，所有这些都是有代价的。因此，当您选择数据库(NoSQL、NewSQL或RDBMS)时，请考虑您要解决的问题和可伸缩性需求。没有一个数据库可以完成所有的工作。

根据DataStax，当需要Cassandra时，它并不是最好的用例

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

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

当然，你遇到的任何现实问题都处于这两个极端之间，没有一个解决方案是完美的。您需要考虑每个存储的功能以及使用其中一个的后果，这将非常具体于您试图解决的问题。

Right. It makes sense to use Cassandra when you have a huge amount of data, a huge number of queries but very little variety of queries. Cassandra basically works by partitioning and replicating. If all your queries will be based on the same partition key, Cassandra is your best bet. If you get a query on an attribute that is not the partition key, Cassandra allows you to replicate the whole data with a new partition key. So now you have 2 replicas of the same data with 2 different partition keys.

这就引出了你的下一个问题。什么时候不用卡桑德拉。正如我提到的，Cassandra通过为每个新的分区键复制完整的数据库来扩展。但你不能一遍又一遍地复制。因此，当你有大量的查询，即每个查询在where子句中有不同的列时，Cassandra不是一个好的选择。

现在是第三个问题。使用RDBMS的关键在于需要ACID属性。如果您正在构建类似于支付服务的东西，并且希望每个交易都是隔离的，每个交易要么完成要么根本不发生，即使系统出现故障，更改仍然是持久的，并且在交易完成之前和之后各银行账户的资金是一致的，那么RDBMS是帮助您实现这一目标的唯一选择。

这篇文章实际上解释了整个事情，特别是什么时候使用Cassandra或不使用(相对于其他一些NoSQL选项)问题的一部分——>选择最好的数据库。一定要去看看。

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

All of this information needs to be stored in some database or the another. Now if you store the account related information like account balance, that is something that needs to be consistent at all times. For example, if you try to send money from account A to account B, then the money that disappears from account A should instantaneousy show up in account B, and it cannot be present in both accounts at the same time. This system cannot be inconsistant at any point. This is where ACID is of utmost importance.

另一方面，如果您正在保存信用卡详细信息或信用记录，不应该落入坏人之手，那么您需要一些只允许授权用户访问的东西。我相信这是卡桑德拉支持的。也就是说，像信用记录和信用卡交易这样的数据，我认为这是一个不断增长的数据。此外，你可以查询的数据也只有这么多，即它有非常有限的查询数量。这两个条件使Cassandra成为一个完美的解决方案。

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

如果你需要严格的语义，需要对SQL查询的支持，可以选择其他的解决方案，比如MySQL, PostGres，或者结合使用Cassandra和Solr。