基本 nosql 和 mongodb等数据库对比基本 nosql 和 mongodb等数据库对比

咱们工作或者学习的过程中，接到一个需求，或者学习一个技能的时候，我们是如何去学习的呢？

我想大概分成如下几步吧：

了解背景，了解这个技术或者需求的背景，特性，定律等等对比学习，进行同类事物对比关联学习，关联已知的知识进行学习

一起来看看 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 的官方文档地址，学习任何一门技术，都是看官网的一手资料才是正确的

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

好了，本次就到这里

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是小魔童哪吒，欢迎点赞关注收藏，下次见~