云计算存储类型总结(DOC)

块存
储
单机块存储
首先，一个硬盘是一个块设备。

内核检测到硬盘后，在/dev/下会看到
/dev/sda/。

为了用一个硬盘来得到不同的分区来做不同的事，我们使用fdisk
工具得到/dev/sda1、/dev/sda2等。

这种方式通过直接写入分区表来规定和
切分硬盘，是最死板的分区方式。

1. LVM & Device-mapper
LVM是一种逻辑卷管理器。

通过LVM来对硬盘创建逻辑卷组和得到逻辑卷，要
比fdisk方式更加弹性。

2. SAN & iSCSI
在接触了单机下的逻辑卷管理后，你需要了解SAN，目前主流的企业级存储方
式。

大部分SAN使用SCSI协议在服务器和存储设备之间传输和沟通，通过在SCSI
之上建立不同镜像层，可以实现存储网络的连接。

常见的有iSCSI，FCP，Fibre
Channel over Ethernet等。

SAN通常需要在专用存储设备中建立，而iSCSI是基于TCP/IP的SCSI映射，
通过iSCSI协议和Linux iSCSI项目，我们可以在常见的PC机上建立SAN存
储。

分布式块存储
在面对极具弹性的存储需求和性能要求下，单机或者独立的SAN越来越不能
满足企业的需要。

如同数据库系统一样，块存储在scale up的瓶颈下也面临
着scale out的需要。

我们可以用以下几个特点来描述分布式块存储系统的
概念：
1.分布式块存储可以为任何物理机或者虚拟机提供持久化的块存储设
备
2.分布式块存储系统管理块设备的创建、删除和attach/detach
3.分布式块存储支持强大的快照功能，快照可以用来恢复或者创建新
的块设备
4.分布式存储系统能够提供不同IO性能要求的块设备
可扩展性较差
文件存储随着互联网企业的高速发展，这些企业对数据存储的要求越来越高，而且模
式各异，如淘宝主站的大量商品图片，其特点是文件较小，但数量巨大；而
类似于youtube，优酷这样的视频服务网站，其后台存储着大量的视频文件，
不同的分布式文
件系统会对存储
的文件有一定的
尺寸大多在数十兆到数吉字节不等。

这些应用场景都是传统文件系统不能解决的。

分布式文件系统将数据存储在物理上分散的多个存储节点上，对这些节点的资源进行统一的管理与分配，并向用户提供文件系统访问接口，其主要解决了本地文件系统在文件大小、文件数量、打开文件数等的限制问题。

倾向性。

常见的分布式文件系统有，GFS、HDFS、Lustre 、Ceph 、GridFS 、mogileFS、TFS、FastDFS等。

各自适用于不同的领域。

对象存储
SNIA（网络存储工业协会）定义的对象存储设备是这样的：
一种“新的”SCSI存储设备；对象是自完备的，包含元数据、数据和属性；
存储设备可以自行决定对象的具体存储位置和数据的分布；存储设备可以对
不同的对象提供不同的QoS
对象存储设备相对于块设备有更高的“智能”，上层通过对象ID来访问对象，
而不了解对象的具体空间分布情况。

对象是智能化、封装得更好的块，是“文件”或其他应用级逻辑结构的组成
部分，当然，用一个对象存储一个文件也是有可能的，这是上层的事情，至
于上层究竟是个文件系统（如EXOFS）还是让应用直接访问对象存储设备就无
关紧要了。

而对象存储设备本身也有可能是个分布式的系统——这就是分布
式对象存储系统了，强调的依然是这个封装的概念。

对象本身是平等的，也就是说，对象分布在一个平坦的空间中，而非文件系
统那样的树状逻辑结构（Namespace）之中，这也就给了我们很大的灵活性——
如果需要，可以利用对象构建一个文件系统，因为对象本身包含了元数据信
息了，甚至包含了更多的属性，因此，文件系统本身的设计就相对简单了；
如果不需要，可以直接用平坦的空间，对于海量文件系统来说，似乎没有这
个必要；也可以用一部分对象构建一个树状文件系统，甚至可以为同一个对
象存储系统组织成不同的树状文件系统结构。

用对象替代传统的块的好处在于对象的内容本身来自应用，其具有内在的联
系，具有“原子性”，因此可以做到：
在存储层进行更智能的空间管理
内容相关的数据预取和缓存
可靠的多用户共享访问
对象级别的安全性
同时，对象存储架构还具有更好的可伸缩性。

一个对象除了ID和用户数据外，还包含了属主、时间、尺寸、位置等源数据
信息，权限等预定义属性，乃至很多自定义属性，对象存储设备中的对象分
成了四类：
用户对象：应用创建的普通对象
集合对象：一组具有共同点的用户对象的集合——比如一组mp3等
分区对象：容纳用户对象和集合对象的容器，包含了有某些空间管
理、安全等方面（比如quota）的共性的对象。

