redis | 一NoSql演进史

Posted 2021-10-22 anyoneElse

redis系列文章:

https://liudongdong.top/categories/redis

本篇来源：

https://liudongdong.top/archives/redisyi-nosql-yan-jin-shi

公众号：雨中散步撒哈拉

备注：欢迎关注公众号，一起学习，共同进步！

一、数据库演进史

1. 单机 mysql 时代

在 web 初现峥嵘的那段时间 ，大部分网站都是使用的单机 MySQL 来存储用户数据，由于网站的用户与访问量不会太大，甚至大部分都使用额静态网页，与后端没有过多的交互，所以单机 MySQL 足矣

image.png

但是随着 web 的发展带来的用户群体激增，瓶颈也就随之而来了，在单机 MySQL 时代，造成瓶颈的原因主要有

1. 数据量太大，一个服务器硬盘存不下
2. 读写混合，一个服务器性能不足
3. 数据库索引太大，内存不足

2. 垂直拆分与缓存时代

后来，随着网站访问量的上升，使用单机 MySQL 的网站开始出现了性能问题，因此程序员们将目光从功能转移到了性能上

为了解决单机 MySQL 时代的不足，又对 MySQL 引入了 ​​Memcached ( 缓存 ) 和垂直拆分 (读写分离)​​ 等方案

一个运行中的网站其大部分时间都是在被用户进行查询操作，如果将读写拆分到不同的数据库中，就可以提高查询效率，所以数据库有了垂直拆分的方案，也就是数据库根据作用拆分为读服务器和写服务器，并利用主从复制保证数据正确，同时利用缓存加快速度

image.png

3. 水平拆分与集群时代

读写分离与分库分表也满足不了用户数据的存储了，这时就出现了对服务器的水平拆分，多个主从节点组成一个集群节点，而多个集群节点就组成了集群

image.png

4. 数据爆炸时代

image.png

在如今这个信息爆炸的时代，人们对于信息的实时性要求越来越高，互联网用户同样也越来越多，因此 MySQL 等关系型数据库就不够用了，因为数据量很大，数据变化也很快

通过对第三方平台的访问和数据抓取，可以很容易的获得用户个人信息，社交网络，用户生成的数据和用户的操作日志已经成倍的增加，对于这些结构并不确定的数据如果想要对这些数据进行深度的挖掘，那关系型数据库就已经不再实用了

二、什么是 NoSQL

NoSQL = Not Only SQL，即泛指非关系型数据库

由于 web2.0 时代的到来，互联网用户和数据量呈几何式上升，传统的非关系型数据库很难应付大型网站的超大数据量和高并发，这就暴露出来了很多关系型数据库难以克服的问题

因为关系型数据库从本质上来说就是一张表格，是有固定结构的，并且所有的数据都必须遵循相同的方式进行存储

而非关系型数据库是非结构化的，数据可以以多种方式存储，即可以面向文档存储，面向图像存储，甚至面向 K-V 存储等。Java 中的 Map 就是一种经典的 "NoSQL"，因为 Object 类型可以面向任何类型的对象

1. NoSQL 的特点

1. 方便扩展，数据之间没有关系
2. 大数据量存储，高性能 ( redis 1s 能写 8w 次，读取 11w 条)
3. 数据类型多样，不需要事先设计数据库

2. RDBMS 和 NoSQL 的区别

RDBMS

1. RDBMS 使用结构化组织
2. DDL，DQL，DML
3. 数据和关系都存在单独的表中，只能以行和列进行存储
4. ACID 原则，严格一致性
5. 事务
6. …

NoSQL

1. 没有固定的查询语言
2. 存储方式多样化：键值对存储 ( redis )，列存储 ( HBase )，文档存储 ( MongDB )，图形数据库
3. 最终一致性，只需保证数据的最终一致
4. CAP 定理和 Base 理论 ( 异地多活 )
5. 高性能，高可用，高可扩
6. …

在公司中，一定是 NoSQL + RDBMS 一起使用

3. 大数据时代的要求

大数据时代有 3V 和 3高的概念

3V 用来描述大数据时代下数据的问题：

1. 海量 ( volume )
2. 多样 ( variety )
3. 实时 (velocity)

3高指的是大数据时代，程序所需要达到的标准：

1. 高可用
2. 高并发
3. 高性能

三、阿里巴巴架构演进

image.png

阿里从 2010 年底，开始实施第五代网站架构改造，阿里巴巴对第五代架构有如下要求

1. 敏捷：需求的敏捷开发，应用系统的膨胀和耦合恶化使得架构越来越复杂，该如何保持业务的敏捷开发
2. 开放：如何提升网站开放性，吸引第三方开发者加入到网站的共建
3. 体验：并发压力快速增长，用户对体验的要求也越来越高

1. 数据层：数据架构的日益复杂

复杂的数据架构图

image.pngimage.png

为了提高访问速度，一个商品的不同信息就可能来自不同的数据库

1. 商品基本信息：名称，商家信息等，可以存储在关系型数据库中
2. 商品的描述，评论：由于这部分的文字较多，因此存储在关系型数据库中可能会导致性能下降，因此使用的是文档型数据库，如 MongDB
3. 图片：分布式文件系统。淘宝的 TFS，阿里云的 OSS，google 的 GFT，Hadoop 的 HDFS，以及 FastDFS，
4. 关键字搜索：solr，elasticsearch，淘宝使用的则是 Isearch
5. 商品热门的波段信息：内存数据库 redis，tair，memache
6. 商品的交易，外部支付接口：第三方应用

数据的多样性就带来了很多的问题

1. 数据源繁多，数据源改造导致相关应用的大面积重构
2. 跨数据源定位问题困难，缓存和性能优化难以实施
3. 数据架构复杂，应用需要直接依赖多种类型的数据源
4. …

为了解决这些问题，阿里巴巴提出的解决访问是：​​统一数据服务层 UDSL​​，在网站应用集群和底层数据源之间构建一层代理，统一数据层

image.png

增加了 UDSL 后的数据架构如下

image.png

UDSL 屏蔽了底层数据库的差异，使用统一的操作语言对不同的数据库进行操作，具体细节由 UDSL 进行维护

2. 热点缓存

使用了 UDSL 后，数据架构虽然得到了大幅的简化，但是性能问题依然很严重。网站的数据非常庞大，缓存过多数据的性价比不高，因此缓存热点数据成了最好的选择

因此阿里巴巴开发了热点缓存平台，提供给 UDSL 作为缓存系统

image.png

四、NoSQL 四大类型

1. KV 键值对型

以键值对形式存储数据，常见的有 Redis，Tair，Memecache

2. 文档型

传输格式多为 Bson，和 Json 类似

常见的有 MongDB，MongDB 是基于分布式文件存储的数据库，使用 C++ 编写，主要用来处理大量的文档，MongDB 是非关系型数据库中功能最丰富，最像关系型数据库的

此外还有：CouchDB，RavenDB …… 等

3. 列存储型

常见的有 HBase，和一些分布式文件系统

4. 图关系数据库

图关系数据库并不是用来存储图片的，而是用来存储关系和构建关系图谱的，比如：社交网络，朋友圈，广告推荐等

常见的有：Neo4j，InfoGrid …… 等

5.四者对比

image.png