爆炸式发展的NoSQL技术—-MongoDB
在过去的很长一段时间中，关系型数据库（RelationalDatabaseManagementSystem）一直是最主流的数据库解决方案，他运用真实世界中事物与关系来解释数据库中抽象的数据架构。然而，在信息技术爆炸式发展的今天，大数据已经成为了继云计算，物联网后新的技术革命，关系型数据库在处理大数据量时已经开始吃力，开发者只能通过不断地优化数据库来解决数据量的问题，但优化毕竟不是一个长期方案，所以人们提出了一种新的数据库解决方案来迎接大数据时代的到来——NoSQL（非关系型数据库）。
NoSQL非常年轻，但他拥有的众多优秀的特性已经让众多企业和开发者开始接受，让我们来看一下来自于美国数据库知识网站DB-engines上个月的数据库排名情况。
从排名中可以看到MongoDB数据库从众多的RDBMS（关系型数据库）中脱颖而出，已经成为第五名，并且还在不断上升中。
如果将数据库比喻成人类的话，那么MongoDB完全可以说是神童了，年仅5岁的他单枪匹马挑战一群叔叔级别的人物，并且按照近几年的发展速度来看，他也即将超越PgSQL成为第四名，虽然距离前方三位有着NB爹的富二代还有一定的距离，但在这样一个技术爆炸的年代还有什么不可能的事呢？
为什么选择MongoDB？
1.性能
在大数据时代中，大数据量的处理已经成了考量一个数据库最重要的原因之一。而MongoDB的一个主要目标就是尽可能的让数据库保持卓越的性能，这很大程度地决定了MongoDB的设计。在一个以传统机械硬盘为主导的年代，硬盘很可能会成为性能的短板，而MongoDB选择了最大程度而利用内存资源用作缓存来换取卓越的性能，并且会自动选择速度最快的索引来进行查询。MongoDB尽可能精简数据库，将尽可能多的操作交给客户端，这种方式也是MongoDB能够保持卓越性能的原因之一。
2.扩展
现在互联网的数据量已经从过去的MB、GB变为了现在的TB级别，单一的数据库显然已经无法承受，扩展性成为重要的话题，然而现在的开发人员常常在选择扩展方式的时候犯了难，到底是选择横向扩展还是纵向扩展呢？
横向扩展（scaleout）是以增加分区的方式将数据库拆分成不同的区块来分布到不同的机器中来，这样的优势是扩展成本低但管理困难。
纵向扩展（scaleup）纵向扩展与横向扩展不同的是他会将原本的服务器进行升级，让其拥有更强大的计算能力。这样的优势是易于管理无需考虑扩展带来的众多问题，但缺点也显而易见，那就是成本高。一台大型机的价格往往非常昂贵，并且这样的升级在数据达到极限时，可能就找不到计算能力更为强大的机器了。
而MongoDB选择的是更为经济的横向扩展，他可以很容易的将数据拆分至不同的服务器中。而且在获取数据时开发者也无需考虑多服务器带来的问题，MongoDB可以将开发者的请求自动路由到正确的服务器中，让开发者脱离横向扩展带来的弊病，更专注于程序的开发上。
3.使用
MongoDB采用的是NoSQL的设计方式，可以更加灵活的操作数据。在进行传统的RDBMS中你一定遇到过几十行甚至上百行的复杂SQL语句，传统的RDBMS的SQL语句中包含着大量关联，子查询等语句，在增加复杂性的同时还让性能调优变得更加困难。MongoDB的面向文档（document-oriented）设计中采用更为灵活的文档来作为数据模型用来取代RDBMS中的行，面向文档的设计让开发人员获取数据的方式更加灵活，甚至于开发人员仅用一条语句即可查询复杂的嵌套关系，让开发人员不必为了获取数据而绞尽脑汁。
NoSQL对传统数据库设计思维的影响
1.预设计模式与动态模式
传统数据库设计思维中，项目的设计阶段需要对数据库表中的字段名称、字段类型、进行规定，如果尝试插入不符合设计的数据，数据库不会接受这条数据以保证数据的完整性。
#p#分页标题#e#
NoSQL采用的是对集合（类似”表”）中的文档（类似于”行”）进行动态追加，在创建集合之初不会对数据类型进行限定，任何文档都可以追加到任何集合中去，例如我们可以将这样两条文档添加到一个集合中去：
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还需要成长，但他优秀的设计，肯定会让越来越多的开发者接受它。
MongoDB是目前最流行的NoSQL数据库，越来越多的DBA开始深入研究MongoDB。当然关注的人越多，暴露问题的机会也就越多，有不少用户开始抱怨MongoDB有这样的不足有那样的限制，对此伦敦MongoDB用户组的创始人RussellSmith特意在博客中进行了解答。他告诫用户，虽然MongoDB有一定的限制，但是只需一点点技巧就完全能够避免这些问题。以下就是给MongoDB用户的一些建议：
1、MongoDB分成32位版本和64位版本，由于MongoDB使用内存映射文件，所以32位版本只能存储2GB左右的数据。建议存储更多数据的用户使用64位版本。
#p#分页标题#e#
2、MongoDB是文档型数据库，数据以BSON形式存储在文档中。最新版本的MongoDB能够支持最大16MB的文档大小。建议用户尽量不要存储大型对象，将文档控制在16MB以内。
3、MongoDB的写入和更新速度非常快，所以错误提示并不明确。要确保写入正确，建议用户使用getLastError或者使用安全写入。
4、关系型数据库往往会有预定义的schema，你想添加额外的列就需要在整个表上添加。MongoDB没有这个约束，这使得开发和管理变得更简单。但这并不意味着你就可以完全忽视MongoDB的schema设计，一个设计良好的schema能够让MongoDB的性能达到最佳。
5、MongoDB的更新在默认情况下会使用类似于传统数据库的LIMIT语句，即LIMIT1。因此更新不会影响到所有的文档，如果你想要一次更新许多文档，那么请把multi设为true。
6、MongoDB默认情况下是区分大小写的，例如db.people.find({name:'Russell'})和db.people.find({name:'russell'})就是不一样的。所以用户需要知道MongoDB的大小写限制。
7、传统数据库中，如果插入错误的数据类型，通常会提示错误或者强制转换成预定义的数据值。MongoDB中没有这种限制，所以输入错误数据类型不会出现提示。建议用户确保输入正确的数据类型。
8、全局锁是一直被MongoDB用户诟病的特性，MongoDB2.2中增加了数据库级锁，这是一个很大的改进。建议用户使用稳定版的MongoDB2.2数据库，避免全局锁限制。
9、过期版本MongoDB用户在下载程序包时会出问题，建议用户使用10gen最新版本的官方程序包。
10、ReplicaSet是MongoDB中受关注最多的功能，它能为MongoDB集群增加冗余并提供良好的读性能。但由于ReplicaSet的选举机制，必须保证ReplicaSet成员数目为奇数。如果是偶数的话，主节点宕机就会导致其他节点变为只读。解决方法也可以使用一个仲裁节点(arbiter)，它也是一个ReplicaSet的成员，但并不存储用户数据。所以请记住设置ReplicaSet成员时要定为奇数。
11、MongoDB中不存在join，你要针对多个集合进行数据检索的时候，必须使用多个查询。所以当你遇到这个问题时，可以考虑重新设计MongoDB的schema。
12、Journaling日志是MongoDB中非常好的功能，能够增强节点的可用性。在2.0版本之后，MongoDB默认是开启Journaling日志功能的。虽然Journaling日志会对数据库性能造成一定的影响，但这部分影响是可以忽略的。因此建议用户开启Journaling功能，特别是对于可用性要求较高的用户。
13、MongoDB默认情况下是没有认证功能的，因此建议用户使用防火墙对MongoDB进行保护。
14、ReplicaSet的工作是通过传送oplog来完成的，主节点发生故障后，新的数据将会存放在数据目录下的一个特定文件夹内，即rollback文件夹。你可以用来手动完成数据恢复。所以在每次故障发生之后，你一定要看看这个文件夹，MongoDB自带的工具就能够帮助你轻松地完成手动数据恢复。
15、跨服务器的数据拆分中，Sharding是一个有效的方法。MongoDB中支持自动化Sharding，但是对数据库性能会造成很大影响。因此建议用户尽早进行Sharding，使用MMS、Munin(+Mongoplugin)和CloudWatch等工具对MongoDB进行监控，确保系统资源使用达到80%之前就完成Sharding工作。
16、MongoDB使用shardkey来决定特定的文档在哪个分片上，当插入一个文档之后，你是无法更新shardkey的。这里建议用户删除文档并重新插入，这样就能够将其分配到合适的分片上。
17、MongoDB对分片的限制还包括集合的大小，当超过256GB的时候，MongoDB将不允许进行分片。相信10gen公司会在未来放弃这一限制，但在此之前用户需要留意。
18、MongoDB中跨分片并没有强制要求唯一性，MongoDB只针对独立的分片进行强制而非全局性。当然除shardkey之外。
19、进行拆分的时候，MongoDB会要求你选择一个键。用户需要注意选择正确的键，否则会造成不必要的麻烦。如何进行选择并无定式，主要取决于你的应用，比如针对newsfeed使用时间戳就是错的。在下一版本中，MongoDB将对此进行改进。
20、MongoDB连接默认情况下是不加密的，也就是说你的数据是能够被第三方记录和使用的。所以你在公共网中访问MongoDB的话，就一定要进行加密。
21、MongoDB只支持单一文档的原子性，这一点与传统的数据库有所不同，如MySQL。因此MongoDB中跨多个文档是不提供内置的transaction支持的。
22、当MongoDB显示ready的时候，其实内部还在进行journal的配置。因此针对速度较慢的文件系统，MongoDB的journal配置也会很慢。
23、不建议尝试NUMA+Linux+MongoDB的组合，如果你的MongoDB跑在NUMA服务器上，建议将它关掉。
24、在Linux上运行MongoDB遭遇segfault错误时，这主要是因为openfiles/process限制过低。建议用户将限制设定为4K+。
小编结语：
更多内容尽在课课家教育！
