NoSQL数据库的分布式模型
NoSQL数据库的分布式模型
单一服务器
在一个服务器完全能够胜任工作时就没必要考虑分布式,这样部署简单,维护也方便很多;
分片
特点
数据的各个部分存放在集群的不同服务器中;
比如按字母来划分:以a-g开头的键值都存放到第一台服务器上,以h-n开头的存放到第二台...
需要考虑的问题
如何存放数据,让用户基本上只需从一台服务器上获取数据
如果经常需要与多个结点交互才能取到需要数据,可能分片策略不合适,或者该场景中分片不是一个理想的方案;数据节点的分布:地理位置与访问用户的关系
数据结点分布在全球各地,让北京的用户只需要访问北京的结点就能取到所需数据;保持负载均衡
优点
同时提升读取和写入性能
由于分片是将数据分散到多个结点存储,这样在写入时,压力同样分散;横向扩展写入能力
缺点
降低数据库的错误恢复能力
分片后,集群中结点的故障将导致部分数据丢失;
解决方案:每个分片数据不只存放在一个结点上,冗余存放,增加数据安全性(通过后面讲到的与主从复制的结合使用,是常用的手段)
主从复制
特点
主节点存放权威数据,负责数据更新操作;
主节点将更新的数据复制到从节点;
优点
有助于提升数据读取性能
从结点只负责查询,增加从结点提升数据读取性能增强“读取操作的故障恢复能力”
主节点损坏,依然可处理读取请求;
从结点升级为主结点后可以处理更新请求;“一拖一” 即时备份的单存储方案
即使不需要分布式部署,主从复制也可以用来做为单机服务器备份的部署方案;
缺点
数据的不一致性(未及时更新)
主节点更新后,同步到各个从结点的数据不能保证及时,可能导致各个结点上查询的数据不一致(只具有最终一致性)对提升写入操作性能帮助不大
所有的更新操作都通过主结点处理,对于更新频繁的业务,使用主从复制模型优势不大;主节点是系统的瓶颈和弱点
对等复制
特点
所有节点地位相同,都可接收查询和写入请求;
各节点将自己的更新的数据复制到其他节点;
优点
- 从容处理出错节点,不必担心数据请求的丢失
- 增加节点,轻易提升查询和写入性能
缺点
- 数据不一致性
写入和读取都有可能发生冲突;
结合使用
分片和主从复制中的一拖一方案结合使用;
分片的作用在于数据的分布式存储;主从复制的作用在于为各个分片结点提供备份,增加数据安全;
注:新浪Redis集群的部署使用的是这种方案,关于新浪redis的使用详见大CC之前的博客:
Redis 在新浪微博中的应用
附思维导图
参考
Posted by: 大CC | 30JUN,2014
博客:blog.me115.com [订阅]
微博:新浪微博
最新文章
- CSS3 media 入门
- EasyUI TreeGrid DataTable转换数据实现案例
- 更改Android Studio的主题背景
- Scalaz(44)- concurrency :scalaz Future,尚不完整的多线程类型
- ManualResetEvent详解
- webmatrix
- 小黑的镇魂曲(HDU2155:贪心+dfs+奇葩解法)
- C语言指针的初始化和赋值
- Redis协议详解
- 【CSS学习笔记】字体的控制
- 我是这样发现ISP劫持HTTP请求的
- .net面式题
- Pytorch自定义dataloader以及在迭代过程中返回image的name
- php输出异常的检查方法
- Tomcat 配置学习
- Codeforces Round #288 (Div. 2) E. Arthur and Brackets 贪心
- java IO操作:FileInputStream,FileOutputStream,FileReader,FileWriter实例
- Session分布式共享 = Session + Redis + Nginx(转)
- (二)Audio子系统之new AudioRecord()(Android4.4)
- 为什么jdbc中的resultset只能取一次去第二次就报错了