Transcript kCloudStorage 基于云技术的廉价冗余天文海量数据存储

kCloudStorage
- 基于云技术的廉价冗余天
文海量数据存储
王锋 季凯帆 邓辉
1昆明理工大学
2国家天文台-昆明理工大学天文信息技术联合实验室
2011.11.10 贵阳
SUMMARY
•
•
•
•
•
1）研究背景
2）当前存储技术的局限
3）天文需求的描述
4）云存储的关键技术
5）可行性与前期实验结果
Background
• 数据的存储，是天文信息学的基础。
• 海量数据的保存，本质上并没有很好的解决。
• 当前常用的技术
• DAS, NAS , SAN
•
DAS – 直接存储
•
NAS – 网络附加存储
•
SAN – 存储区域网络
DAS vs NAS architecture
Clients
Application
Servers
LAN
Win2k Linux
LAN
Win2k Linux Unix
Unix Win2k Linux Unix
Generic
SCSI
FC
FC
Application
Servers
Tape
Direct Attached
Storage
Generic
NAS Appliances
or
NAS Head Ends
SAN architecture
• Storage is accessed
at block level not at
file level
• Very high
performances
• Storage is shared
• Good management
tools
• Interoperability
issues
Clients
LAN
Database
Servers
Fibre
Channel
SAN
Block
Storage
Devices
Storage Area Network (SAN)
天文数据特点
数据特点
• 1、存在变长大数据段，
例如天文观测图片，数据
规格有限
• 拆分变长数据为定长KV
• 2、数据总量大，PB级数
据量
• 分布式KV系统
• 3、更改可能性小
• 降低分布式事务的严格性，
采用不删除 ，更改数据重
新分配储存空间的方式规
避储存器碎片问题，避免
处理空间整理问题，并且
保持数据局部顺序性，有
利于预读
查询需求
• 1、需要范围查询，例如
按照精度纬度查询
• B+树实现索引
• 如果存储按照经纬有序可
以采用位图索引
天文数据需要存储系统
既需要文件系统特性
也有关系数据库的查询需求
• 2、顺序存储，顺序读取
可能性大
• 可以采取预读
• 3、近几年实时处理的要
求明显增加
• 4、有大量的数据导出需
求！！！！！
关系型数据库存储天文数据时的问题
• 问题
•
•
•
•
1、热备份对性能的影响以及热备的不一致
性
2、大数据量
3、磁盘限制导致的QPS瓶颈（SSD）
优雅解决2,3问题往往通过引入高端储存，
从而带来高成本
• 改变
•
当不优雅的分库分表成为用户解决大数据量
的首选办法的时候数据库的革命开始了
• 如何改变Google引领
方向，
• 放弃高端设备，使用
Commodity Device
• 分布式数据库是必然选
择
•
如何选择
•
如何选择
•
如何实现
索引
储存
事务
• 理想的天文数字库
•
•
•
•
•
•
•
•
•
1、海量
2、分布
3、事务
4、确保一致性
5、可检索查询
6、高速、线速读写
7、随意更换设备
8、任意导出
9、便宜
为天文数据设计量体裁衣
三个技术点
储存（定长，变长记录）
索引(B+,Hash)
事务(行锁，表锁)
•
•
云存储的现状
什么是云存储
是指通过集群应用、网格技术或分
布式文件系统等功能，将网络中大
量各种不同类型的存储设备通过应
用软件集合起来协同工作，共同对
外提供数据存储和业务访问功能的
一个系统
•
•
•
•
•
•
•
•
•
•
Amazon
Amazon的云服务主要包括弹性计算云（EC2）、简单存储
服务（S3）、简单数据库服务（SimpleDB）。EC2服务偏
向计算，S3服务偏向存储，提供IaaS级别的服务，
SImpleDB偏向应用，提供PaaS和SaaS级别的服务。
Google
Google当数最大的云计算的使用者。Google搜索引擎就建
立在分布在200多个地点、超过100万台服务器的支撑之上，
这些设施的数量正在迅猛增长。Google地球、地图、Gmail、
Docs等也同样使用了这些基础设施。
三篇重要论文基本描述了这种集群的结构
”WEB SEARCH FOR A PLANET:THE GOOGLE CLUSTER
ARCHITECTURE”
“The Google File System”
“The Chubby lock service for loosely-coupled distributed
systems”
淘宝
淘宝具有一个模仿gfs构架的tfs系统，以及配套的cdn网络
形成了国内较大规模的云存储平台，主要提供商家宣传图
片的存储，淘宝直接针对这种储存服务收费。
Tencent
同样基于gfs构架，为整个腾讯公司提供文件存储服务
文件系统存储和数据存储
的边界正在缩小
从google提出gfs开始，分布式系统
中存储文件变成了分段存储。以hfs
为例，这种分布式文件系统使用了
64M为一段来存储文件。就是用KV
模式组织数据。
NoSQL挑战传统关系型数据库的声
音也从四面八方传来。同样也是用
KV的方式组织数据。
总结：KV方式用于存储数据，已经
成为当下存储系统统一的方式
• 开源的云存储系统和KV数据库
• ---------------------------------------------• 分布式文件系统
– 始祖级别
• bigtable，依赖（chubby）
– Apache的实现
• Hbase， Cassandra
• ---------------------------------------------• KV数据库
– 耳熟能详的
• Redis，Mongodb（value是结构数
据，实现了结构数据的索引，几乎
就是传统数据库，但是不支持事务）
索引—必然选择KV
从mysql(innodb)说KV
• 既是数据储存方式
也是索引
• 红色部分，主键B+
树索引了每个记录
• 主键就是Key，记
录就是Value
• 传统关系型数据库，
如Oracle，
sqlserver，mysql的
底层都存在着KV的
影子
Key是否支持范围查询决定分布方式
•
•
•
•
B+
连续范围分区
（多重索引）
Bigtable方式
• Hash
• 一致性hash环算
法
基本数据库储存系统
• 几大特征：
• 加快查询读取速
度
• 加快写入速度
• 保证安全
• 具体做法
• 充分利用分层储
存器，将HotData
Cache在内存中
• 通过日志推后内
存数据结构落地
• 落地时候的两次
写
• 一致性
储存方式-可以选择Tablet
leveldb带来的新方法
• Tablet的继承了传
统储存的结构的
三个特征
• 主要的创新在于
SSTable这个结构
是天然支持分布
的
重说cap理论
• 为什么大多数KV数据库都选择最终一致性并且
不支持事务
• 消除高端硬件之后，容错性上升为软件的职责
• 保证强一致性系统的容错性。
• 可以证明强一致性和容错性矛盾吗？
• Oracle新推的NoSQL数据支持事务，牺牲了容
错性
• Consistency, Availability, Partition-tolerance
复杂的分布式事务
• 假设可以设计可靠的储存组件，在分布式事务
中如何实现事务
• 分布式事务实现的几个话题：提交完整性，控
制器故障处理，节点故障处理机制，节点同步
的时间开销控制，大数据传输的网络开销
一致性和事务
• 本身就是矛盾，设想一下什么是最终一致性的
事务。
• 限制读取，增加控制器的负载。
• 分布式的控制器,要选择paxos？
• 事务最理想的情况就是同时保证一致性和容错
性
• 最终一致性的事务知否就只能是传统数据库的
读写分离模式
典型KV数据库构架
ControlServer
Maste
r1
Maste
r2
Maste
r3
Client
A
B
C
DataServer
D
E
DataServer的结构
Request
Request Plugins
Response
Plug-ins
DataServer
Migrate
Replicat
or
Storage Engine
Mdb
Fdb
Response
Bdb
ControlServer的结构
Request
Paxos
DataServer
DataServer
DataServer
MetaData
MetaData
MetaData
可行性与前期实验结
果
储存系统瓶颈是网络
•
•
•
•
•
•
实验：
在Mongodb上的测试的分片存储数据
结论：
分片对存取性能意义不大
网络成为此种存储系统的瓶颈(1000M线速）
分布式KV可以明显提高存储提高并发存储能力
如何保证索引和数据的一致性
•
•
•
•
•
思路：
简化一致性模型：
讨论：
本地存储索引的可行性
只要在本地计算机存储，远程集群存储观测数
据就可以简化系统的一致性模型
• 即改多机提交为单机提交
kCloudStorage
- see me next year….
• 谢谢。。
• Q&A