目录
前言
一、MongoDB 的历史
二、MongoDB 特点
三、MongoDB 适用场景
四、MongoDB 不适合场景
总结
前言
? ? ? ? 学习MongoDB
一、MongoDB 的历史
关系型的数据库已经出现了近 40 年，并且在很长一段时间里，一直是数据库领域当之无愧的 王者，例如 SQL Server、MySQL、Oracle 等，目前在数据库领域中仍处于主导地位。但随着信息时代 数据量的增大以及 Web2.0 的数据结构复杂化，关系型数据库的一些缺陷也逐渐显现出来，主要包 括以下几项。
（1） 大数据处理能力差。关系型数据库被设计为单机运行，在处理海量数据方面代价高昂，甚至 无法承担重任。
（2） 程序产出效率低。我们在开发程序使用关系型数据库会发现， 更多的精力被用在了建立关 系型数据库表的数据结构与开发语言数据结构的映射上。使用关系型数据库时，为了实现系 统中某个实体的存储查询操作，我们首先需要设计表的结构和字段以及数据类型。于是无论 是创建、删除还是更新，我们要涉及的操作增加了许多。
（3） 数据结构变动困难。互联网项目时刻都在发展和变动，改变存储单元的结构是常事，但是生 产环境中关系型数据库要增加或减少一个字段无疑是非常严肃、 重要并且是容易生意外的 事情。
为了解决这些存在的问题，一个更好的数据库方案 NoSQL 数据库应运而生。 所谓 NoSQL ，并不是 指没有 SQL ，而是指“Not Only SQL ”，即非传统关系型数据库。这类数库的主要特点包括非关系 型、水平可扩展、分布式与开源；另外它还具有模式自由、 最终一致性。NoSQL 常用的存储模式有 key-value 存储、文档存储、列存储、 图形存储、 XML 存储等， MongoDB 正是文档数据库的典型 代表。
二、MongoDB 特点（1）数据文件存储格式为 BSON （JSON 的扩展） ｛"name"："joe"｝这是 BSON 的例子，其中"name"是键，"joe"是值。键值对组成了 BSON 格式。
（2）面向集合存储，易于存储对象类型和 JSON 形式的数据 所谓集合（collection）有点类似一张表格，区别在于集合没有固定的表头。
（3）模式自由 一个集合中可以存储一个键值对的文档，也可以存储多个键值对的文档，还可以存储键不一样 的文档，而且在生产环境下可以轻松增减字段而不影响现有程序的运行。
（4）支持动态查询 MongoDB 支持丰富的查询表达式，查询语句使用 JSON 形式作为参数，可以很方便地查询内嵌 文档和对象数组。
（5）完整的索引支持 文档内嵌对象和数组都可以创建索引。
（6）支持复制和故障恢复。
MongoDB 数据库从节点可以复制主节点的数据，主节点所有对数据的操作都会同步到从节点， 从节点的数据和主节点的数据是完全一样的，以作备份。当主节点发生故障之后，从节点可以升级 为主节点，也可以通过从节点对故障的主节点进行数据恢复。
（7）二进制数据存储 MongoDB 使用传统高效的二进制数据存储方式，可以将图片文件甚至视频转换成二进制的数据 存储到数据库中。
（8）自动分片 自动分片功能支持水平的数据库集群，可动态添加机器。分片的功能实现海量数据的分布式存 储，分片通常与复制集配合起来使用，实现读写分离、负载均衡，当然如何选择片键是实现分片功 能的关键。
（9）支持多种语言 MongoDB 支持 C＋＋、 C＃、 Erlang、Haskell、JavaScript、Java、Perl、PHP、Python、Ruby、Scala 等开发语言。
（10）MongoDB 使用的是内存映射存储引擎。 MongoDB 会把磁盘 IO 操作转换成内存操作，如果是读操作，内存中的数据起到缓存的作用： 如果是写操作，内存还可以把随机的写操作转换成顺序的写操作，总之可以大幅度提升性能。但坏 处是没有办法很方便地控制 MongoDB 占多大内存，MongoDB 会占用所有能用的内存，所以最好不 要把别的服务和 MongoDB 放在同一台服务器部署。
三、MongoDB 适用场景MongoDB 适用于以下场景，只要有一项需求满足就可以考虑匹配越多，就约可以考虑使用MongoDB。
（1）网站数据
MongoDB 非常适合实时地插入、更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。如果 你正考虑搭建一个网站，可以考虑使用 MongoDB，你会发现它非常适用于迭代更新快、需求变更多、以 对象数据为主的网站应用。
（2）缓存
由于 MongoDB 是内存+硬盘型数据库，性能很高，MongoDB 也适合作为信息基础设施的缓存层。在系统 重启后，由 MongoDB 搭建的持久化缓存可以避免下层的数据过载。
（3）大尺寸、低价值的数据
?使用传统的关系型数据库存储一些数据会超级麻烦，首先要创建表，再设计数据表结构，进行数据清理， 得到有用的数据，按格式存入表中；而 MongoDB 可以随意构建一个 Json 格式的文档就能把它先保存起 来，留着以后处理。
（4）高伸缩性的场景
如果网站的数据量非常大，很快就会超过一台服务器能够承受的范围，那么 MongoDB 可以胜任网站对 数据库的需求，MongoDB 可以轻松地自动分片到数十甚至数百台服务器。
（5）用于对象及 JSON 数据的存储
MongoDB 的 BSON 数据格式非常适合文档格式化的存储及查询。
（6）不需要事务及复杂 join 支持
（7）新应用，需求会变，数据模型不确定，想快速迭代开发
（8）要应对 2000~3000 以上的的读写 QPS（或更高）
（9）要存储 TB 甚至 PB 级别数据
（10）应用发展迅速，要快速水平扩展
（11）有大量的地理位置查询，文本查询。
实际的应用案例：
1.?游戏场景，使用 MongoDB 存储游戏用户信息，用户的装备、积分等直接以内嵌文档的形式存储， 方便查询、更新 。
2. 物流场景，使用 MongoDB 存储订单信息，订单状态在运送过程中会不断更新，以 MongoDB 内嵌 数组的形式来存储，一次查询就能将订单所有的变更读取出来。
3. 社交场景，使用 MongoDB 存储用户信息，以及用户发表的朋友圈信息，通过地理位置索引实现附 近的人、地点等功能 。
4. 物联网场景，使用 MongoDB 存储所有接入的智能设备信息，以及设备汇报的日志信息，并对这些 信息进行多维度的分析 。
5. 视频直播，使用 MongoDB 存储用户信息、礼物信息等。
四、MongoDB 不适合场景对钱对数字非常敏感的业务是不适合的。
（1）高度事务性的系统
传统的关系型数据库还是更适用于大量原子性复杂事务的应用程序，例如银行或会计系统。支持事务的 传统关系型数据库，当原子性操作失败时数据能够回滚，以保证数据在操作过程中的准确性，而且目前 MongoDB 不支持此事务。
（2）传统的商业智能应用
针对特定性问题的 BI 数据库需要高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
（3）使用 SQL 方便时；数据结构相对固定
MongoDB 的查询方式是 JSON 类型的查询方式，虽然查询也比较灵活，但如果使用 SQL 进行统计会比较 方便时，这种情况就不适合使用 MongoDB。
????????
总结
? ? ? ?掌握了MongoDB的适合场景和不适合场景，为以后的架构选择提供了参考方向。
技术参考
C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂
 1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。 |
标签： #MongoDB学习一 #40 #王者例如 #SQL
