mysql - 在单节点设置中，Cassandra 与 MySQL(或任何其他 RDBMS)相比如何？

Question

在研究了关系数据库、文档存储、图形数据库和面向列的数据库之后，我得出结论，像 Cassandra 这样的东西最适合我的需求。特别是，动态添加列的能力并且不需要严格的架构对我来说很划算。这似乎很好地弥合了相当新颖的图形数据库和耗时考验的 rdbms 之间的差距。

但我担心如何在单个节点上运行 Cassandra。像许多其他人一样，我只能从少量数据开始，所以从多个节点开始是不切实际的。基于另一个优秀的 SO 问题:Why don't you start off with a "single & small" Cassandra server as you usually do it with MySQL?我的结论是，Cassandra 确实可以作为单个节点运行得很好，只要人们愿意放弃从多节点设置中获得的可用性等好处。

似乎还有一些方法可以在 RDBMS 中实现动态添加字段，例如在 SO 上讨论的:How to design a database for User Defined Fields?在某种程度上，这将模仿无模式。

所以我现在想了解 Cassandra 和 MySQL 在单节点设置上的特性和性能方面如何比较？在我的情况下，您会对某人提出什么建议 - 从一个简单的 RDBMS 开始，并计划/打算稍后切换到 Cassandra？或者从 Cassandra 开始？

Answer 1

在 Cassandra 的单节点设置中，Cassandra 的许多优势都丧失了，所以这样做的主要原因是如果您打算在未来扩展到多个节点。在大多数应用程序中，当使用单个节点时，性能往往有利于 RDBMS，因为 RDBMS 是为该环境设计的，并且可以假设所有数据都是本地的。

Cassandra 的优势在于可扩展性和可用性。您可以添加节点以增加容量，拥有多个节点意味着您可以处理硬件故障而不会停机。这些优势是以更困难的模式设计为​​代价的，因为访问主要基于一致性哈希。这也意味着您没有可用的完整 SQL，并且通常必须依赖非规范化技术来支持对数据的快速访问。 Cassandra 在 ACID 事务方面也很弱，因为它天生就很难协调多个节点上的原子操作。

相比之下，RDBMS 是一种更成熟的技术。 ACID 事务没有问题。模式设计要简单得多，因为您可以向任何列添加有效的索引以优化查询，并且您有可用的连接，因此可以在很大程度上消除冗余数据。通过消除冗余数据，可以更轻松地保持数据的一致性，因为例如当有人更改地址时，不需要更新多个数据副本。但是您冒着用完一台机器上的空间来存储所有数据的风险。如果发生磁盘崩溃，您将停机并需要备份来恢复数据，而 Cassandra 通常可以轻松修复不同步的节点上的数据。除了购买更快的机器之外，也没有简单的方法来扩展 RDBMS 以处理更高的事务率。

还有很多其他差​​异，但这些是主要差异。没有一个比另一个更好，但每个都可能更适合某些应用程序。因此，这实际上取决于您的用例要求，哪一个更适合。