云计算存储类型总结.docx

云计算存储类型总结.docx

《云计算存储类型总结.docx》由会员分享，可在线阅读，更多相关《云计算存储类型总结.docx（12页珍藏版）》请在冰豆网上搜索。

云计算存储类型总结

云计算存储类型总结

LT

日志详单存储

特定环境的存储机制；

中国移动私有云规范：

结构化数据库与文件系统向结合；

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数据库并没有固定的模式，所以我们可以使用它储存不同的信息。

2.分析。

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

不适用场景

在不同的文档上添加事务。

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

三、列存储（WideColumnStore/Column-Family）数据库

列存储数据库将数据储存在列族（columnfamily）中，一个列族存储经常被一起查询的相关数据。

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

这种情况下适用的场景

1.日志。

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

2.博客平台。

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

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

不适用场景

1.如果我们需要ACID事务。

Vassandra就不支持事务。

2.原型设计。

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

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

四、图（Graph-Oriented）数据库

图数据库允许我们将数据以图的方式储存。

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

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

适用的场景

1.在一些关系性强的数据中

2.推荐引擎。

如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定

不适用场景

不适合的数据模型。

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

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

每一个都拥有以下几个特性中的一个：

不再使用SQL语言，比如MongoDB、Cassandra就有自己的查询语言

通常是开源项目

为集群运行而生

弱结构化——不会严格的限制数据结构类型

文档数据库

∙源起：

受LotusNotes启发。

∙数据模型：

包含了key-value的文档集合

∙例子：

CouchDB,MongoDB

∙优点：

数据模型自然，编程友好，快速开发，web友好，CRUD。

图数据库

∙源起：

欧拉和图理论。

∙数据模型：

节点和关系，也可处理键值对。

∙例子：

AllegroGraph,InfoGrid,Neo4j

∙优点：

解决复杂的图问题。

关系数据库

∙源起：

 E.F.Codd在ARelationalModelofDataforLargeSharedDataBanks提出的

∙数据模型：

各种关系

∙例子：

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类型的数据库，因为它的数据存储在一个分布式文件系统上，很容易扩展。

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

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

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

这可不是件容易事。

∙移动平台上可以用CouchDB/Mobilecouchbase.