NOSQL(三)分布式数据模型

《NoSQL精粹》读书笔记,转载请注明出处《jiq?钦‘s technical Blog》

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

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

1 单一服务器

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

2 分片

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

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

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

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

3 复制

3.1 主从复制

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

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

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

3.2 对等复制

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

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

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

4 分片和复制相结合

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

时间: 2024-08-06 19:50:41

NOSQL(三)分布式数据模型的相关文章

NOSQL(二)聚合数据模型

<NoSQL精粹>读书笔记,转载请注明出处<jiq?钦's technical Blog> 一.NoSQL的数据模型 关系型数据库的数据模型是"关系"和"元组",一个关系对应一张表,而一个元组对应一行,其中元组由一系列的值组成,不能嵌套. NoSQL数据库最大的转变就是抛弃了关系模型.但是每种NoSQL解决方案模型都不同,大体上可以将NoSQL数据模型分为四类:"键值"."文档"."列族&qu

复习三——关系数据模型

数据模型 描述现实世界实体,实体间联系以及数据语义和一致性约束的模型.这个定义看起来没什么实际用途,但是理解了对使用power designer设计数据库有好处.嘛...反正我没理解透. 按照模型应用的不同目的,可以分为 概念数据模型(概念模型):按用户的观点对数据进行建模,强调语义表达功能.主要用于数据库的概念设计. 结构数据模型(数据模型):按计算机系统的观点对数据进行建模,直接面向数据库的逻辑结构. 现实世界-->信息世界 概念模型(如E-R模型,即实体-联系模型)-->机器世界 数据模

日志系统实战(三)-分布式跟踪的Net实现

介绍 在大型系统开发调试中,跨系统之间联调开始变得不好使了.莫名其妙一个错误爆出来了,日志虽然有记录,但到底是哪里出问题了呢? 是ios端参数传的不对?还是A系统或B系统提供的接口导致?相信大家碰到不少,大多数问题不大,但排查起来比较费劲. 下面,我们来具体看下实现. 目录 1:概述 2:web环境 3:多线程环境 4:异步环境 5:性能,大数据量,隐私安全 6:总结 一:概述 一句话总结:通过一个TraceId把整个请求,形成一个调用链. 这样无论任何地方报错,只要拿TraceId去系统查下,

(三)分布式数据库tidb-隔离级别详解

tidb隔离级别详解: 1.TiDB 支持的隔离级别是 Snapshot Isolation(SI),它和 Repeatable Read(RR) 隔离级别基本等价,详细情况如下: ● TiDB 的 SI 隔离级别可以克服幻读异常(Phantom Reads),但 ANSI/ISO SQL 标准中的 RR 不能. 所谓幻读是指:事务 A 首先根据条件查询得到 n 条记录,然后事务 B 改变了这 n 条记录之的 m 条记录或者增添了 m 条符合事务 A 查询条件的记录,导致事务 A 再次发起请求时

云计算背后的秘密:NoSQL诞生的原因和优缺点

转载收藏一篇对nosql讲解的比较全面的文章:http://blog.csdn.net/xlgen157387/article/details/47908797 这篇文章将和大家聊聊为什么NoSQL会在关系型数据库已经非常普及的情况下异军突起? 诞生的原因 随着互联网的不断发展,各种类型的应用层出不穷,所以导致在这个云计算的时代,对技术提出了更多的需求,主要体现在下面这四个方面: 1. 低延迟的读写速度:应用快速地反应能极大地提升用户的满意度; 2. 支撑海量的数据和流量:对于搜索这样大型应用而

Survey on Nosql database笔记

新型应用对数据库的新要求 -高并发性的读写请求下的低延时 -有效的大数据存储和存取需求(pb级别) -高扩展性和高可用性 -更小的管理和操作花费 传统关系型数据库的限制 -由于关系型数据库的逻辑复杂性,使得随着数据大小增大,有很多的死锁或者并发问题出现,使得读写速度下降 -容量限制,传统数据库无法处理大数据 -多表关联的机制使得数据库扩展十分困难 nosql数据库的特征 -读写迅速 -支持大容量存储 -易于扩展 -低花费 不支持工业标准的sql 缺少事务机制 nosql数据库的数据模型 -key

《NoSQL精粹》读书摘要

一.Why NoSQL? 关注NoSQL的两个原因 应用程序的开发效率(NoSQL简化了数据交互) 大规模的数据(NoSQL为集群环境而设计) NoSQL不是独立存在的,以后也不会取代关系型数据库,以后数据库领域将步入混合持久化(Polyglot Persistence)时代. 关系型数据库的优点: 标准化的建模 较为容易的处理关系 通过事务来处理并发 可以持久化 关系型数据库的缺点: 阻抗失谐:关系型数据库中的存储结构(模式.表.元组)与应用程序中的数据结构需要转换.ORM框架可以解决这个问题

NoSQL简介(NoSQL Distilled读书笔记)

随着NoSQL的流行,了解这种新型数据库十分有必要. 首先,为什么我们要选择NoSQL? 主要是两个原因:一是待处理的数据量很大,或对数据访问的效率要求很高,从而必须将数据放在集群上:二是想采用一种更为方便的数据交互方式来提高应用程序开发效率 而传统关系数据库最大的问题,应该就是阻抗失谐 第二,NoSQL数据库的共同特性是什么? 不使用关系模型:在集群中运行良好:开源:适用于21世纪的互联网公司:无模式 第三,NoSQL数据模型: 模型主要可以分为四类:‘键值’ ‘文档’ ‘列族’ ‘图’ 前三

NoSQL 与大数据

概览一下大数据项目中可以使用的数据存储技术,聚焦于Couchbase 和 ElasticSearch,展示如何使用以及它们的区别,先理解一下NoSQL领域中各种不同的技术. NoSQL 关系型数据库是过去的选择,几乎是许多开发者和DBA对于传统三层架构应用的唯一选择.使用这一场景有很多原因,数据建模方法,查询语言与数据交互,保证数据的一致性部署,并能够为复杂的应用服务. 然而,这不是解决所有数据存储问题的唯一方案,也是NoSQL 产生的原因.NoSQL 提供了新的方法而不是采用面向标准SQL的范