Nosql 入门概述及相关知识介绍
一、互联网时代背景下的演变(数据存储瓶颈):
1. 单机Mysql 的时代
- 数据量的总大小,一个机器存储不够;
- 数据索引(B+Tree)一个机器的内存放不下;
- 访问量(读写混合)一个实例不能承受;
2.Memcached(缓存)+ Mysql+ 垂直拆分
- 随着访问量的上升,大部分使用Mysql架构的网站在数据库上出现性能的问题,web程序不仅关注功能,同时追求性能。
- 使用缓存技术来缓解数据库的压力,优化数据库的结构和索引。
- 开始比较流行的是通过文件缓存来缓解数据库压力,担当党文亮增大的时候,多台web机器通过文件缓存不能共享,大量的小文件缓存也带来比较高的IO压力。
- 这时候Memcached就自然成为一个非常时尚的技术产品
3. Mysql 主从复制读写分离
- 由于数据库写入压力增加,Memcached只能缓解数据库的读取压力。
- 读写及种子啊一个数据库让数据库压力很大,大部分网站开始使用主从复制技术来达到读写分离,以提高读写性能和读库的可扩展性。
- Mysql 的master-slave模式成为这个时代网站的标配。
4. 分库分表 + 水平拆分 + mysql 集群
- Mysql主库的写压力开始出现瓶颈,而数据量猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发Mysql应用开始使用InnoDB引擎代替MyISAM。
- 开始流行使用分表分库来缓解写压力和数据增长的数据问题,Mysql退出不太稳定的分区分表。
- 虽然Mysql退出Mysql Cluster集群,单性能也不能很好满足互联网要求,只是可在高可靠性上提供非常大的保证。
5. Mysql 的扩展性瓶颈
- Mysql数据库存一些大的文字图片等,导致数据库表非常大,在做数据库恢复的时候非常慢,不容易快速回复数据库。。
- 关系数据库强大,但是不能很好地应付所有场景。Mysql的扩展性差(需要复杂的技术实现),大数据下IO压力大,表结构更改困难,正式当时使用Mysql的开发人员面临的问题。
6. 为什么用Nosql
- 对用户数据进行挖掘,SQL数据库已经不适合这些应用。
二、Nosql是什么
- NoSQL = Not Only Sql ,不仅仅是sql,泛指非关系型数据库。
- 亿万比特的数据,这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展。
三、Nosql能做什么
1. 易扩展
NoSql 数据种类多,但是一个共同的特点是去掉关系数据库的关系型特性。
数据之间无关系,这样就很容易扩展,也在架构层面带来了可扩展性的能力。
2. 大数据量高性能
- Nosql 数据库都具有非常高的读写性能,尤其在大数据量下,同样优秀;
- 一般Mysql使用Query Cache,每次表的更新Cache就是小,是一种大粒度的Cache,真对web 2.0的交互频繁应用,Cache性能不高,而Nosql的Cache是记录的,是一种细粒度的Cache。
3. 多样灵活的数据模型
Nosql 无需实现为要存储的数据建立字段,随时可以存储自定义的数据格式。但在关系型数据库增删字段,在表特别大时,危险大。
4. 传统 RDBMS VS NoSQL
- RDBMS
- 高度组织化结构化数据
- 结构化查询语言SQL
- 数据和关系都存储在单独的表中
- 数据操纵语言、数据定义语言
- 严格的一致性
- 基础事务
- Nosql
- 不仅仅sql
- 没有声明性查询语言
- 没有预定义的模式
- 键值对存储 ,列存储,文档存储,图形数据库
- 最终一致性,而非ACID属性
- 非结构化和不可预知的数据
- CAP定力
- 高性能,高可用和可伸缩性
四、下载(后期慢慢补充这部分)
- Redis
- Memcache
- Mongdb
- tair
五、使用方向
- KV
- Cache
- Persistence
六、相关知识体系
6.1 3V + 3高
6.1.1 大数据时代的3V
- 海量Volume
- 多样Variety
- 实时Velocity
6.2 互联网需求的3高
- 高并发
- 高可扩 - 导航策略、负载均衡
- 高性能 - 容灾备份
七、当先Nosql的应用场景
7.1 阿里中文网站为例子
7.1.1 商品基本信息
- 冷信息存储在Mysql这种数据库中
- 去IOE化
- 阿里巴巴集团首席架构师 - 王坚;
- 在IT建设过程中,去除IBM小型机、Oracle数据库及EMC存储设备
7.1.2 商品描述,详情,文字类信息
文档库数据库MongDB
7.1.3 商品图片
7.1.4 商品关键字
- 搜索引擎、站内搜索
- ISearch
7.1.5 商品的波段性的热点高频词汇
- 内存数据库
- Tair、Redis、Memcache
7.1.6 商品的交易、价值计算、积分累计
- 外部系统
- 支付宝
八、大型互联网应用(大数据、高并发、多样数据类型)的难点和解决方案
81. 难点
8.1.1 数据类型多样性
8.1.2 多个数据源多变
8.1.3 数据源改造而数据服务平台不需要大面积重构
8.2 解决方案
8.2.1 统一数据平台服务层
8.2.2 UDSL
- 在网站应用集群和底层数据源之间,构建一层代理,统一数据层
- 模型数据映射 :
- 实现业务模型各属性与底层不同类型数据源的模型数据映射
- 目前支持关系数据库:ISearch、Redis、MongDB
- 统一的查询和更新API
提供了基于业务模型的统一查询更新API,简化网站应用跨不同数据源的开发模式 - 性能优化策略
- 字段延迟加载,按需返回设置
- 基于热点缓存平台的二级缓存
- 异步并行的查询数据:异步并行加载模型中来自不同数据源的字段
- 并发保护:拒绝访问频率过高的主机IP
- 过滤高危查询:例如会导致数据库崩溃的全表扫描