根对象：对象存储设备自己
对象存储，就是
每个数据对应着
一个唯一的id，
在面向对象存储
中，不再有类似
文件系统的目录
层级结构，完全
扁平化存储，即
可以根据对象的
id直接定位到数
据的位置，这一
点类似SAN，而每
个数据对象即包
含元数据又包括
存储数据，含有
文件的概念，这
一点类似NAS。

除
此之外，用户不
必关系数据对象
的安全性，数据
恢复，自动负载
平衡等等问题，
这些均由对象存
储系统自身完
成。

而且，面向
对象存储还解决
了SAN面临的有
限扩充和NAS传
输性能开销大问
题，能够实现海
量数据存储。

日志详单存储特定环境的存储机制；
中国移动私有云规范：结构化数据库与文件系统向结合；
NoSQL 存储传统“关系型数据库”在应付互联网WEB2.0应用已显示的力不从心，由其是
超大规模和高并发的SNS类型的WEB2.0网站。

主要需要应对以下三方面难题：
1、对数据库高并发读写的要求。

2、对数据库高可扩展性和高可用性的要求。

3、对海量数据高效存储和访问的要求。

NoSQL数据库的类型
一、键值（Key-Value）数据库
键值数据库就像在传统语言中使用的哈希表。

你可以通过key来添加、查询
或者删除数据，鉴于使用主键访问，所以会获得不错的性能及扩展性。

适用的场景
储存用户信息，比如会话、配置文件、参数、购物车等等。

这些信息一般都
和ID（键）挂钩，这种情景下键值数据库是个很好的选择。

不适用场景
1. 取代通过键查询，而是通过值来查询。

Key-Value数据库中根本没有通
过值查询的途径。

2. 需要储存数据之间的关系。

在Key-Value数据库中不能通过两个或以上
的键来关联数据。

3. 事务的支持。

在Key-Value数据库中故障产生时不可以进行回滚。

二、面向文档（Document-Oriented）数据库
面向文档数据库会将数据以文档的形式储存。

每个文档都是自包含的数据单
元，是一系列数据项的集合。

每个数据项都有一个名称与对应的值，值既可
以是简单的数据类型，如字符串、数字和日期等；也可以是复杂的类型，如
有序列表和关联对象。

数据存储的最小单位是文档，同一个表中存储的文档
属性可以是不同的，数据可以使用XML、JSON或者JSONB等多种形式存储。

适用的场景
1. 日志。

企业环境下，每个应用程序都有不同的日志信息。

Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同
的信息。

当下已经存在很
多的NoSQL数据
库，比如
MongoDB、Redis、
Riak、HBase、
Cassandra等等。

每一个都拥有以
下几个特性中的
一个：
不再使用SQL语
言，比如
MongoDB、
Cassandra就有
自己的查询语言
通常是开源项目
为集群运行而生
弱结构化——不
会严格的限制数
据结构类型
2. 分析。

鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及
添加新的度量。

不适用场景
在不同的文档上添加事务。

Document-Oriented数据库并不支持文档间的事
务，如果对这方面有需求则不应该选用这个解决方案。

三、列存储（Wide Column Store/Column-Family）数据库
列存储数据库将数据储存在列族（column family）中，一个列族存储经常被
一起查询的相关数据。

举个例子，如果我们有一个Person类，我们通常会一
起查询他们的姓名和年龄而不是薪资。

这种情况下适用的场景
1. 日志。

因为我们可以将数据储存在不同的列中，每个应用程序可以将信息
写入自己的列族中。

2. 博客平台。

我们储存每个信息到不同的列族中。

举个例子，标签可以储存
在一个，类别可以在一个，而文章则在另一个。

不适用场景
1. 如果我们需要ACID事务。

Vassandra就不支持事务。

2. 原型设计。

如果我们分析Cassandra的数据结构，我们就会发现结构是基
于我们期望的数据查询方式而定。

在模型设计之初，我们根本不可能去预测
它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。

四、图（Graph-Oriented）数据库
图数据库允许我们将数据以图的方式储存。

实体会被作为顶点，而实体之间
的关系则会被作为边。

比如我们有三个实体，Steve Jobs、Apple和Next，
则会有两个“Founded by”的边将Apple和Next连接到Steve Jobs。

适用的场景
1. 在一些关系性强的数据中
2. 推荐引擎。

如果我们将数据以图的形式表现，那么将会非常有益于推荐的
制定
不适用场景
不适合的数据模型。

图数据库的适用范围很小，因为很少有操作涉及到整个
图。

文档数据库
源起：受Lotus Notes启发。

∙数据模型：包含了key-value的文档集合
∙例子：CouchDB, MongoDB
∙优点：数据模型自然，编程友好，快速开发，web友好，CRUD。

图数据库
∙源起：欧拉和图理论。

∙数据模型：节点和关系，也可处理键值对。

