aja*_*jay 155
没有像银弹一样的东西,一切都是为解决具体问题而建立的,并且各有利弊.这取决于你,你有什么问题陈述,以及什么是最适合该问题的解决方案.
我会按照你问他们的顺序逐一回答你的问题.由于Cassandra基于NoSQL系列数据库,因此在我回答您的问题之前,了解为何使用NoSQL数据库非常重要.
为什么要使用NoSQL
对于RDBMS,做出选择非常简单,因为此类别中的所有数据库(如MySQL,Oracle,MS SQL,PostgreSQL)都提供了几乎与ACID属性相同的解决方案.在NoSQL方面,决策变得困难,因为每个NoSQL数据库都提供不同的解决方案,您必须了解哪一个最适合您的应用程序/系统要求.例如,MongoDB适用于系统需要无架构文档存储的用例.HBase可能适合搜索引擎,分析日志数据,或任何需要扫描巨大的二维无连接表的地方.Redis旨在为各种数据结构(如树,队列,链表等)提供内存搜索,并且非常适合制作实时排行榜,pub-sub类型的系统.同样,此类别中的其他数据库(包括Cassandra)适用于不同的问题陈述.现在让我们转到原始问题,然后逐一回答.
什么时候使用Cassandra
作为NoSQL系列的一部分,Cassandra提供了一个解决问题的解决方案,其中一个要求是拥有一个非常繁重的写入系统,并且您希望在存储的数据之上拥有一个响应迅速的报告系统.考虑Web分析的用例,其中为每个请求存储日志数据,并且您希望围绕它构建分析平台,以实时方式按浏览器,IP等计算每小时的点击次数.您可以参考此博客文章,以了解有关Cassandra适合的用例的更多信息.
何时使用RDMS而不是Cassandra
Cassandra基于NoSQL数据库,不提供ACID和关系数据属性.如果您对ACID属性有强烈要求(例如财务数据),那么Cassandra就不适合.显然,你可以为此做一个解决方法,但是你最终会编写大量的应用程序代码来模拟ACID属性,并且会很快失去市场.使用Cassandra管理这种系统对你来说既复杂又乏味.
何时不使用Cassandra
如果上述解释有意义,我认为不需要回答.
Nat*_*rst 48
在评估分布式数据系统时,您必须考虑CAP定理 - 您可以选择以下两项:一致性,可用性和分区容差.
Cassandra是一个可用的分区容错系统,支持最终的一致性.有关更多信息,请参阅我写的这篇博客文章:NoSQL系统的可视指南.
Vag*_*rdi 28
Cassandra是一个特定问题的答案:当你拥有如此多的数据而不适合一台服务器时,你会怎么做？如何将您的所有数据存储在许多服务器上,不要破坏您的银行帐户,不要让您的开发人员疯狂？Facebook每天都会获得4TB的新压缩数据.这个数字最有可能在一年内增长两倍以上.
如果您没有这么多数据,或者您有数百万美元需要支付Enterprise Oracle/DB2集群安装以及设置和维护它所需的专家,那么您可以使用SQL数据库.
然而Facebook不再使用cassandra,现在使用MySQL几乎专门在应用程序堆栈中移动分区,以实现更快的性能和更好的控制.
Tom*_*son 27
NoSQL的一般概念是你应该使用最适合你的应用程序的数据存储.如果您有财务数据表,请使用SQL.如果您的对象需要复杂/慢速查询以映射到关系模式,请使用对象或键/值存储.
当然,您遇到的任何现实世界问题都介于这两个极端之间,并且两种解决方案都不是完美的.您需要考虑每个商店的功能以及使用其中一个的后果,这将非常具体地解决您要解决的问题.
Nad*_*'El 13
除了上面给出的关于什么时候使用以及什么时候不使用Cassandra的答案,如果你决定使用Cassandra,你可能想要考虑不使用Cassandra本身,而是使用其中的许多表兄弟之一.
上面的一些答案已经指出各种"NoSQL"系统与Cassandra共享许多属性,有一些小的或大的差异,并且可能比Cassandra本身更适合您的特定需求.
此外,最近(最初询问这个问题几年后),发布了一个名为Scylla的Cassandra克隆(请参阅https://en.wikipedia.org/wiki/Scylla_(database)).Scylla是Cassandra在C++中的一个开源重新实现,它声称具有比原始Java Cassandra更高的吞吐量和更低的延迟,同时与它大多兼容(在功能,API和文件格式中).所以,如果你已经在考虑Cassandra,你可能也想考虑Scylla.
rai*_*mar 12
我将在这里重点介绍一些重要方面，它们可以帮助您确定是否真的需要 Cassandra。该列表并非详尽无遗，只是我最想到的一些要点-
当您对关系（跨数据集）有严格要求时，不要将 Cassandra 视为首选。
Cassandra 默认是 AP 系统（CAP）。但是，它支持可调一致性，这意味着它也可以配置为支持 CP。所以不要因为你在某处读到它是 AP 而你正在寻找 CP 系统而忽略它。Cassandra 被更准确地称为“可调一致性”，这意味着它允许您轻松地决定所需的一致性级别，并与可用性级别保持平衡。
如果您的规模不大或者您可以处理非分布式数据库，请不要使用 Cassandra。
如果您的团队认为如果您使用像 Cassandra 这样的分布式数据库，您的所有问题都将得到解决，请多想想。开始使用这些 DB 非常简单，因为它带有许多默认值，但是优化和掌握它以解决特定问题需要大量的工程工作（如果不是很多的话）。
Cassandra 是面向列的，但同时每一行也有一个唯一的键。因此，将其视为索引的、面向行的存储可能会有所帮助。您甚至可以将其用作文档存储。
Cassandra 不会强迫您事先定义字段。因此，如果您处于启动模式或您的功能正在发展（如敏捷） - Cassandra 会接受它。所以更好的是，首先考虑查询，然后考虑数据来回答它们。
Cassandra 针对真正的高写入吞吐量进行了优化。如果您的用例需要大量读取（如缓存），那么 Cassandra 可能不是理想的选择。
小智 9
在部署Cassandra的过程中与某人交谈时,它并不能很好地处理多对多的问题.他们正在做一个黑客工作来进行初步测试.我和一位Cassandra顾问谈过这件事,他说如果你有这个问题,他就不会推荐它.
小智 5
你应该问自己以下问题：
如果对于这些问题中的任何一个，您认为“可能”或“否”，您应该使用其他方法。如果您对所有这些问题的回答都是“地狱是”，那么您应该使用 Cassandra。
当您可以在一个盒子上完成所有事情时，请使用 RDBMS。它可能比大多数人更容易，任何人都可以使用它。
对。当您拥有大量数据、大量查询但查询种类很少时，使用 Cassandra 是有意义的。Cassandra 基本上通过分区和复制来工作。如果您的所有查询都基于相同的分区键，那么 Cassandra 是您的最佳选择。如果您查询的不是分区键的属性，Cassandra 允许您使用新的分区键复制整个数据。所以现在您有 2 个具有 2 个不同分区键的相同数据的副本。
这让我想到你的下一个问题。何时不使用 Cassandra。正如我提到的，Cassandra 通过为每个新的分区键复制完整的数据库来扩展。但是你不能一次又一次地制作新的副本。因此，当您的查询种类繁多时，即每个查询在 where 子句中都有不同的列时，Cassandra 不是一个好的选择。
现在是第三个问题。使用 RDBMS 的全部意义在于何时需要ACID属性。如果您正在构建支付服务之类的东西，并希望将每笔交易隔离开来，每笔交易要么完成要么根本不发生，尽管系统出现故障，但更改仍是持久的，并且交易前后银行账户中的资金保持一致完成后，RDBMS 是帮助您实现这一目标的唯一选择。
这篇文章实际上解释了整个事情，尤其是何时使用 Cassandra（与其他一些 NoSQL 选项相反）问题的一部分 ->选择最佳数据库。请检查一下。
编辑：为了回答 proximab 评论中的问题，当我们想到银行系统时，我们立即认为“ACID 是最佳解决方案”。但即使是银行系统也由多个子系统组成，这些子系统甚至可能不处理任何与交易相关的数据，如账户持有人的个人信息、账户报表、信用卡详细信息、信用历史等。
所有这些信息都需要存储在某个数据库或另一个数据库中。现在，如果您存储与帐户相关的信息（例如帐户余额），则需要始终保持一致。例如，如果您尝试从账户 A 向账户 B 发送资金，那么从账户 A 消失的资金应该会立即出现在账户 B 中，并且不能同时出现在两个账户中。这个系统在任何时候都不能不一致。这就是 ACID 最重要的地方。
另一方面，如果您要保存信用卡详细信息或信用历史记录，这不应该落入坏人之手，那么您需要一些仅允许授权用户访问的内容。我相信这得到了 Cassandra 的支持。也就是说，信用记录和信用卡交易等数据，我认为这是一个不断增加的数据。也只有这么多你可以查询这个数据，即它的查询数量非常有限。这两个条件使 Cassandra 成为一个完美的解决方案。