分布式存储技术和应用

QQ群组: 281442983（单击链接加入该群组: ； k = 29LoD19）QQ: 1542385235

根据您是否知道（）的数据，当前可在Internet上访问的信息量接近10亿= 1万亿元（1024）. 毫无疑问，各种大型网站还存储大量数据. 如何有效地存储这些海量数据是每个大型网站的架构师必须解决的问题. 分布式存储技术是为解决此问题而开发的技术. 该技术和应用将在下面详细描述.

分布式存储概念

与当前的集中式存储技术不同，分布式存储技术不将数据存储在一个或多个特定节点上，而是通过网络使用企业中每台计算机上的磁盘空间，这些分散的存储资源构成一个虚拟存储设备，并且数据分散并存储在企业的各个角落.

特定技术和应用:

根据结构的程度来划分大量数据分布式文件存储技术，可以将其大致分为结构化数据，非结构化数据和半结构化数据.

本文将介绍这三种数据是如何分布存储的.

结构化数据的存储和应用

所谓的结构化数据是用户定义的数据类型，它包含一系列属性，每个属性都有一个数据类型，存储在关系中，可以使用二维表结构来表达实现的数据

大多数系统具有大量结构化数据，通常将其存储在关系中，例如Oracle或MySQL. 当系统规模太大而无法支持单个节点时，通常有两种方法: 垂直扩展和水平扩展.

·垂直扩展: 垂直扩展更容易理解. 简单来说，就是将按功能划分，将不同功能的数据存储在不同的中，从而将一个大型分为多个小型，从而达到了的扩展. 具有精心设计的体系结构的应用程序系统的总体功能通常由许多松散耦合的功能模块组成，每个功能模块所需的数据对应于中的一个或多个表. 各个功能模块之间的交互作用越少，统一性就越高，系统的耦合程度就越低，这样的系统就越容易实现垂直分割.

·水平扩展: 简单来说，数据的水平分段可以理解为根据数据行的分段，即表中的某些行被分段为，而其他一些行则被分段. 分为其他. 为了能够轻松确定每行数据被划分为哪个，分段始终需要根据特定规则执行，例如特定数字字段的范围，特定时间类型字段的范围，或字段的特定哈希值.

垂直扩展和水平扩展各有优缺点. 通常，大型系统会同时使用水平和垂直扩展.

实际应用: 图1是为核高级项目设计的结构化数据的分布式存储的体系.

图1可水平和垂直拆分的数据访问框架

·采用独立的分布式数据访问层分布式文件存储技术，后端分布式集群对前端应用程序是透明的.

集成的Memcached集群可减少对后端的访问并提高数据查询效率.

·支持垂直和水平扩展方法.

·基于全局唯一主键范围的分段方法减少了后续维护的工作量.

·全局唯一主键的生成使用DRBD + Heartbeat技术来确保可靠性.

·使用MySQL复制技术实现高度可用的体系结构.

注意: 上面的数据分段方案不是扩展MySql的唯一方法. 有兴趣的读者可以关注“云计算时代的MySQL-Clustrix Sierra分布式系统”.

非结构化数据的存储和应用

与结构化数据相比，不方便使用二维逻辑表表示的数据称为非结构化数据，包括办公文档，文本，图片，XML，HTML，各种报告，图像和音频/视频的所有格式信息等

分布式文件系统是实现非结构化数据存储的主要技术. 对于分布式文件系统，我们必须提到GFS（全名“ Google File System”）. GFS的系统架构如下图所示.

图2 Google文件系统架构图

图3 Google文件系统架构图（详细信息）

GFS将整个系统分为三种角色: 客户端（客户端），主服务器（主服务器）和块服务器（数据块服务器）.

客户端（客户端）: 这是GFS提供给应用程序的访问接口. 它是一组不符合POSIX规范的专用接口，并以库文件的形式提供. 该应用程序直接调用这些库函数，并将它们与库链接.

