对比MySQL，什么场景MongoDB更适用

欢迎关注我的头条号：Wooola，10年Java软件开发及架构设计经验，专注于Java、Golang、微服务架构，致力于每天分享原创文章、快乐编码和开源技术。

它已经流行了很长时间。与MySQL相比，哪些场景需要用到更多？下面是一些总结。

更高的写入负载

默认情况下，它更注重高数据写入性能而不是事务安全，适用于业务系统中存在大量“低价值”数据的场景。但是，在事务安全性高的系统中应该避免这种情况，除非架构设计可以保证事务安全。

高可用性

副本集（-Slave）的配置非常简单方便。此外，它可以快速响应单节点故障，自动安全地完成故障转移。这些特性使得在相对不稳定的环境（如云主机）中保持高可用性成为可能。

数据量非常大或未来会变得非常大

依靠数据库（MySQL）本身的特性，很难完成数据的扩展。在 MySQL 中，当单个表达式表达到 5-10GB 时，会出现明显的性能下降。这时候就需要对数据进行横向和纵向的拆分。分库分库完成扩容。MySQL的使用通常需要驱动层或者代理层的帮助来完成这样的需求。多种数据分片的内置特性可以很好地适应大数据量的需求。

基于位置的数据查询

支持二维空间索引，可以快速准确地从指定位置获取数据。

表结构不清晰为什么要使用mongodb，数据不断增长

在一些传统的 RDBMS 中，添加字段会锁定整个数据库/表，或者在执行重负载请求时显着降低其他请求的性能。通常在数据表大于 1G 时发生（大于 1TB 时甚至更多）。由于它是文档数据库，因此向非结构化或非结构化文档添加新字段是一种快速操作，不会影响现有数据。另一个好处是当业务数据发生变化时，不需要DBA修改表结构。

没有 DBA 支持

如果您没有全职 DBA，并且准备在没有标准关系思维（结构化、连接等）的情况下处理数据，那么它将是您的首选。对象数据的存储非常方便，类可以直接序列化成JSON存储在里面。但是你需要了解一些最佳实践，以避免在数据变大时文档设计问题导致的性能缺陷。

– 基于计费系统（来自 oc666)

它是由 Ofer Cohen 推出并用作数据存储的开源计费系统。该计费系统被以色列发展最快的电信运营商之一采用，每月处理 5 亿条通信记录。Ofer解释了好处的具体特点：

弱数据结构的特点使得快速支持新的CDR（通信记录）类型成为可能。此功能使文档数据库非常适合具有不确定业务需求的快速发展的系统。

仅使用一个，就可以管理 TB 级的文档数据，而不会遇到结构变化、数据爆炸带来的限制和问题。

副本集功能使构建更多数据中心 DRP 变得更加容易。

内置分片功能，避免系统在数据增长过程中遇到性能瓶颈。

每秒插入 2,000 条通信记录，得到高负载数据写入的架构设计的良好支持。并且可以使用（比较慢的）基本事务完成特性为什么要使用mongodb，并通过应用层的支持，实现两阶段提交。

与SQL相比，查询方式更容易阅读和理解，开发也相对容易。

基于位置可以更好地分析用户使用情况，从而更好地定位移动电话基础设施。