知识前提:
数据库的CAP原则: 一致性、可用性、分区容错性(只能能满足三者之二)
一致性:
强一致性
弱一致性:
最终一致性:时间窗口
实现一致性:
NRW法则
两段式提交2pc
paxos算法
两段式提交2pc实现过程:
第一阶段:协调者询问参与者是否可以提交事务。如果参与者事务操作执行成功则回复yes,反之no
第二阶段:参与者都回复yes,协调者发出提交请求,则参与者收到后开始提交事务并释放相关资源。反之参与者 则事务回滚并释放资源
可能出现的问题:
第二阶段的时候,假如其中一个参与者收到了do commit命令然后它提交了事务,但是另外一个参与者可能因为 网络问题或者协调者挂掉了,导致一直苦苦等待一直占用资源,另外导致数据不一致
另外假如协调者是集群,如果协调者在发出一个commit指令的时候宕机了,然后刚好一个接受到该命令的参与 者也宕机了,等选举出新的协调者的时候,无法知道现在事务的状态
mongodb是一个开源的,基于分布式的,面向文档存储的非关系型数据库。是非关系型数据库当中功能最丰富、最像关系数据库的。
mongoDB由C++编写,其名字来源于"humongous"这个单词,其宗旨在于处理大量数据。
mongoDB可以运行在Windows、unix、OSX、Solaris系统上,支持32位和64位应用,提供多种编程语言的驱动程序。
mongoDB支持的数据结构非常松散,是json的格式,通过键值对的形式存储数据,可以存储复杂的数据类型。
mongoDB支持的数据类型有:null、boolean、String、objectId、32位整数、64位整数、64位浮点数、日期、正则表达式、js代码、二进制数据、数组、内嵌文档、最大值、最小值、未定义类型。
其中,内嵌文档我理解的并不是.doc.txt等文件,这里所指的文档是mongoDB的一个存储单元(相当于关系型数据当中的记录),在mongoDB中的表现形式为{key1:value1,key2:value2},而内嵌文档则是这样的形式{key1:value1,key2:{key2.1:value2.1,key2.2:value2.2}}。
mongoDB最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。
二、mongoDB的特性:
1. 面向集合存储。数据被分组到若干集合,每个集合可以包含无限个文档,可以将集合想象成RDBMS的表,区别是集合不需要进行模式定义。
2. 模式自由。集合中没有行和列的概念,每个文档可以有不同的key,key的值不要求一致的数据类型。
3. 支持动态查询。mongoDB支持丰富的查询表达式,查询指令使用json形式表达式。
4. 完整的索引支持。mongoDB的查询优化器会分析查询表达式,并生成一个高效的查询计划。
5. 高效的数据存储,支持二进制数据及大型对象(图片、视频等)。
6. 支持复制和故障恢复。
7. 自动分片以支持云级别的伸缩性,支持水平的数据库集群,可动态添加额外的服务器。
三、 mongoDB的适用场景:
1. 适合作为信息基础设施的持久化缓存层
2. 适合实时的插入、更新与查询,并具备应用程序实时数据存储所需的复制及高度伸缩性
3. 适合文档化格式的存储及查询
4. 适合由数十或数百台服务器组成的数据库
四、mongoDB不适用场景:
1. 要求高度事务性的系统。例如对于银行或会计等需要大量原子性复杂事物的应用程序来说,还是需要关系型数据库的。
2. 传统的商业智能应用
3. 复杂的表级联查询
Mysql和MongoDB的比较
![](http://img.bbs.csdn.net/upload/201409/15/1410763099_785499.png)
![](http://img.bbs.csdn.net/upload/201409/15/1410763109_683124.png)
mongodb的复制功能:
1. master/slave
2. replica set:复制集、副本集 服务于同一数据集的多个mongodb实例,主节点将数据修改操作保存至oplog中
工作特性:至少三个,且应该为奇数个节点;可以使用arbiter来参与选举;
heartbeat(2s), 自动失效转移(通过选举方式实现)
复制集的中特殊类型的节点:
0优先级的节点:冷备节点,不会被选举成为主节点,但可以参与选举;
被隐藏的从节点:首先是一个0优先级的从节点,且对客户端不可见;
延迟复制的从节点:首先是一个0优先级的从节点,且复制时间落后于主节点一个固定时长;
arbiter:
MongoDB的复制架构:
oplog
heartbeat
oplog: 大小固定的文件,存储在local数据库
初始同步(initial sync)
回滚后追赶(post-rollback catch-up)
切分块迁移(sharding chunk migrations)
local: 存放了副本集的所有元数据和oplog;用于存储oplog的是一个名为oplog.rs的collection;
oplog.rs的大小依赖于OS及文件系统;但可以自定义其大小oplogSize
Mongo的数据同步类型:
初始同步:
节点没有任何数据时
节点丢失副本复制历史
复制
初始同步的步骤:
1、克隆所有数据库
2、应用数据集的所有改变:复制oplog并应用于本地
3、为所有collection构建索引
副本集的重新选举的影响条件:
心跳信息
优先级
optime
网络连接
网络分区
选举机制:
触发选举的事件:
新副本集初始化时
从节点联系不到主节点时
主节点“下台”时
主节点收到stepDown()命令时
某从节点有更高的优先级且已经满足成主节点其它所有条件
主节点无法联系到副本集的“多数方”
MongoDB的分片:
CPU
Memory
IO
MySQL: Gizzard, HiveDB, MySQL Proxy + HSACLE, Hibernate Shard, Pyshards
分片架构中的角色:
mongos: Router
config server: 元数据服务器
shard: 数据节点,也称mongod实例
zookeeper
基于范围切片
range
基于列表切片
list
基于hash切片
hash
写离散,读集中
面试题总结:
3. MySQL与MongoDB之间最基本的差别是什么?
MySQL和MongoDB两者都是免费开源的数据库。MySQL和MongoDB有许多基本差别包括数据的表示(data representation),查询,关系,事务
,schema的设计和定义,标准化(normalization),速度和性能。通过比较MySQL和MongoDB,实际上我们是在比较关系型和非关系型数据库。
4. 你怎么比较MongoDB、CouchDB及CouchBase?
MongoDB和CouchDB都是面向文档的数据库。MongoDB和CouchDB都是开源NoSQL数据库的最典型代表。 除了都以文档形式存储外它们没有其
他的共同点。MongoDB和CouchDB在数据模型实现、接口、对象存储以及复制方法等方面有很多不同。
5. MongoDB成为最好NoSQL数据库的原因是什么?
以下特点使得MongoDB成为最好的NoSQL数据库:
面向文件的 高性能 高可用性 易扩展性 丰富的查询语言
6.32位系统上有什么细微差别?
journaling会激活额外的内存映射文件。这将进一步抑制32位版本上的数据库大小。因此,现在journaling在32位系统上默认是禁用的。
7. journal回放在条目(entry)不完整时(比如恰巧有一个中途故障了)会遇到问题吗?
每个journal (group)的写操作都是一致的,除非它是完整的否则在恢复过程中它不会回放。
8. 分析器在MongoDB中的作用是什么?
MongoDB中包括了一个可以显示数据库中每个操作性能特点的数据库分析器。通过这个分析器你可以找到比预期慢的查询(或写操作);利用这一信息,比如,可以确定是否需要添加索引。
9. 名字空间(namespace)是什么?
MongoDB存储BSON对象在丛集(collection)中。数据库名字和丛集名字以句点连结起来叫做名字空间(namespace)。
10. 如果用户移除对象的属性,该属性是否从存储层中删除?
是的,用户移除属性然后对象会重新保存(re-save())。
11. 能否使用日志特征进行安全备份? 是的。
12. 允许空值null吗?
对于对象成员而言,是的。然而用户不能够添加空值(null)到数据库丛集(collection)因为空值不是对象。然而用户能够添加空对象{}。
13. 更新操作立刻fsync到磁盘?
不会,磁盘写操作默认是延迟执行的。写操作可能在两三秒(默认在60秒内)后到达磁盘。例如,如果一秒内数据库收到一千个对一个对象递增的操作,仅刷新磁盘一次。(注意,尽管fsync选项在命令行和经过getLastError_old是有效的)(译者:也许是坑人的面试题??)。
14. 如何执行事务/加锁?
MongoDB没有使用传统的锁或者复杂的带回滚的事务,因为它设计的宗旨是轻量,快速以及可预计的高性能。可以把它类比成MySQL MylSAM的自动提交模式。通过精简对事务的支持,性能得到了提升,特别是在一个可能会穿过多个服务器的系统里。
15. 为什么我的数据文件如此庞大?
MongoDB会积极的预分配预留空间来防止文件系统碎片。
16. 启用备份故障恢复需要多久?
从备份数据库声明主数据库宕机到选出一个备份数据库作为新的主数据库将花费10到30秒时间。这期间在主数据库上的操作将会失败--包括写入和强一致性读取(strong consistent read)操作。然而,你还能在第二数据库上执行最终一致性查询(eventually consistent query)(在slaveOk模式下),即使在这段时间里。
17. 什么是master或primary?
它是当前备份集群(replica set)中负责处理所有写入操作的主要节点/成员。在一个备份集群中,当失效备援(failover)事件发生时,一个另外的成员会变成primary。
18. 什么是secondary或slave?
Seconday从当前的primary上复制相应的操作。它是通过跟踪复制oplog(local.oplog.rs)做到的。
19. 我必须调用getLastError来确保写操作生效了么?
不用。不管你有没有调用getLastError(又叫"Safe Mode")服务器做的操作都一样。调用getLastError只是为了确认写操作成功提交了。当然,你经常想得到确认,但是写操作的安全性和是否生效不是由这个决定的。
20. 我应该启动一个集群分片(sharded)还是一个非集群分片的 MongoDB 环境?
为开发便捷起见,我们建议以非集群分片(unsharded)方式开始一个 MongoDB 环境,除非一台服务器不足以存放你的初始数据集。从非集群分片升级到集群分片(sharding)是无缝的,所以在你的数据集还不是很大的时候没必要考虑集群分片(sharding)。
21. 分片(sharding)和复制(replication)是怎样工作的?
每一个分片(shard)是一个分区数据的逻辑集合。分片可能由单一服务器或者集群组成,我们推荐为每一个分片(shard)使用集群。
22. 数据在什么时候才会扩展到多个分片(shard)里?
MongoDB 分片是基于区域(range)的。所以一个集合(collection)中的所有的对象都被存放到一个块(chunk)中。只有当存在多余一个块的时候,才会有多个分片获取数据的选项。现在,每个默认块的大小是 64Mb,所以你需要至少 64 Mb 空间才可以实施一个迁移。
23. 当我试图更新一个正在被迁移的块(chunk)上的文档时会发生什么? 更新操作会立即发生在旧的分片(shard)上,然后更改才会在所有权转移(ownership transfers)前复制到新的分片上。
24. 如果在一个分片(shard)停止或者很慢的时候,我发起一个查询会怎样?
如果一个分片(shard)停止了,除非查询设置了“Partial”选项,否则查询会返回一个错误。如果一个分片(shard)响应很慢,MongoDB则会等待它的响应。
25. 我可以把moveChunk目录里的旧文件删除吗?
没问题,这些文件是在分片(shard)进行均衡操作(balancing)的时候产生的临时文件。一旦这些操作已经完成,相关的临时文件也应该被删除掉。但目前清理工作是需要手动的,所以请小心地考虑再释放这些文件的空间。
26. 我怎么查看 Mongo 正在使用的链接?
db._adminCommand("connPoolStats");
27. 如果块移动操作(moveChunk)失败了,我需要手动清除部分转移的文档吗?
不需要,移动操作是一致(consistent)并且是确定性的(deterministic);一次失败后,移动操作会不断重试;当完成后,数据只会出现在新的分片里(shard)。
28. 如果我在使用复制技术(replication),可以一部分使用日志(journaling)而其他部分则不使用吗? 可以