blocks|key|3264059|text|NoSQL的总体思想是，您应该使用最适合您的应用程序的任何数据存储。如果您有一个财务数据表，请使用SQL。如果您有需要复杂/慢查询才能映射到关系模式的对象，请使用对象或键/值存储。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3264060|当然，您遇到的任何现实问题都介于这两个极端之间，任何一种解决方案都不会是完美的。你需要考虑每个商店的功能，以及使用一个商店而不是另一个商店的后果，这将非常具体于你试图解决的问题。|3264061|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The general idea of NoSQL is that you should use whichever data store is the best fit for your application. If you have a table of financial data, use SQL. If you have objects that would require complex/slow queries to map to a relational schema, use an object or key/value store. 

Of course just about any real world problem you run into is somewhere in between those two extremes and neither solution will be perfect. You need to consider the capabilities of each store and the consequences of using one over the other, which will be very much specific to the problem you are trying to solve.

blocks|key|3264080|text|在评估分布式数据系统时，您必须考虑CAP定理-您可以选择以下两个:一致性、可用性和分区容错性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3264081|Cassandra是一个可用的、可容忍分区的系统，它支持最终的一致性。有关更多信息，请参阅我写的这篇博客文章：Visual+Guide+to+NoSQL+Systems。|offset|length|3264082|entityMap|0|LINK|mutability|MUTABLE|url|http://blog.nahurst.com/visual-guide-to-nosql-systems^0|0|1J|T|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

When evaluating distributed data systems, you have to consider the CAP theorem - you can pick two of the following: consistency, availability, and partition tolerance.

Cassandra is an available, partition-tolerant system that supports eventual consistency. For more information see this blog post I wrote: <a href="http://blog.nahurst.com/visual-guide-to-nosql-systems" rel="noreferrer">Visual Guide to NoSQL Systems</a>.

blocks|key|3050410|text|Cassandra是一个特殊问题的答案:当您有如此多的数据无法放在一台服务器上时，您该怎么办？您如何将所有数据存储在多个服务器上，并且不会破坏您的银行帐户，也不会让您的开发人员发疯？Facebook每天都会获得4TB的新压缩数据。这个数字很可能会在一年内增长两倍以上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3050411|如果您没有这么多数据，或者您需要为企业Oracle/DB2集群安装支付数百万美元，并且需要专家对其进行设置和维护，那么您可以使用SQL数据库。|3050412|然而，Facebook不再使用cassandra，现在几乎完全使用MySQL，将分区移到应用程序堆栈中，以获得更快的性能和更好的控制。|3050413|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Cassandra is the answer to a particular problem: What do you do when you have so much data that it does not fit on one server ? How do you store all your data on many servers and do not break your bank account and not make your developers insane ? Facebook gets 4 Terabyte of new compressed data EVERY DAY. And this number most likely will grow more than twice within a year.

If you do not have this much data or if you have millions to pay for Enterprise Oracle/DB2 cluster installation and specialists required to set it up and maintain it, then you are fine with SQL database.

However Facebook no longer uses cassandra and now uses MySQL almost exclusively moving the partitioning up in the application stack for faster performance and better control.

blocks|key|3264158|text|另一种让选择变得更容易的情况是，当你想要使用聚合函数，如sum，min，max，etcetera和复杂的查询(如上面提到的金融系统)，那么关系数据库可能比nosql数据库更方便，因为在nosql数据库上两者都不可能，除非你使用大量的倒排索引。当您使用nosql时，您将不得不在代码中执行聚合函数，或者将它们单独存储在它自己的列族中，但这会使它变得非常复杂，并降低您通过使用nosql获得的性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3264159|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|308700|text|与正在部署Cassandra的人交谈时，它不能很好地处理多对多。他们正在做一个黑客工作来做他们的初始测试。我和Cassandra的一位顾问谈过这个问题，他说如果你有这个问题集，他不会推荐。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308701|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Talking with someone in the midst of deploying Cassandra, it doesn't handle the many-to-many well. They are doing a hack job to do their initial testing. I spoke with a Cassandra consultant about this and he said he wouldn't recommend it if you had this problem set.

