咱们工作或者学习的过程中，接到一个需要，或者学习一个技能的时候，咱们是如何去学习的呢？
我想大略分成如下几步吧：
- 理解背景，理解这个技术或者需要的背景，个性，定律等等
- 比照学习，进行同类事物比照
- 关联学习，关联已知的常识进行学习
一起来看看 NOSQL 是什么
这里来举荐一个看数据排名的地址：
DB-Engines
这里能够看到各种类型的数据库排名，数据库选型的时候这个网址就很香了
NOSQL 是什么
咱们先来列举一下传统型数据库的特点：
- 结构化
- 二维表
- E- R 关系（实体 - 关系模型）
- sql 标准化
- 反对事务（ACID）
- 锁
- 索引
sql，是结构化查询语言，泛指关系型数据库
nosql（not noly sql），不仅仅是 sql，这泛指不提供 sql 性能的非关系型数据库
它不遵循 sql 的规范，acid 个性，表构造等个性。
最开始 nosql 实际上是 not sql，前面缓缓倒退成 not only sql
简述 nosql 的倒退历史：
列式存储 – 键值对存储 – 文档存储 – 图形存储
为什么须要 NOSQL？
大抵列举如下几点：
- 因为古代网络的倒退，大多是超大规模高并发的 web 2.0 动静网站
- 对于大量数据，关系型数据库曾经遇到瓶颈，性能方面和扩展性方面的瓶颈
- 如何解决大规模数据汇合，多重数据品种带来的挑战，这就须要 nosql 来解决了
- mysql 等关系型数据库利用在大数据下面，显然是一个难题了
罕用的四大类 NOSQL 数据库的优缺点比照
| 分类 | 劣势 | 劣势 | 场景 | 代表 |
|---|---|---|---|---|
| 键值对 | 查找速度快 | 数据无结构化，通常只是用来作为字符串或者二进制 | 内容缓存，次要用于解决大量数据的高频拜访负载 | reids |
| 列式存储 | 查找速度快，反对分布式横向扩大，数据压缩率搞 | 性能绝对受限 | 用于分布式文件系统 | HBase |
| 文档存储 | 数据结构要求不严格，表构造可变 | 查问性能不高，不足对立的查问语法 | 用于 web 利用等 | MongoDB |
| 图形数据库 | 能够利用图构造相干等算法 | 须要对整个图做计算，不利于图数据的分布式存储 | 用于社交网络，举荐零碎，动向图，趣味图，关系图等等 | Neo4J |
咱们能够晓得 es 也是 文档存储的 nosql，那么 es 和 mongodb 有什么异同的呢？
mongodb 和 elasticsearch 相同点：
- 文档结构化
- 都有自定义的一套操作语法
- 有全文检索（es 更多是用在搜索引擎下面）
- 索引
不同点：
- mongodb 有 MapReduce，es 没有
- 全文检索实现的形式不一样
nosql 和 关系型数据库比照
| 特点 | NoSQL | 关系型数据库 |
|---|---|---|
| 数据一致性下面 | 使用 CAP 定理，保障最终一致性，非 ACID 属性 | 严格的一致性，ACID |
| 数据表的模式 | 键 - 值对存储，列存储，文档存储，图形数据库 | 二维表，数据和关系都存储在独自的表中 |
| 是否结构化 | 非结构化的、半结构化的，没有申明性查询语言 | 高度组织化结构化数据，结构化查询语言 sql |
| 事务方面 | 属于 弱 事务 | 根底事务 |
| Join 方面 | 弱，没有预约义的模式 | 强，数据操作语言，数据定义语言 |
| 老本代价 | 低 | 高（硬件方面和软件方面） |
| 扩展性方面 | 强，高性能，高可用，可伸缩性强 | 弱 |
什么是 mongodb？
mongodb 是基于 C++ 开发的 NOSQL 开源文档数据库，是最像关系型数据库的 nosql，性能也是最丰盛的 nosql
它具备所以的可伸缩性，灵活性，高性能，高扩展性的劣势，大抵有如下个性：
- 面向汇合文档的存储，存储 Bson（json 的扩大）
- 格局自在，数据格式自在，生产环境上面批改数据表构造对程序没有影响
- 查问语句弱小，面向对象查问语句，笼罩了 sql 语言的能力
- 欠缺的索引反对，反对查问打算
- 反对复制和主动故障转移（这里有点像 redis）
- 反对二进制数据和大型对象文件的高效存储
- 应用分片集群晋升零碎的扩展性
- 应用内存映射存储引擎，把磁盘的 IO 操作转换成内存的操作
什么业务场景须要应用 mongodb？
mongodb 数据库，并不是说适宜每一种场景的，咱们须要人尽其才，物尽其用，技术选型，咱们也是要抉择最合适的技术来解决理论的业务问题或者是场景问题
如下的场景就适宜应用 mongodb：
- 不须要事务及简单的 join 反对
- 要应答 2k – 3k 以上的读写 QPS 的时候
- 存储的数据达到 TB 或者 PB
- 新的服务，数据结构会变，类型会变，模型也会变的状况
- 要求存储的数据不失落
- 要求 4 个 9 的高可用
- 须要服务水平扩大，继续迭代的
- 大量的地理位置查问，文本查问的
理论过程中，咱们会在哪些成场景应用到 mongodb 呢？
mongodb 利用的场景能够说是十分的多，大抵有游戏，物流，内容治理，物联网，电商，社交，视频直播等等
如物流场景：
mongodb 存储订单信息，订单在运送的过程中，订单信息会一直的更新，这个时候应用 mongodb 内嵌的数据模式来存储就十分不便，一次查问就能够将所有的物流信息全副取出来
再例如社交场景：
mongodb 存储用户信息，存储用户发表的朋友圈信息，那么就能够通过地理位置索引到左近的人，地点，以及相干的配套性能
不适宜应用 mongodb 的场景
不适宜应用 mongodb 的场景，即是 mongodb 本身的劣势场景，例如：
- 高度的事务性零碎，例如做银行等金融业务的，要求高度的一致性，mongodb 就不适合
- 应用 sql 不便，数据结构绝对固定的场景，这个应用应用 sql 规范老本会更低
最初贴一下 mongodb 的官网文档地址，学习任何一门技术，都是看官网的一手材料才是正确的
欢送点赞，关注，珍藏
敌人们，你的反对和激励，是我保持分享，提高质量的能源
好了，本次就到这里
技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。
我是 小魔童哪吒，欢送点赞关注珍藏，下次见~