∙例子：AllegroGraph, InfoGrid, Neo4j
∙优点：解决复杂的图问题。

关系数据库
∙源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的∙数据模型：各种关系
∙例子：VoltDB, Clustrix, MySQL
∙优点：高性能、可扩展的OLTP，支持SQL，物化视图，支持事务，编程友好。

对象数据库
∙源起：图数据库研究
∙数据模型：对象
∙例子：Objectivity, Gemstone
∙优点：复杂对象模型，快速键值访问，键功能访问，以及图数据库的优点。

Key-Value数据库
∙源起：Amazon的论文Dynamo和Distributed HashTables。

∙数据模型：键值对
∙例子：Membase, Riak
∙优点：处理大量数据，快速处理大量读写请求。

编程友好。

BigTable类型数据库
∙源起：Google的论文BigTable。

∙数据模型：列簇，每一行在理论上都是不同的
∙例子：HBase, Hypertable, Cassandra
∙优点：处理大量数据，应对极高写负载，高可用，支持跨数据中心， MapReduce。

数据结构服务
∙源起：?
∙数据模型：字典操作，lists, sets和字符串值
∙例子：Redis
∙优点：不同于以前的任何数据库
网格数据库
∙源起：数据网格和元组空间研究。

∙数据模型：基于空间的架构
∙例子：GigaSpaces, Coherence
∙优点：适于事务处理的高性能和高扩展性
你的应用应该用什么?
∙关键是要意识到不同的应用需要不同的数据模型和产品。

选择合适的数据模型和产品。

∙要了解你的应用需要什么样的数据模型可以看What The Heck Are You Actually Using NoSQL For?在这篇文章里我总结了一些特色各异的非常规的使用场景。

∙适应你的需求和应用场景。

依次而为你就能找到最适合你的架构的产品。

无论NoSQL还是SQL都不重要。

∙综合考虑数据模型、产品特性和应用情景。

不同产品功能各异，只凭数据模型来决定选择谁是不可能的。

∙哪个产品具有你最需要的特点哪个就是最好的。

假如你的应用有以下需求：
∙复杂事物，如果你不能承受数据丢失的风险或者你想要一个简单的事务编程模型可以选择关系数据库和网格数据库。

∙例子：一个库存系统需要完整的ACID特性。

如果我在买了一个东西后才被告知它已经售罄我会非常不快。

不不想要补偿，我只要我买的东西。

∙扩展性，NoSQL或SQL皆可，目标产品要支持水平扩展、分区、在线增减硬件、负载均衡、自动分片、数据平衡和容错等特性。

∙追求高可用性，可用Bigtable类型的等支持最终一致性的数据库。

∙需要处理长期的快速读写，可以看看文档数据库，Key-value数据库或者内存数据库，还可以考虑SSD。

∙要实现社会化网络，第一选择应该是图数据库。

其次像Riak这样支持关系的数据库也可以。

一个支持简单SQL join操作的内存关系数据库能够处理数据量不大的情况。

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即可增加、减少域。

∙为了支持完整性约束，选择支持SQL DDL的数据库，可以在存储过程或者应用代码中实现。

∙深度连接用图数据库，它支持实体键间的快速定位。

∙为了让计算靠近数据，减少数据在网络中传送的开销，可以考虑存储过程。

关系数据库，网个数据库，文档数据库和Key-value数据库都支持存储过程。

假如你的应用有以下需求：
∙要存储BLOB数据，可选择Key-value数据库。

它可以存储网页或者复杂对象，后者在关系数据库中要用join才能获取，代价高昂。

还可以降低延迟。

∙选择一个经过验证的成熟产品，在处理扩展性问题的时候的时候选择通用的方案（纵向扩展、调优、缓存、数据分片、反范式等等）
∙多变的数据类型，数据不规整，列数不固定，复杂的数据结构等，考虑文档数据库，Key-value 数据库，和Bigtable型数据库。

它们的数据类型都比较灵活。

∙需要快速的关系查询，但是又不想自己实现，那么就选择支持SQL的数据库。

∙能够在云中操作，自动利用云的一切特性和好处，目前还没有这样的东西。

假如你的应用有以下需求：
∙支持二级索引，通过不同的键来检索，可以考虑关系数据库和Cassandra，后者新增了对二级索引的支持。

∙规模不断增长（真正的大数据场景），但是访问不频繁的数据可以使用Bigtable类型的数据库，因为它的数据存储在一个分布式文件系统上，很容易扩展。

∙要和其他服务集成，检查数据库是否提供某种写后同步功能，以便能够捕捉到数据库变化，通知其它系统，保证一致性。

∙容错性，检查在停电、分区故障以及其他故障场景下写操作是否能够成功。

∙如果只是为了推动某个方向上的技术创新，似乎没有现成的东西能够达到这个目的，你得自己去创造一个新的。

这可不是件容易事。

移动平台上可以用CouchDB/Mobile couchbase.。