mongodb杂记

MongoDB是当前最受欢迎的新一代数据库。迄今为止已经有接近800万下载。使用MongoDB的用户包括财富500公司如eBay, Cisco, MetLife, 

mongodb介绍

    MongoDB (名称来自"humongous") 是一个可扩展的高性能，开源，模式自由，面向文档的数据库。它使用C++编写。MongoDB特点:

  a.面向集合的存储：适合存储对象及JSON形式的数据。

  b.动态查询：mongo支持丰富的查询表达方式，查询指令使用JSON形式的标记，可轻易查询文档中的内嵌的对象及数组。

  c.完整的索引支持:包括文档内嵌对象及数组。mongo的查询优化器会分析查询表达式，并生成一个高效的查询计划。

  d.查询监视：mongo包含一个监视工具用于分析数据库操作性能。

  e.复制及自动故障转移：mongo数据库支持服务器之间的数据复制，支持主-从模式及服务器之间的相互复制。复制的主要目的是提供冗余及自动故障转移。

  f.高效的传统存储方式：支持二进制数据及大型对象（如照片或图片）。

  g.自动分片以支持云级别的伸缩性：自动分片功能支持水平的数据库集群，可动态添加额外的机器。

2.mongo使用场合

    mongodb的主要目标是在键/值存储方式（提供了高性能和高度伸缩性）以及传统的RDBMS系统（丰富的功能）架起一座桥梁，集两者的优势于一身。mongo适用于以下场景：

  a.网站数据：mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。

  b.缓存：由于性能很高，mongo也适合作为信息基础设施的缓存层。在系统重启之后，由mongo搭建的持久化缓存可以避免下层的数据源过载。

  c.大尺寸、低价值的数据：使用传统的关系数据库存储一些数据时可能会比较贵，在此之前，很多程序员往往会选择传统的文件进行存储。

  d.高伸缩性的场景：mongo非常适合由数十或者数百台服务器组成的数据库。

  e.用于对象及JSON数据的存储：mongo的BSON数据格式非常适合文档格式化的存储及查询。

不适合的场景：

  a.高度事物性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。

  b.传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。

  c.需要SQL的问题。

  

  B+Tree

地理位置索引支持是MongoDB的一大亮点，这也是全球最流行的LBS服务foursquare 选择MongoDB的原因之一。

5.内从映射存储引擎

MongoDB默认的存储引擎是内存映射引擎,当服务器启动后,将所有数据文件映射到内存,然后由操作系统来

负责将缓冲数据写入磁盘并将数据调入调出内存页面

这样的移情有若干重要的特性:

a)MongoDB管理内存的代码非常精炼,原因是将大部分工作交给了操作系统.

b)MongoDB服务器进程的虚拟大小通常会非常大,超过整个数据集的大小,这没关系,

因为操作系统会处理让那些数据常驻内存.

c)MongoDB不能控制数据写入到磁盘的顺序,也就不能用预写日志提供单机的持久性.

d)32位的MongoDB服务器有个限制,每个mongod最多处理2GB数据,这是因为所有数据必须能用32

位地址访问到.

Wire Protocol

TCP是一种Stream的通讯方式，每次请求之间没有间隔，数据源源不断的发来，那如何才能识别出一个完整的请求块？一般的解决方法是加上一个Header，Header的长度固定，用来描述余下的信息量，包括携带的信息长度。额外说明：MongoDB的网络协议都是little-endian。

Journal

In order to ensure that all modifications to a MongoDB data set are durably written to disk, MongoDB, by default, records all modifications to an on-disk journal. MongoDB writes more frequently to the journal than it writes the data files. The journal allows
MongoDB to successfully recover data from data files after a mongod instance exits without flushing all changes.

See Journaling for more information about the journal in MongoDB.

6. sharding、replica set对并发的影响

　在sharding模式下每一个mongod实例都是独立于分片集群中其它实例的包括它的锁，一个mongod实例中的锁不会影响其它实例。 

　在replica set模式下因为要保持primary、secondaries之间的同步，所以当在primary写入数据的时候MongoDB同步更新primary中的oplog（oplog是一个特殊的集合在local数据库中），因此MongoDB会同时锁住两个数据库以保证同步。

是用的 WiredTiger 引擎，对数据是文档锁，不像以前是库锁的，所以插入和更新性能比之前好很多，很适用于写操作比较频繁的场景。hbase 最后还是没用上，下次有机会再用吧，确实感觉适用场景比较局限，先跑阵子看看吧，我们用的Mongodb 3.0.5，目前为止一切正常，不知道会不会踩到什么坑。。祈祷吧，哈哈~

存储的话与2.6相比磁盘占用量也减少了一些，对于内存的开销从2.6的有多少吃多少到3.0的可以设定。一系列的调优让人眼前一亮；终于在3.0.2版本后按耐不住，将线上项目升级到3.X。对于部署来讲即使在2.6版本的mongodb，官方也是不建议使用主从部署的，在3.0更是标注将在下个大版本取消掉这种部署模式，mongodb的核心点在于部署，分片则是部署的核心点，而片键的选择更是分片的核心。当然，很难推动分片部署的原因在于主从<复制集<分片（数据冗余度，白话就是磁盘空间大小）。

