在这里，我将重点介绍一些重要的方面，这些方面可以帮助你决定是否真的需要卡桑德拉。这个清单并不详尽，只是我脑海中最重要的一些观点

Don't consider Cassandra as the first choice when you have a strict requirement on the relationship (across your dataset). Cassandra by default is AP system (of CAP). But, it supports tunable consistency which means it can be configured to support as CP as well. So don't ignore it just because you read somewhere that it's AP and you are looking for CP systems. Cassandra is more accurately termed “tuneably consistent,” which means it allows you to easily decide the level of consistency you require, in balance with the level of availability. Don't use Cassandra if your scale is not much or if you can deal with a non-distributed DB. Think harder if your team thinks that all your problems will be solved if you use distributed DBs like Cassandra. To start with these DBs is very simple as it comes with many defaults but optimizing and mastering it for solving a specific problem would require a good (if not a lot) amount of engineering effort. Cassandra is column-oriented but at the same time each row also has a unique key. So, it might be helpful to think of it as an indexed, row-oriented store. You can even use it as a document store. Cassandra doesn't force you to define the fields beforehand. So, if you are in a startup mode or your features are evolving (as in agile) - Cassandra embraces it. So better, first think about queries and then think about data to answer them. Cassandra is optimized for really high throughput on writes. If your use case is read-heavy (like cache) then Cassandra might not be an ideal choice.

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

Cassandra是一个可用的、支持最终一致性的分区容忍系统。要了解更多信息，请参阅我写的这篇博客文章:NoSQL系统的可视化指南。

another situation that makes the choice easier is when you want to use aggregate function like sum, min, max, etcetera and complex queries (like in the financial system mentioned above) then a relational database is probably more convenient then a nosql database since both are not possible on a nosql databse unless you use really a lot of Inverted indexes. When you do use nosql you would have to do the aggregate functions in code or store them seperatly in its own columnfamily but this makes it all quite complex and reduces the performance that you gained by using nosql.

除了这里的其他答案之外，沉重的单个查询与无数的轻查询负载是另一个需要考虑的问题。在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可以并行多个查询，但不太擅长优化单个查询。

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

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

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

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快。无论如何不会有多实例可伸缩性。