除了上面给出的关于何时使用和何时不使用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.

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

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

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

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

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

Cassandra是个不错的选择，如果:

您不需要DB中的ACID属性。 DB上会有大量的写操作。 需要与大数据、Hadoop、Hive和Spark集成。 需要实时数据分析和生成报告。 有一个强大的容错机制的要求。 有一个齐次系统的要求。 调优需要大量的自定义。

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

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

在部署Cassandra的过程中与某人交谈，它不能很好地处理多对多。他们正在做初步测试。我和Cassandra的顾问谈过这个问题，他说如果你有这样的习题集，他就不建议你这么做。