NOSQL(三)分布式数据模型

前端之家收集整理的这篇文章主要介绍了NOSQL(三)分布式数据模型前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

《Nosql精粹》读书笔记,转载请注明出处《jiq•钦's technical Blog》

催生Nosql的主要原因是:需要一种能够运行在大集群上的数据库

面向聚合的数据库非常适合于横向拓展的集群架构,聚合自然成为了数据分布单元,而数据分布主要有两条路:“复制(replication)”和“分片(sharding)”,复制是将同一份数据拷贝至多个节点,分片是将数据分散存放到不同节点上。

1 单一服务器

若使用Nosql数据库的目的基本上是为了处理聚合,那么就可以考虑在单一的服务器上部署Nosql数据库。换句话说在不需要分布数据就能应对的场景下,优先选择“单一服务器”的方案。

2 分片

如果数据库的繁忙体现在:不同用户需要访问数据集中的不同部分。那么优先选择分片,将数据的各个部分存放于不同的服务器中,以此实现横向拓展。

思路:为了将不同用户的请求均衡地分布到不同的服务器上,采取怎样的策略存放数据是关键。之所以设计“聚合”,就是为了把经常要同时访问的数据放在一起,因此聚合可以作为数据分布式的单元。如何把聚合数据均匀地分布在不同的机器上,有时可能需要采取“领域特定的规则”,很多Nosql数据库已经提供了“自动分片(auto-sharding)”的功能,由数据库负责将数据分布到各分片,并将数据访问请求引导至适合的分片上。

优点:分片对于提升性能尤其有用,因为可以同时提升读取和写入效率,复制技术,尤其是带缓存的复制技术,可以极大提升读取性能,但是对于需要频繁执行写入操作的场景却作用不大,而分片提供了可以横向拓展写入能力的方式。

缺点:分片对于提升数据库“故障恢复能力”帮助不大,跟“单一服务器”一样,甚至可能还会降低数据库错误恢复能力。

3 复制

3.1 主从复制

思路:主从结构中有一个主节点和多个从节点,从节点复制主节点的数据,保证所有从节点数据与主节点同步。读取时,可以从主节点或者任意从节点读取数据,即使主节点出错了,从节点依然可以处理数据读取请求,而且还能重新指派一个从节点作为新的主节点,通过新增从节点可以很容易进行水平拓展。这样不仅能够“大幅提升数据读取性能”,还能够“保证读取操作的故障恢复能力”。写入时就比较惨了,需要请求主节点进行更新操作,然后由主节点将数据更新请求发布到从节点,一方面性能不高,不适合频繁写入的场景,另一方面,若主节点出错,在恢复之前都无法处理数据更新请求。

优点:处理写入请求性能、具备故障恢复能力。即使不需要横向拓展,采用主从复制也有其用处,再主节点处理所有读写操作同时,从节点可以充当“即时备份”。

缺点:一方面因为主节点是系统的瓶颈和弱点,导致写入操作性能和故障恢复能力都不尽如人意。另一方面有一个很大的缺陷,即数据的不一致性,因为如果主节点处理的更新操作还没有完全通知到所有从节点时,不同的客户端从不同的从节点就可能读出各异的值。

3.2 对等复制

思路:为了解决主从复制中主节点成为系统瓶颈和弱点这一问题,抛弃主节点概念,所有节点都可以接受写入请求。

优点:解决了主从复制结构中,主节点作为写入操作时的瓶颈和弱点这一问题。

缺点:仍然是一致性,由于两个不同节点可以同时处理写入请求,当同一时间试图更新同一份数据时,就会出现“写入冲突”,同时读取一致性问题也会存在。两种极端解决一致性:一种是在真正写入前各个副本之间先协调好,确保不会发生冲突;另一种是把相互冲突的写入操作合并起来,这样任意副本都可以进行数据写入。

4 分片和复制相结合

思路:首先对数据进行分片,然后对于每一份数据都采用“主从复制”进行维护,这就意味着系统中存在多个主节点,对于每项数据来说,负责它的主节点只有一个。“列族数据库”就是这样一个例子。

原文链接:https://www.f2er.com/nosql/203935.html

猜你在找的NoSQL相关文章