(原)MongoDB在系统中的使用
本文内容纲要：
**序）**Nosql并不是要取代原有的数据产品，而是为不同的应用场景提供更多的选择。
一）结构类型
传统数据库的领域在于结构化文档，对于非结构化文档和半结构化文档，它能处理，但是有一定的缺陷，那么什么又是结构化文档，概括如下：
结构化信息——这种信息可以在关系数据库中找到，多年来一直主导着IT应用。这是关键任务OLTP系统业务所依赖的信息，另外，还可对结构数据库信息进行排序和查询；
半结构化信息——这是IT的第二次浪潮，包括电子邮件，文字处理文件以及大量保存和发布在网络上的信息。半结构化信息是以内容为基础，可以用于搜索，这也是谷歌存在的理由；
非结构化信息——该信息在本质形式上可认为主要是位映射数据。数据必须处于一种可感知的形式中（诸如可在音频、视频和多媒体文件中被听或被看）。许多大数据都是非结构化的，其庞大规模和复杂性需要高级分析工具来创建或利用一种更易于人们感知和交互的结构。
二）MongoDB和行导向数据库的区别
老实说，我觉得Nosql领域比较奇葩的东西算是Hive，不过在此不介绍它，对于项目中使用到MongoDB，也是有一定原因的，我一直以为Nosql这种东西和行导向数据库并不冲突，它仅仅是行导向数据的一个补充，对于MongoDB，它和我们用的mysql，Oracle等有什么区别，曾经我也查找过一些东西，发现网上很多相关的文章都是千篇一律，几乎一模一样，没啥价值，于是捉摸自己总结下。
举个栗子：
在上面的表中，很直接，数据也很直观，但是如果我们需要存储另外一个东西：头像，一般人会这样干：
尽管不同数据库都提供了直接存储二进制的数据库字段，但是我还是会选择以上的存储方式，我相信也有很多人也会这样做，这样做其实没有什么不好，但是如果我们的文件很大，几个GB，那么无论读还是写都会很耗时，成为系统的瓶颈，基于这种情况，才会诞生云计算以及Nosql这些东西，也就是说Hadoop，Hbase等诞生的原因是：
多年来磁盘存储容量快速增加的同时，访问速度-磁盘数据读取速度却未能与时俱进,寻址时间的提高远远慢于传输速率的提高，寻址是将磁盘移动到特定磁盘位置进行读写操作，它是导致磁盘操作延迟的主要原因，而传输速率取决与磁盘的带宽。
于是人们想出了一个办法：既然在一个服务器读取一个文件需要100个小时，那么将文件放在100个服务器，每个服务器放1%的数据，那么1小时就搞定了，这也是Hadoop的核心思想，MongoDB数据库继承了这一思想，它的区块划分，以及节点分裂，都延续了这样的思想，另一方面，MongoDB又吸取了memcached的东西，提前申请一片内存区域以及文件区域，将内存中的地址和物理地址对应起来，可以极高的提高速度，这也是MongoDB相当的消耗内存和磁盘的原因之一。
三）MongoDB应用范围
1：MongoDB与传统数据库整合：
在以上表中，如果内容是一个包含上千上万字的文章，一般会该字段的内容丢入MongoDB，然后在此放入MongoDB的ID。
2：MongoDB取代传统数据库：
在某些事物要求不高的场合，以及允许出现部分错误的系统中，可以使用MongoDB取代传统数据库，例如论坛，博客等系统，举个栗子：
博客有人发表了一篇文章，MongoDB存储如下：
>db.article.insert({"title":"测试文章","content":"测试内容","time":"17822455","uid":"1"});
WriteResult({"nInserted":1})
>db.article.findOne();
{
"_id":ObjectId("546168c9573c0742d8be1544"),
"title":"测试文章",
"content":"测试内容",
"time":"17822455",
"uid":"1"
}
>
现在有一个人对这篇文章进行了评论，如下：
>vararticleInfo=db.article.findOne({"_id":ObjectId("54616db1d92589121def0c70")});
>articleInfo;
{
"_id":ObjectId("54616db1d92589121def0c70"),
"title":"测试文章",
"content":"测试内容",
"time":"17822455",
"uid":"1"
}
>articleInfo.commentary={"uid":"2",info:{"content":"这篇文章不错","times":"145881444"}};
{
"uid":"2",
"info":{
"content":"这篇文章不错",
"times":"145881444"
}
}
>db.article.update({"_id":ObjectId("54616db1d92589121def0c70")},articleInfo);
WriteResult({"nMatched":1,"nUpserted":0,"nModified":1})
>db.article.findOne({"_id":ObjectId("54616db1d92589121def0c70")});
{
"_id":ObjectId("54616db1d92589121def0c70"),
"title":"测试文章",
"content":"测试内容",
"time":"17822455",
"uid":"1",
"commentary":{
"uid":"2",
"info":{
"content":"这篇文章不错",
"times":"145881444"
}
}
}
>
现在又有一个人对它评论如下：
于是MongoDB的存储结构成了这样：
>db.article.update({"_id":ObjectId("54617115d92589121def0c72")},{"$push":{"commentary":{"uid":3,info:{"content":"我也这篇文章不错","times":"1444"}}}});
WriteResult({"nMatched":1,"nUpserted":0,"nModified":1})
>db.article.findOne({"_id":ObjectId("54617115d92589121def0c72")});
{
"_id":ObjectId("54617115d92589121def0c72"),
"title":"测试文章",
"content":"测试内容",
"time":"17822455",
"uid":"1",
"commentary":[
{
"uid":2,
"info":{
"content":"这篇文章不错",
"times":"1444"
}
},
{
"uid":3,
"info":{
"content":"我也这篇文章不错",
"times":"1444"
}
}
]
}
>
由此可见，如果再有评论，继续往后加就OK，MongoDB对此的存储是一目了然，伸缩性很强，如果不能够在代码中实现对数据一致性的处理，那么还是使用回关系型数据库为妙，在这种事务性不太强的场合，使用MongoDB是可以取代掉关系型数据库的。
四）MongoDB使用
由于之前使用logback处理日志，自己还得写一大堆的shell脚本，各种awk处理文本分析用户行为丢入postgres，可能自己技术不到家，但是自己能够想出的东西也就这些，于是在这个项目中毅然决定用MongoDB作为日志分析系统。如果不在分布式中，使用Nosql没有价值，码字太辛苦了。。
本文内容总结：
原文链接：https://www.cnblogs.com/bfchuan/p/4090249.html