Redis学习笔记（一）——NoSQL

NoSql

1、概述

1. 传统关系型数据库瓶颈

   网站的访问量一般不大时，单个数据库完全可以轻松应付。但访问量巨大时，单个数据库面临瓶颈：

   • 数据量的总大小一个机器放不下时

   • 数据的索引（B+ Tree）一个机器的内存放不下时

   • 访问量(读写混合)一个实例不能承受

2. 优化关系型数据库

   面对大量的访问，可以使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。

   • Memcached+Mysql+垂直拆分：Memcached独立分布式缓存服务器，能够为多个web服务器提供了一个共享的高性能缓存服务，将Memcached放在mysql和应用之间作为缓存。垂直拆分可以将电商数据库分为卖家和买家数据库
   • Mysql主从复制和读写分离：从库用于复制备份主库，避免出现意外情况导致主库数据丢失。生产环境中读的操作从从库中读，写的时候写到主库。
   • 分库分表+水平拆分+Mysql集群：当主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM（数据库引擎）使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM，InnoDB使用行锁。 同时，使用分表分库来缓解写压力和数据增长的扩展问题，使用MySQL Cluster集群。

3. 现在关系型数据库仍面临瓶颈

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

4. 引入非关系型数据库

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

2、NoSQL

1. 概念：

   NoSQL(Not Only SQL )，泛指非关系型的数据库。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余操作就可以横向扩展。

2. 优点：

   数据之间无关系，容易扩展。

   在大数据量下具有非常高的读写性能。

   无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。

   没有声明性查询语言；没有预定义的模式；键值对存储，列存储，文档存储，图形数据库；最终一致性，而非ACID属性；非结构化和不可预知的数据；CAP定理；高性能、高可用性和可伸缩性 ；

3. 种类：

   Redis

   memcache

   Mongdb

4. 应用：

   阿里商品信息存放：

   • 商品基本信息：名称、价格，出厂日期，生产厂商等；使用关系型数据库Mysql存储。
   • 商品描述、详情、评价信息(多文字类)：文档数据库MongDB中
   • 商品图片：分布式的文件系统，淘宝自己的TFS
   • 商品的关键字：搜索引擎ISearch
   • 商品的波段性的热点高频信息：内存数据库tair、Redis、Memcache
   • 商品的交易、价格计算、积分累计：支付宝（外部系统，外部第3方支付接口）

   整合：统一数据平台UDSL（类似于JDBC），统一连UDSL。不用再细分连Redis、Mysql等。

5. 关系型和非关系型对比

   • 关系型设计：ER图

   • 非关系型设计：使用BSON构建数据模型， BSON是一种类json的一种二进制形式的存储格式，简称Binary JSON，它和JSON一样，支持内嵌的文档对象和数组对象。

   对高并发的操作不建议关联查询。分布式事务支持不了太多的并发。

   使用关系型数据库进行多表查询需要多个join操作，语句长且复杂，关联到多个表。而非关系型可以使用键值对的方式进行查询，根据键（id）查出的值为一个json字符串，而嵌套的数据（对应于关系型中的关联表数据）也在这个字符串中。

6. 聚合模型

   KV键值：Redis

   bson：文档型数据库MongoDB

   列族（按列存储数据的）：分布式文件系统

   图：社交网络、知识图谱

3、分布式数据库

1. ACID：原子性、一致性、独立性、持久性

2. CAP：

   Consistency（强一致性）： 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

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

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

3. CAP只能三选二，不能三个都满足：

   由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性P必须需要实现。

   CA：传统Oracle数据库是，不是分布式

   AP：大多数网站架构的选择（例如一个商品被浏览过，浏览量需要加一，此时面对大量的浏览数时，满足C需要耗费大量资源，因此不需要被满足）

   CP：Redis、Mongodb

   一致性C与可用性A的决择

   • 数据库事务一致性需求：很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。
   • 数据库的写实时性和读实时性需求：对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
   • 对复杂的SQL查询，特别是多表关联查询的需求：任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

4. BASE

   BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。BASE：基本可用（Basically Available） 软状态（Soft state） 最终一致（Eventually consistent）它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。

5. 分布式和集群

   分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。

   集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。