blocks|key|3264231|text|Mongodb拥有非常强大的聚合函数和一个富有表现力的聚合框架。它具有许多开发人员在关系数据库世界中习惯使用的特性。例如，它的文档数据/存储结构允许比Cassandra更复杂的数据模型。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3264232|当然，所有这些都是有权衡的。因此，当您选择数据库(NoSQL、NewSQL或RDBMS)时，请查看您试图解决的问题以及您的可伸缩性需求。没有一个数据库能做所有的事情。|3264233|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Mongodb has very powerful aggregate functions and an expressive aggregate framework. It has many of the features developers are accustomed to using from the relational database world. It's document data/storage structure allows for more complex data models than Cassandra, for example.

All this comes with trade-offs of course. So when you select your database (NoSQL, NewSQL, or RDBMS) look at what problem you are trying to solve and at your scalability needs. No one database does it all.

blocks|key|3050511|text|除了这里的其他答案之外，繁重的单个查询与庞大的轻量级查询负载是另一个需要考虑的问题。在NoSql风格的数据库中自动优化单个查询本身就比较困难。我使用过MongoDB，但在尝试计算复杂查询时遇到了性能问题。我没有使用过Cassandra，但我希望它会有同样的问题。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3050512|另一方面，如果您的负载是非常小的查询的负载，并且您希望能够轻松地向外扩展，那么您可以利用大多数NoSql+DB提供的最终一致性。请注意，最终一致性并不是非关系数据模型的真正特性，但在基于NoSql的系统中实现和设置它要容易得多。|3050513|对于一个非常繁重的查询，任何现代RDBMS引擎都可以很好地并行化查询的各个部分，并(在一台机器上)利用尽可能多的CPU和内存。NoSql数据库没有足够的数据结构信息，无法做出假设，从而实现真正智能的大型查询并行化。它们确实允许您轻松地向外扩展更多的服务器(或核心)，但是一旦查询达到一定的复杂程度，您基本上就不得不手动将其拆分成NoSql引擎知道如何智能处理的部分。|3050514|在我使用MongoDB的经验中，最终由于查询的复杂性，Mongo无法对其进行优化，并在多个数据上运行部分查询。Mongo+parallelizes+multiple+queries，但并不擅长优化单个脚本。|3050515|entityMap|0|LINK|mutability|MUTABLE|url|http://docs.mongodb.org/manual/faq/concurrency/^0|C|G|0|0|0|1J|Z|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|X|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|Y|8|@]|D|@$9|Z|A|10|1|11]]|E|$]]|$1|L|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|M|$N|$5|O|P|Q|E|$R|S]]]]

Heavy single query vs. gazillion light query load is another point to consider, in addition to other answers here. It's inherently harder to automatically optimize a single query in a NoSql-style DB. I've used MongoDB and ran into performance issues when trying to calculate a complex query. I haven't used Cassandra but I expect it to have the same issue. 

On the other hand, if your load is expected to be that of very many small queries, and you want to be able to easily scale out, you could take advantage of eventual consistency that is offered by most NoSql DBs. Note that eventual consistency is not really a feature of a non-relational data model, but it is much easier to implement and to set up in a NoSql-based system.

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.

In my experience with MongoDB, in the end because of the complexity of the query there wasn't much Mongo could do to optimize it and run parts of it on multiple data. <a href="http://docs.mongodb.org/manual/faq/concurrency/" rel="nofollow">Mongo parallelizes multiple queries</a> but isn't so good at optimizing a single one.

blocks|key|308725|text|让我们来读一些现实世界的案例：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308726|http://planetcassandra.org/apache-cassandra-use-cases/|offset|length|308727|本文简介：http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra|308728|他们详细阐述了没有选择MySql的原因是因为数据库同步太慢了。|308729|(也是由于两段提交、FK、PK)|308730|308731|Cassandra基于Amazon+Dynamo纸张|308732|功能：|308733|稳定性|308734|高可用性|308735|备份性能良好|308736|读写比HBase+(java中的BigTable克隆)更好。|308737|维基http://en.wikipedia.org/wiki/Apache_Cassandra|308738|的结论是：|308739|We+looked+at+HBase,+Dynamo,+Mongo+and+Cassandra.+

