它不支持跨 表。 不支持二级索引。 二级索引必须依赖Elastic search /Solr，并且必须编写自定义同步组件。 非ACID兼容系统。 查询支持有限。

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成为一个完美的解决方案。

除了这里的其他答案之外，沉重的单个查询与无数的轻查询负载是另一个需要考虑的问题。在nosql风格的DB中自动优化单个查询本身就比较困难。我使用过MongoDB，在尝试计算复杂查询时遇到了性能问题。我没有使用Cassandra，但我预计它会有同样的问题。

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

For a single, very heavy query, any modern RDBMS engine can do a decent job parallelizing parts of the query and take advantage of as much CPU and memory you throw at it (on a single machine). NoSql databases don't have enough information about the structure of the data to be able to make assumptions that will allow truly intelligent parallelization of a big query. They do allow you to easily scale out more servers (or cores) but once the query hits a complexity level you are basically forced to split it apart manually to parts that the NoSql engine knows how to deal with intelligently.

根据我使用MongoDB的经验，由于查询的复杂性，MongoDB最终无法对其进行优化，也无法在多个数据上运行部分查询。Mongo可以并行多个查询，但不太擅长优化单个查询。

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

该架构完全基于上限定理，即可用性和分区容忍，有趣的是最终一致。

不要使用它，如果你不存储数据卷的机架集群， 如果您不存储时间序列数据，请不要使用， 不要使用如果你不分区你的服务器， 如果你要求强烈的一致性，请不要使用。

让我们来读一些真实的案例:

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的原因，因为数据库同步太慢。

(也是由于2- phase commit, 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本身，而是使用它的众多表亲之一。

上面的一些答案已经指出了各种“NoSQL”系统，它们与Cassandra有许多相同的属性，有一些或大或小的差异，并且可能比Cassandra本身更适合您的特定需求。

Additionally, recently (several years after this question was originally asked), a Cassandra clone called Scylla (see https://en.wikipedia.org/wiki/Scylla_(database)) was released. Scylla is an open-source re-implementation of Cassandra in C++, which claims to have significantly higher throughput and lower latencies than the original Java Cassandra, while being mostly compatible with it (in features, APIs, and file formats). So if you're already considering Cassandra, you may want to consider Scylla as well.