mongodb总结

mongodb总结

总览：
1，将原来的“行”的概念换成更加灵活的"文档"模型。其文档，数组可以相互内嵌起来。因此mongodb没有模式。
2，容易扩展
如具备灵活的自动的分片功能。
3，不牺牲速度
第一，对文档进行动态填充，预分配数据文件，用空间换取性能的稳定。
其次，默认的存储引擎中使用内存映射文件，将内存管理工作交给操作系统去处理
第三，动态查询优化查询器中会记住执行查询最高效的方式。
第四, 当执行插入的时候，使用的驱动程序会将数据转换成BSON形式，然后将其送入到数据库，数据库服务器解析BSON，只是检验是否包含了“_id”,并且检查文档不超过16M。除此之外不做别的验证。


数据类型：
字符串，数字，日期，数组，内嵌文档，ObjectId类型的_id

瞬间完成
Mongodb的插入，删除，更新都是瞬间完成的，这是因为他们不需要等待数据库的响应，但这并不是异步操作的（疑问，不是异步操作是什么操作）。Mongodb的默认设置为瞬间完成，但是可以通过设置为安全操作的方式来获取操作的返回码。


三个技术点：
1，地理空间索引
2，GridFS进行存储二进制文件的机制
3，区别于内嵌文档的另一种技术DBRef


复制集
是从主从模式演变而来，增加了自动故障转移和节点成员自动恢复。
复制集模式中没有固定的主结点，在启动后，多个服务节点间将自动选举产生一个主结点。该主结点被称为primary，一个或多个从结点被称为secondaries。
primary结点基本上就是master结点，不同之处在于primary结点在不同时间可能是不同的服务器。
如果当前的主结点失效了，复制集中的其余结点将会试图选出一个新的主结点。
复制集模式的好处是，一切自动化。首先，复制集模式本身做了大量的管理工作，自动管理从节点，确保数据不会不一致。其次，主节点挂掉后，会自动判断集群中的服务器并进行故障转移，推举新的主节点。
在一个复制集集群中，各个服务器有以下几种状态：
Primary 主节点，一个复制集有且仅有一台服务器处于Primary状态，只有主节点才对外提供读写服务。如果主节点挂掉，复制集将会投票选出一个备用节点成为新的主节点。
Secondary 备用节点，复制集允许有多台Secondary，每个备用节点的数据与主节点的数据是完全同步的。
Recovering 恢复中，当复制集中某台服务器挂掉或者掉线后数据无法同步，重新恢复服务后从其他成员复制数据，这时就处于恢复过程，数据同步后，该节点又回到备用状态。
Arbiter 仲裁节点，该类节点可以不用单独存在，如果配置为仲裁节点，就主要负责在复本集中监控其他节点状态，投票选出主节点。该节点将不会用于存放数据。如果没有仲裁节点，那么投票工作将由所有节点共同进行。
Down 无效节点，当服务器挂掉或掉线时就会处于该状态。
复制集的从节点读请求，也是在各个Driver层设置slaveOk的值来实现的。






Journal文件：即使服务器意外宕机的情况下，通过journal文件可以对数据库操作进行重演。






参考文献：
Mongodb权威指南