文档介绍：该【云计算存储类型总结(DOC) 】是由【HShess】上传分享，文档一共【11】页，该文档可以免费在线阅读，需要了解更多关于【云计算存储类型总结(DOC) 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。云计算存储类型总结(DOC)块存储单机块存储首先,一个硬盘是一个块设备。内核检测到硬盘后,在/dev/下会看到/dev/sda/。为了用一个硬盘来得到不同的分区来做不同的事,我们使用fdisk工具得到/dev/sda1、/dev/sda2等。这种方式通过直接写入分区表来规定和切分硬盘,是最死板的分区方式。&Device-mapperLVM是一种逻辑卷管理器。通过LVM来对硬盘创建逻辑卷组和得到逻辑卷,要比fdisk方式更加弹性。&iSCSI在接触了单机下的逻辑卷管理后,你需要了解SAN,目前主流的企业级存储方式。大部分SAN使用SCSI协议在服务器和存储设备之间传输和沟通,通过在SCSI之上建立不同镜像层,可以实现存储网络的连接。常见的有iSCSI,FCP,等。SAN通常需要在专用存储设备中建立,而iSCSI是基于TCP/IP的SCSI映射,通过iSCSI协议和LinuxiSCSI项目,我们可以在常见的PC机上建立SAN存储。分布式块存储在面对极具弹性的存储需求和性能要求下,单机或者独立的SAN越来越不能满足企业的需要。如同数据库系统一样,块存储在scaleup的瓶颈下也面临着scaleout的需要。我们可以用以下几个特点来描述分布式块存储系统的概念:分布式块存储可以为任何物理机或者虚拟机提供持久化的块存储设备分布式块存储系统管理块设备的创建、删除和attach/detach分布式块存储支持强大的快照功能,快照可以用来恢复或者创建新的块设备分布式存储系统能够提供不同IO性能要求的块设备可扩展性较差不同的分布式文件系统会对存储的文件有一定的倾向性。常见的分布式文件系统有,GFS、HDFS、Lustre、Ceph、GridFS、mogileFS、TFS、FastDFS等。各自适用于不同的领域。对象存储,就是每个数据对应着一个唯一的id,在面向对象存储中,不再有类似文件系统的目录层级结构,完全扁平化存储,即可以根据对象的id直接定位到数据的位置,这一点类似SAN,而每个数据对象即包含元数据又包括存储数据,含有文件的概念,这一点类似NAS。除此之外,用户不必关系数据对象的安全性,数据恢复,自动负载平衡等等问题,这些均由对象存储系统自身完成。而且,面向对象存储还解决了SAN面临的有限扩充和NAS传输性能开销大问题,能够实现海量数据存储。日志详单存储特定环境的存储机制;***私有云规范:结构化数据库与文件系统向结合;NoSQL存储传统“关系型数据库”,。主要需要应对以下三方面难题:1、对数据库高并发读写的要求。2、对数据库高可扩展性和高可用性的要求。3、对海量数据高效存储和访问的要求。NoSQL数据库的类型一、键值(Key-Value)数据库键值数据库就像在传统语言中使用的哈希表。你可以通过key来添加、查询或者删除数据,鉴于使用主键访问,所以会获得不错的性能及扩展性。适用的场景储存用户信息,比如会话、配置文件、参数、购物车等等。这些信息一般都和ID(键)挂钩,这种情景下键值数据库是个很好的选择。不适用场景 ,而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。 。在Key-Value数据库中不能通过两个或以上的键来关联数据。 。在Key-Value数据库中故障产生时不可以进行回滚。二、面向文档(Document-Oriented)数据库面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元,是一系列数据项的集合。每个数据项都有一个名称与对应的值,值既可以是简单的数据类型,如字符串、数字和日期等;也可以是复杂的类型,如有序列表和关联对象。数据存储的最小单位是文档,同一个表中存储的文档属性可以是不同的,数据可以使用XML、JSON或者JSONB等多种形式存储。。企业环境下,每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式,所以我们可以使用它储存不同的信息。。鉴于它的弱模式结构,不改变模式下就可以储存不同的度量方法及添加新的度量。当下已经存在很多的NoSQL数据库,比如MongoDB、Redis、Riak、HBase、Cassandra等等。每一个都拥有以下几个特性中的一个:不再使用SQL语言,比如MongoDB、Cassandra就有自己的查询语言通常是开源项目为集群运行而生弱结构化——不会严格的限制数据结构类型不适用场景在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务,如果对这方面有需求则不应该选用这个解决方案。三、列存储(WideColumnStore/Column-Family)数据库列存储数据库将数据储存在列族(columnfamily)中,一个列族存储经常被一起查询的相关数据。举个例子,如果我们有一个Person类,我们通常会一起查询他们的姓名和年龄而不是薪资。。因为我们可以将数据储存在不同的列中,每个应用程序可以将信息写入自己的列族中。。我们储存每个信息到不同的列族中。举个例子,标签可以储存在一个,类别可以在一个,而文章则在另一个。。Vassandra就不支持事务。。如果我们分析Cassandra的数据结构,我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初,我们根本不可能去预测它的查询方式,而一旦查询方式改变,我们就必须重新设计列族。四、图(Graph-Oriented)数据库图数据库允许我们将数据以图的方式储存。实体会被作为顶点,而实体之间的关系则会被作为边。比如我们有三个实体,SteveJobs、Apple和Next,则会有两个“Foundedby”的边将Apple和Next连接到SteveJobs。。如果我们将数据以图的形式表现,那么将会非常有益于推荐的制定不适用场景不适合的数据模型。图数据库的适用范围很小,因为很少有操作涉及到整个图。文档数据库源起:受LotusNotes启发。数据模型:包含了key-value的文档集合例子:CouchDB,MongoDB优点:数据模型自然,编程友好,快速开发,web友好,CRUD。图数据库源起:欧拉和图理论。数据模型:节点和关系,也可处理键值对。例子:AllegroGraph,InfoGrid,Neo4j优点:解决复杂的图问题。关系数据库源起:?:各种关系例子:VoltDB,?Clustrix,MySQL优点:高性能、可扩展的OLTP,支持SQL,物化视图,支持事务,编程友好。对象数据库源起:图数据库研究数据模型:对象例子:Objectivity,Gemstone优点:复杂对象模型,快速键值访问,键功能访问,以及图数据库的优点。Key-Value数据库源起:Amazon的论文?Dynamo?和?DistributedHashTables。数据模型:键值对例子:Membase,Riak优点:处理大量数据,快速处理大量读写请求。编程友好。BigTable类型数据库源起:Google的论文?BigTable。数据模型:列簇,每一行在理论上都是不同的例子:HBase,Hypertable,Cassandra优点:处理大量数据,应对极高写负载,高可用,支持跨数据中心,MapReduce。数据结构服务源起:??数据模型:字典操作,lists,sets和字符串值例子:Redis优点:不同于以前的任何数据库网格数据库源起:数据网格和元组空间研究。数据模型:基于空间的架构例子:GigaSpaces,Coherence优点:适于事务处理的高性能和高扩展性你的应用应该用什么?关键是要意识到不同的应用需要不同的数据模型和产品。选择合适的数据模型和产品。要了解你的应用需要什么样的数据模型可以看?WhatTheHeckAreYouActuallyUsingNoSQLFor??在这篇文章里我总结了一些特色各异的非常规的使用场景。适应你的需求和应用场景。依次而为你就能找到最适合你的架构的产品。无论NoSQL还是SQL都不重要。综合考虑数据模型、产品特性和应用情景。不同产品功能各异,只凭数据模型来决定选择谁是不可能的。哪个产品具有你最需要的特点哪个就是最好的。假如你的应用有以下需求:复杂事物,如果你不能承受数据丢失的风险或者你想要一个简单的事务编程模型可以选择关系数据库和网格数据库。例子:一个库存系统需要完整的ACID特性。如果我在买了一个东西后才被告知它已经售罄我会非常不快。不不想要补偿,我只要我买的东西。扩展性,NoSQL或SQL皆可,目标产品要支持水平扩展、分区、在线增减硬件、负载均衡、自动分片、数据平衡和容错等特性。追求高可用性,可用Bigtable类型的等支持最终一致性的数据库。需要处理长期的快速读写,可以看看文档数据库,Key-value数据库或者内存数据库,还可以考虑SSD。要实现社会化网络,第一选择应该是图数据库。其次像Riak这样支持关系的数据库也可以。一个支持简单SQLjoin操作的内存关系数据库能够处理数据量不大的情况。Redis’?set和list操作就是这样。假如你的应用有以下需求:需要不同的访问方式和数据类型的话可以看看文档数据库,它们在这方面很灵活。大数据量的离线分析首先应该考虑Hadoop,其次是其他支持MapReduce的产品。当然,支持MapReduce与擅长MapReduce处理不是一回事。如需跨越多个数据中心,可选用基于Bigtable模型的产品,或其分布式的,能解决延迟问题,分区容错性问题的产品CRUD类型的应用可以考虑文档数据库,这样不需要join就可访问复杂的数据结构。搜索可以考虑Riak。需要lists,sets,queues,publish-subscribe等数据结构的话,可以考虑Redis,它的分布式锁等特性也非常有用。编程友好,如果要使用JSON,HTTP,REST,Javascript等程序员喜闻乐见的数据类型,第一选择就是文档数据库和Key-value数据库。假如你的应用有以下需求:用于实时事务处理的物化视图,可以考虑VoltDB,非常适合于快速处理大量事务。企业级支持及服务级协议?,可以寻找市场上以此为卖点的产品,如Membase。要记录连续的大量数据,又对一致性无太高要求,可以看看Bigtable类型数据库,因为它工作在分布式文件系统上,可以处理大规模的写入请求。需要尽可能使用简单,请考虑PAAS方案,用这种方案你自己几乎不需要做什么。如果你的产品要卖给企业客户请考虑关系数据库,因为他们****惯于关系数据库。要动态构建对象间的关系,对象的属性能够动态加减,可以考虑图数据库,因为它不需要schema,可以在代码中随需建模。要支持大影音文件,可以看看像S3这样的存储服务。NoSQL不适于存储BLOBS,尽管MongoDB也提供了文件服务。假如你的应用有以下需求:要快速批量上传大量数据,得寻找支持这种场景的产品。但是大多数产品都不支持批量操作。易于变化,要选择支持动态schema的文档数据库和?Key-value数据库。它支持可选域,不需要修改schema即可增加、减少域。为了支持完整性约束,选择支持SQLDDL的数据库,可以在存储过程或者应用代码中实现。深度连接用图数据库,它支持实体键间的快速定位。为了让计算靠近数据,减少数据在网络中传送的开销,可以考虑存储过程。关系数据库,网个数据库,文档数据库和Key-value数据库都支持存储过程。假如你的应用有以下需求:要存储BLOB数据,可选择Key-value数据库。它可以存储网页或者复杂对象,后者在关系数据库中要用join才能获取,代价高昂。还可以降低延迟。选择一个经过验证的成熟产品,在处理扩展性问题的时候的时候选择通用的方案(纵向扩展、调优、缓存、数据分片、反范式等等)多变的数据类型,数据不规整,列数不固定,复杂的数据结构等,考虑文档数据库,Key-value数据库,和Bigtable型数据库。它们的数据类型都比较灵活。需要快速的关系查询,但是又不想自己实现,那么就选择支持SQL的数据库。能够在云中操作,自动利用云的一切特性和好处,目前还没有这样的东西。假如你的应用有以下需求:支持二级索引,通过不同的键来检索,可以考虑关系数据库和?Cassandra,后者新增了对二级索引的支持。规模不断增长(真正的大数据场景),但是访问不频繁的数据可以使用Bigtable类型的数据库,因为它的数据存储在一个分布式文件系统上,很容易扩展。要和其他服务集成,检查数据库是否提供某种写后同步功能,以便能够捕捉到数据库变化,通知其它系统,保证一致性。容错性,检查在停电、分区故障以及其他故障场景下写操作是否能够成功。