阅读 65
redis | 一、NoSql演进史

redis | 一、NoSql演进史

redis系列文章:

liudongdong.top/categories/…

本篇来源:

liudongdong.top/archives/re…

公众号:雨中散步撒哈拉

备注:欢迎公众号,一起学习,共同进步!

一、数据库演进史

1. 单机 MySQL 时代

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

图片

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

  1. 数据量太大,一个服务器硬盘存不下

  2. 读写混合,一个服务器性能不足

  3. 数据库索引太大,内存不足

2. 垂直拆分与缓存时代

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

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

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

图片

3. 水平拆分与集群时代

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

图片

4.  数据爆炸时代

图片

在如今这个信息爆炸的时代,人们对于信息的实时性要求越来越高,互联网用户同样也越来越多,因此 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. 事务

NoSQL

  1. 没有固定的查询语言

  2. 存储方式多样化:键值对存储 ( redis ),列存储 ( HBase ),文档存储 ( MongDB ),图形数据库

  3. 最终一致性,只需保证数据的最终一致

  4. CAP 定理和 Base 理论 ( 异地多活 )

  5. 高性能,高可用,高可扩

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

3. 大数据时代的要求

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

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

  1. 海量 ( volume )

  2. 多样 ( variety )

  3. 实时 (velocity)

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

  1. 高可用

  2. 高并发

  3. 高性能

三、阿里巴巴架构演进

图片

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

  1. 敏捷:需求的敏捷开发,应用系统的膨胀和耦合恶化使得架构越来越复杂,该如何保持业务的敏捷开发

  2. 开放:如何提升网站开放性,吸引第三方开发者加入到网站的共建

  3. 体验:并发压力快速增长,用户对体验的要求也越来越高

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

复杂的数据架构图

图片

图片

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

  1. 商品基本信息:名称,商家信息等,可以存储在关系型数据库中

  2. 商品的描述,评论:由于这部分的文字较多,因此存储在关系型数据库中可能会导致性能下降,因此使用的是文档型数据库,如 MongDB

  3. 图片:分布式文件系统。淘宝的 TFS,阿里云的 OSS,google 的 GFT,Hadoop 的 HDFS,以及 FastDFS,

  4. 关键字搜索:solr,elasticsearch,淘宝使用的则是 Isearch

  5. 商品热门的波段信息:内存数据库 redis,tair,memache

  6. 商品的交易,外部支付接口:第三方应用

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

  1. 数据源繁多,数据源改造导致相关应用的大面积重构

  2. 跨数据源定位问题困难,缓存和性能优化难以实施

  3. 数据架构复杂,应用需要直接依赖多种类型的数据源

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

图片

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

图片

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

2. 热点缓存

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

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

图片

四、NoSQL 四大类型

1. KV 键值对型

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

2. 文档型

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

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

此外还有:CouchDB,RavenDB …… 等

3. 列存储型

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

4. 图关系数据库

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

常见的有:Neo4j,InfoGrid …… 等

5.四者对比

图片

文章分类
后端
文章标签