Cassandra+was+simply+the+best+storage+solution+for+the+majority+of+our+data.|code-block|syntax|javascript|308740|截至2018年，|308741|如果您需要后台支持，我建议您使用ScyllaDB来替代经典的cassandra。|308742|Postgres+kv插件也比cassandra快。然而，它不会有多实例可伸缩性。|308743|entityMap|0|LINK|mutability|MUTABLE|url|1|http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra|2|http://en.wikipedia.org/wiki/Apache_Cassandra^0|0|0|1I|0|0|5|3K|1|0|0|0|0|0|0|0|0|0|0|2|19|2|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1P|8|@]|9|@$D|1Q|E|1R|1|1S]]|A|$]]|$1|F|3|G|5|6|7|1T|8|@]|9|@$D|1U|E|1V|1|1W]]|A|$]]|$1|H|3|I|5|6|7|1X|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|20|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|21|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|22|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|23|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|24|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|25|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|26|8|@]|9|@$D|27|E|28|1|29]]|A|$]]|$1|10|3|11|5|6|7|2A|8|@]|9|@]|A|$]]|$1|12|3|13|5|14|7|2B|8|@]|9|@]|A|$15|16]]|$1|17|3|18|5|6|7|2C|8|@]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2D|8|@]|9|@]|A|$]]|$1|1B|3|1C|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1D|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]]|1E|$1F|$5|1G|1H|1I|A|$1J|C]]|1K|$5|1G|1H|1I|A|$1J|1L]]|1M|$5|1G|1H|1I|A|$1J|1N]]]]

Let's read some real world cases:

<a href="http://planetcassandra.org/apache-cassandra-use-cases/" rel="nofollow noreferrer">http://planetcassandra.org/apache-cassandra-use-cases/</a>

In this article: <a href="http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra" rel="nofollow noreferrer">http://planetcassandra.org/blog/post/agentis-energy-stores-over-15-billion-records-of-time-series-usage-data-in-apache-cassandra</a>

They elaborated the reason why they didn't choose MySql is because db synchronization is too slow. 

(Also due to 2-phrase commit, FK, PK)

<hr>

Cassandra is based on Amazon Dynamo paper

Features:

Stability

High availability

Backup performs well 

Read and Write is better than HBase, (BigTable clone in java). 

wiki <a href="http://en.wikipedia.org/wiki/Apache_Cassandra" rel="nofollow noreferrer">http://en.wikipedia.org/wiki/Apache_Cassandra</a>

Their Conclusion is:

<pre><code>We looked at HBase, Dynamo, Mongo and Cassandra. 

Cassandra was simply the best storage solution for the majority of our data.
</code></pre>

As of 2018,

I would recommend using ScyllaDB to replace classic cassandra, if you need back support.

Postgres kv plugin is also quick than cassandra. How ever won't have multi-instance scalability.

