mysql json mongodb_使用MongoDB与MySQL有很多JSON字段？

所以，直接回答问题......

如果有一半的数据是无模式的，那么我们选择mongodb，如果使用MySQL，它们将被存储为JSON吗？

无模式存储肯定是使用MongoDB的一个令人信服的理由，但正如您所指出的，将JSON存储在RDBMS中也相当容易 . MongoDB背后的力量在于对无模式存储的丰富查询 .

如果我可以指出关于更新JSON字段的插图中的一个小缺陷，那不仅仅是获取当前值，更新文档然后将其推回数据库 . 该过程必须全部包含在事务中 . 在您开始对数据库进行非规范化之前，事务往往相当简单 . 然后像记录upvote这样简单的东西可以锁定整个模式的表 .

使用MongoDB，没有事务 . 但是，操作几乎总是以允许原子更新的方式构建 . 这通常涉及SQL范例的一些戏剧性转变，但在我看来，一旦你停止尝试强制对象进入表格，它们就相当明显 . 至少，许多其他人遇到了你将面临的同样问题，而Mongo社区往往对他们所克服的挑战相当开放和直言不讳 .

主要帖子等一些数据很关键，因此将使用安全写入保存，计数器等将使用不安全写入进行保存 . 此政策是否基于数据的重要性，写密集性是否正确？

通过“安全写入”我认为你的意思是打开自动的选项每次写入后都会出现“getLastError()” . 我们在DBCollection上有一个非常薄的包装器，允许我们在调用getLastError()时进行细粒度控制 . 但是，我们的策略不是基于“重要”数据的方式，而是基于查询后面的代码是否期望在以下读取中立即可见任何修改 .

一般来说，这仍然是一个糟糕的指标，我们已经迁移到findAndModify()以获得相同的行为 . 在我们仍然显式调用getLastError()的情况下，当数据库可能拒绝写入时，例如当我们使用可能重复的_id insert()时 .

与mysql相比，监控，备份和恢复Mongodb有多容易？我们需要计划定期备份(比如每天)，并在发生灾难时轻松恢复 . 我有什么最好的选择mongoDb使它成为应用程序的安全赌注？

我担心我的备份/恢复策略是否有效，因为我们还没有恢复 . 我们正在遵循MongoDB的备份建议; @ mark-hillick在总结这些方面做得很好 . 我们正在使用副本集，我们已经迁移了MongoDB版本以及引入了新的副本成员 . 到目前为止，我们没有停机时间，所以我不确定我能说得好 .

稳定性，备份，快照，恢复，更广泛的采用，即数据库持久性是指向我使用MySQL作为RDBMS NoSql的原因，即使NoSQL文档存储可以更好地服务于我的目的 .

因此，根据我的经验，MongoDB提供了无模式数据的存储，其中包含一组足够丰富的查询原语，以便通常可以用原子操作替换事务 . 很难忘掉10年的SQL经验，但我遇到的每个问题都已经由社区或10gen直接解决 . 我们没有丢失数据或没有任何我能记得的停机时间 .

简而言之，MongoDB是我在查询，维护，可扩展性和可靠性方面所使用的最佳数据存储生态系统 . 除非我有一个非常明确的关系应用程序，否则我不能使用除SQL以外的任何东西，我会尽一切努力使用MongoDB .

我不为10gen工作，但我非常感谢那些做过的人 .