kCloudStorage - 基于云技术的廉价冗余天文海量数据存储 王锋 季凯帆 邓辉 1昆明理工大学 2国家天文台-昆明理工大学天文信息技术联合实验室 2011.11.10 贵阳

SUMMARY 1）研究背景 2）当前存储技术的局限 3）天文需求的描述 4）云存储的关键技术 5）可行性与前期实验结果

Background 数据的存储，是天文信息学的基础。 海量数据的保存，本质上并没有很好的解决。 当前常用的技术 DAS, NAS , SAN DAS – 直接存储 NAS – 网络附加存储 SAN – 存储区域网络

DAS vs NAS architecture Application Servers NAS Appliances or NAS Head Ends Generic Win2k Linux Unix LAN FC Clients Direct Attached Storage Application Servers Win2k Linux Unix Tape SCSI LAN

Storage Area Network (SAN) SAN architecture Storage Area Network (SAN) Database Servers Block Storage Devices Fibre Channel SAN Clients LAN Storage is accessed at block level not at file level Very high performances Storage is shared Good management tools Interoperability issues

天文数据特点 数据特点 1、存在变长大数据段，例如天文观测图片，数据规格有限 拆分变长数据为定长KV 2、数据总量大，PB级数据量 3、更改可能性小 降低分布式事务的严格性，采用不删除 ，更改数据重新分配储存空间的方式规避储存器碎片问题，避免处理空间整理问题，并且保持数据局部顺序性，有利于预读

天文数据需要存储系统 既需要文件系统特性 也有关系数据库的查询需求 1、需要范围查询，例如按照精度纬度查询 B+树实现索引 如果存储按照经纬有序可以采用位图索引 2、顺序存储，顺序读取可能性大 可以采取预读 3、近几年实时处理的要求明显增加 4、有大量的数据导出需求！！！！！ 天文数据需要存储系统 既需要文件系统特性 也有关系数据库的查询需求

关系型数据库存储天文数据时的问题 问题 改变 如何改变Google引领方向， 放弃高端设备，使用Commodity Device 1、热备份对性能的影响以及热备的不一致性 2、大数据量 3、磁盘限制导致的QPS瓶颈（SSD） 优雅解决2,3问题往往通过引入高端储存，从而带来高成本 改变 当不优雅的分库分表成为用户解决大数据量的首选办法的时候数据库的革命开始了 如何改变Google引领方向， 放弃高端设备，使用Commodity Device 分布式数据库是必然选择 如何选择索引 如何选择储存 如何实现事务

理想的天文数字库 1、海量 2、分布 3、事务 4、确保一致性 5、可检索查询 6、高速、线速读写 7、随意更换设备 8、任意导出 9、便宜

三个技术点 储存（定长，变长记录） 索引(B+,Hash) 事务(行锁，表锁) 为天文数据设计量体裁衣 三个技术点 储存（定长，变长记录） 索引(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构架，为整个腾讯公司提供文件存储服务 什么是云存储 是指通过集群应用、网格技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统

----------------------------------------------- 分布式文件系统 文件系统存储和数据存储的边界正在缩小 开源的云存储系统和KV数据库 ----------------------------------------------- 分布式文件系统 始祖级别 bigtable，依赖（chubby） Apache的实现 Hbase， Cassandra KV数据库 耳熟能详的 Redis，Mongodb（value是结构数据，实现了结构数据的索引，几乎就是传统数据库，但是不支持事务） 从google提出gfs开始，分布式系统中存储文件变成了分段存储。以hfs为例，这种分布式文件系统使用了64M为一段来存储文件。就是用KV模式组织数据。 NoSQL挑战传统关系型数据库的声音也从四面八方传来。同样也是用KV的方式组织数据。 总结：KV方式用于存储数据，已经成为当下存储系统统一的方式

索引—必然选择KV 从mysql(innodb)说KV 既是数据储存方式也是索引 红色部分，主键B+树索引了每个记录 主键就是Key，记录就是Value 传统关系型数据库，如Oracle，sqlserver，mysql的底层都存在着KV的影子

Key是否支持范围查询决定分布方式 B+ 连续范围分区 （多重索引） Bigtable方式 Hash 一致性hash环算法

基本数据库储存系统 几大特征： 加快查询读取速度 加快写入速度 保证安全 具体做法 充分利用分层储存器，将HotData Cache在内存中 通过日志推后内存数据结构落地 落地时候的两次写 一致性

储存方式-可以选择Tablet leveldb带来的新方法 主要的创新在于SSTable这个结构是天然支持分布的

重说cap理论 为什么大多数KV数据库都选择最终一致性并且不支持事务 消除高端硬件之后，容错性上升为软件的职责 保证强一致性系统的容错性。 可以证明强一致性和容错性矛盾吗？ Oracle新推的NoSQL数据支持事务，牺牲了容错性 Consistency, Availability, Partition-tolerance

复杂的分布式事务 假设可以设计可靠的储存组件，在分布式事务中如何实现事务 分布式事务实现的几个话题：提交完整性，控制器故障处理，节点故障处理机制，节点同步的时间开销控制，大数据传输的网络开销

一致性和事务 本身就是矛盾，设想一下什么是最终一致性的事务。 限制读取，增加控制器的负载。 分布式的控制器,要选择paxos？ 事务最理想的情况就是同时保证一致性和容错性 最终一致性的事务知否就只能是传统数据库的读写分离模式

典型KV数据库构架 Master1 Master2 Master3 Client A B C D E ControlServer DataServer

DataServer的结构 Request Request Plug-ins Response Plug-ins Response Migrate Storage Engine Replicator Mdb Fdb Bdb

ControlServer的结构 Request Paxos DataServer MetaData DataServer MetaData

可行性与前期实验结果

储存系统瓶颈是网络 实验： 在Mongodb上的测试的分片存储数据 结论： 分片对存取性能意义不大 分布式KV可以明显提高存储提高并发存储能力

如何保证索引和数据的一致性 思路： 简化一致性模型： 讨论： 本地存储索引的可行性 只要在本地计算机存储，远程集群存储观测数据就可以简化系统的一致性模型 即改多机提交为单机提交

kCloudStorage - see me next year…. 谢谢。。 Q&A