blocks|key|308771|text|没有什么比银弹更好的了，每件事都是为了解决特定的问题而构建的，都有自己的利弊。这取决于你，你有什么问题陈述，对于这个问题最合适的解决方案是什么。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308772|我会试着按照你问的顺序逐一回答你的问题。由于Cassandra是基于NoSQL数据库系列的，因此在回答您的问题之前，了解为什么要使用NoSQL数据库是很重要的。|308773|为什么使用NoSQL|offset|length|style|BOLD|308774|在关系型数据库的情况下，做出选择是相当容易的，因为这一类别中的所有数据库，如MySQL、Oracle、MySQL、PostgreSQL都提供了几乎相同类型的面向ACID属性的解决方案。当涉及到NoSQL时，决定变得很困难，因为每个NoSQL数据库都提供不同的解决方案，您必须了解哪一个最适合您的应用程序/系统需求。例如，MongoDB适用于系统需要无模式文档存储的用例。HBase可能适用于搜索引擎、分析日志数据，或者需要扫描巨大的二维无连接表的任何地方。Redis是为树、队列、链表等各种数据结构提供内存搜索而构建的，非常适合制作实时排行榜、发布-订阅类型的系统。同样，这一类别中还有其他数据库(包括Cassandra)，它们适合于不同的问题陈述。现在让我们转到原始问题，并逐一回答它们。|308775|何时使用Cassandra|308776|作为NoSQL家族的一员，Cassandra为以下问题提供了解决方案:您的需求之一是拥有一个非常繁重的写入系统，并且您希望在存储的数据之上拥有一个响应性很强的报告系统。考虑Web分析的用例，其中为每个请求存储日志数据，并且您希望围绕它构建一个分析平台，以实时方式统计每小时、按浏览器、按IP等的点击量。你可以参考this的博客文章来了解更多关于Cassandra适合的用例。|308777|何时使用RDMS而不是Cassandra|308778|Cassandra基于NoSQL数据库，不提供ACID和关系数据属性。如果您对ACID属性有很强的需求(例如，财务数据)，那么Cassandra将不适合这种情况。显然，你可以解决这个问题，但是你最终会编写大量的应用程序代码来模拟ACID属性，并且会在上市时间上损失惨重。此外，使用Cassandra管理这种系统对您来说将是复杂和乏味的。|308779|不使用Cassandra时使用|308780|我认为如果上面的解释是有意义的，就不需要回答这个问题。|308781|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.shephertz.com/2015/04/22/why-cassandra-excellent-choice-for-realtime-analytics-workload/^0|0|0|0|A|0|0|0|D|0|4C|4|0|0|0|K|0|0|0|0|R|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|16|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|17|8|@$F|18|G|19|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|1A|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1B|8|@$F|1C|G|1D|H|I]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1E|8|@]|9|@$F|1F|G|1G|1|1H]]|A|$]]|$1|P|3|Q|5|6|7|1I|8|@$F|1J|G|1K|H|I]]|9|@]|A|$]]|$1|R|3|S|5|6|7|1L|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1M|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1N|8|@$F|1O|G|1P|H|I]]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]]|Y|$Z|$5|10|11|12|A|$13|14]]]]

There is nothing like a silver bullet, everything is built to solve specific problems and has its own pros and cons. It is up to you, what problem statement you have and what is the best fitting solution for that problem.

I will try to answer your questions one by one in the same order you asked them. Since Cassandra is based on the NoSQL family of databases, it's important you understand why use a NoSQL database before I answer your questions.

Why use NoSQL

In the case of RDBMS, making a choice is quite easy because all the databases like MySQL, Oracle, MS SQL, PostgreSQL in this category offer almost the same kind of solutions oriented toward ACID properties. When it comes to NoSQL, the decision becomes difficult because every NoSQL database offers different solutions and you have to understand which one is best suited for your app/system requirements. For example, MongoDB is fit for use cases where your system demands a schema-less document store. HBase might be fit for search engines, analyzing log data, or any place where scanning huge, two-dimensional join-less tables is a requirement. Redis is built to provide In-Memory search for varieties of data structures like trees, queues, linked lists, etc and can be a good fit for making real-time leaderboards, pub-sub kind of system. Similarly there are other databases in this category (Including Cassandra) which are fit for different problem statements. Now lets move to the original questions, and answer them one by one.

When to use Cassandra

Being a part of the NoSQL family, Cassandra offers a solution for problems where one of your requirements is to have a very heavy write system and you want to have a quite responsive reporting system on top of that stored data. Consider the use case of Web analytics where log data is stored for each request and you want to built an analytical platform around it to count hits per hour, by browser, by IP, etc in a real time manner. You can refer to <a href="http://blogs.shephertz.com/2015/04/22/why-cassandra-excellent-choice-for-realtime-analytics-workload/" rel="noreferrer">this</a> blog post to understand more about the use cases where Cassandra fits in. 

When to Use a RDMS instead of Cassandra

Cassandra is based on a NoSQL database and does not provide ACID and relational data properties. If you have a strong requirement for ACID properties (for example Financial data), Cassandra would not be a fit in that case. Obviously, you can make a workaround for that, however you will end up writing lots of application code to simulate ACID properties and will lose on time to market badly. Also managing that kind of system with Cassandra would be complex and tedious for you.

When not to use Cassandra

I don't think it needs to be answered if the above explanation makes sense.

