MongoDB就是数据库，是一款致力于web应用程序和互联网基础设施而设计的数据库，是一种新型的Nosql数据库（Not only sql/New sql）
为什么我们要用mongodb？在json数据愈发流行的今天，数据交互已经不那么的强制要求关系的联系。在一些场景下，mysql这样的关系型数据已经不是唯一的选择，而json的数据格式的操作也十分的方便，甚至一些场景json会更加的方便，现在的前后端分离接口，基本上都使用json进行数据交换，xml已经比较少见了。
mongodb存储使用类json的数据结构bson来存储数据（就比json多一个ObjectId，如果不指定，mongodb会自动生成一个类似uuid）。一条bson数据类似与mysql中的一行数据，不同的是bson并不需要预先定义表结构，这样的数据模型设计，使得吞吐量大大提升相较于mysql等sql数据库。
MongoDB的主要特性
- 文档数据类型：
sql数据类型是有格式的，预先定义的，还可以添加外键的约束来保证数据的完整和准确，即使现在的数据库设计都不建议使用外键，因为它会给应用系统带来业务处理的复杂性。虽然mongodb在这一方面没有sql数据库这样标准化，有固定的Schema，但也就是因为这样，使数据的存储更加的灵活，也能使插入和查询效率大大提升。
- 即时查询能力
MongoDB拥有即使查询能力，插入完成之后可以马上查询到数据，而且保留了基于B-tree的索引，相较于同类型数据库elasticSearch就没有即时查询的能力，而redis也没有B-tree索引的能力。
- 自带复制能力
MongoDB自身提供了副本集功能，副本集能够将数据分布在多台机器上实现冗余（前提是在多态机器上部署副本，并配置），能够实现类似sql数据库的读写分离（这个则略可配置，读请求使用副本，写使用主库、读写都用主库等），副本集能够在主库故障的时候自动转移，提高了数据的安全性。
- 提供数据安全
MongoDB提供Journaling日志，类似mysql的binglog，插入数据的时候先会向日志中写入记录，然后完成写入操作，这样可以在断电重启时恢复数据；
- 数据扩展性
MongoDB天生支持数据分片，分片也许容易和副本集的概念混淆。分片指的是假设只有一台机器，存储了100%的数据，现在加了一台机器，那么每台机器存放50%的数据；副本集指的对mongodb中所有数据的一个复制类似主从备份，当存在分片的时候，则副本集对所有分片存在复制。这些特性在elasticSearch相同，elasticSearch需要在创建index的时候配置。
- 地理位置查询
MongoDB支持按经纬度范围查询，只要在文档数据中添加loc的地理位置（近卫度坐标），并建立成2dphere索引，就可以在查询的时候按经纬度范围查询距离内的左边点（附近的公交、地铁、餐饮等功能）。
- 使用js来操作mongodb工具行
sql数据库操作使用sql来操作数据库中的数据，而mongodb的命令行使用js语法操作，这对于初学者来说也是比较友好的，就类似于用js操作json。个人比较喜欢使用的mongodb数据可视化工具
Robo 3t，但是这个工具并没有提供导入导出数据的能力，即使用js操作数据导入导出，也只能是少量的。mongodb提供了mongoimport和mongoexport来帮助我们导出导入数据，数据的格式可以是json，可以是csv或tsv，这就类似于mysql中的source text.sql和mysqldunm语句。
你一般如何使用MongoDB
根据MongoDB的特性，类json形式的数据，高吞吐，即时查询能力自动分片，副本集，自动故障转移等等。
但是MongoDB也有他的局限性，无事务的支持，无关联查询，无存储过程、触发器等等。
目前了解到的比较合理的使用场景：
- 作为复杂可编辑页面的临时存储环节，比如像编辑博客，编辑的时候的自动保存功能，可以将博客的草稿放置在mongodb中，以防编辑未完成浏览器卡死；
- 系统的关键性操作日志，数据交换记录等。例如一个管理系统有相当多的操作，而这些操作都被赋予了权限控制，管理员需要清楚的知道谁在这个系统中做了什么样的操作，可以将这些操作的信息保存下来，以便查询和追责；如果做过交易系统，订单之间有许多的通知回调等数据交换，例如对接支付宝、微信，他们的用户支付订单完成的通知通过http回调的方式，可以将这些回调的记录保存起来；
- 大批量的无关联数据。比如boss直聘中的简历。这些简历可以以json的形式保存下来，查询的时候按简历的标签来匹配。再比如现在的大屏数据，如果你的大屏数据不是假数据的化，一般来说动态变化的大屏是通过流式计算的方式将特定时间床的数据统计出来，按时间存储，然后通过大屏实现数据可视化。大屏的后端服务有很多都是node开发的，node和mongodb可以说是绝配。
上面的这些功能不是说一定要使用MongoDB，而是这些需求下使用MongoDB是相对合理的，但仅仅是个人观点。如果涉及到类似订单状态更新、库存更新等需要事务处理，MongoDB就不太合适了。MongoDB其实和ElasticSearch很像，而ElasticSearch最大的特性是它的
反向索引，ElasticSearch的性能关键在于内存，个人觉得在考虑中间件选型的时候，成本也是一个比较关键的因素。
