MongoDB 使用记录
一、为什么使用mangodb
1、Highperformance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。
2、HugeStorage - 对海量数据的高效率存储和访问的需求
对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，
3、HighScalability && High Availability- 对数据库的高可扩展性和高可用性的需求
4、MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。它的特点是高性能、易部署、易使用，存储数据非常方便。
MongoDB服务端可运行在Linux、Windows或OS X平台，支持32位和64位应用，默认端口为27017。推荐运行在64位平台，因为MongoDB在32位模式运行时支持的最大文件尺寸为2GB。
二、安装使用
http://dl.mongodb.org/dl/win32/i386 下载安装
http://www.mongovue.com/downloads/ mangodb客户端
输入指令E:\projectTest\MangoDB\mongodb-win32-i386-2.5.0\bin\mongod.exe 进行安装，如下图
再设置db位置，命令为E:\projectTest\MangoDB\mongodb-win32-i386-2.5.0\bin\mongod.exe-dbpath E:\projectTest\MangoDB\myDB (文件夹路径需提前建立)
查看安装情况，命令为E:\projectTest\MangoDB\mongodb-win32-i386-2.5.0\bin\mongod.exe -dbpathE:\projectTest\MangoDB\myDB
三、注意事项
1、MongoDB分成32位版本和64位版本，由于MongoDB使用内存映射文件，所以32位版本只能存储2GB左右的数据。建议存储更多数据的用户使用64位版本。
2、MongoDB是文档型数据库，数据以BSON形式存储在文档中。最新版本的MongoDB能够支持最大16 MB的文档大小。建议用户尽量不要存储大型对象，将文档控制在16 MB以内。
3、MongoDB的写入和更新速度非常快，所以错误提示并不明确。要确保写入正确，建议用户使用getLastError或者使用安全写入。
4、关系型数据库往往会有预定义的schema，你想添加额外的列就需要在整个表上添加。MongoDB没有这个约束，这使得开发和管理变得更简单。但这并不意味着你就可以完全忽视MongoDB的schema设计，一个设计良好的schema能够让MongoDB的性能达到最佳。
5、MongoDB的更新在默认情况下会使用类似于传统数据库的LIMIT语句，即LIMIT 1。因此更新不会影响到所有的文档，如果你想要一次更新许多文档，那么请把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、Replica Set是MongoDB中受关注最多的功能，它能为MongoDB集群增加冗余并提供良好的读性能。但由于ReplicaSet的选举机制，必须保证ReplicaSet成员数目为奇数。如果是偶数的话，主节点宕机就会导致其他节点变为只读。解决方法也可以使用一个仲裁节点(arbiter)，它也是一个Replica Set的成员，但并不存储用户数据。所以请记住设置ReplicaSet成员时要定为奇数。
11、MongoDB中不存在join，你要针对多个集合进行数据检索的时候，必须使用多个查询。所以当你遇到这个问题时，可以考虑重新设计MongoDB的schema。
12、Journaling日志是MongoDB中非常好的功能，能够增强节点的可用性。在2.0版本之后，MongoDB默认是开启Journaling日志功能的。虽然Journaling日志会对数据库性能造成一定的影响，但这部分影响是可以忽略的。因此建议用户开启Journaling功能，特别是对于可用性要求较高的用户。
13、MongoDB默认情况下是没有认证功能的，因此建议用户使用防火墙对MongoDB进行保护。
14、Replica Set的工作是通过传送oplog来完成的，主节点发生故障后，新的数据将会存放在数据目录下的一个特定文件夹内，即rollback文件夹。你可以用来手动完成数据恢复。所以在每次故障发生之后，你一定要看看这个文件夹，MongoDB自带的工具就能够帮助你轻松地完成手动数据恢复。
15、跨服务器的数据拆分中，Sharding是一个有效的方法。MongoDB中支持自动化Sharding，但是对数据库性能会造成很大影响。因此建议用户尽早进行Sharding，使用MMS、Munin (+ Mongo plugin)和CloudWatch等工具对MongoDB进行监控，确保系统资源使用达到80%之前就完成Sharding工作。
16、MongoDB使用shard key来决定特定的文档在哪个分片上，当插入一个文档之后，你是无法更新shardkey的。这里建议用户删除文档并重新插入，这样就能够将其分配到合适的分片上。
17、MongoDB对分片的限制还包括集合的大小，当超过256 GB的时候，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+。