blocks|key|308783|text|如果您需要一个具有SQL语义的完全一致的数据库，Cassandra不是您的解决方案。Cassandra支持键值查找。它不支持SQL查询。Cassandra中的数据“最终是一致的”。数据的并发查找可能不一致，但最终查找是一致的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|308784|如果您需要严格的语义，并且需要支持SQL查询，那么可以选择另一个解决方案，比如MySQL、PostGres，或者结合使用Cassandra和Solr。|308785|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you need a fully consistent database with SQL semantics, Cassandra is NOT the solution for you. Cassandra supports key-value lookups. It does not support SQL queries. Data in Cassandra is "eventually consistent". Concurrent lookups of data may be inconsistent, but eventually lookups are consistent. 

If you need strict semantics and need support for SQL queries, choose another solution such as MySQL, PostGres, or combine use of Cassandra with Solr.

blocks|key|313956|text|根据DataStax的说法，卡桑德拉不是最好的用例，当需要|type|unstyled|depth|inlineStyleRanges|entityRanges|data|313957|1-高端硬件设备。2-符合ACID，无回滚(银行交易)|313958|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

According to DataStax, Cassandra is not the best use case when there is a need for

1- High end hardware devices.
2- ACID compliant with no roll back (bank transaction)

blocks|key|313965|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|313966|它不支持跨表的完整事务管理。|unordered-list-item|313967|辅助索引不是supported.|313968|Have要依赖于弹性搜索/Solr的辅助索引，必须写入自定义同步组件。|313969|不符合ACID的系统。|313970|查询支持有限。|313971|313972|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|O|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|P|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|Q|7|@]|8|@]|9|$]]|$1|F|3|G|4|C|6|R|7|@]|8|@]|9|$]]|$1|H|3|I|4|C|6|S|7|@]|8|@]|9|$]]|$1|J|3|K|4|C|6|T|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|U|7|@]|8|@]|9|$]]|$1|M|3|-4|4|5|6|V|7|@]|8|@]|9|$]]]|N|$]]

<ul>
<li>It does not support complete transaction management across the
tables. </li>
<li>Secondary Index not supported.</li>
<li>Have to rely on Elastic search /Solr for Secondary index and the custom sync component has to be written.</li>
<li>Not ACID compliant system.</li>
<li>Query support is limited.</li>
</ul>

blocks|key|314008|text|除了上面给出的何时使用和何时不使用Cassandra的答案之外，如果你决定使用Cassandra，你可能会考虑不使用Cassandra本身，而是它的众多表亲之一。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|314009|上面的一些答案已经指出了各种"NoSQL“系统，它们与Cassandra有许多相同的属性，但有一些或小或大的差异，可能比Cassandra本身更适合您的特定需求。|314010|此外，最近(这个问题最初被问到几年后)，名为“锡拉”的卡桑德拉克隆被发布(参见https://en.wikipedia.org/wiki/Scylla_(database)+)。Scylla是Cassandra在C%2B%2B中的开源重新实现，它声称比原始的Java+Cassandra具有更高的吞吐量和更低的延迟，同时几乎与其兼容(在功能、API和文件格式方面)。因此，如果你已经在考虑Cassandra，你可能也想考虑Scylla。|offset|length|314011|entityMap|0|LINK|mutability|MUTABLE|url|https://en.wikipedia.org/wiki/Scylla_(database%2529)^0|0|0|13|1B|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Besides the answers given above about when to use and when not to use Cassandra, if you do decide to use Cassandra you may want to consider not using Cassandra itself, but one of the its many cousins out there.

Some answers above already pointed to various "NoSQL" systems which share many properties with Cassandra, with some small or large differences, and may be better than Cassandra itself for your specific needs.

Additionally, recently (several years after this question was originally asked), a Cassandra clone called Scylla (see <a href="https://en.wikipedia.org/wiki/Scylla_(database)" rel="noreferrer">https://en.wikipedia.org/wiki/Scylla_(database)</a>) 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.

blocks|key|3050762|text|Apache+cassandra是一个分布式数据库，用于管理许多商用服务器上的大量结构化数据，同时提供高可用性服务和无单点故障。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3050763|该体系结构纯粹基于上限定理，即可用性和分区容忍度，有趣的是最终是一致的。|3050764|3050765|请勿使用它，如果您未跨群集机架存储大量数据，请勿使用如果您未存储时间序列数据，请勿使用如果您未分配服务器，请勿使用如果您需要强一致性。|blockquote|3050766|3050767|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|M|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|N|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]]|J|$]]

