我广泛地使用MongoDB(在过去的6个月里)，构建了一个分层的数据管理系统，我可以保证安装的简易性(安装、运行、使用!)和速度。只要您仔细考虑索引，它绝对可以在速度方面快速运行。

我收集到Cassandra，由于它被用于像Twitter这样的大型项目，有更好的扩展功能，尽管MongoDB团队正在那里进行对等工作。我应该指出的是，我在试运行阶段之后就没有使用过Cassandra，所以我不能透露细节。

对我来说，当我们评估NoSQL数据库时，真正的摇摆是查询——Cassandra基本上只是一个巨大的键/值存储，查询有点繁琐(至少与MongoDB相比)，所以为了性能，你必须复制相当多的数据作为一种手动索引。另一方面，MongoDB使用“按示例查询”模型。

例如，假设您有一个包含Users的Collection (MongoDB中相当于RDMS表的说法)。MongoDB将记录存储为文档，基本上是二进制JSON对象。例句:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "john@smith.com",
   Groups: ["Admin", "User", "SuperUser"]
}

如果你想找到所有名为Smith的拥有Admin权限的用户，你只需要创建一个新文档(在管理控制台使用Javascript，或者在生产环境中使用你选择的语言):

{
   LastName: "Smith",
   Groups: "Admin"
}

.．.然后运行查询。就是这样。还添加了用于比较、RegEx过滤等操作符，但都非常简单，基于wiki的文档也非常好。

我广泛地使用MongoDB(在过去的6个月里)，构建了一个分层的数据管理系统，我可以保证安装的简易性(安装、运行、使用!)和速度。只要您仔细考虑索引，它绝对可以在速度方面快速运行。

我收集到Cassandra，由于它被用于像Twitter这样的大型项目，有更好的扩展功能，尽管MongoDB团队正在那里进行对等工作。我应该指出的是，我在试运行阶段之后就没有使用过Cassandra，所以我不能透露细节。

对我来说，当我们评估NoSQL数据库时，真正的摇摆是查询——Cassandra基本上只是一个巨大的键/值存储，查询有点繁琐(至少与MongoDB相比)，所以为了性能，你必须复制相当多的数据作为一种手动索引。另一方面，MongoDB使用“按示例查询”模型。

例如，假设您有一个包含Users的Collection (MongoDB中相当于RDMS表的说法)。MongoDB将记录存储为文档，基本上是二进制JSON对象。例句:

{
   FirstName: "John",
   LastName: "Smith",
   Email: "john@smith.com",
   Groups: ["Admin", "User", "SuperUser"]
}

如果你想找到所有名为Smith的拥有Admin权限的用户，你只需要创建一个新文档(在管理控制台使用Javascript，或者在生产环境中使用你选择的语言):

{
   LastName: "Smith",
   Groups: "Admin"
}

.．.然后运行查询。就是这样。还添加了用于比较、RegEx过滤等操作符，但都非常简单，基于wiki的文档也非常好。

我可能会成为一个奇怪的人，但我认为你需要继续使用MySQL。你没有描述你需要解决的真正问题，MySQL/InnoDB是一个优秀的存储后端，即使是blob/json数据。

在Web工程师中有一个常见的技巧，即在意识到RDBMS并没有使用所有特性时尝试使用更多的NoSQL。这本身并不是一个好的理由，因为大多数情况下NoSQL数据库的数据引擎(MySQL称之为存储引擎)相当差。

现在，如果你不是这样的人，那么请说明MySQL中缺少什么，你正在寻找一个不同的数据库(比如，自动分片，自动故障转移，多主复制，集群中较弱的数据一致性保证，以更高的写吞吐量，等等)。

为什么要在传统数据库和NoSQL数据存储之间进行选择?同时使用!NoSQL解决方案的问题(超出了最初的学习曲线)是缺乏事务——你对MySQL进行所有更新，并让MySQL填充一个NoSQL数据存储进行读取——然后你从每种技术的优势中受益。这确实增加了更多的复杂性，但您已经有了MySQL方面——只需将MongoDB、Cassandra等添加到混合中。

在相同规格的情况下，NoSQL数据存储通常比传统数据库的扩展性更好——这就是为什么Facebook、Twitter、谷歌和大多数初创企业都在使用NoSQL解决方案的原因。不仅仅是极客们在新科技上兴奋。

每个查询都有大量的读操作，很少有常规的写操作

当热数据集适合内存时，这两个数据库在读取时都表现良好。两者都强调无连接数据模型(鼓励非规格化)，都提供文档或行索引，不过MongoDB的索引目前更加灵活。

Cassandra的存储引擎提供恒定时间的写入，无论您的数据集增长有多大。在MongoDB中写的问题更大，部分原因是基于b-树的存储引擎，但更多的原因是它所做的多粒度锁定。

对于分析，MongoDB提供了一个自定义的map/reduce实现;Cassandra提供原生Hadoop支持，包括Hive(一种基于Hadoop map/reduce构建的SQL数据仓库)和Pig(一种Hadoop特定的分析语言，许多人认为它比SQL更适合map/reduce工作负载)。Cassandra也支持Spark的使用。

不担心“大规模”的可伸缩性

如果您正在查看单个服务器，MongoDB可能是一个更好的选择。对于那些更关心扩展的人来说，Cassandra的无单点故障架构将更容易建立，也更可靠。(MongoDB的全局写锁也会变得更加痛苦。)Cassandra还可以更好地控制复制的工作方式，包括支持多个数据中心。

更关心简单的设置、维护和代码

两者的设置都很简单，对于单个服务器都有合理的开箱即用的默认值。Cassandra在多服务器配置中更容易设置，因为不需要担心特殊角色的节点。

如果您目前正在使用JSON blobs, MongoDB非常适合您的用例，因为它使用BSON存储数据。您将能够拥有比当前数据库更丰富、更可查询的数据。这将是Mongo最重要的胜利。

昨天我看了一个关于mongodb的报告。我可以肯定地说，这个设置很“简单”，就像打开并启动它一样简单。完成了。

我相信mongodb和cassandra几乎可以在任何常规的linux硬件上运行，所以在这方面你不应该发现太多的障碍。

I think in this case, at the end of the day, it will come down to which do you personally feel more comfortable with and which has a toolset that you prefer. As far as the presentation on mongodb, the presenter indicated that the toolset for mongodb was pretty light and that there werent many (they said any really) tools similar to whats available for MySQL. This was of course their experience so YMMV. One thing that I did like about mongodb was that there seemed to be lots of language support for it (Python, and .NET being the two that I primarily use).

使用mongodb的站点列表非常令人印象深刻，我知道twitter刚刚改用cassandra。