云计算存储类型总结

SAN通常需要在专用存储设备中建立，而 iSCSI是基于TCP/IP的SCSI映射，通过 iSCSI协议和Linux iSCSI项目，我们可以 在常见的PC机上建立SAN存储。
分布式块存储 在面对极具弹性的存储需求和性能要求 下，单机或者独立的SAN越来越不能满足 企业的需要。如同数据库系统一样，块存 储在scale up的瓶颈下也面临着scale out的需要。我们可以用以下几个特点来 描述分布式块存储系统的概念：
当下已经存 在很多的 NoSQL数据 库，比如 MongoDB、 Redis、 Riak、 HBase、 Cassandra 等等。每一 个都拥有以 下几个特性 中的一个： 不再使用 SQL语言， 比如 MongoDB、 Cassandra 就有自己的 查询语言 通常是开源
不适用场景 1. 取代通过键查询，而是通过值来查 询。Key-Value数据库中根本没有通过值 查询的途径。 2. 需要储存数据之间的关系。在KeyValue数据库中不能通过两个或以上的键 来关联数据。 3. 事务的支持。在Key-Value数据库中 故障产生时不可以进行回滚。 二、 面向文档（Document-Oriented）数 据库 面向文档数据库会将数据以文档的形式储 存。每个文档都是自包含的数据单元，是 一系列数据项的集合。每个数据项都有一 个名称与对应的值，值既可以是简单的数 据类型，如字符串、数字和日期等；也可 以是复杂的类型，如有序列表和关联对 象。数据存储的最小单位是文档，同一个 表中存储的文档属性可以是不同的，数据 可以使用XML、JSON或者JSONB等多种形式 存储。 适用的场景 1. 日志。企业环境下，每个应用程序都 有不同的日志信息。Document-Oriented 数据库并没有固定的模式，所以我们可以 使用它储存不同的信息。 2. 分析。鉴于它的弱模式结构，不改变 模式下就可以储存不同的度量方法及添加 新的度量。 不适用场景 在不同的文档上添加事务。DocumentOriented数据库并不支持文档间的事务， 如果对这方面有需求则不应该选用这个解 决方案。 三、 列存储（Wide Column Store/Column-Family）数据库 列存储数据库将数据储存在列族（column
你的应用应该用什么? 关键是要意识到不同的应用需要不同的数据模型和产品。选 择合适的数据模型和产品。 要了解你的应用需要什么样的数据模型可以看 What The Heck Are You Actually Using NoSQL For? 在这篇文章里我 总结了一些特色各异的非常规的使用场景。 适应你的需求和应用场景。依次而为你就能找到最适合你的 架构的产品。无论NoSQL还是SQL都不重要。 综合考虑数据模型、产品特性和应用情景。不同产品功能各 异，只凭数据模型来决定选择谁是不可能的。 哪个产品具有你最需要的特点哪个就是最好的。
文档数据库 源起：受Lotus Notes启发。 数据模型：包含了key-value的文档集合 例子：CouchDB, MongoDB 优点：数据模型自然，编程友好，快速开发，web友好， CRUD。
图数据库 源起： 欧拉和图理论。 数据模型：节点和关系，也可处理键值对。 例子：AllegroGraph, InfoGrid, Neo4j 优点：解决复杂的图问题。
日志 特定环境的存储机制； 详单 中国移动私有云规范：结构化数据库与文 存储 件系统向结合；
NoSQL 传统“关系型数据库”在应付互联网 存储 WEB2.0应用已显示的力不从心，由其是超
大规模和高并发的SNS类型的WEB2.0网 站。 主要需要应对以下三方面难题： 1、对数据库高并发读写的要求。 2、对数据库高可扩展性和高可用性的要 求。 3、对海量数据高效存储和访问的要求。
对象是智能化、封装得更好的块，是“文 件”或其他应用级逻辑结构的组成部分， 当然，用一个对象存储一个文件也是有可 能的，这是上层的事情，至于上层究竟是 个文件系统（如EXOFS）还是让应用直接 访问对象存储设备就无关紧要了。而对象 存储设备本身也有可能是个分布式的系统 ——这就是分布式对象存储系统了，强调 的依然是这个封装的概念。 对象本身是平等的，也就是说，对象分布 在一个平坦的空间中，而非文件系统那样 的树状逻辑结构（Namespace）之中，这 也就给了我们很大的灵活性——如果需 要，可以利用对象构建一个文件系统，因 为对象本身包含了元数据信息了，甚至包 含了更多的属性，因此，文件系统本身的 设计就相对简单了；如果不需要，可以直 接用平坦的空间，对于海量文件系统来 说，似乎没有这个必要；也可以用一部分 对象构建一个树状文件系统，甚至可以为 同一个对象存储系统组织成不同的树状文 件系统结构。 用对象替代传统的块的好处在于对象的内 容本身来自应用，其具有内在的联系，具 有“原子性”，因此可以做到：
权限等预定义属性，乃至很多自定义属 性，对象存储设备中的对象分成了四类：
用户对象：应用创建的普通对象
集合对象：一组具有共同点的用户对 象的集合——比如一组mp3等 分区对象：容纳用户对象和集合对象 的容器，包含了有某些空间管理、安 全等方面（比如quota）的共性的对 象。
根对象：对象存储设备自己
关系数据库 源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的 数据模型：各种关系 例子：VoltDB, Clustrix, MySQL 优点：高性能、可扩展的OLTP，支持SQL，物化视图，支持事 务，编程友好。
NoSQL数据库的类型 一、 键值（Key-Value）数据库 键值数据库就像在传统语言中使用的哈希 表。你可以通过key来添加、查询或者删 除数据，鉴于使用主键访问，所以会获得 不错的性能及扩展性。 适用的场景 储存用户信息，比如会话、配置文件、参 数、购物车等等。这些信息一般都和 ID（键）挂钩，这种情景下键值数据库是 个很好的选择。
就是每个数
一种“新的”SCSI存储设备；对象是自完 据对应着一
备的，包含元数据、数据和属性 ；存储 个唯一的
设备可以自行决定对象的具体存储位置和 id，在面向
数据的分布；存储设备可以对不同的对象 对象存储
提供不同的QoS
中，不再有
对象存储设备相对于块设备Байду номын сангаас更高的“智 能”，上层通过对象ID来访问对象，而不 了解对象的具体空间分布情况。
在存储层进行更智能的空间管理 内容相关的数据预取和缓存
可靠的多用户共享访问 对象级别的安全性
同时，对象存储架构还具有更好的可伸缩 性。 一个对象除了ID和用户数据外，还包含了 属主、时间、尺寸、位置等源数据信息，
类似文件系 统的目录层 级结构，完 全扁平化存 储，即可以 根据对象的 id直接定位 到数据的位 置，这一点 类似SAN， 而每个数据 对象即包含 元数据又包 括存储数 据，含有文 件的概念， 这一点类似 NAS。除此 之外，用户 不必关系数 据对象的安 全性，数据 恢复，自动 负载平衡等 等问题，这 些均由对象 存储系统自 身完成。而 且，面向对 象存储还解 决了SAN面 临的有限扩 充和NAS传 输性能开销 大问题，能 够实现海量 数据存储。
1. 分布式块存储可以为任何物理 机或者虚拟机提供持久化的块 存储设备
2. 分布式块存储系统管理块设备 的创建、删除和attach/detach
3. 分布式块存储支持强大的快照 功能，快照可以用来恢复或者 创建新的块设备
4. 分布式存储系统能够提供不同 IO性能要求的块设备
文件 存储
对象 存储
随着互联网企业的高速发展，这些企业对 数据存储的要求越来越高，而且模式各 异，如淘宝主站的大量商品图片，其特点 是文件较小，但数量巨大；而类似于 youtube，优酷这样的视频服务网站，其 后台存储着大量的视频文件，尺寸大多在 数十兆到数吉字节不等。这些应用场景都 是传统文件系统不能解决的。分布式文件 系统将数据存储在物理上分散的多个存储 节点上，对这些节点的资源进行统一的管 理与分配，并向用户提供文件系统访问接 口，其主要解决了本地文件系统在文件大 小、文件数量、打开文件数等的限制问 题。
优点：处理大量数据，快速处理大量读写请求。编程友好。 BigTable类型数据库
源起：Google的论文 BigTable。 数据模型：列簇，每一行在理论上都是不同的 例子：HBase, Hypertable, Cassandra 优点：处理大量数据，应对极高写负载，高可用，支持跨数 据中心， MapReduce。 数据结构服务 源起： ? 数据模型：字典操作，lists, sets和字符串值 例子：Redis 优点：不同于以前的任何数据库 网格数据库 源起：数据网格和元组空间研究。 数据模型：基于空间的架构 例子：GigaSpaces, Coherence 优点：适于事务处理的高性能和高扩展性
不同的分布 式文件系统 会对存储的 文件有一定 的倾向性。 常见的分布 式文件系统 有，GFS、 HDFS、 Lustre 、 Ceph 、 GridFS 、 mogileFS、 TFS、 FastDFS 等。各自适 用于不同的 领域。
SNIA（网络存储工业协会）定义的对象存 对象存储，
储设备是这样的：
LVM是一种逻辑卷管理器。通过LVM来对硬
盘创建逻辑卷组和得到逻辑卷，要比
fdisk方式更加弹性。
2. SAN & iSCSI
在接触了单机下的逻辑卷管理后，你需要 了解SAN，目前主流的企业级存储方式。
大部分SAN使用SCSI协议在服务器和存储 设备之间传输和沟通，通过在SCSI之上建 立不同镜像层，可以实现存储网络的连 接。常见的有iSCSI，FCP，Fibre Channel over Ethernet等。
块存 单机块存储
可扩展性较
储 首先，一个硬盘是一个块设备。内核检测 差
到硬盘后，在/dev/下会看到/dev/sda/。
为了用一个硬盘来得到不同的分区来做不
同的事，我们使用fdisk工具得
到/dev/sda1、/dev/sda2等。这种方式通
过直接写入分区表来规定和切分硬盘，是
最死板的分区方式。
1. LVM & Device-mapper
对象数据库 源起：图数据库研究 数据模型：对象 例子：Objectivity, Gemstone 优点：复杂对象模型，快速键值访问，键功能访问，以及图 数据库的优点。
Key-Value数据库 源起：Amazon的论文 Dynamo 和 Distributed HashTables。 数据模型：键值对 例子：Membase, Riak
项目 为集群运行 而生 弱结构化 ——不会严 格的限制数 据结构类型
family）中，一个列族存储经常被一起查 询的相关数据。举个例子，如果我们有一 个Person类，我们通常会一起查询他们的 姓名和年龄而不是薪资。这种情况下适用 的场景 1. 日志。因为我们可以将数据储存在不 同的列中，每个应用程序可以将信息写入 自己的列族中。 2. 博客平台。我们储存每个信息到不同 的列族中。举个例子，标签可以储存在一 个，类别可以在一个，而文章则在另一 个。 不适用场景 1. 如果我们需要ACID事务。Vassandra就 不支持事务。 2. 原型设计。如果我们分析Cassandra的 数据结构，我们就会发现结构是基于我们 期望的数据查询方式而定。在模型设计之 初，我们根本不可能去预测它的查询方 式，而一旦查询方式改变，我们就必须重 新设计列族。 四、 图（Graph-Oriented）数据库 图数据库允许我们将数据以图的方式储 存。实体会被作为顶点，而实体之间的关 系则会被作为边。比如我们有三个实体， Steve Jobs、Apple和Next，则会有两 个“Founded by”的边将Apple和Next连 接到Steve Jobs。 适用的场景 1. 在一些关系性强的数据中 2. 推荐引擎。如果我们将数据以图的形 式表现，那么将会非常有益于推荐的制定 不适用场景 不适合的数据模型。图数据库的适用范围 很小，因为很少有操作涉及到整个图。