初探MongoDB：暴力美学

AUTH：PHILO version:2.0

Abstract

为了在项目中更好的使用MongoDB来完成咱们的业务，咱们探究了MongoDB性能暴力的成因以及如何更加合理的使用MongoDB。

而且简单的描述普通业务数据库设计的简单分析方法。以及避免盲目崇拜对总体数据存储与处理的分析。

同时也为了你们初探本数据库提供了可靠的研究学习路线让学习曲线不会那么陡峭。
固然咱们也总结了关于以golang为例的驱动解决方案，以及复杂存储业务的解决方案。

在整个研究过程当中咱们发现MongoDB的存储由于更加符合现代业务既关系复杂涉及到的实体比较多的特征。提高了整个存储系统的IO能力。

另外BSON数据操做让业务处理如虎添翼。更是提高了开发速度。

Introduction

随着互联网业务爆炸式的增加，云计算的兴起，业务的拓展与实现面临着又一次新的挑战。
MongoDB的出现可以快速的完成系统的开发于拓展需求。提高持久化系统的吞吐量。

MongoDB相较于普通的关系型数据库（SQL）具备简洁的数据库设计同时设计也是很是容易的。更加契合业务数据特征的存储方式。

下降了不少业务存储上的代价。在工程中应该从严谨的角度来给MongoDB选择合适的业务来存储。

关于性能

性能方面没有必要列举过多的数据来讲明具体的状况。一方面这些都是官方应该干的事。另一方面每次项目每一个公司的硬件环境都有很大的不一样，这些硬件上的不一样会致使测试数据的结果有着天差地别的结果。
最为重要的一点是应用场景的不一样。不一样的业务会致使不一样的数据库使用状况。因此真正想要获得具体的项目解决方案，一方面要靠我的对项目的准确判断，另外一方面具体的方案肯定须要根据状况作出具体的测试。

说到性能确定是要从搜索Page Rank最高的结果提及
来自博主疯狂光纤的博文 http://www.cnblogs.com/crazylights/archive/2013/05/08/3066056.html
以及相关的实战相关博文 http://www.cnblogs.com/crazylights/archive/2013/05/08/3068098.html
客观来说，第一篇文的内容语言的确是比较激进的。缺乏可观的分析。可是第二篇文章直接上了实战来直接说明到底MongoDB性能有多暴力。可是有一点不可取的点就是第一篇说的忘记。这个观点与个人想法有点背道而驰，咱们更应该扬长避短结合SQL于NoSQL的优点来快速完成咱们的需求。正片开始。

简单的存储特征分析

1. 使用KV数据存储（BSON）

   1. 使用方便。相似JSON操做，固然不少语言能够映射到内存里面。
   2. 查询修改也使用BSON，操做更加清晰。

2. 文件存储

   1. 每一条数据都是一个文件，文件有大小限制，若是想使用更大的文件系统请使用GridFS
   2. 提高数据存储于业务的契合度，好比说一个帖子的文件中直接存储回复。一次取出整个文件减小了再次查询回复内容的时间。

3. 查询功能强大

   1. 使用BSON查询的功能很是强大清晰。
   2. 因为使用文件的对象存储方式，所以在索引上相对于普通的 SQL92 标准的数据库会有必定的性能代价。推荐使用有意义的键值来尽可能避免业务的查询。

由于MongoDB有如上的特征。所以：

1. MongoDB更适合存储关系型数据
2. 普通的关系型数据库更适合大量对象的数据检索

理由在于两者索引的区别，前者不适合有大量数据扫描的查询，后者更加擅长大量数据扫描的业务。
在不少文章中MongoDB不适合有太多的skip操做（甚至还提出避免skip的方案）

适应状况的例子

业务描述粒度：具体到CURD应该在什么数据库中存储，
描述方法: 业务类型，使用数据库，场景举例。
这里只是大概描述一下数据库选择的轮廓有一个选择的概念。也只是说了很小一部分的片面的参考。

1. 偏向增长的业务

2. 用户数据版本管理（文章，记事本等）

3. 偏向于复杂关系数据的查询

   1. 帖子的回复（帖子的范围： 能够评论的对象）
   2. 对象状态改变的记录图 (好比说订单状态改变，记录具体时间，事件，发起者，以及其余内容。)

