我正在评估什么是最好的迁移选项 .
目前，我使用分片MySQL（水平分区），我的大部分数据存储在JSON blob中 . 我没有任何复杂的SQL查询（自从我对数据库进行分区后已经迁移过了） .
现在，似乎MongoDB和Cassandra都可能是选择 . 我的情况：
每个查询中有大量读取，而不是常规写入
不担心"massive"可伸缩性
更关注简单的设置，维护和代码
最大限度地降低硬件/服务器成本
我可能会成为一个奇怪的人，但我认为你需要留在MySQL . 您还没有描述需要解决的实际问题，即使对于blob / json数据，MySQL / InnoDB也是一个出色的存储后端 .
Web工程师有一个常见的伎俩，一旦实现并未使用RDBMS的所有功能，就会尝试使用更多的NoSQL . 仅此一点并不是一个好理由，因为大多数情况下NoSQL数据库的数据引擎相当差（MySQL称之为存储引擎） .
现在，如果您不是那种类型，那么请指明MySQL中缺少的内容，并且您正在寻找不同的数据库（例如，自动分片，自动故障转移，多主复制，以及较弱的数据一致性保证）群集在更高的写入吞吐量等方面得到了回报 .
我已经广泛使用了MongoDB（过去6个月），构建了一个分层数据管理系统，我可以保证设置的简易性（安装，运行，使用它！）和速度 . 只要你仔细考虑索引，它就可以绝对地尖叫，速度方面 .
我认为Cassandra由于其在Twitter等大型项目中的使用，具有更好的扩展功能，尽管MongoDB团队正在努力实现平价 . 我应该指出，我没有在试运行阶段之外使用Cassandra，所以我不能说明细节 .
当我们评估NoSQL数据库时，对我来说真正的摇摆是查询 - Cassandra基本上只是一个巨大的键/值存储，查询有点繁琐（至少与MongoDB相比），所以对于性能你必须将很多数据复制为一种手动索引 . 另一方面，MongoDB使用“按示例查询”模型 .
例如，假设您有一个包含Users的Collection（MongoDB用于等效于RDMS表的用法） . MongoDB将记录存储为Documents，它们基本上是二进制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数据存储区进行读取 - 然后您将从每项技术的优势中受益 . 这确实增加了更多的复杂性，但你已经拥有MySQL方面 - 只需添加MongoDB，Cassandra等 .
对于相同的规范，NoSQL数据存储通常比传统数据库更好地扩展 - 有一个原因，Facebook，Twitter，谷歌和大多数初创公司都在使用NoSQL解决方案 . 这不只是极客们对新技术的高度重视 .
我没有使用过Cassandra，但是我使用过MongoDB并认为它很棒 .
如果你的简单设置，这就是它 . 你只需解压MongoDB并运行mongod守护进程就可以了 . 它正在运行 .
显然这只是一个首发，但为了让你开始它很容易 .
我昨天在mongodb上看过一个演讲 . 我可以肯定地说，设置是“简单的”，就像打开包装并将其启动一样简单 . 完成 .
我相信mongodb和cassandra几乎可以在任何常规的Linux硬件上运行，所以你不应该在那个领域找到很多障碍 .
我认为在这种情况下，在一天结束时，它将归结为您个人感觉更舒服，哪个有您喜欢的工具集 . 至于关于mongodb的演示文稿，主持人表示mongodb的工具集很轻，并且没有很多（他们说的任何真正的）工具类似于可用于MySQL的工具 . 这当然是他们的体验，所以YMMV . 我对mongodb所做的一件事就是它似乎有很多语言支持（Python和.NET是我主要使用的两种语言） .
使用mongodb的网站列表相当impressive，我知道Twitter刚刚切换到使用cassandra .
Lots of reads in every query, fewer regular writes
两个数据库在热数据集适合内存的读取中表现良好 . 两者都强调无连接数据模型（并鼓励非规范化）而且，两者都提供documents或rows的索引，尽管MongoDB的索引目前更灵活 .
无论您的数据集有多大，Cassandra的存储引擎都能提供恒定时间写入 . 在MongoDB中写入更有问题，部分原因是基于b树的存储引擎，但更多是因为multi-granularity locking它 .
对于分析，MongoDB提供自定义map / reduce实现; Cassandra提供本机Hadoop支持，包括Hive（基于Hadoop map / reduce构建的SQL数据仓库）和Pig（许多人认为特定于Hadoop的分析语言比SQL更适合映射/减少工作负载） . Cassandra还支持使用Spark .
Not worried about "massive" scalability
如果您正在查看单个服务器，MongoDB可能更适合 . 对于那些更关心扩展的人来说，Cassandra的无单点故障架构将更容易设置和更可靠 . （MongoDB的全局写锁也会变得更加痛苦 . ）Cassandra还可以更好地控制复制的工作方式，包括支持多个数据中心 .
More concerned about simple setup, maintenance and code
两者都很容易设置，单个服务器具有合理的开箱即用默认值 . 由于不需要担心特殊角色节点，因此在多服务器配置中设置Cassandra更加简单 .
如果您目前正在使用JSON blob，那么MongoDB与您的用例非常匹配，因为它使用BSON来存储数据 . 与现有数据库相比，您将能够获得更丰富，更易查询的数据 . 这将是Mongo最重要的胜利 .
6 回答
我可能会成为一个奇怪的人，但我认为你需要留在MySQL . 您还没有描述需要解决的实际问题，即使对于blob / json数据，MySQL / InnoDB也是一个出色的存储后端 .
Web工程师有一个常见的伎俩，一旦实现并未使用RDBMS的所有功能，就会尝试使用更多的NoSQL . 仅此一点并不是一个好理由，因为大多数情况下NoSQL数据库的数据引擎相当差（MySQL称之为存储引擎） .
现在，如果您不是那种类型，那么请指明MySQL中缺少的内容，并且您正在寻找不同的数据库（例如，自动分片，自动故障转移，多主复制，以及较弱的数据一致性保证）群集在更高的写入吞吐量等方面得到了回报 .
我已经广泛使用了MongoDB（过去6个月），构建了一个分层数据管理系统，我可以保证设置的简易性（安装，运行，使用它！）和速度 . 只要你仔细考虑索引，它就可以绝对地尖叫，速度方面 .
我认为Cassandra由于其在Twitter等大型项目中的使用，具有更好的扩展功能，尽管MongoDB团队正在努力实现平价 . 我应该指出，我没有在试运行阶段之外使用Cassandra，所以我不能说明细节 .
当我们评估NoSQL数据库时，对我来说真正的摇摆是查询 - Cassandra基本上只是一个巨大的键/值存储，查询有点繁琐（至少与MongoDB相比），所以对于性能你必须将很多数据复制为一种手动索引 . 另一方面，MongoDB使用“按示例查询”模型 .
例如，假设您有一个包含Users的Collection（MongoDB用于等效于RDMS表的用法） . MongoDB将记录存储为Documents，它们基本上是二进制JSON对象 . 例如：
如果您想要找到所有名为Smith的用户拥有管理员权限，您只需创建一个新文档（使用Javascript在管理控制台上，或使用您选择的语言在 生产环境 中）：
...然后运行查询 . 而已 . 增加了比较运算符，RegEx过滤等，但它们都非常简单，基于Wiki的文档非常好 .
为什么要在传统数据库和NoSQL数据存储之间进行选择？同时使用！ NoSQL解决方案的问题（超出最初的学习曲线）是缺少事务 - 您对MySQL进行了所有更新，并让MySQL填充NoSQL数据存储区进行读取 - 然后您将从每项技术的优势中受益 . 这确实增加了更多的复杂性，但你已经拥有MySQL方面 - 只需添加MongoDB，Cassandra等 .
对于相同的规范，NoSQL数据存储通常比传统数据库更好地扩展 - 有一个原因，Facebook，Twitter，谷歌和大多数初创公司都在使用NoSQL解决方案 . 这不只是极客们对新技术的高度重视 .
我没有使用过Cassandra，但是我使用过MongoDB并认为它很棒 .
如果你的简单设置，这就是它 . 你只需解压MongoDB并运行mongod守护进程就可以了 . 它正在运行 .
显然这只是一个首发，但为了让你开始它很容易 .
我昨天在mongodb上看过一个演讲 . 我可以肯定地说，设置是“简单的”，就像打开包装并将其启动一样简单 . 完成 .
我相信mongodb和cassandra几乎可以在任何常规的Linux硬件上运行，所以你不应该在那个领域找到很多障碍 .
我认为在这种情况下，在一天结束时，它将归结为您个人感觉更舒服，哪个有您喜欢的工具集 . 至于关于mongodb的演示文稿，主持人表示mongodb的工具集很轻，并且没有很多（他们说的任何真正的）工具类似于可用于MySQL的工具 . 这当然是他们的体验，所以YMMV . 我对mongodb所做的一件事就是它似乎有很多语言支持（Python和.NET是我主要使用的两种语言） .
使用mongodb的网站列表相当impressive，我知道Twitter刚刚切换到使用cassandra .
Lots of reads in every query, fewer regular writes
两个数据库在热数据集适合内存的读取中表现良好 . 两者都强调无连接数据模型（并鼓励非规范化）而且，两者都提供documents或rows的索引，尽管MongoDB的索引目前更灵活 .
无论您的数据集有多大，Cassandra的存储引擎都能提供恒定时间写入 . 在MongoDB中写入更有问题，部分原因是基于b树的存储引擎，但更多是因为multi-granularity locking它 .
对于分析，MongoDB提供自定义map / reduce实现; Cassandra提供本机Hadoop支持，包括Hive（基于Hadoop map / reduce构建的SQL数据仓库）和Pig（许多人认为特定于Hadoop的分析语言比SQL更适合映射/减少工作负载） . Cassandra还支持使用Spark .
Not worried about "massive" scalability
如果您正在查看单个服务器，MongoDB可能更适合 . 对于那些更关心扩展的人来说，Cassandra的无单点故障架构将更容易设置和更可靠 . （MongoDB的全局写锁也会变得更加痛苦 . ）Cassandra还可以更好地控制复制的工作方式，包括支持多个数据中心 .
More concerned about simple setup, maintenance and code
两者都很容易设置，单个服务器具有合理的开箱即用默认值 . 由于不需要担心特殊角色节点，因此在多服务器配置中设置Cassandra更加简单 .
如果您目前正在使用JSON blob，那么MongoDB与您的用例非常匹配，因为它使用BSON来存储数据 . 与现有数据库相比，您将能够获得更丰富，更易查询的数据 . 这将是Mongo最重要的胜利 .