MongoDB与Cassandra
我正在评估什么可能是最好的迁移选项。
目前，我在一个分区的MySQL（水平分区）上，大部分数据都存储在JSON blob中。 我没有任何复杂的SQL查询（自从我将db分区后，已经迁移了）。
现在，似乎MongoDB和Cassandra都可能成为选择。 我的情况：
每个查询中都有大量的读取，更少的正常写入
这两个数据库在热数据集适合内存的读取中表现良好。 两者都强调无连接的数据模型（并鼓励反规范化），并且都为文档或行提供索引，尽管MongoDB的索引当前更加灵活。
Cassandra的存储引擎可以提供恒定时间写入，无论数据集增长多大。 写入在MongoDB中更成问题，部分原因在于基于B树的存储引擎，但更多的原因是每个数据库写入锁定。
对于分析，MongoDB提供了一个自定义的映射/减少实现; Cassandra提供本地Hadoop支持，包括Hive（基于Hadoop map / reduce构建的SQL数据仓库）和Pig（许多人认为更适合用于map / reduce工作负载的Hadoop特定分析语言）。
不担心“大规模”的可扩展性
如果您正在查看单个服务器，MongoDB可能更适合。 对于那些更关心扩展的人来说，Cassandra的非单点故障架构将更容易设置，并且更可靠。 （MongoDB的全局写锁定也会变得更加痛苦。）Cassandra还可以更好地控制复制的工作方式，包括支持多个数据中心。
更关心简单的设置，维护和代码
这两者都是微不足道的设置，对于单个服务器具有合理的现成默认值。 Cassandra更容易在多服务器配置中设置，因为不需要担心特殊角色节点; 这里是一个截屏视频，演示在两分钟内设置一个4节点Cassandra集群。
如果您目前正在使用JSON blob，那么考虑到它使用BSON来存储数据，MongoDB对于您的用例来说非常适合。 您可以拥有比您现在的数据库更丰富，更可查询的数据。 这将是Mongo最重要的胜利。
我广泛使用了MongoDB（过去6个月），构建了一个分层数据管理系统，我可以为安装的简易性（安装，运行，使用它）和速度提供保证。 只要你仔细考虑索引，它可以绝对尖叫，速度明智。
我认为Cassandra由于可以用于像Twitter这样的大型项目而具有更好的扩展功能，尽管MongoDB团队正在努力实现平价。 我应该指出，在试运行阶段之后我还没有使用Cassandra，所以我不能说详细信息。
对于我来说，当我们评估NoSQL数据库时，真正的震撼人心的是询问 - Cassandra基本上只是一个巨大的关键/价值存储区，查询有点烦琐（至少与MongoDB相比），因此对于性能来说，您必须重复相当多的数据作为一种手动索引。 另一方面，MongoDB使用“按实例查询”模型。
例如，假设你有一个包含用户的Collection（MongoDB与RDMS表相当的说法）。 MongoDB将记录存储为文档，基本上是二进制JSON对象。 例如：
{
FirstName: "John",
LastName: "Smith",
Email: "john@smith.com",
Groups: ["Admin", "User", "SuperUser"]
}
如果您想查找所有具有管理员权限的Smith用户，则只需创建一个新文档（在使用Javascript的管理控制台中，或者在使用您选择的语言的生产环境中）：
{
LastName: "Smith",
Groups: "Admin"
}
...然后运行查询。 而已。 有添加运算符进行比较，RegEx过滤等，但它非常简单，基于Wiki的文档相当不错。
为什么选择传统数据库和NoSQL数据存储？ 同时使用！ NoSQL解决方案的问题（超出最初的学习曲线）是缺少事务处理 - 您对MySQL进行所有更新并使MySQL为NoSQL填充NoSQL数据存储区 - 然后，您将受益于每种技术的优势。 这确实增加了更多的复杂性，但是您已经拥有MySQL端 - 只需将MongoDB，Cassandra等添加到混合中即可。
NoSQL数据存储的规模通常比传统数据库的规模要好得多，因为其他规格相同 - Facebook，Twitter，Google和大多数初创公司都在使用NoSQL解决方案。 这不仅仅是极客们对新技术的高度评价。
链接地址: http://www.djcxy.com/p/50229.html