4. 偏向于修改的业务

   1. 用户我的信息的修改（密码，NickName等）
   2. 复杂对象的属性修改（店铺信息等）
   3. 对象复杂可是存储数据内容简短的内容且update比较频繁的状况。

5. 不推荐删除系统数据这部分会在后面给出解释

   1. 数据永远都不要删除，数据就是财富。在凌晨的时候或者负载非得低的时候停机一个小时来维护数据仍是很是值得的。

学习方法路线以及其余应该注意的地方

以前确实参考了不少其余人写的书，可是最后发现。必定仍是Manual写的是最好的。

由浅入深，讲明白了基础知识以后从CURD开始一步一步的讲述MongoDB是如何存储数据的。

所以在这里也是强烈推荐你们从MongoDB的manual开始学习。

驱动

由于语言不一样驱动也有不一样，可是对于MongoDB来讲都是对应几个接口的Bson操做。所以接口比较好脑补。若是遇到难点能够直接绕过去，我在2014年年底的时候就研究出来一套复杂查询的方案。

只在极端状况下使用，若是你的查询过于复杂也许你就犯了Skip过多数据的错误。 http://www.philo.top/1899/11/30/788MongoDB%E5%AD%98%E5%82%A8%E8%BF%87%E7%A8%8B%E6%80%A7%E8%83%BD%E8%B0%83%E4%BC%98/

删除数据

请不要在数据库中删除数据。由于remove()函数不会删除集合自己，同时，原有的索引也一样不会被删除。所以在查询的时候就会留下一个黑洞。对于生产环境会有很大的问题。

关于Don’t use MongoDB

原文连接 http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/
我不作评论，只是几点须要注意

1.吐槽者所解决的问题已是很是复杂的了。就相似于12306已经达到了计算机集群的性能极限。所以只说MongoDB的问题是片面的。
2.这只是高手级别（CTO级别）的吐槽。解决问题的办法老是有的。可能他们须要更加复杂的方案
3 注意吐槽者说的项目时间是在2010年吐槽时间实际在2013年。
4.他们通篇并无说起MongoDB使用的版本可是我相信他们用是MongoDB的官方版本，若是他们的产品是千万用户量级的话,也许就会相似淘宝&&FaceBook同样针对社区产品Fork本身应用场景的Branch

So , do not panic.

Cache必不可少

1.好比说用户表的缓存。

新浪微博对用户分类的方法： 1. 当天登录过的用户 2. 活跃用户 3. 不活跃的用户
咱们能够对第一种跟第二种的状况进行缓存，由于不少用户数据的查询都关系到了User表的查询。在高负载状况请创建用户缓存。
可是请注意优化不要过早。缓存类型根据状况选择Memcache或Redis

2.高速度也是有代价的。所以要针对业务热点作一个权衡，是否应该浪费性能在磁盘IO上。

盲目崇拜

早在2010年的时候我在学校的图书馆里面为数很少的订阅杂志里面发现了NoSQL方面的论文，那时候MongoDB也只是距离First Release刚刚一年而已，而我也只是饶有兴趣的在读里面的CAP理论，清楚的记得，数据库也只能三选二。

再后来2011年的时候Mysql Release 5.5的版。我在寝室里面奔走相告。告诉你们性能提高了百分之55。

而当我毕业的时候正好有一个百万用户量级的需求押在了MySql+MongoDB+Golang的头上。

话很少说，我只看见了不少口炮一方面又开始说XX数据库很垃圾。另外一方面说。你只是不会用而已。可是我的推崇一种更加中立的观点: 工程是一种妥协的艺术。因此方案的选择没有好坏只有根据具体状况的不一样有着不一样的选择。

而通过几个月的研究学习，虽然我很是肤浅的研究了一下MongoDB可是仍是总结出来了一套关于MongoDB性能的掌握，我我的认为适用的应用场景以及最低学习代价的学习方法。

最关键的是，咱们所使用的大部分服务器都是基于冯诺依曼体系的，他规定了计算机核心组件就那么几样，特征也都是固定的，因此只要是同样的机器。

执行指令集的性能应该是同样的。既然你们的大环境都是同样的，只是存储跟查询的方式不同，若是深刻了解以后会发现，两种数据库存储数据的方式上的差别形成了各类业务存储选择的多样化。所以只有深刻学习深刻了解这两种数据库具体的核心内容才能断定到底哪一个更适合你的业务。

转自 初探MongoDB：暴力美学