我考虑从SQL切换到NoSQL，我有点沮丧 . 我是一名自学者，在考虑一个包含大量ad-hoc元数据的项目时，精通MySQL，寻找潜在的替代方案 . 我已经做了很多关于趋势NoSQL替代品的研究，但我不确定他们是否值得转换 . 大多数讨论都是关于我无法考虑的主题，例如可扩展性和性能（这样做会是一个梦想 . ）通过一些背景信息，也许有人可以帮助我 .
现在我正在考虑以典型的第3范式形式设置MySQL，然后将单独的表作为必要元数据的键值，如果不是仅仅完全采用键值 . 不是所有对象的原因都是相同的数据，数据是可变的 . 因此，我无法计划一个明确的设计，即使我可以在同一研究中指出我可能不值得努力（即关键数据更容易 . ）这是迄今为止最快的选择，因为实施是立即给我一些东西 . 我在这里担心的是，我不能确保将所有内容减少到键值是必要的，但我会得到MySQL的安慰 .
作为替代方案，我正在考虑使用Cassandra或MongoDB将所有内容视为带有元数据的对象 . 我觉得这可能比我的MySQL解决方案更干净 . Cassandra很有吸引力，因为它保留了一些熟悉的SQL及其CQL，因此更容易进入 . MongoDB具有JSON（BSON）的吸引力，我觉得我将使用对象（文档）而不是表 . 因此，我的需求感觉更直观 . 从这里开始，考虑到我从RDMS的转变，我将能够做什么样的查询 - 看起来我在Cassandra和MongoDB都失去了一些奢侈品 .
我的主要关注点是，如果仅仅根据我存储和访问数据的方式来改变MySQL是值得的 . 虽然阅读非RDMS资源（这真的改变了我查看数据的方式）非常有启发性，但我不能说Cassandra和MongoDB在我的情况下都没有真正卖掉我的实用程序，特别是考虑到学习和测试所需的时间新技术 .
鉴于我的担忧，考虑转换是明智的还是我坚持使用MySQL是合理的？
1 回答
我们看了两个并且在发现我们自己的测试表明我们可以从Cassandra获得更好的性能后决定了Cassandra .
是的，乍一看，CQL看起来像SQL . 一旦你尝试了，你会发现它非常有限 . 想加入？不 .
想分组吗？不 .
想要找到独特的 Value 观？不 .
想要在不知道 primary key 的情况下选择？不 .
示例：在SQL中，您可以查询任何字段 . 在CQL中，查询是分层的 . 数据是结构化主键，列键，值 . 您需要知道要查询的整个主键，并且至少需要部分列键 . 在指定整个主键和列键之前，不能将结果限制在任何值上 .
想要选择和限制结果？是的，但是这样做的时间会随着数据量的增加而增加，所以如果你有很多，你可能会超时 .
哦，并且为那个cassandra提供的服务将会失败并且可能会使您处于无法在不增加硬盘空间的情况下恢复的状态 . 有60GB的数据？您至少需要一个120 GB的驱动器，并且's if you don' t考虑其他开销 .
如果切换，期望花费大量时间对不同的模式进行基准测试并配置系统 . 要利用cassandra的可扩展性，您需要全面了解复制及其附带的硬件 .
还要考虑一下精彩的mysql文档 . Cassandra 并不总是准确或最新的 . 示例：write_survey做了什么以及如何使用它？ http://www.datastax.com/documentation/cassandra/1.2/webhelp/?pagename=docs&version=1.2&file=#cassandra/tools/../operations/ops_test_compact_compress_t.html
简而言之，SQL到noSQL是一种权衡 . 如果您需要noSQL提供的性能和自由，那么它可能是值得的 . 如果你不这样做，那么你可能会因为最好被归类为beta的软件而陷入困境 .