mysql - 使用带有大量 JSON 字段的 MongoDB 与 MySQL？

Question

有一个微博类型的应用程序。两个主要的基本数据库存储是:MySQL 或 MongoDB。

我计划对大量数据进行非规范化，即对帖子进行的投票存储在投票表中，并且在主帖子表中增加计数。该帖子还涉及其他操作(例如，喜欢，投反对票)。

如果我使用 MySQL，一些数据比固定模式更适合 JSON，以便更快地查找。

例如

POST_ID   |  activity_data

213423424 | { 'likes': {'count':213,'recent_likers' :
             ['john','jack',..fixed list of recent N users]} , 'smiles' : 
             {'count':345,'recent_smilers' :
             ['mary','jack',..fixed list of recent N users]}  }

应用程序的其他组件也被提议使用 JSON。因此，更新 JSON 字段的顺序是:

1. 在 python 脚本中读取 JSON。

2. 更新 JSON

3. 将 JSON 存储回 MySQL。

这将是 MongoDB 中的单个操作，具有 $push、$inc、$pull 等原子操作。还有MongoDB的文档结构很适合我的数据。

我在选择数据存储时的考虑。

关于 MySQL:

1. 稳定且熟悉。
2. 备份和恢复很容易。
3. 使用某些字段作为无模式 JSON 可以避免 future 的一些模式更改。
4. 可能需要提前使用memcached层。
5. JSON blob 在某些表(如主帖子)中将是静态的，但会在其他一些表(如帖子投票和点赞)中进行大量更新。

关于 MongoDB:

1. 更适合将架构较少的数据存储为文档。
2. 在以后的阶段可能会避免缓存。
3. 有时应用可能会变得写密集型，但 MongoDB 在不安全写入不成问题的那些点上可以表现得更好。
4. 不确定稳定性和可靠性。
5. 不确定备份和恢复是否容易。

问题:

1. 如果一半数据是无模式的，我们是否应该选择 MongoDB，如果使用 MySQL，我们是否应该将其存储为 JSON？

2. 像主帖这样的一些数据很关键，所以它会使用安全写入、计数器等来保存将使用不安全的写入保存。这种基于数据重要性和写入密集度的策略是否正确？

3. 与 MySQL 相比，监控、备份和恢复 MongoDB 有多容易？我们需要计划定期备份(比如每天)，并在发生灾难时轻松恢复它们。我对 MongoDB 的最佳选择是什么，以使其成为应用程序的安全选择。

稳定性、备份、快照、恢复、更广泛的采用，即数据库持久性是指向我的原因将 MySQL 用作 RDBMS+NoSql，即使 NoSQL 文档存储可以更好地满足我的目的。

考虑到我心目中的数据库设计，请将您的观点集中在 MySQL 和 MongoDB 之间的选择上。我知道可能有更好的方法来使用 RDBMS 或 MongoDB 文档来规划数据库设计。但这不是我当前问题的重点。

更新:从 MySQL 5.7 开始，MySQL 支持丰富的原生 JSON 数据类型，它提供了数据灵 active 以及丰富的 JSON 查询。

https://dev.mysql.com/doc/refman/5.7/en/json.html

Answer 1

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

Shall we chose mongodb if half of data is schemaless, and is being stored as JSON if using MySQL?

无模式存储无疑是使用 MongoDB 的一个令人信服的理由，但正如您所指出的，在 RDBMS 中存储 JSON 也相当容易。 MongoDB 的强大之处在于对无模式存储的丰富查询。

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

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

Some of the data like main posts is critical , so it will be saved using safe writes , the counters etc will be saved using unsafe writes. Is this policy based on importance of data, and write intensiveness correct?

我认为“安全写入”是指在每次写入后打开自动“getLastError()”的选项。我们对 DBCollection 有一个非常薄的包装器，它允许我们对何时调用 getLastError() 进行细粒度控制。但是，我们的政策不是基于数据的“重要程度”，而是基于查询后的代码是否期望任何修改在接下来的读取中立即可见。

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

How easy is it to monitor,backup and restore Mongodb as compared to mysql? We need to plan periodic backups (say daily), and restore them with ease in case of disaster. What are the best options I have with mongoDb to make it a safe bet for the application?

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

Stability,backup,snapshots,restoring,wider adoption i.e.database durability are the reasons pointing me to use MySQL as RDBMS+NoSql even though a NoSQL document storage could serve my purpose better.

因此，根据我的经验，MongoDB 使用一组足够丰富的查询原语来存储无模式数据，以至于事务通常可以被原子操作替换。忘记 10 多年的 SQL 经验是很困难的，但我遇到的每个问题都已由社区或 10gen 直接解决。我记得我们没有丢失数据或有任何停机时间。

简单地说，就查询、维护、可扩展性和可靠性而言，MongoDB 是我用过的最好的数据存储生态系统。除非我有一个非常明确的关系应用程序，以至于我良心上只能使用 SQL 以外的任何东西，否则我会尽一切努力使用 MongoDB。

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