当前位置:文档之家› 大数据存储

大数据存储



02 数据库设计的CAP
2)
CAP原理 可用性
P

是指网络的分区 网络中的两个服务结点出现分区的原因 很多,比如网络断了、对方结点因为程 序bug或死机等原因不能访问
02 数据库设计的CAP
2)
CAP原理

CAP(Consistency,Availability,Patition tolerance)理论 论述的是在任何分布式系统 中,只可能满足一致性 ,可用性及分区容忍性三者中的两者,不可能全部都 满足。所 以不用花时间精力在如何满足所有三者上 面。
02 03
NoSQL将意味着不止SQL
科学研究的第四范式为数据存储存储的研究和快速发展带来了新的动力
01 数据存储的前世今生
事件一:公共卫生
事件 对手 武器 结果 2009年,H1N1流感预测 谷歌
分析搜索记录
疾控中心
医院报告
谷哥提前两周得到结果 与官方数据相关性达97%
− 5000万美国人 − 2003 — 2008 年 流感关键词
大数据存储
数据库技术的变革和发展
余洋
yuy@
目录
完整的科学研究周期包含四个部分:数据采集、数据整理、数据分析 及数据可视化。现代科学研究可以通过多种方式收集和生成数据,对 于大量收集到的数据,却缺乏好的整理与分析工具。
01
数据存储的前世今生 数据库设计的CAP 大数据时代的NOSQL
− 4.5亿数学模型
− 45个关键词组合
01 数据存储的前世今生
事件二:变革商业
事件 对手 武器 机票价格预测 埃齐奥尼的Farecast系统
分析大量价格记录
结果
票价预测准确度达75% 平均每张机票节省50美元
− 到2013年拥有2000亿条航班记录
01 数据存储的前世今生
事件三:出租车
事件 对手 武器 结果 交通拥堵热点提取 武汉1.5万出租车GPS数据
Server、Informix 和许多其他的系统。可以认为,Stonebraker教授是目前主流 数据库的奠基人。
01 数据存储的前世今生
2)
关系数据库
行式存储 → ACID → 关系数据库的问题 数据存放在数据文件内 数据文件的基本组成单位:块/页 块内结构:块头、数据区
01 数据存储的前世今生
他是MIT麻省理工学院客席教授。
Stonebraker 教授领导了称为Postgres项目,并把Postgres 放在了BSD 版权的 保护下。如今Postgres名字已经 变成了PostgreSQL,功能也是日渐强大。
在Ingres 基础上产生了很多商业数据库软件,包括 Sybase、Microsoft SQL
C

是说数据的原子性,这种原子性在经典 ACID的数据库中是通过事务来保证的; 当事务完成时,无论其是成功还是回滚, 数据都会处于一致的状态; 在分布式环境中,一致性是说多点的数 据是否一致。


02 数据库设计的CAP
2)
CAP原理 可用性
A

可用性是说服务能一直保证是可用的状 态,当用户发出一个请求,服务能在有 限时间内返回结果。 而这种可用性是不关乎结果的正确与否 ,所以,如果服务一致返回错误的数据, 其实也可以称为其是可用的。
CAP理论无疑是导致技术趋势由关系数据库系统向 NoSQL系统转变的最重要原因。

02 数据库设计的CAP
2)
CAP原理
• CA 传统数据库 • AP 大多数网站架构的选择 • CP Redis、 MongoDB
用户对数据的不一致性是不敏感的(数字敏感的 场景除外)
02 数据库设计的CAP
2)
CAP原理
01 数据存储的前世今生
1)
数据库管理系统
层次数据库→ 网状数据库→ 关系数据库
数据量越大,结构越复杂,不利于用户掌握 用户必须了解系统存储结构的细节,加重了编程的负担
01 数据存储的前世今生
1)
数据库管理系统
层次数据库→ 网状数据库→ 关系数据库
Edfar F. Codd
Don Chamberlin
什么是大数据

Big velocity
03 大数据时代的NOSQL
1)
什么是大数据

Big variety
03 大数据时代的NOSQL
2)
常见的NOSQL产品
DynamoDB
03 大数据时代的NOSQL
2)

常见的NOSQL产品
HBase是一个分布式的、面向列的开源数据库,该技术来源于 Google论文“Bigtable:一个结构化数据的分布式存储系统”。
BigT able (column-oriented/tabular) Hypertable (column-oriented/tabular) HBase (column-oriented/tabular)
MongoDB (document-oriented)
errastore (document-oriented) T Redis (key-value)
CA 满足一致性,可用性的系统,通常在可扩展性上 不太强大

Traditional RDBMSs like Postgres, MySQL, etc (relational) Vertica (column-oriented)



Aster Data (relational)
Greenplum (relational)
2)
关系数据库
行式存储 → ACID → 关系数据库的问题 读某个列必须读入整行 行不等长,修改数据可能导致行迁移
行数据较多时可能导致行链
01 数据存储的前世今生
2)
关系数据库
行式存储 → ACID → 关系数据库的问题 全表扫描 行标识访问
01 数据存储的前世今生
2)
关系数据库
Scalaris (key-value)
MemcacheDB (key-value) Berkeley DB (key-value)
02 数据库设计的CAP
2)
CAP原理
03 大数据时代的NOSQL
NOSQL的发展源于 大数据的需求
变革的基础
一切事物都可量化,变为数据
变革的重点
由T(技术)转变到I(信息)上
− I 隔离性 两个事务不会相互影响,覆盖彼此数据等 − D 持久化 事务一旦完成,那么数据应该是被写到安全的,持久
化存储的设备上
01 数据存储的前世今生
2)
关系数据库
Impedance Mismatch
– ORM (Hibernate存在的价值) – 这个问题影响的是开发效率
行式存储 → ACID → 关系数据库的问题
01 数据存储的前世今生
2)
关系数据库
行式存储 → ACID → 关系数据库的问题

关系型数据库在单机容量达到上限的时候,做扩展是
非常难的,往往要要根据主键进行分表;其实可以想
到一旦分表之后,就已经开始违反关系型数据库的范式
了,因为“同一个集合的数据被拆分到多个表”

当数据开始分布存储的时候,关系型数据库逐渐演变成
xml数据库
01 数据存储的前世今生3) NhomakorabeaNOSQL数据库
新型数据库的崛起
大部分NOSQL产品的共同点:

保持产品功能的简单,在细分方向上做到极致,不仅仅是众多 NOSQL产品的特点。

对于开发者,在架构设计的过程中,面对的不是单个的NOSQL 产品选择,而是在NOSQL生态圈中选择出最佳拍档。
下面的问题 什么是NOSQL生态圈? 怎么选择最佳拍档?
02 数据库设计的CAP
1)
NOSQL的生态圈
02 数据库设计的CAP
2)
CAP原理
C P
P: Tolerance of network Partition 分区容忍性(分布式)
C: Consistency 一致性
A
A: Availability 可用性
02 数据库设计的CAP
2)
CAP原理
一致性

01 数据存储的前世今生
3)
NOSQL数据库
新型数据库的崛起
类型 部分代表
列存储
文档存储 key-value存储 图存储 对象存储
Hbase、Cassandra、Hypertable
MongoDB、CouchDB Tokyo Cabinet / Tyrant、Berkeley DB MemcacheDB、Redis Neo4J、FlockDB、InfoGrid Db4o、Versant Berkeley DB XML、BaseX
行式存储 → ACID → 关系数据库的问题 B-树索引
01 数据存储的前世今生
2)
关系数据库
行式存储 → ACID → 关系数据库的问题
− A 原子性 在事务中执行多个操作是原子性的,要么操作全部
执行,要么一个都不执行
− C 一致性 进行事务的过程中整个数据加的状态是一致的,不
会出现数据花掉的情况


Not designed to be run on clusters
– Scaling up – Scaling out – 传统的SQL Server , Oracle 都是强依赖于磁盘系统来实现 集群
01 数据存储的前世今生
2)
关系数据库
问题1:表数据膨胀了
行式存储 → ACID → 关系数据库的问题
分析车辆速度
低密度
相关主题