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.

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

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.

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

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

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

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

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

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

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