爆炸式发展的NoSQL技术
在过去的很长一段时间中，关系型数据库（Relational Database Management System）一直是最主流的数据库解决方案，他运用真实世界中事物与关系来解释数据库中抽象的数据架构。然而，在信息技术爆炸式发展的今天，大数据已经成为了继云计算，物联网后新的技术革命，关系型数据库在处理大数据量时已经开始吃力，开发者只能通过不断地优化数据库来解决数据量的问题，但优化毕竟不是一个长期方案，所以人们提出了一种新的数据库解决方案来迎接大数据时代的到来——NoSQL（非关系型数据库）。
NoSQL非常年轻，但他拥有的众多优秀的特性已经让众多企业和开发者开始接受，让我们来看一下来自于美国数据库知识网站DB-engines上个月的数据库排名情况。
从排名中可以看到MongoDB数据库从众多的RDBMS（关系型数据库）中脱颖而出，已经成为第五名，并且还在不断上升中。
如果将数据库比喻成人类的话，那么MongoDB完全可以说是神童了，年仅5岁的他单枪匹马挑战一群叔叔级别的人物，并且按照近几年的发展速度来看，他也即将超越PgSQL成为第四名，虽然距离前方三位有着NB爹的富二代还有一定的距离，但在这样一个技术爆炸的年代还有什么不可能的事呢？
为什么选择MongoDB？
1.性能
在大数据时代中，大数据量的处理已经成了考量一个数据库最重要的原因之一。而MongoDB的一个主要目标就是尽可能的让数据库保持卓越的性能，这很大程度地决定了MongoDB的设计。在一个以传统机械硬盘为主导的年代，硬盘很可能会成为性能的短板，而MongoDB选择了最大程度而利用内存资源用作缓存来换取卓越的性能，并且会自动选择速度最快的索引来进行查询。MongoDB尽可能精简数据库，将尽可能多的操作交给客户端，这种方式也是MongoDB能够保持卓越性能的原因之一。
2.扩展
现在互联网的数据量已经从过去的MB、GB变为了现在的TB级别，单一的数据库显然已经无法承受，扩展性成为重要的话题，然而现在的开发人员常常在选择扩展方式的时候犯了难，到底是选择横向扩展还是纵向扩展呢？
——————————————————————————————————————————————————————————————
横向扩展（scale out）是以增加分区的方式将数据库拆分成不同的区块来分布到不同的机器中来，这样的优势是扩展成本低但管理困难。
纵向扩展（scale up） 纵向扩展与横向扩展不同的是他会将原本的服务器进行升级，让其拥有更强大的计算能力。这样的优势是易于管理无需考虑扩展带来的众多问题，但缺点也显而易见，那就是成本高。一台大型机的价格往往非常昂贵，并且这样的升级在数据达到极限时，可能就找不到计算能力更为强大的机器了。
———————————————————————————————————————————————————————————————
而MongoDB选择的是更为经济的横向扩展，他可以很容易的将数据拆分至不同的服务器中。而且在获取数据时开发者也无需考虑多服务器带来的问题，MongoDB可以将开发者的请求自动路由到正确的服务器中，让开发者脱离横向扩展带来的弊病，更专注于程序的开发上。
3.使用
MongoDB采用的是NoSQL的设计方式，可以更加灵活的操作数据。在进行传统的RDBMS中你一定遇到过几十行甚至上百行的复杂SQL语句，传统的RDBMS的SQL语句中包含着大量关联，子查询等语句，在增加复杂性的同时还让性能调优变得更加困难。MongoDB的面向文档（document-oriented）设计中采用更为灵活的文档来作为数据模型用来取代RDBMS中的行，面向文档的设计让开发人员获取数据的方式更加灵活，甚至于开发人员仅用一条语句即可查询复杂的嵌套关系，让开发人员不必为了获取数据而绞尽脑汁。
NoSQL对传统数据库设计思维的影响
1.预设计模式与动态模式
传统数据库设计思维中，项目的设计阶段需要对数据库表中的字段名称、字段类型、进行规定，如果尝试插入不符合设计的数据，数据库不会接受这条数据以保证数据的完整性。
--数据库字段:NAME, SONG
INSERT INTO T_INFO VALUES('John','Come Together'); --成功
INSERT INTO T_INFO VALUES('小明', 20, 'xiaoming@111.com'); --失败
NoSQL采用的是对集合（类似"表"）中的文档（类似于"行"）进行动态追加，在创建集合之初不会对数据类型进行限定，任何文档都可以追加到任何集合中去，例如我们可以将这样两条文档添加到一个集合中去：
{"name" : "John", "song" : "Come Together"}
{"name" : "小明", "age":"20", "email" : "xiaoming@111.com"}
MongoDB中文档的格式类似于我们常见的JSON，由此可见，我们第一个拥有"name"、"song"两个字段，而第二个拥有"name"、"age"、"email"三个字段，这在预设计模式中的数据库是不可能插入成功的，但在MongoDB的动态模式是可以的，这样做的优势是我们不必为一些数量很少，但种类很多的字段单独设计一张表，可以将他们集中在单独一张表进行存储，但这样做的弊病也是显而易见的，我们在获取数据时需要对同一张表的不同文档进行区分，增加了开发上的代码量。所以在设计之初需要权衡动态模式的优劣来选择表中的数据类型。
2.范式化与反范式化
范式化（normalization）是关系模型的发明者埃德加·科德于1970年提出这一概念，范式化会将数据分散到不同的表中，利用关系模型进行关联，由此带来的优点是，在后期进行修改时，不会影响到与其关联的数据，仅对自身修改即可完成。
反范式化（denormalization）是针对范式化提出的相反理念，反范式化会将当前文档的数据集中存放在本表中，而不会采用拆分的方式进行存储。
范式化和反范式化之间不存在优劣的问题，范式化的好处是可以在我们写入、修改、删除时的提供更高性能，而反范式化可以提高我们在查询时的性能。当然NoSQL中是不存在关联查询的，以此提高查询性能，但我们依旧可以以在表中存储关联表ID的方式进行范式化。但由此可见，NoSQL的理念中反范式化的地位是大于范式化的。
MongoDB还年轻
MongoDB又有众多卓越的设计，但MongoDB依然存在着许多不擅长的问题，其中包括：
1. MongoDB不支持事务，现在众多的软件依旧需要事务的管理，所以对于事务一致性要求较高的程序只能在软件层面进行管理，而无法从数据库进行管理。
2. 其他工具的支持范围，MongoDB从发布起到现在还不到5年的时间，所以会面临着许多的语言没有对应的工具包，所以如果你使用的语言没有对应的包，可能是导致你无法使用MongoDB最大的阻碍。
3. 社区的资源量，这个问题同第二个问题一样是因为MongoDB过于年轻导致的，相对于其他大型数据库的社区而言，MongoDB显然是无法与之相比的，然而社区往往也是一个重要考量因素之一，社区资源的匮乏会导致问题解决周期延长，从而拖延工作。
近几年的技术发展之快是激动人心的，每年都会出现让人眼前一亮的产品，然而它都需要经过时间的累积才能成为一个成熟的产品，MongoDB还需要成长，但他优秀的设计，肯定会让越来越多的开发者接受它。
性能与用户量
“如何能让软件拥有更高的性能？”，我想这是一个大部分开发者都思考过的问题。性能往往决定了一个软件的质量，如果你开发的是一个互联网产品，那么你的产品性能将更加受到考验，因为你面对的是广大的互联网用户，他们可不是那么有耐心的。严重点说，页面的加载速度每增加一秒也许都会使你失去一部分用户，也就是说，加载速度和用户量是成反比的。那么用户能够接受的加载速度到底是多少呢？
如图，如果页面加载时间超过10s那么用户就会离开，如果1s--10s的话就需要有提示，但如果我们的页面没有提示的话需要多快的加载速度呢？是的，1s 。
当然，这是站在一个产品经理的角度来说的，但如果站在一个技术人员的角度来说呢？加载速度和用户量就是成正比的，你的用户数量越多需要处理的数据当然也就越多，加载速度当然也就越慢。这是一件很有趣的事，所以如果你的产品如果是一件激动人心的产品，那么作为技术人员你需要做的事就是让软件的性能和用户的数量同时增长，甚至性能增长要快于用户量的增长。
数据库性能对软件整体性能的影响是不言而喻的，那么，当我们使用MongoDB时改如何提高数据库性能呢？
1.范式化与反范式化
在项目设计阶段，明确集合的用途是对性能调优非常重要的一步。
从性能优化的角度来看，集合的设计我们需要考虑的是集合中数据的常用操作，例如我们需要设计一个日志（log）集合，日志的查看频率不高，但写入频率却很高，那么我们就可以得到这个集合中常用的操作是更新（增删改）。如果我们要保存的是城市列表呢？显而易见，这个集合是一个查看频率很高，但写入频率很低的集合，那么常用的操作就是查询。
对于频繁更新和频繁查询的集合，我们最需要关注的重点是他们的范式化程度，在上篇范式化与反范式化的介绍中我们了解到，范式化与反范式化的合理运用对于性能的提高至关重要。然而这种设计的使用非常灵活，假设现在我们需要存储一篇图书及其作者，在MongoDB中的关联就可以体现为以下几种形式：
1.完全分离（范式化设计）
示例1：
{ "_id" : ObjectId("5124b5d86041c7dca81917"), "title" : "如何使用MongoDB", "author" : [ ObjectId("144b5d83041c7dca84416"), ObjectId("144b5d83041c7dca84418"), ObjectId("144b5d83041c7dca84420"), ] }
我们将作者(comment) 的id数组作为一个字段添加到了图书中去。这样的设计方式是在非关系型数据库中常用的，也就是我们所说的范式化设计。在MongoDB中我们将与主键没有直接关系的图书单独提取到另一个集合，用存储主键的方式进行关联查询。当我们要查询文章和评论时需要先查询到所需的文章，再从文章中获取评论id，最后用获得的完整的文章及其评论。在这种情况下查询性能显然是不理想的。但当某位作者的信息需要修改时，范式化的维护优势就凸显出来了，我们无需考虑此作者关联的图书，直接进行修改此作者的字段即可。
2.完全内嵌（反范式化设计）
示例2：
{ "_id" : ObjectId("5124b5d86041c7dca81917"), "title" : "如何使用MongoDB", "author" : [ { "name" : "丁磊" "age" : 40, "nationality" : "china", }, { "name" : "马云" "age" : 49, "nationality" : "china", }, { "name" : "张召忠" "age" : 59, "nationality" : "china", }, ] }
在这个示例中我们将作者的字段完全嵌入到了图书中去，在查询的时候直接查询图书即可获得所对应作者的全部信息，但因一个作者可能有多本著作，当修改某位作者的信息时时，我们需要遍历所有图书以找到该作者，将其修改。
3.部分内嵌（折中方案）
示例3：
{ "_id" : ObjectId("5124b5d86041c7dca81917"), "title" : "如何使用MongoDB", "author" : [ { "_id" : ObjectId("144b5d83041c7dca84416"), "name" : "丁磊" }, { "_id" : ObjectId("144b5d83041c7dca84418"), "name" : "马云" }, { "_id" : ObjectId("144b5d83041c7dca84420"), "name" : "张召忠" }, ] }
这次我们将作者字段中的最常用的一部分提取出来。当我们只需要获得图书和作者名时，无需再次进入作者集合进行查询，仅在图书集合查询即可获得。
这种方式是一种相对折中的方式，既保证了查询效率，也保证的更新效率。但这样的方式显然要比前两种较难以掌握，难点在于需要与实际业务进行结合来寻找合适的提取字段。如同示例3所述，名字显然不是一个经常修改的字段，这样的字段如果提取出来是没问题的，但如果提取出来的字段是一个经常修改的字段（比如age）的话，我们依旧在更新这个字段时需要大范围的寻找并依此进行更新。
在上面三个示例中，第一个示例的更新效率是最高的，但查询效率是最低的，而第二个示例的查询效率最高，但更新效率最低。所以在实际的工作中我们需要根据自己实际的需要来设计表中的字段，以获得最高的效率。
2.理解填充因子
何为填充因子？
填充因子（padding factor）是MongoDB为文档的扩展而预留的增长空间，因为MongoDB的文档是以顺序表的方式存储的，每个文档之间会非常紧凑，如图所示。
（注：图片出处：《MongoDB The Definitive Guide》）
1.元素之间没有多余的可增长空间。
2.当我们对顺序表中某个元素的大小进行增长的时候，就会导致原来分配的空间不足，只能要求其向后移动。
3.当修改元素移动后，后续插入的文档都会提供一定的填充因子，以便于文档频繁的修改，如果没有不再有文档因增大而移动的话，后续插入的文档的填充因子会依此减小。
填充因子的理解之所以重要，是因为文档的移动非常消耗性能，频繁的移动会大大增加系统的负担，在实际开发中最有可能会让文档体积变大的因素是数组，所以如果我们的文档会频繁修改并增大空间的话，则一定要充分考虑填充因子。
那么如果我们的文档是个常常会扩展的话，应该如何提高性能？
两种方案
1.增加初始分配空间。在集合的属性中包含一个 usePowerOf2Sizes 属性，当这个选项为true时，系统会将后续插入的文档，初始空间都分配为2的N次方。
这种分配机制适用于一个数据会频繁变更的集合使用，他会给每个文档留有更大的空间，但因此空间的分配不会像原来那样高效，如果你的集合在更新时不会频繁的出现移动现象，这种分配方式会导致写入速度相对变慢。
2.我们可以利用数据强行将初始分配空间扩大。
1 db.book.insert({
2 "name" : "MongoDB",
3 "publishing" : "清华大学出版社",
4 "author" : "john"
5 "tags" : []
6 "stuff" : "ggggggggggggggggggggggggggggggggggggg
7 ggggggggggggggggggggggggggggggggggggg
8 ggggggggggggggggggggggggggggggggggggg"
9 })
是的，这样看起来可能不太优雅...但有时却很有效！当我们对这个文档进行增长式修改时，只要将stuff字段删掉即可。当然，这个stuff字段随便你怎么起名，包括里边的填充字符当然也是可以随意添加的。
3.准确利用索引
索引对于一个数据库的影响相信大家一定了解，如果一个查询命令进入到数据库中后，查询优化器没有找到合适的索引，那么数据库会进行全集合扫描(在RDBMS中也叫全表扫描)，全集合查询对于性能的影响是灾难性的。没有索引的查询就如同在词典那毫无规律的海量词汇中获得某个你想要的词汇，但这个词典是没有目录的，只能通过逐页来查找。这样的查找可能会让你耗费几个小时的时间，但如果要求你查询词汇的频率如同用户访问的频率一样的话。。。嘿嘿，我相信你一定会大喊“老子不干了！”。显然计算机不会这样喊，它一直是一个勤勤恳恳的员工，不论多么苛刻的请求他都会完成。所以请通过索引善待你的计算机：D。
在MongoDB中索引的类型与RDBMS中大体一致，我们不做过多重复，我们来看一下在MongoDB中如何才能更高效的利用索引。
1.索引越少越好
索引可以极大地提高查询性能，那么索引是不是越多越好？答案是否定的，并且索引并非越多越好，而是越少越好。每当你建立一个索引时，系统会为你添加一个索引表，用于索引指定的列，然而当你对已建立索引的列进行插入或修改时，数据库则需要对原来的索引表进行重新排序，重新排序的过程非常消耗性能，但应对少量的索引压力并不是很大，但如果索引的数量较多的话对于性能的影响可想而知。所以在创建索引时需要谨慎建立索引，要把每个索引的功能都要发挥到极致，也就是说在可以满足索引需求的情况下，索引的数量越少越好。
一. 隐式索引
//建立复合索引
db.test.ensureIndex({"age": 1,"no": 1,"name": 1 })
我们在查询时可以迅速的将age,no字段进行排序，隐式索引指的是如果我们想要排序的字段包含在已建立的复合索引中则无需重复建立索引。
db.test.find().sort("age": 1,"no": 1)
db.test.find().sort("age": 1)
如以上两个排序查询，均可使用上面的复合索引，而不需要重新建立索引。
二. 翻转索引
//建立复合索引
db.test.ensureIndex({"age": 1})
翻转索引很好理解，就是我们在排序查询时无需考虑索引列的方向，例如这个例子中我们在查询时可以将排序条件写为"{'age': 0}"，依旧不会影响性能。
2.索引列颗粒越小越好
什么叫颗粒越小越好？在索引列中每个数据的重复数量称为颗粒，也叫作索引的基数。如果数据的颗粒过大，索引就无法发挥该有的性能。例如，我们拥有一个"age"列索引，如果在"age"列中，20岁占了50%，如果现在要查询一个20岁，名叫"Tom"的人，我们则需要在表的50%的数据中查询，索引的作用大大降低。所以，我们在建立索引时要尽量将数据颗粒小的列放在索引左侧，以保证索引发挥最大的作用。