Master（主服务器）: 是GFS的管理节点，主要存储与数据文件相关的元数据，而不存储Chunk（数据块）. 元数据包括: 名称空间（Name Space），它是整个文件系统的目录结构，可以将64位标记映射到数据块及其组成文件的位置的表，块复制位置信息以及哪个过程是读取和写入特定的数据块等. 此外，主节点将定期从每个Chunk节点接收更新（“ Heart-beat”），以使元数据保持最新.

Chunk Server（块服务器）: 负责特定的存储工作，用于存储Chunk. GFS根据固定大小将文件分为多个块. 默认值为64MB. 每个块称为块. 每个块均分为多个块. 大小为64KB. 每个块都有一个唯一的64位标签. GFS通过使用副本来实现容错. 每个块都有多个存储副本（默认为三个）. 可以有一个以上的Chunk Server，其数量直接决定GFS的规模.

GFS之所以重要，是因为Google发布了GFS论文之后，许多开源组织都基于GFS论文开发了自己的分布式文件系统，其中更著名的是HDFS，MooseFS，MogileFS等.

实际应用: 由于将来在核高基础项目中将需要存储大量数据和应用，因此在设计时我们也使用分布式文件系统解决方案. 由于开放源代码的分布式文件系统可以基本满足我们的需求，此外，时间也相对紧张，因此我们采用了开放源代码的MooseFS作为底层的分布式文件系统.

·MooseFS的问题: 由于MooseFS也是根据GFS论文设计的，因此只有一个Master（主服务器）. 尽管可以添加备份日志服务器，但是仍然存在无法扩展主服务器的问题. 当单个主节点存储了越来越多的元数据时，该主节点占用的内存将增加，直到达到服务器的内存限制为止，因此单个主节点具有内存瓶颈，只能存储有限的数据，并且可扩展性差. 而且不稳定.

·MooseFS的优化: 面对MooseFS的问题，我们采用了类似于分布式的“共享”技术，并设计了一个分布式文件系统访问框架，该框架可以实现垂直分布的文件系统按级别拆分. 这样可以最大限度地提高MooseFS系统的可伸缩性和稳定性.

下图是为核高层项目设计的非结构化数据的分布式存储的体系. 我们设计了两种访问方法，一种是类似于GFS的API访问方法，它作为库文件提供，并且应用程序通过调用API直接访问分布式文件系统. 第二种类型是通过RESTful Web服务访问.

图4水平和垂直拆分和扩展分布式文件系统访问框架（API版本）

图5水平和垂直拆分和扩展分布式文件系统访问框架（RESTful Web服务版本）

半结构化数据的存储和应用

是完全结构化数据（例如关系，面向对象中的数据）和完全非结构化数据（例如声音，图像文件等）之间的数据. 半结构化数据模型具有一定的结构性，但是比传统的关系模型和面向对象模型更灵活. 半结构化数据模型根本不基于传统模式的严格概念. 这些模型中的数据是自描述的.

由于对半结构化数据没有严格的架构定义，因此不适合与传统的关系一起存储. 适合存储此类数据的称为“ NoSQL”.

NoSQL定义:

所谓的下一代具有一个非关系，分布式，轻量级的数据存储系统，该系统支持水平扩展，并且通常不保证遵守ACID原则. “ NoSQL”实际上是一个误导性的别名，称为非关系（non-relational database）更合适. 所谓“非关系”是指:

·使用松散耦合的类型和可扩展的数据模型对数据（地图，列，文档，图表等）进行逻辑建模，而不是使用固定的关系模型元组来构建数据模型.

·根据跨节点数据分布模型进行设计，该模型遵循CAP定理（可以保证一致性，可用性和分区容差中的任意两个），并支持水平缩放. 这意味着对多个数据中心和动态配置（在生产集群中透明地添加/删除节点）的必要支持，这也称为弹性.

·具有将数据持久存储在磁盘或内存中或两者中的功能，有时您可以使用可热插拔的自定义存储.

·支持多个“非SQL”接口（通常不止一个）用于数据访问.

图6是Sourav Mazumder提出的NoSQL总体架构:

图6 NoSQL总体架构