请教两个问题

主从<复制集<分片。主从的冗余度为什么小于复制集？

以关系型数据库的思维部署mongodb体现在哪里？

主从一般会一主一从，或一主二从，而复制集部署最少是一个活跃节点和两个备份节点（原因在于如果活跃节点挂掉后，剩余的非活跃节点不仅要做数据备份，还要提供查询服务会挂的更快）。所以一般情况下复制集一份数据都要存储三份或更多。

关系型数据库的思维是指部署方案主从的选择以及不考虑死锁因素。对于主从方案，一般情况下为了容灾或是单点故障都会做数据的备份，很自然的会使用主从的模式，但是这种模式其实很需要外界的介入（比如主挂掉了自动漂移肯定是外部逻辑实现，不会像复制集一样自主选举），这样就是舍近求远的思路。对于死锁关注度不够，使用关系型数据库（比如mysql很自然的会将一些表存在同一个库下）习惯将多个表放在同一库中，这样一个表的逻辑出现锁将会影响本库（指2.6版本）所有表的业务逻辑。

MongoDB 分片

分片

在Mongodb里面存在另一种集群，就是分片技术,可以满足MongoDB数据量大量增长的需求。

当MongoDB存储海量的数据时，一台机器可能不足以存储数据也足以提供可接受的读写吞吐量。这时，我们就可以通过在多台机器上分割数据，使得数据库系统能存储和处理更多的数据。

为什么使用分片

复制所有的写入操作到主节点

延迟的敏感数据会在主节点查询

单个副本集限制在12个节点

当请求量巨大时会出现内存不足。

本地磁盘不足

垂直扩展价格昂贵

MongoDB 复制（副本集）

MongoDB复制是将数据同步在多个服务器的过程。

复制提供了数据的冗余备份，并在多个服务器上存储数据副本，提高了数据的可用性， 并可以保证数据的安全性。

复制还允许您从硬件故障和服务中断中恢复数据。

什么是复制?

保障数据的安全性

数据高可用性 (24*7)

灾难恢复

无需停机维护（如备份，重建索引，压缩）

分布式读取数据

MongoDB复制原理

mongodb的复制至少需要两个节点。其中一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据。

mongodb各个节点常见的搭配方式为：一主一从、一主多从。

主节点记录在其上的所有操作oplog，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。

MongoDB复制结构图如下所示：

=averageifs(A:A,A2)

　另一个值得关注的地方是，Stack Overflow 仍然使用着纵向扩展策略，没有使用云。他们使用了 384GB 的内存和 2TB 的 SSD 来支撑 SQL Servers，如果使用 AWS 的话，花费可想而知。没有使用云的另一个原因是 Stack Overflow 认为云会一定程度上的降低性能，同时也会给优化和排查系统问题增加难度。此外，他们的架构也并不需要横向扩展。峰值期间是横向扩展的杀手级应用场景，然而他们有着丰富的系统调整经验去应对。该公司仍然坚持着 Jeff Atwood 的名言——硬件永远比程序员便宜。

下表中列出了多个SQL中的术语和概念以及相对应的MongoDB中的术语和概念。

在MongoDB中推荐使用管道来做聚合，是因为管道使用了MongoDB内置的原生操作，聚合效率非常高。

在 3.2 版更改: Starting in MongoDB 3.2, config servers for sharded clusters can be deployed as a replica set. The replica set config servers must run the WiredTiger storage engine. MongoDB 3.2 deprecates the use of three mirrored mongod instances for config servers.

最常见的做法是将 mongos 运行在应用所在的系统上,不过在分片上或者其他专用的机器上运行也是可以的.

片键决定了集群中一个集合的 documents 在不同 shards 中的分布.片键字段必须被索引,且在集合中的每条记录都不能为空,可以是单个字段或复合字段.

MongoDB使用片键的范围把数据分布在分片中,每个范围,又称为数据块,定义了一个不重叠的片键范围,MongoDB把数据块与他们存储的文档分布到集群中的不同分片中.

片键在写入后不能被改变,参见 集合的限制 以获取更多信息.

片键上的索引 不能 是 多键索引

应用服务器或者 mongos 不可用

If each application server has its own mongos instance, other application servers can continue to access the database. Furthermore, mongos instances do not maintain persistent state, and they can restart and become unavailable without losing any state or data.
When a mongos instance starts, it retrieves a copy of the config database and can begin routing queries.

MMAPv1

In the default configuration for the MMAPv1 storage engine, MongoDB writes to the data files on disk every 60 seconds and writes to the journal files roughly every 100 milliseconds.

什么时候我应该使用GridFS？

For documents in a MongoDB collection, you should always use GridFS for storing files larger than 16 MB.

提升 MongoDB 安全性的 10 个提示
http://blog.csdn.net/jamescookres988/article/details/51278388