自加入项目以来，一直觉得MongoDB不太适合做业务系统的主数据库，它是导致目前主要的逻辑都是面向JSON的数据处理，而不是面向业务领域的模型开发的主要原因。客户当初选择MongoDB也只是为了方便将对象以文档的方式持久化和反序列化，而并没有考虑存储的数据需要支持的业务场景(目前没有足够的用户去收集需求是原因之一)，这样也导致了整个分层应用中，前台应用的数据模型和后台应用的业务模型强绑定，页面发送什么样的数据，后台进行简单的校验处理，然后将数据基本原封不动的持久化到MongoDB。当今天碰到一个需要给对象加序列ID的需求，发现没有原生支持，需要自己设计分布式同步序列时，越发迫切的想引入一个关系型数据库。那为了避免以后落入类似的窘境里，什么时候可以考虑使用MongoDB呢？
首先我们来看MongoDB的数据结构和数据检索的方式：
MongoDB中的数据以文档的方式存储，文档也就是BSON(Binary JSON)结构的数据。相较与JSON，它有更快的遍历速度，对数据更简易的操作和更多的数据类型几大特点。MangoDB中存储的数据结构灵活，没有schema限制。下图展示了内嵌结构的BSON数据（每条记录都有自动分配的哈希ID作为唯一标识）：
在搜索方面，MongoDB支持在属性以及嵌套属性上灵活创建索引，用户可以从文档结构中进行各种灵活的匹配对结果进行过滤，具体的搜索语法可参考官方文档。MongoDB另一个强大的功能是按地理位置索引，只要文档集合中有地理位置坐标，用户可以搜索指定坐标附近的相关记录，也可搜索坐标指定范围内匹配的结果，具体的搜索语法参考官方文档，因此对于基于地理位置的应用，可以提供很强大的开箱即用的功能，同时官方文档也很全面。但是，你也可以发现，MongoDB的检索都是对某一个数据集合进行操作，任何跨集合的操作都需要引用来实现。这表明在设计系统时，你需要在搜索性能和存储空间中做出权衡。要么使用嵌套的方式，直接存储引用对象的值方便索引，要么牺牲查询性能只存储引用，再通过引用进行二次检索，严格的说通过二次查询还会限制检索的自由度。比如上面的例子中，如果班级列表中存储的是引用，那么就无法直接索引出所有要在201教室上课的全部学生。
从开发和维护角度，MongoDB也拥有众多的亮眼特性：支持复制和故障恢复，支持分片可以构建高可用集群，易伸缩，支持多平台，多语言驱动和良好的文档支持。
综合以上特性，我认为MongoDB在以下场景下更适用：
不确定业务模型，快速验证的原型项目。
高写负载的场景，存储评论，日志等大规模的非核心业务数据。
大规模或可能爆发式增长的非结构化数据存储。
大数据量缓存。
基于位置的查询业务。
不适用如下场景：
复杂的业务查询，比如需要复杂的连表查询，这个领域还是RDB的天下。
强事务一致性系统。
网友评论