接口: REST（HBase，CouchDB，Riak等），MapReduce（HBase，CouchDB，MongoDB，Hypertable等），获取/放置（Voldemort，Scalaris等），节俭（HBase，Hypertable，Cassandra）等等），特定语言的API（MongoDB）.

·逻辑数据模型: 面向键值的（Voldemort，Dynomite等），列族（BigTable，HBase，Hypertable等），面向文档（Couch DB，MongoDB等），图形-面向（Neo4j，Infogrid等）

·数据分发模型: 一致性和可用性（HBase，Hypertable，MongoDB等），可用性和可分区性（Cassandra等）. 一致性和可分区性的结合会导致某些未分级的节点失去可用性. 有趣的是，目前没有支持这种组合的“非关系”.

数据持久性: 基于内存的磁盘（例如Redis，Scalaris，Terrastore），基于磁盘的磁盘（例如MongoDB，Riak等）或内存和磁盘的组合（例如HBase，Hypertable，Cassandra）. 存储类型可帮助我们确定解决方案适合的类型. 但是，在大多数情况下，人们发现基于组合的解决方案是最佳选择. 它不仅可以通过内存中的数据存储来支持高性能，而且还可以在写入足够的数据以确保连续性之后将其存储到磁盘中.

NoSQL的重要理论基础:

CAP理论:

·C: 一致性

·A: 可用性可用性（指快速数据获取）

·P: 网络分区容忍度（分布式）

图7 CAP理论

CAP原则告诉我们，这三个因素最多只能满足两个条件，不可能平衡这三个条件. 对于分布式系统，分区容错是一个基本要求，因此有必要放弃一致性. 对于大型网站，分区容错性和可用性要求较高，因此通常选择放弃一致性. 与CAP理论相对应，NoSQL追求AP，而传统追求CA，这也可以解释为什么传统的可伸缩性有限.

基本模型:

有趣的是，英语中的BASE表示碱，而ACID表示酸. 真是无法忍受.

·基本可用-基本可用

·软状态-软状态/灵活交易

·最终一致性–最终一致性

BASE模型与传统ACID模型相反. 与ACID模型不同，BASE强调牺牲高一致性以获得可用性或可靠性.

基本可用意味着通过分片，某些分区允许发生故障.

软状态是指异步的，只要最终一致性足够，就可以使数据在一段时间内不一致.

最终一致性是NoSQL的核心概念，强调最终数据是一致的，而不总是一致的.

法定人数NRW:

图8 Quorum NRW

N: 复制的节点数，即要保存的一条数据的副本数.

R: 成功读取操作的最小节点数，即每次成功读取所需的副本数.

W: 成功写入操作的最小节点数，即每次成功写入操作所需的副本数.

这三个因素决定了可用性，一致性和分区容错能力. 只有W + R> N才能保证强一致性.

实际应用: 今年上半年，我负责aspire搜索团队的Internet搜索设计和开发. 我设计的Web爬网程序系统使用Cassandra来存储网页和链接信息. 让我结合实际经验谈谈我对卡桑德拉的看法:

好处:

·弹性扩展: 由于Cassandra是完全分布式的，因此您不需要设计复杂的数据分段解决方案（例如MySQL），也不需要配置复杂的DRBD + Heartbeat. 一切都变得非常简单. 只有简单的配置才能将新节点添加到群集，并且对客户端完全透明，而无需任何更改.

灵活的架构: 无需像一样预先设计架构，添加或删除字段非常方便.

·易于使用: 由于没有像SQL这样的复杂查询语言，因此学习成本不高且易于上手.

缺点:

稳定性差: 在我们的实际使用中，发现一台机器的数据量达到200G或更多，并且不时出现停机现象.

·缺乏管理和分析工具: 传统的关系数据具有更好的管理和分析工具. 使用这些工具，您可以轻松地管理，查看数据和分析性能瓶颈. Cassandra确实缺少类似的工具. ，即使是简单的数据视图也必须通过编程才能看到.

个人公共帐户谢谢您对旧铁路的支持

QQ群组: 281442983（单击链接加入该群组: ； k = 29LoD19）QQ: 1542385235

我的淘宝店，您可以去购物: ; scene = taobao_shop

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-284009-1.html