基本 nosql 和 mongodb等数据库对比基本 nosql 和 mongodb等数据库对比
作者：互联网
咱们工作或者学习的过程中，接到一个需求，或者学习一个技能的时候，我们是如何去学习的呢？
我想大概分成如下几步吧：
- 了解背景，了解这个技术或者需求的背景，特性，定律等等
- 对比学习，进行同类事物对比
- 关联学习，关联已知的知识进行学习
一起来看看 NOSQL 是什么
这里来推荐一个看数据排名的地址：
这里可以看到各种类型的数据库排名，数据库选型的时候这个网址就很香了
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 的官方文档地址，学习任何一门技术，都是看官网的一手资料才是正确的
欢迎点赞，关注，收藏
朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力
好了，本次就到这里
技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。
我是小魔童哪吒，欢迎点赞关注收藏，下次见~
标签：存储,场景,nosql,mongodb,数据库,sql 来源： https://www.cnblogs.com/xiaomotong/p/16651535.html