21 Nov 2016

NOSQL基础

#NOSQL基础

今天开始，我会将我NOSQL数据库学习的学习笔记和学习感悟写成一篇篇的文章。我会尽量的把它做的详细。来吧，一起奔向非关系型数据存储的海洋！

基础概念

NoSql，全称是 Not Only Sql,指的是非关系型的数据库。下一代数据库主要解决几个要点：非关系型的、分布式的、开源的、水平可扩展的.

现在开发的特点：3V和3高

  • 3V:海量Volume;多样Variety;实时Velocity
  • 3高:高并发;高可扩;高性能

NOSQL的数据模型

聚合模型

  1. KV键值（redis主要存储方式）
  2. bson：类型与json储存（mongodb的储存方式）
  3. 列族：顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。
  4. 图形

NOSQL的分类

  1. KV键值：redis
  2. 文档型数据库(bson格式比较多)：典型介绍：MongoDB

    MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。 MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。（期待一起学习）

  3. 列存储数据库:HBase;分布式文件系统
  4. 图关系数据库

CAP原理：

传统的ACID

ACID，是指在关系型传统数据库管理系统（DBMS）中事务所具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。

  1. A (Atomicity) 原子性：整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
  2. C (Consistency) 一致性：在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
  3. I (Isolation) 独立性：两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时，中间某一时刻的数据。
  4. D (Durability) 持久性：在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

CAP原则

在非关系型数据库中，并不存在事务的acid，甚至，有些数据库是对事务弱支持的（像redis），但分布式数据库中(包括传统)中有CAP原则。CAP原则又称CAP定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼

  1. C:Consistency（强一致性）：分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

  2. A:Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（简单理解就是那些数据保持可以比用户使用。

  3. P:Partition tolerance（分区容错性）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

    CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求， 最多只能同时较好的满足两个。

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

  • CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
  • CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
  • AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

当然，在有些博文中，他们多于分布式数据库中有自己的观点，这些观点也不无道理，如NOSQL都是实现A，而少满足C

CAP的3进2

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。

C:强一致性 A：高可用性 P：分布式容忍性

  1. CA 传统Oracle数据库
  2. AP 大多数网站架构的选择
  3. CP Redis、Mongodb

一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。因此牺牲C换取P，这是目前分布式数据库产品的方向

一致性与可用性的决择

对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

  • 数据库事务一致性需求 　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。

  • 数据库的写实时性和读实时性需求 　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

  • 对复杂的SQL查询，特别是多表关联查询的需求  　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

base

  • 定义：BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

BASE其实是下面三个术语的缩写：

  1. 基本可用（Basically Available）
  2. 软状态（Soft state）
  3. 最终一致（Eventually consistent）

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法

分布式系统，集群

  1. 分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。
  2. 集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。

Tags:
Stats:
comments


Share: