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

1、kCloudStorage- 基于云技术的廉价冗余天基于云技术的廉价冗余天文海量数据存储文海量数据存储 1）研究背景 2）当前存储技术的局限 3）天文需求的描述 4）云存储的关键技术 5）可行性与前期实验结果 SUMMARYBackground 数据的存储，是天文信息学的基础。 海量数据的保存，本质上并没有很好的解决。 当前常用的技术 DAS, NAS , SAN DAS 直接存储 NAS 网络附加存储 SAN 存储区域网络DAS vs NAS architectureFCClientsDirect Attached StorageApplication ServersWin2k LinuxU

2、nixUnixTapeFCLinuxWin2kSCSILANApplicationServersNAS AppliancesorNAS Head EndsGenericGenericWin2k LinuxUnixLANSAN architecture Storage is accessed at block level not at file level Very high performances Storage is shared Good management tools Interoperability issuesStorage Area Network (SAN)DatabaseS

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

4、系数据库的也有关系数据库的查询需求查询需求查询需求查询需求 1、需要范围查询，例如、需要范围查询，例如按照精度纬度查询按照精度纬度查询 B+树实现索引 如果存储按照经纬有序可以采用位图索引 2、顺序存储，顺序读取、顺序存储，顺序读取可能性大可能性大 可以采取预读 3、近几年实时处理的要、近几年实时处理的要求明显增加求明显增加 4、有大量的数据导出需、有大量的数据导出需求！求！关系型数据库存储天文数据时的问题关系型数据库存储天文数据时的问题 问题问题1、热备份对性能的影响以及热备的不一致性2、大数据量3、磁盘限制导致的QPS瓶颈（SSD）优雅解决2,3问题往往通过引入高端储存，从而带来高成本 改

5、变改变当不优雅的分库分表成为用户解决大数据量的首选办法的时候数据库的革命开始了 如何改变如何改变Google引领引领方向，方向， 放弃高端设备放弃高端设备，使用，使用Commodity Device 分布式数据库分布式数据库是必然选是必然选择择如何选择如何选择索引索引如何选择如何选择储存储存如何实现如何实现事务事务 理想的天文数字库 1、海量 2、分布 3、事务 4、确保一致性 5、可检索查询 6、高速、线速读写 7、随意更换设备 8、任意导出 9、便宜、便宜为天文数据设计量体裁衣为天文数据设计量体裁衣三个技术点储存（定长，变长记录）索引(B+,Hash)事务(行锁，表锁)云存储的现状云存储的

6、现状AmazonAmazon的云服务主要包括弹性计算云（EC2）、简单存储服务（S3）、简单数据库服务（SimpleDB）。EC2服务偏向计算，S3服务偏向存储，提供IaaS级别的服务，SImpleDB偏向应用，提供PaaS和SaaS级别的服务。GoogleGoogle当数最大的云计算的使用者。Google搜索引擎就建立在分布在200多个地点、超过100万台服务器的支撑之上，这些设施的数量正在迅猛增长。Google地球、地图、Gmail、Docs等也同样使用了这些基础设施。三篇重要论文基本描述了这种集群的结构”WEB SEARCH FOR A PLANET:THE GOOGLE CLUSTER

7、 ARCHITECTURE”“The Google File System”“The Chubby lock service for loosely-coupled distributed systems”淘宝淘宝具有一个模仿gfs构架的tfs系统，以及配套的cdn网络形成了国内较大规模的云存储平台，主要提供商家宣传图片的存储，淘宝直接针对这种储存服务收费。Tencent同样基于gfs构架，为整个腾讯公司提供文件存储服务什么是云存储 是指通过集群应用、网格技术或分布式文件系统等功能，将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作，共同对外提供数据存储和业务访问功能的一个系统文件

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

9、组织数据。总结：KV方式用于存储数据，已经成为当下存储系统统一的方式索引索引必然必然选择选择KV从从mysql(innodb)说说KV 既是数据储存方式也是索引 红色部分，主键B+树索引了每个记录 主键就是Key，记录就是Value 传统关系型数据库，如Oracle，sqlserver，mysql的底层都存在着KV的影子Key是否支持范围查询决定分布方式是否支持范围查询决定分布方式 B+ 连续范围分区连续范围分区 （多重索引）（多重索引） Bigtable方式 Hash 一致性一致性hash环算环算法法基本数据库储存系统基本数据库储存系统 几大特征： 加快查询读取速度 加快写入速度 保证安全

10、具体做法 充分利用分层储存器，将HotData Cache在内存中 通过日志推后内存数据结构落地 落地时候的两次写 一致性储存方式储存方式- -可以可以选择选择TabletTabletleveldbleveldb带来的新方法带来的新方法 Tablet的继承了传统储存的结构的三个特征 主要的创新在于SSTable这个结构是天然支持分布的重说重说cap理论理论 为什么大多数KV数据库都选择最终一致性并且不支持事务 消除高端硬件之后，容错性上升为软件的职责 保证强一致性系统的容错性。 可以证明强一致性和容错性矛盾吗？ Oracle新推的NoSQL数据支持事务，牺牲了容错性 Consistency,

11、Availability, Partition-tolerance复杂的复杂的分布式事务分布式事务 假设可以设计可靠的储存组件，在分布式事务中如何实现事务 分布式事务实现的几个话题：提交完整性，控制器故障处理，节点故障处理机制，节点同步的时间开销控制，大数据传输的网络开销一致性和事务一致性和事务 本身就是矛盾，设想一下什么是最终一致性的事务。 限制读取，增加控制器的负载。 分布式的控制器,要选择paxos？ 事务最理想的情况就是同时保证一致性和容错性 最终一致性的事务知否就只能是传统数据库的读写分离模式典型典型KV数据库构架数据库构架ClientABCDEDataServerControlServerMaster1Master2Master3DataServer的结构Request Plug-insMdbFdbBdbRequestResponseDataServerStorage EngineResponse Plug-insMigrateReplicatorControlServer的结构PaxosRequestDataServerMetaDataDataServerMetaDataDataServerMetaData可行性与前期实验结可行性与前期实验结果果 储存系统瓶颈是网络储存系统瓶颈是网络 实验： 在Mongodb上的测试的分片存储数据 结论： 分片对存取性能