Redis -- NoSQL 概述

怼烎@ 2022-05-31 10:15 211阅读 0赞

# 什么是 NoSQL #

NoSQL( NoSQL = Not Only SQL )，意即“不仅仅是SQL”，泛指非关系型的数据库。随着互联网 web 2.0 网站的兴起，传统的关系数据库在应付 web 2.0 网站，特别是超大规模和高并发的 SNS 类型的 web 2.0 纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL 数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。

# NoSQL 特点 #

*  易扩展  
    NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。
 *  大数据量高性能  
    NoSQL 数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般 MySQL 使用 Query Cache，每次表的更新 Cache 就失效，是一种大粒度的 Cache，  
    在针对 web 2.0 的交互频繁的应用，Cache 性能不高。而 NoSQL 的 Cache 是记录级的，是一种细粒度的 Cache，所以 NoSQL 在这个层面上来说就要性能高很多了
 *  多样灵活的数据模型  
    NoSQL 无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。
 *  RDBMS vs NoSQL

**RDBMS**

*  高度组织化结构化数据
 *  结构化查询语言（SQL）
 *  数据和关系都存储在单独的表中。
 *  数据操纵语言，数据定义语言
 *  严格的一致性
 *  基础事务

**NoSQL**

*  代表着不仅仅是 SQL
 *  没有声明性查询语言
 *  没有预定义的模式
 *  键 - 值对存储，列存储，文档存储，图形数据库
 *  最终一致性，而非 ACID 属性
 *  非结构化和不可预知的数据
 *  CAP 定理
 *  高性能，高可用性和可伸缩性

# 主流 NoSQL 产品 #

NoSQL 数据库的四大分类如下：

*  键值（Key-Value）存储数据库  
    相关产品：Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB  
    典型应用：内容缓存，主要用于处理大量数据的高访问负载  
    数据模型：一系列键值对  
    优势：快速查询  
    劣势：存储的数据缺少结构化
 *  列存储数据库  
    相关产品：Cassandra、HBase、Riak  
    典型应用：分布式的文件系统  
    数据模型：以列簇式存储，将同一列数据存在一起  
    优势：查找速度快，可扩展性强，更容易进行分布式扩展  
    劣势：功能相对局限
 *  文档型数据库  
    相关产品：CouchDB、MongoDB  
    典型应用：Web应用（与Key-Value类似，Value是结构化的）  
    数据模型：一系列键值对  
    优势：数据结构要求不严格  
    劣势：查询性能不高，而且缺乏统一的查询语法
 *  图形（Graph）数据库  
    相关数据库：Neo4J、InfoGrid、Infinite Graph  
    典型应用：社交网络  
    数据模型：图结构  
    优势：利用图结构相关算法  
    劣势：需要对整个图做计算才能得出结果，不容易做分布式的集群方案

# CAP #

*  Consistency（强一致性）
 *  Availability（可用性）
 *  Partition tolerance（分区容错性）

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

而由于当前的网络硬件肯定会出现延迟丢包等问题，所以**分区容忍性**是我们必须需要实现的。

所以我们只能在一致性和可用性之间进行权衡，没有 NoSQL 系统能同时保证这三点。

*  CA 传统Oracle数据库
 *  AP 大多数网站架构的选择
 *  CP Redis、MongoDB

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

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

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

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

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

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

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

# BASE #

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

BASE其实是下面三个术语的缩写：  
基本可用（Basically Available）  
软状态（Soft state）  
最终一致（Eventually consistent）

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