关系型数据存在以下问题:
Mongodb是一个Nosql数据库,可以很好地解决上面的问题;
mongodb尽量将数据放在缓存中;
mongodb的journal日志,是一种WAL日志,类似mysql的redo log;
主从复制,在主节点上进行写操作,从节点可以分担主节点的读压力;但是当主节点宕机后,无法对外提供服务;
复制集主要对主从复制进行了优化,主节点宕机后能够选举出新的主节点,继续提供服务;
复制集中主要有三个角色:主节点(primary)、从节点(secondary)、仲裁者(Arbiter);主节点负责接收客户端的写请求等操作;从节点复制主节点的数据,也可以提供读服务;仲裁者则是辅助投票修复集群。
比较重要的两点:
类似于mysql中的binlog;主从节点通过发送oplog完成复制;oplog有时间戳,从节点通过以下操作完成数据同步:
如果一定时间没有收到某个节点的心跳,则认为该节点已宕机;如果宕机的节点是Primary,Secondary会发起新的Primary选举;
如果主节点失去多数节点的心跳时,必须降级为从节点;
从多个从节点中选举数据最新的从节点做为新的主节点;获得大多数选票的节点成为主节点;非仲裁节点可以配置优先级,范围为0~100,值越大越优先成为主节点;可以将性能好的机器的优先级设置的高一些;
主节点故障后,选出新的主节点;之后旧的主节点恢复工作,即使它的数据更新,仍然要以新的主节点的数据为准,旧的主节点要进行数据回滚;
mongodb原生支持了自动分片,支持水平扩展;支持范围分片、哈希分片和标签分片等策略;
根据key的范围进行分片;
优点:范围查询性能好,优化读;
缺点:数据分布可能会不均匀,容易有热点;
哈希分片最大的好处就是保证数据在各个节点上分布基本均匀;
优点:数据分布均匀,写优化;
缺点:范围查询效率低;
标签分片也是基于key的范围进行的,对每一个节点打上一个或多个tag,每个tag对应key的一个范围;
write concern表示事务是否关注写入的结果。
几个选项值:
设置示例:
writeConcern: {
w:“majority” // 大多数原则
j:true,
wtimeout: 5000,
}
使用示例:
db.user.insert({name: “congchp”}, {writeConcern: {w: “majority”}})
对于重要的数据可以应用w:“majority”,普通数据 w:1保证最佳性能;w设置的节点数越多,延迟就越大;
事务中使用readPreference来决定读取时从哪个节点读取;可方便的实现读写分离、就近读取策略;
可以设置为以下5个值:
readPreference决定从哪个节点读取,readConcern决定该节点的哪些数据是可读的;主要保证事务的隔离性,避免脏读;
主要的可选值:
local:默认值,数据写入本地;
majority:数据被写入大多数节点;
mongodb的readConcern默认使用local,readPreference是primary,就会有脏读的问题,例如,用户在主节点读取一条数据后,该节点未将数据同步至其它节点,就因为异常宕机或者网络故障,待主节点恢复后,需要将未同步至其它节点的数据进行回滚,就出现了脏读;
majority:数据被写入大多数节点;
mongodb的readConcern默认使用local,readPreference是primary,就会有脏读的问题,例如,用户在主节点读取一条数据后,该节点未将数据同步至其它节点,就因为异常宕机或者网络故障,待主节点恢复后,需要将未同步至其它节点的数据进行回滚,就出现了脏读;
readConcern设置为majority,保证读到的数据已经写入大多数节点,保证了事务的隔离性;