NoSQL 数据库(尤其是 Cassandra)凭借其以更便宜的成本实现高可扩展性的 promise 而引起了广泛关注。
关于 Cassandr 被 facebook、twitter 和 digg 等社交网络专业人士采用的议论纷纷。但事实确实如此，fb 在最近的项目中不再真正考虑 Cassandra，而 facebook 也从未完全依赖 cassandra 放弃 mysql，尽管它仍在与 mySQL 苦苦挣扎，而 Cassandra 可能非常适合他们的模型。
Even twitter stepped back from its plans to move to Cassandra cluster
此外，Digg 在其 Cassandra 实现方面也不是很成功(但不清楚谁应该为此负责)。
有了这个，周围就没有大牌玩家以与 Cassandra 一起玩而自豪了..!!
它仍处于alpha 阶段，而且社区规模较小，因此是否应考虑将 Cassandra 用于大型项目的生产环境？对于社交网站，MySQL 和 Cassandra 之间的数据库解决方案是:
- 更易于构建、维护和管理
- 表现良好
- 更便宜的解决方案
- 面向 future (在可扩展性、可靠性等方面)
- 需要更少的人工管理。
在以上所有内容中，我主要怀疑它的可靠性....我是否在用 Cassandra 冒险我的数据!!？？？
您还有其他建议吗？
编辑，2017 年 11 月:请注意原始答案写于 2010 年。Cassandra 现在已成为领先的 NoSQL 数据存储之一。它可靠、成熟并且得到了 Datastax 的良好支持。它发生了重大变化。 super 列消失了，二级索引出现了，使用 JNI 进行了大量改进，它现在具有类似 SQL 的查询语言，并与分布式计算工具(如 Spark 和 Hadoop)很好地集成。随着时间的推移也出现了其他选择；查看 ScyllaDB。
不确定我能否说服你。但是，我正在开发一个使用 Cassandra 的项目。 Cassandra 不是完整的解决方案，但速度非常快，而且非常适合分组信息。
我们已将所有密集的读写数据卸载到 Cassandra，需求较少且确实需要关系完整性的数据仍在 MySQL 中(其上有 MemcacheD)。而且，我猜 Facebook 一定也有 MySQL、Cassandra 和 MemcacheD 的混合体。至少我是这么想的。
回答你的问题(基于我对 Cassandra 和 MySQL 的短暂体验)
- MySQL 是传统的，您可以轻松地在其上进行构建。 Cassandra(或任何新的 NoSQL 方法)需要被吸收，有时您会发现术语冲突。因此，MySQL 在这里胜出。
- 性能明智的 Cassandra 获胜。 (读写性能)
- 如果你在谈论硬件，我不确定。但我想，硬件方面，一个 MySQL master + 四个 slave 与 4 个 Cassandra 节点相同。但老实说，我不知道。
- 可扩展性:Cassandra，可靠性:MySQL。如果您阅读 Cassandra 文档，它会说它最终是一致的。但我还没有测试过 Cassandra 的可靠性。顺便说一句，在可靠性下指出“最终一致性”，并不是说它不可靠。我的意思是，在任何给定时间，您可能不确定节点是否是最新的以及是否具有所有更新。
- 有很多用于数据库管理和变更的自动化工具。但对于 Cassandra 来说，就没有那么多了。所以，MySQL 在这里获胜。但我想，Cassandra 的工具很快就会可用。
我们只是从 Cassandra 开始，我希望有人能指出他们是否发现上面的任何内容不正确。如有必要，我很乐意重新测试和纠正。
刚开始时我没有找到太多文档，但现在看起来 Apache Cassandra 页面上列出了很多文章。引用: