Cassandra是一个特定问题的答案:当您有太多数据，以至于无法在一台服务器上存储时，您该怎么办?如何将所有数据存储在多个服务器上，同时不破坏银行账户，不让开发人员抓狂?Facebook每天都会收到4tb的压缩数据。这个数字很可能在一年内增长两倍以上。

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

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

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

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

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

Cassandra是一个特定问题的答案:当您有太多数据，以至于无法在一台服务器上存储时，您该怎么办?如何将所有数据存储在多个服务器上，同时不破坏银行账户，不让开发人员抓狂?Facebook每天都会收到4tb的压缩数据。这个数字很可能在一年内增长两倍以上。

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

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

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

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

你应该问自己以下问题:

(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。它可能比大多数方法都简单，任何人都可以使用它。