Redis篇(1)--浅谈NoSQL

  都说面试造火箭，入职拧螺丝，初入社会，面试中经常被问到Redis，对于Redis本人了解尚浅，应对此问题往往略显慌张甚至不知所措，想diss面试官却奈何自己的技术还不够格。本文开始将循序渐进地讲解Redis相关知识与应用，学成归来能否吊打面试官尚不敢断言，但愿能活学活用！！！
  说到Redis，就不能不谈谈NoSQL。废话少说，开始入坑！！！

---

为什么要用 NoSQL ？

1、 单机 MySQL 的美好时代

  在90年代，一个基本的网站访问量一般不会太大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站并不多。服务器根本没有太大的压力！

DAL：dal是数据访问层的英文缩写，即为数据访问层（Data Access Layer）。其功能主要是负责数据库的访问。简单地说就是实现对数据表的Select（查询）、Insert（插入）、Update（更新）、Delete（删除）等操作。

这种情况下，数据存储的瓶颈是什么？

• 数据量如果太大，一个机器放不下
• 数据的索引（B + Tree），一个机器的内存也放不下（单表超过300万就一定要建立索引了）
• 访问量（读写混合），一个服务器承受不了

如果满足了上述1 or 3个条件时，只能对数据库的整体架构进行重构

2、Memcached（缓存） + MySQL + 垂直拆分

  后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器文件缓存不能共享，大量的小文件缓存也带了比较高的IO压力。在这个时候，Memcached 就自然的成为一个非常时尚的技术产品。

发展过程：
优化数据结构和索引 ➠ 文件缓存（IO）➠ Memcached（当时最热门的技术!）

  Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端。

  网站80%的情况都是在读，每次都要去查数据库的话就很麻烦，所以说我们希望减轻数据库的压力，从而要使用缓存来保证效率。

3、MySQL 主从读写分离

  由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

4、分库分表 + 水平拆分 + MySQL集群

  在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM在写数据的时候会使用表锁，在高并发写数据的情况下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。

  ps：这就是为什么 MySQL 在 5.6 版本之后使用 InnoDB 做为默认存储引擎的原因 – MyISAM 写会锁表，InnoDB 有行锁，发生冲突的几率低，并发性能高。

  同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只是在高可靠性上提供了非常大的保证。

优化的本质：数据库（读、写），终究是为了解决读写问题

发展过程：

• 上面缓存的加入，解决了读的问题

• 早些年MyISAM：表锁，十分影响效率！高并发下会出现严重的锁问题

• 转战InnoDB：行锁

• 逐渐开始使用分库分表来解决写的压力

• MySQL在那个年代虽然推出了表分区，但并没有得到广泛使用，而后来MySQL集群的出现，在高可靠性上提供了非常大的保证

MySQL的扩展性瓶颈？

  MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。

如今…

  2010–2020 十年之间，世界已经发生了翻天覆地的变化

  MySQL等关系型数据库就不够用了，使用它来存储一些比较大的数据，数据表就很大、效率低；大数据的IO压力下，表结构几乎无法更改

  如果有一种数据库来专门处理这些数据，就能减小MySQL的压力…该如何解决此问题？

目前一个基本的互联网项目：

最前面的是企业级防火墙，后面通过负载均衡主机（软负载：Nginx，硬负载：F5）在 web 服务器集群之间进行调度，再由具体的 web 服务器去访问缓存，访问数据库。

为什么要用NoSQL？

  今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展却能很好的处理这些大的数据。

  用户的个人信息、社交网络、地理位置…用户自己产生的数据、日志等等爆发式增长，这时候我们就需要使用NoSQL数据库，以解决以上问题。

什么是NoSQL？

NoSQL 概述

  NoSQL：Not Only SQL （不仅仅是SQL）泛指非关系型的数据库

  随着互联网web2.0网站的兴起，传统的关系型数据库很难应付web2.0时代，特别是超大规模和高并发的SNS（社交网络服务：社交软件、社交网站）类型的web2.0纯动态网站已经显得力不从心，暴露出来很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。

  很多类型的数据，如用户的个人信息、社交网络、地理位置…这些类型的数据存储不需要一个固定的格式，不需要多余的操作就可以横向扩展。

  NoSQL在当今大数据环境下发展得十分迅速，其中Redis发展最快，而且是我们当下必须要掌握的一个技术。

传统 RDBMS 与 NoSQL 的区别？

RDBMS（关系型数据库）：

  指采用了关系模型来组织数据的数据库

​  关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。

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

ACID：

• Atomicity（原子性）：事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚
• Consistency（一致性）：数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束
• Isolation（隔离型）：指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响
• Durability（持久性）：指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失

NoSQL（非关系型数据库）：

  指非关系型的，分布式的，且一般不保证遵循ACID原则的数据存储系统

  非关系型数据库以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，不局限于固定的结构，可以减少一些时间和空间的开销。

• 代表着不仅仅是SQL
• 没有声明性查询语言，没有预定义的模式
• 键 - 值对存储、列存储、文档存储、图形数据库
• 最终一致性，而非ACID属性
• CAP定理、BASE原理
• 高性能，高可用、高可扩

BASE：

• Basically Available（BA 基本可用）：NoSQL允许分布式系统中某些部分出现故障，那么系统的其余部分依然可用。它不会像ACID那样，在系统出现故障时，进行强制拒绝，允许继续部分访问。

• Soft State（软状态）：NoSQL在数据处理过程中，允许这个过程，存在数据状态暂时不一致的情况。但经过纠错处理，最终会一致的。

• Eventually Consistent（最终一致性）：NoSQL的软状态允许数据处理过程的暂时不一致，但是最终处理结果将是一致的，说明NoSQL对数据处理过程可以有短暂的时间间隔，也允许分更细的步骤一个一个地处理，最好数据达到一致即可。这在互联网上进行分布式应用具有其明显的优势。

BASE是NoSQL数据库通常对可用性及一致性的弱要求原则

CAP：

• Consistency（一致性）：所有节点在同一时间具有相同的数据

• Availability（可用性）：保证每个请求不管成功或者失败都有响应

• Partition tolerance（分区容错性）：系统中任意信息的丢失或失败不会影响系统的继续运作

定理：任何分布式系统只可同时满足二点，没法三者兼顾。鱼和熊掌不可兼得！

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类

NoSQL特点

• 方便扩展（数据之间没有关系，很好扩展）

• 大数据量高性能（Redis一秒可以写8万次、读取11万次，NoSQL的缓存记录级，是一种细粒度的缓存，性能会比较高）

• 数据类型是多样型的（不需要事先设计数据库，随取随用）

NoSQL四大分类

• KV键值对 如：Redis、Memcached
• 文档型数据库（bson格式，和json一样） 如：MongoDB、ConthDB
• 列存储数据库 如：HBase、分布式文件系统
• 图关系数据库 如：Neo4j、InfoGrid

至此，本篇完结，待续…