Apache cassandra is a distributed database for managing large amounts of structured data across many commodity servers, while providing highly available service and no single point of failure.

The archichecture is purely based on the cap theorem, which is availability , and partition tolerance, and interestingly eventual consistently.

<blockquote>
 Dont Use it, if your not storing volumes of data across racks of clusters,
 Dont use if you are not storing Time series data,
 Dont Use if you not patitioning your servers, 
 Dont use if you require strong Consistency.
</blockquote>

blocks|key|3264534|text|在以下情况下，Cassandra是一个不错的选择：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3264535|3264536|你不需要数据库的ACID属性。|ordered-list-item|3264537|在数据库上会有大量的写操作。|3264538|需要与大数据、Hadoop、Hive和Spark集成。|3264539|需要实时数据分析和报告ACID是令人印象深刻的容错能力的要求，Hadoop是同构系统的要求。|3264540|需要进行大量自定义以进行调整。|3264541|3264542|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|T|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|W|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|P|$]]

Cassandra is a good choice if:

<ol>
<li>You don't require the ACID properties from your DB.</li>
<li>There would be massive and huge number of writes on the DB.</li>
<li>There is a requirement to integrate with Big Data, Hadoop, Hive and Spark.</li>
<li>There is a need of real time data analytics and report generations.</li>
<li>There is a requirement of impressive fault tolerant mechanism.</li>
<li>There is a requirement of homogenous system. </li>
<li>There is a requirement of lots of customisation for tuning.</li>
</ol>

blocks|key|311972|text|你应该问你自己以下问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|311973|311974|(Volume，Velocity)您将写入和读取大量的信息，如此之多的信息以至于没有一台计算机能够处理这些写入。|ordered-list-item|offset|length|style|BOLD|311975|(Global)您是否需要世界各地的这种写入和读取功能，以便可以在世界的另一部分访问世界某一部分的写入？|311976|(Reliability)您是否需要此数据库始终保持正常运行，并且无论是哪个云、哪个国家/地区、是虚拟机、容器或者裸机？|311977|(Scale-ability)您是否需要此数据库能够继续轻松增长和线性扩展|311978|(Consistency)您是否需要可调一致性(某些写入可以异步进行，而其他写入则需要进行认证)？|311979|(Skill)您是否愿意采取一切必要措施来学习此技术和数据建模，以创建可在任何地方、任何人都能快速使用的全球分布式数据库？|311980|311981|对于这些问题中的任何一个，如果你认为“可能”或“不是”，你应该使用其他的东西。如果你对所有问题的回答都是“见鬼了”，那么你应该使用Cassandra。|311982|当你可以在一台机器上做所有的事情时，就使用RDBMS。它可能比大多数更简单，任何人都可以使用它。|311983|entityMap^0|0|0|0|H|0|0|8|0|0|D|0|0|F|0|0|D|0|0|7|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|12|8|@$F|13|G|14|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|15|8|@$F|16|G|17|H|I]]|9|@]|A|$]]|$1|L|3|M|5|E|7|18|8|@$F|19|G|1A|H|I]]|9|@]|A|$]]|$1|N|3|O|5|E|7|1B|8|@$F|1C|G|1D|H|I]]|9|@]|A|$]]|$1|P|3|Q|5|E|7|1E|8|@$F|1F|G|1G|H|I]]|9|@]|A|$]]|$1|R|3|S|5|E|7|1H|8|@$F|1I|G|1J|H|I]]|9|@]|A|$]]|$1|T|3|-4|5|6|7|1K|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1L|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1M|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]]|Z|$]]

You should ask your self the following questions:

<ol>
<li>(Volume, Velocity) Will you be writing and reading TONS of information , so much information that no one computer could handle the writes. </li>
<li>(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? </li>
<li>(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? </li>
<li>(Scale-ability) Do you need this database to be able to continue to grow easily and scale linearly </li>
<li>(Consistency) Do you need TUNABLE consistency where some writes can happen asynchronously where as others need to be certified? </li>
<li>(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?</li>
</ol>

If for any of these questions you thought "maybe" or "no," you should use something else. If you had "hell yes" as an answer to all of them, then you should use Cassandra. 

Use RDBMS when you can do everything on one box. It's probably easier than most and anyone can work with it.

blocks|key|3050966|text|我将在这里集中讨论一些重要的方面，这些方面可以帮助您决定是否真的需要Cassandra。这份清单不是详尽的，只是我脑海中的一些观点-|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3050967|当您对关系有严格的要求(跨数据集)时，不要将|3050968|视为首选。|unordered-list-item|3050969|Cassandra默认为AP系统(属于CAP)。但是，它支持可调一致性，这意味着它也可以配置为支持as+CP。CassandraCassandra.cassandra.cassandra.c|3050970|如果你的团队认为如果你使用像Cassandra这样的分布式数据库，你的所有问题都会得到解决，那你就得花点心思。开始使用这些数据库非常简单，因为它有许多默认值，但是优化和掌握它来解决特定的问题需要大量的工程工作(如果不是很多的话)。|3050971|Cassandra是面向列的，但同时每一行也有一个惟一的键。因此，将其视为索引的、面向行的存储可能会有所帮助。+|3050972|Cassandra不会强制你预先定义字段。因此，如果您处于启动模式，或者您的功能正在发展(如敏捷)--+Cassandra会拥抱它。更好的是，首先考虑查询，然后再考虑数据来回答它们。+|offset|length|style|BOLD|3050973|Cassandra针对真正高吞吐量的写入进行了优化。如果您的用例需要大量读取(如缓存)，则Cassandra可能不是理想的Cassandra|3050974|3050975|entityMap^0|0|0|0|0|0|0|1Z|K|0|Q|18|0|0^^$0|@$1|2|3|4|5|6|7|X|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Y|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Z|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|10|8|@]|9|@]|A|$]]|$1|I|3|J|5|F|7|11|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|13|8|@$O|14|P|15|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|F|7|16|8|@$O|17|P|18|Q|R]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|19|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|W|$]]

I will focus here on some of the important aspects which can help you to decide if you really need Cassandra. The list is not exhaustive, just some of the points which I have at top of my mind-

<ul>
<li>Don't consider Cassandra as the first choice when you have a strict requirement on the relationship (across your dataset). </li>
<li>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.</li>
<li>Don't use Cassandra if your scale is not much or if you can deal with a non-distributed DB. </li>
<li>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. </li>
<li>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. </li>
<li>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. </li>
<li>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. </li>
</ul>

