Redis-01-SQL和NoSQL
1. NoSQL和SQL
1.1 数据的类型分类
-
根据数据结构的不同,我们大致可以将数据分成三种类型的数据,结构化数据,非结构化数据,半结构化数据
-
结构化数据
-
结构化数据拥有严格的长度和格式规范,通常以行为单位进行存储,一行就代表一个数据
-
示例
ID 姓名 年龄 地址 手机 1 张三 18 浙江 1234 2 李四 19 上海 2345 3 王五 20 北京 3456
-
1.2 企业存储架构的演进
-
图片来源于https://www.cnblogs.com/xrq730/p/11039384.html
-
阶段一
- 在这个阶段中APP的访问量较少,一个APP对应一个关系型数据库。
-
阶段二(负载均衡)
- 在该阶段中,数据库不会成为性能的瓶颈。反而是因为单独的一台服务器扛不住日益增长的用户流量和服务需求。因此会出现卡顿等故障。
- 在这个阶段中,我们常用的解决手段是进行负载均衡。通过将流量均匀的分散在各个服务器之间,减小了单个服务器的压力
-
阶段三(垂直拆分)
- 随着用户规模的继续增长,单个数据库也扛不住这么高的读写请求了。
- 于是乎我们进行读写分离操作,每个数据库只单独负载一种操作,然后两个服务器之间进行数据同步。
-
阶段四(水平拆分)
- 随着用户的不断增长,单一的读写分离结构也要扛不住了。
- 于是我们对表进行水平拆分,进行分库分表,建立数据库集群。一个集群就负责某一些特定的表的书写。
-
阶段五(RDBMS+NoSQL)
- 现在,用户的数据量也大大增加了。数据也变得复杂了
- 一个简单商品就涉及到了如此多的数据类型种类,因此,单一的关系型数据库已经不在适合存储复杂类型的数据了,于是,在架构层中,我们就需要加入NoSQL 的数据库来帮助我们存储哪些不适合存储在关系型数据库中的数据
1.3 NoSQL
RDBMS的优缺点
- 优点
- 易理解,一行就是一个数据
- 操作方便,对关系型数据库,我们有SQL这种结构化查询语言来帮助我们进行操作
- 数据一致,事务的ACID原则帮助我们保证了数据之间的高度一致性
- 稳
- ‘定,MySQL和Oracle等常见关系型数据库在经过市场长时间的考验之后,性能优秀
- 缺点
- 高并发下IO压力大,因为数据是按行进行存储,哪怕只是对某一列进行操作,也需要读取出整个表
- 表的维护代价高,随着数据量的增多,表难以进行水平扩展和索引的维护
- 为了保证数据一致性从而导致并发性能的降低
- 最致命的缺点就是高并发性能低下
什么是NoSQL
- NoSQL = Not Only SQL,意识是不仅仅是SQL
- 这里需要注意的是NoSQL和SQL并不是相对立的,而是作为SQL的一种补充。二者各有优劣,可以相互弥补对方的缺点
NoSQL的特点
-
易扩展
-
优秀的高并发性能
-
灵活的数据模型
- NoSQL无需实现为需要存储的数据提前设计数据结构,
PS. NoSQL就像是我们Java中用的Map集合,管他是什么,都可以往里面放。因此使用起来非常便捷
1.4 NoSQL各种类型的对比
分类 | Examples举例 | 典型应用场景 | 数据模型 | 优点 | 缺点 |
---|---|---|---|---|---|
键值(key-value) | Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB | 内容缓存,主要用于处理大量数据的高访问负载,也用于一些日志系统等等。 | Key 指向 Value 的键值对,通常用hash table来实现 | 查找速度快 | 数据无结构化,通常只被当作字符串或者二进制数据 |
列存储数据库 | Cassandra, HBase, Riak | 分布式的文件系统 | 以列簇式存储,将同一列数据存在一起 | 查找速度快,可扩展性强,更容易进行分布式扩展 | 功能相对局限 |
文档型数据库 | CouchDB, MongoDb | Web应用(与Key-Value类似,Value是结构化的,不同的是数据库能够了解Value的内容) | Key-Value对应的键值对,Value为结构化数据 | 数据结构要求不严格,表结构可变,不需要像关系型数据库一样需要预先定义表结构 | 查询性能不高,而且缺乏统一的查询语法。 |
图形(Graph)数据库 | Neo4J, InfoGrid, Infinite Graph | 社交网络,推荐系统等。专注于构建关系图谱 | 图结构 | 利用图结构相关算法。比如最短路径寻址,N度关系查找等 | 很多时候需要对整个图做计算才能得出需要的信息,而且这种结构不太好做分布式的集群方案。 |
1.5 CAP和BASE理论
RDBMS的ACID原则
- 原子性(Atomic)
- 一个事务(transaction)中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
- 一致性(Consistency)
- 在事务开始之前和事务结束以后,数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设规则,这包含资料的精确度、串联性以及后续数据库可以自发性地完成预定的工作。
- 例如:转账过程中,AB两个共1000元,那么不管事务怎么执行,两个人的钱的总和一定是1000不会变。除非有别的新事务发生
- 隔离性(Isolation)
- 数据库允许多个并发事务同时对其数据进行读写和修改的能力,隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别,包括读未提交(Read uncommitted)、读提交(read committed)、可重复读(repeatable read)和串行化(Serializable)。
- 持久性(Durability)
- 事务处理结束后,对数据的修改就是永久的,即便系统故障也不会丢失。如果在系统故障前,事务没有提交,则回滚。不然,则保证更改
CAP理论
- 在计算机科学中, CAP定理(CAP theorem), 又被称作 布鲁尔定理(Brewer's theorem), 它指出对于一个分布式计算系统来说,不可能同时满足以下三点:
- 一致性(Consistency) (所有节点在同一时间具有相同的数据)
- 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
- 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
- CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的满足两个。因此,根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类:
- CA - 单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
- CP - 满足一致性,分区容忍性的系统,通常性能不是特别高。
- AP - 满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。
BASE理论
- BASE:Basically Available, Soft-state, Eventually Consistent。 由 Eric Brewer 定义。
- CAP理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的满足两个。
- BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:
- Basically Availble --基本可用
- Soft-state --软状态/柔性事务。 "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
- Eventual Consistency -- 最终一致性, 也是 ACID 的最终目的。
ACID原则和BASE理论的对比
ACID | BASE |
---|---|
原子性(Atomicity) | 基本可用(Basically Available) |
一致性(Consistency) | 软状态/柔性事务(Soft state) |
隔离性(Isolation) | 最终一致性 (Eventual consistency) |
持久性 (Durable) |