Redis-01-NOSQL的简介

r囧r小猫 2023-10-05 10:02 2阅读 0赞

**目录**

1：NOSQL简介

1.1：NOsql是什么

1.2：特点

2：NOSQL的特点

3：当下NOSQL的经典应用

4：NOSQL的数据模型

1：什么是BSON

2：BSON构建的数据模型

3：聚合模型的数据类型

1：KV键值

2：bson

3：列族

4：图形

5：四者对比

5：在分布式数据库中CAP原理CAP+BASE

1：传统的ACID分别是什么

2： CAP

3： CAP的3进2（只能满足两个）

4：经典CAP图

5： BASE

6：分布式和集群

6:推荐市面上所有数据库对比信息网站

--------------------

# 1：NOSQL简介 #

## 1.1：NOsql是什么 ##

> NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，  
> **泛指非关系型的数据库**。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。
> 
>   
> （例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。**这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。**

## 1.2：特点 ##

1：易扩展

> NoSQL数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。  
> 这得益于它的无关系性，数据库的结构简单。  
> 一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，  
> 在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的Cache是记录级的，  
> 是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了

2：多样灵活的数据模型

> NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，  
> 增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦

3：和传统关系型数据库的对比

> RDBMS vs NoSQL
> 
>   
> RDBMS  
> \- 高度组织化结构化数据  
> \- 结构化查询语言（SQL）  
> \- 数据和关系都存储在单独的表中。  
> \- 数据操纵语言，数据定义语言  
> \- 严格的一致性  
> \- 基础事务
> 
>   
> NoSQL  
> \- 代表着不仅仅是SQL  
> \- 没有声明性查询语言  
> \- 没有预定义的模式  
> \-键 - 值对存储，列存储，文档存储，图形数据库  
> \- 最终一致性，而非ACID属性  
> \- 非结构化和不可预知的数据  
> \- CAP定理  
> \- 高性能，高可用性和可伸缩性

# 2：NOSQL的特点 #

1：海量Volume

2：多样Variety

3：实时Velocity

4：高并发  
5：高可扩  
6：高性能

# 3：当下NOSQL的经典应用 #

阿里巴巴中文的商品信息如何存放

1：商品基本信息：名称，价格，出厂日期等存放在关系型数据库

2：商品描述，评价等多文字信息放在文档型数据库比如MongDB中

3：商品的图片放在分布式文件系统中TFS中；

4：商品的关键字ISearch搜索引擎；

5：商品的波段性的热点高频信息存在内存数据库如：tair、Redis、Memcache

6：商品的交易、价格计算、积分累计使用外部系统，外部第3方支付接口如：支付宝

# 4：NOSQL的数据模型 #

## 1：什么是BSON ##

BSON（）是一种类json的一种二进制形式的存储格式，简称Binary JSON，它和JSON一样，支持内嵌的文档对象和数组对象

## 2：BSON构建的数据模型 ##

> \{  
> "customer":\{  
> "id":1136,  
> "name":"Z3",  
> "billingAddress":\[\{"city":"beijing"\}\],  
> "orders":\[  
> \{  
> "id":17,  
> "customerId":1136,  
> "orderItems":\[\{"productId":27,"price":77.5,"productName":"thinking in java"\}\],  
> "shippingAddress":\[\{"city":"beijing"\}\]  
> "orderPayment":\[\{"ccinfo":"111-222-333","txnid":"asdfadcd334","billingAddress":\{"city":"beijing"\}\}\],  
> \}  
> \]  
> \}  
> \}

## 3：聚合模型的数据类型 ##

### 1：KV键值 ###

新浪：BerkeleyDB+redis  
美团：redis+tair  
阿里、百度：memcache+redis

### 2：bson ###

CouchDB  
MongoDB

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2_size_16_color_FFFFFF_t_70][]

### 3：列族 ###

Cassandra, HBase  
分布式文件系统

### 4：图形 ###

它不是放图形的，放的是关系比如:朋友圈社交网络、广告推荐系统  
社交网络，推荐系统等。专注于构建关系图谱  
Neo4J, InfoGrid

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2_size_16_color_FFFFFF_t_70 1][]

### 5：四者对比 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2_size_16_color_FFFFFF_t_70 2][]

# 5：在分布式数据库中CAP原理CAP+BASE #

##    1：传统的ACID分别是什么 ##

> A (Atomicity) 原子性  
> C (Consistency) 一致性  
> I (Isolation) 独立性  
> D (Durability) 持久性

## 2： CAP ##

> C:Consistency（强一致性）：在[分布式系统][Link 1]中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）。主从一致性会削弱可用性。
> 
> ![681a7020deb8433b88ba52f46738cd63.png][]  
> A:Availability（可用性）：在集群中一部分节点故障后，[集群][Link 2]整体是否还能响应[客户端][Link 3]的读写请求。（对数据更新具备高可用性）
> 
> ![b1091d7150304d469638992682175ee6.png][]  
> P:Partition tolerance（分区容错性）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。说白了同一时间从集群中拿到两种结果；
> 
> ![57f048c84e37441781c8597954d5d39f.png][]

## 3： CAP的3进2（只能满足两个） ##

> CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。  
> 因为只要有网络交互就一定会有延迟和数据丢失，这种状况我们必须接受，必须保证系统不能挂掉。所以分区容忍性是我们必须需要实现的。
> 
>   
> 所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。  
> ======================================  
> C:强一致性 A：高可用性 P：分布式容忍性
> 
>   
> CA 传统Oracle数据库
> 
>   
> AP 大多数网站架构的选择，先保证网站可用；实时性不高的可以有延迟
> 
>   
> CP Redis、Mongodb
> 
>   
> 注意：分布式架构的时候必须做出取舍。  
> 一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。  
> 因此牺牲C换取P，这是目前分布式数据库产品的方向  
> =========================================  
> 一致性与可用性的决择
> 
>   
> 对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地
> 
>   
> 数据库事务一致性需求  
> 　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。
> 
>   
> 数据库的写实时性和读实时性需求  
> 　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
> 
>   
> 对复杂的SQL查询，特别是多表关联查询的需求  
> 　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

## 4：经典CAP图 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2_size_16_color_FFFFFF_t_70 3][]

> CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，  
> 最多只能同时较好的满足两个。  
> 因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：  
> CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。  
> CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。  
> AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

## 5： BASE ##

> BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
> 
>   
> BASE其实是下面三个术语的缩写：  
> 基本可用（Basically Available）  
> 软状态（Soft state）  
> 最终一致（Eventually consistent）
> 
>   
> 它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法

## 6：分布式和集群 ##

> 分布式系统
> 
>   
> 分布式系统（distributed system）  
> 由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。分布式系统可以应用在在不同的平台上如：Pc、工作站、局域网和广域网上等。
> 
>   
> 简单来讲：  
> 1分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。
> 
>   
> 2集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。
> 
> ![7ba918bcd2404d1f943c19e36245611d.png][]

# 6:推荐市面上所有数据库对比信息网站 #

> [https://db-engines.com/en/][https_db-engines.com_en]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/202009211007056.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200921095056889.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200921101451155.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2,size_16,color_FFFFFF,t_70
[Link 1]: https://baike.baidu.com/item/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/4905336
[681a7020deb8433b88ba52f46738cd63.png]: https://img-blog.csdnimg.cn/681a7020deb8433b88ba52f46738cd63.png
[Link 2]: https://baike.baidu.com/item/%E9%9B%86%E7%BE%A4/5486962
[Link 3]: https://baike.baidu.com/item/%E5%AE%A2%E6%88%B7%E7%AB%AF/101081
[b1091d7150304d469638992682175ee6.png]: https://img-blog.csdnimg.cn/b1091d7150304d469638992682175ee6.png
[57f048c84e37441781c8597954d5d39f.png]: https://img-blog.csdnimg.cn/57f048c84e37441781c8597954d5d39f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200921135049460.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjk0OTA2,size_16,color_FFFFFF,t_70
[7ba918bcd2404d1f943c19e36245611d.png]: https://img-blog.csdnimg.cn/7ba918bcd2404d1f943c19e36245611d.png
[https_db-engines.com_en]: https://db-engines.com/en/