blocks|key|311140|text|正确的。当你有大量的数据，大量的查询，但是种类很少的查询时，使用Cassandra是有意义的。Cassandra基本上是通过分区和复制来工作的。如果您的所有查询都将基于相同的分区键，那么Cassandra是您最好的选择。如果查询的属性不是分区键，Cassandra允许您使用新的分区键复制整个数据。因此，现在您有两个相同数据的副本，具有两个不同的分区键。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|311141|这就引出了你的下一个问题。When+not+to+use+Cassandra.正如我所提到的，Cassandra通过为每个新分区键复制完整的数据库来进行扩展。但你不能一次又一次地复制新的副本。因此，当您有大量的查询，即每个查询在where子句中有不同的列时，Cassandra不是一个好的选择。|offset|length|style|BOLD|311142|现在是第三个问题。使用关系型数据库管理系统的主要目的是在需要ACID属性的时候。如果您正在构建类似于支付服务的东西，并且希望每个事务都是隔离的，每个事务要么完成要么根本不发生，即使系统故障也要持久更改，并且在事务完成之前和之后在银行帐户之间保持一致，那么RDBMS是唯一可以帮助您实现这一点的选择。|311143|本文实际上解释了整个问题，特别是在问题->+Choosing+the+best+Database中何时使用Cassandra或不使用Cassandra(与其他NoSQL选项相对)。一定要检查一下。|311144|编辑：为了回答proximab评论中的问题，当我们想到银行系统时，我们立即认为"ACID是最好的解决方案“。但即使是银行系统也是由几个子系统组成的，这些子系统甚至可能不处理任何与交易相关的数据，如帐户持有人的个人信息、帐户对账单、信用卡详细信息、信用记录等。|311145|所有这些信息都需要存储在某个或另一个数据库中。现在，如果您存储与帐户相关的信息，如帐户余额，则需要始终保持一致。例如，如果您尝试将钱从帐户A发送到帐户B，则从帐户A消失的钱应该立即出现在帐户B中，并且不能同时出现在两个帐户中。这个系统在任何时候都不能不一致。这就是ACID最重要的地方。|311146|另一方面，如果您要保存信用卡详细信息或信用记录，这些信息不应落入坏人手中，那么您需要只允许授权用户访问的内容。我相信是由Cassandra支持的。也就是说，像信用记录和信用卡交易这样的数据，我认为这是一个不断增长的数据。此外，yo可以对此数据进行的查询也只有这么多，即它的查询次数非常有限。这两个条件使Cassandra成为一个完美的解决方案。|311147|entityMap|0|LINK|mutability|MUTABLE|url|https://towardsdatascience.com/choosing-the-right-database-in-a-system-design-interview-b8af9c6dc525?source=friends_link&sk=d78ef7e0b0f4071636c57681b9fce1c8^0|0|I|3|0|U|4|0|M|Q|0|0|0|2|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|10|8|@$D|11|E|12|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|13|8|@$D|14|E|15|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|16|8|@]|9|@$D|17|E|18|1|19]]|A|$]]|$1|L|3|M|5|6|7|1A|8|@$D|1B|E|1C|F|G]]|9|@]|A|$]]|$1|N|3|O|5|6|7|1D|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1E|8|@]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|S|$T|$5|U|V|W|A|$X|Y]]]]

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.
Which brings me to your next question. When not to use Cassandra. As I mentioned, Cassandra scales by replicating the complete database for every new partitioning key. But you can't keep making new copies again and again. So when you have a high variety in queries i.e. each query has a different column in the where clause, Cassandra is not a good option.
Now for the third question. The whole point of using RDBMS is when you want the ACID properties. If you are building something like a payment service and want each transaction to be isolated, each transaction to either complete or not happen at all, changes to be persistent despite system failure, and the money to be consistent across bank accounts before and after the transaction completes, an RDBMS is the only option that will help you achieve this.
This article actually explains the whole thing, especially when to use Cassandra or not (as opposed to some other NoSQL option) part of the question -&gt; <a href="https://towardsdatascience.com/choosing-the-right-database-in-a-system-design-interview-b8af9c6dc525?source=friends_link&amp;sk=d78ef7e0b0f4071636c57681b9fce1c8" rel="noreferrer">Choosing the best Database</a>. Do check it out.
EDIT: To answer the question in the comments by proximab, when we think of banking systems we immidiately think &quot;ACID is the best solution&quot;. But even banking systems are made up of several subsystems that might not even be dealing with any transaction related data like account holder's personal information, account statements, credit card details, credit histories, etc.
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.
On the other hand if you are saving credit card details or credit histories, that should not get into the wrong hands, then you need something that allows access only to authorised users. That I believe is supported by Cassandra. That said, data like credit history and credit card transactions, I think that is an ever increasing data. Also there is only so much yo can query on this data i.e. it has a very finite number of queries. These two conditions make Cassandra a perfect solution.

There has been a lot of talk related to <a href="http://cassandra.apache.org/">Cassandra</a> lately.

Twitter, Digg, Facebook, etc all use it.

When does it make sense to:

<ul>
<li>use Cassandra,</li>
<li>not use Cassandra, and</li>
<li>use a RDMS instead of Cassandra.</li>
</ul>

When NOT to use Cassandra?

分布式数据库

关系型数据库

结构化数据

数据库管理

数据建模

数据存储

PostgreSQL

数据库

服务器

虚拟机

大数据

MongoDB

Hadoop 

容器

HBase

Spark 

NoSQL

Redis

MySQL

最近有很多关于的讨论。Twitter、Digg、Facebook等都在使用它。什么时候才有意义：使用Cassandra，不使用Cassandra，使用RDMS而不是Cassandra。

问什么时候不使用Cassandra？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候不使用Cassandra？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候不使用Cassandra？
EN