NoSql介绍与分布式Mongo

前端之家收集整理的这篇文章主要介绍了NoSql介绍与分布式Mongo前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

什么是Nosql

它是“ Not Only sql”的简称,非关系型数据库,它具有非常好的通用性和非常高的性能,它在处理大量的数据方面很有优势,
现今的计算机体系结构在数据存储方面要求具备庞大的水平扩 展性,而Nosql致力于改变这一现状

常见的Nosql

1、键值(key/value)储存:memcached、redis

2、面向文档的数据库:MongoDB、CouchDB

3、面向列的数据库:HBASE、Cassandra

与关系型数据库比较:

sql不擅长处理

1、大量数据写入

2、为有数据更新的表做索引

3、表结构的变更

4、简单查询快速返回结果

5、字段不固定时

Nosql的数据一致型

首先关系型数据库的四个特性ACID:

原子性:事务是不可分割的整体,一个事务中对数据库的操作要么都做,要么都不做

一致性:事务操作后数据库从一个状态到另一个状态,前后状态均为一致性状态,账户A与账户B的总和是不变的

隔离性:在并发环境中,当不同的事务同事操作数据库时,其他事务是看不见当前事务所做的修改,保证在提交之前对于其他事务不可见

持久性:一旦事务提交完成,对数据库所做的修改是持久的

Nosql系统是分布式系统

分布式系统是建立在网上之上的软件系统,具有高度的透明性,在分布式数据库系统中,用户是感觉不到数据是分布的,就好像操作的是一个统一的整体,即用户不须知道关系是否分割、有无副本、数据库存于哪台机器及操作在哪台机器上执行,并不知道其内部工作需要由很多台机器协同完成。

分布式中CAP理论

C: Consistency 强一致性,即对系统数据更新之后,用户取到的数据永远是最新的,注意在分布式中,由于数据存放在是多台机器,所以当一台机器的数据变化后,必须保证其他机器的变化

A: Availability 可用性,每一个操作总能在一定时间内返回结果,注意如果超时则认为是不可用的,

P: Partition Tolerance 分区容错性,整个系统对于某个节点动态的加入或离开(down机)都有足够的处理能力

CAP是在分布式环境中设计和部署系统时所要考虑的三个重要的系统需要,但是根据CAP理论,数据共享系统只能满足其中的两个特征

这是为什么?

理解CAP理论的最简单方式是想象两个节点分别在分区的两侧。允许至少一个节点更新状态会导致数据不一致,即丧失了C性质。如果为了保证数据一致性,将分区一侧的节点设置为不可用,那么又丧失了A性质。除非两个节点可以互相通信,才能既保证C又保证A,这又会导致丧失P性质。一般来说跨区域的系统,设计师无法舍弃P性质,那么就只能在数据一致性和可用性上做一个艰难选择。不确切地说,Nosql运动的主题其实是创造各种可用性优先、数据一致性其次的方案;

传统的关系型数据库注重数据的一致性,而Nosql对海量数据的分布式存储于处理,可用性与分区容忍性优先级要高于数据一致性

所以Nosql系统的主流还是主要保证AP,但是数据一致性又不能置之不顾,所以出现很多一致性方法

强一致性:用于分布式事务协议

弱一致性:能容忍更新后部分用户获取不到最新的数据

最终一致性:是弱一致性的一种特例,它可以保证用户最终获取的数据是最新的数据

Nosql的分布式、水平扩展

水平扩展方式:复制(主从复制、副本集)和分片

主从复制:将数据复制到多个节点,一个节点被指定为主,其他的都是从,主数据库负责处理数据的更新,并启动单独的进程将数据同步到从

当读的需求远大于写的需求时,比如电商商品的数据库,主从复制是非常有效的,当写请求不断增长且服务器达到瓶颈时可以通过水平增加数据库来处理更多的写请求

但是当主主机出现故障时,整个系统就不能响应写请求,而且没有传递到从的数据将会丢失。

副本集:主从复制能对读请求水平扩展,但是对写请求无能为力,从本质上讲主服务器仍然是一个单点瓶颈和单点故障,而对于副本集master / slave,当主服务器出现故障时会从slave选举出一个master,这样就解决了主从中的单点故障,当然我们可以对master对集群,这样可解决了单点瓶颈

分片:当数据量巨大时,或者访问量很多时,在这种情况下,我们可以将数据的不同部分分配到不同的服务器上来提高水平扩展性,这种技术就是分片,当请求来时,定位到对应得服务器上进行数据的读取,当然复制和分片可以同时使用


分片对数据的划分方式

分片Sharding就是将大数据库分布到多个物理节点上,每个shard都被放置在一个节点上面,首先请求到达查询路由器,路由器将解析用户查询语句,并将请求转发到相应的一个或多个节点shard上执行,执行结果通过路由器汇总并返回给相应的客户端

假设只考虑单个表,并且这个表的划分键(Partitioning Key)已经被指定

1、区间划分

将一个大数据表按区间进行切割,在MongoDB中每个节点持有多个区间,这样当节点间数据不均时,就需要迁移,首先将区间分裂,满足迁移条件时,按分裂后的区间进行迁移

2、轮流放置

按节点依次循环放置,但是当需要迁移时使用轮流放置则会对系统性能造成很大的影响

3、一致性hash算法

当有N个cache服务器,我们将很多Object映射到这N个cache上,方法hash(object)%N

假设当需要增加一台cache服务器时,映射公式变成hash(object)%(N+1)

那么问题来了,当去cache时,通过hash(object)%(N+1),之间的object找不到对应得服务器,这就意味着几乎所有的cache都将失效,很明显这时不可取的,如果说使cache变成2*cache,也就是增加一倍,通常情况下这时对机器的极大浪费同样是不可取的

Consistent Hashing算法原理

简单的说在移除或增加一个cache服务器时,它能够几下的改变之前已存在的key映射关系,

它所使用的是环形hash空间

首先计算出一个hash 值 0 ~2^32-1,我们把这个空间想象成一个圆环,我们给cache服务器赋予一个0~32-1值并且均匀分布在这之间,当object需要放入时,在环上顺时针去寻找最近的cache,找到后则放入该cache

当有cache服务器增加或移除时,假设增加,我们只对新增的cache赋予一个合适的值,造成的结果是只有很少一部分object失去映射关系,这个影响相对于其他是可以接受的。移除cache时同造成一部门的影响

原文链接:/nosql/203551.html

猜你在找的NoSQL相关文章