什么是MongoDB？
有了Redis之后，很快又出现了新的应用需求。
相对于MySQL这种存储结构化数据的数据库来说，它所有的数据表都是事先定义好的，数据表中的每一个字段也都有一个预期值存在。即使没有，也会有默认值来填充。
但既然有了结构化数据，也就意味着可能会存在非结构化数据，甚至时半结构化数据。
虽然MySQL在大都数的应用开发中都占据着主流地位，但当对于后两者，很明显，它才是那个少数派。
对于非结构化数据和半结构化数据来说，MySQL那套凡是都先要定规矩，凡事都要一板一眼的方法完全行不通。
因为它们的数据格式参差不齐，而且也不可能事先定义出来。
例如，对于一个PDF文件，它有章节、标题、字数和页码，但同样的属性对于一封Email邮件来说，除了标题和字数可以套用，章节和页码是用不到的。
如果再来一个动漫视频文件，前面的这些属性几乎都白给。
也许，可以把世界上所有的不同类型的数据格式属性，全部先用一张MySQL表事先定义出来。
这样做理论上是可以，但实际上很难办到。
新类型的数据不停出现，例如微博和短视频。这意味着这张表要不停地修改。
有的数据格式只需要1~2个字段，但却必须填成百上千个其他根本用不着的字段。
大量的字段都是空白，存储、查询的效率可想而知。
连MySQL这个大哥都做不到，跟别说Redis这个弟弟了。
所以，文档数据库出场了，它专治非结构化数据和半结构化数据的各种不服。
而MongoDB就是其中的佼佼者。
它无需事先做什么定义，只要告诉它需要保存什么就好了。
PDF需要章节、标题、字数和页码，可以。Email需要主题、收件地址、抄送人、内容和签名，可以。短视频需要名称、时长、视频格式和播放地址，可以。UML用例图需要名称和文件类型，可以。用户日志需要用户名、注册时间戳、行为事件，可以；订单日志需要订单号、商品名称、支付金额，也可以。位置坐标只需要经度Longitude和纬度Latitude就行了，可以。
这里面所有的数据，都各有各的属性字段，而且这些字段都是可以在实际运行的时候动态增加、修改和删除的。
完全是来者不拒，更重要的是它们又绝不会互相影响，且丝毫不影响查询效率。
MongoDB弥补了MySQL在数据存储上的短板，相对于结构化数据，它才是那个占据三分之二的大多数。
感谢支持
更多内容，请移步《超级个体》。