闫浩文

数据中心存储方案范文第1篇

华为“数据按需服务”可以进一步解读为，应客户所需，提供一种存储能力。它不是特指某一类产品，而是要为用户提供一种支持其业务云化的弹性伸缩、智能管控、灵活开放的存储环境。华为存储即服务解决方案的推出将这一设想变成了现实。

“如果你鬯，就送他去纽约，因为那里是天堂；如果你恨他，就送他去纽约，因为那里是地狱。”这是曾经风靡中国的电视剧《北京人在纽约》片头出现的一句话。如今，用这种爱恨交加的复杂心情来形容企业对数据存储的感情似乎也很贴切，或者更直白地说：“爱数据，恨存储！”

为什么会有这种两极分化的感觉？企业信息化最终获得的实实在在的成果就是数据。数据是企业重要的资产，是带来商业价值的源泉。所以，企业有充分的理由爱数据。数据量的爆炸式增长，以及应用越来越复杂，使得数据的载体――存储设备的操作和管理越来越复杂，容易产生数据孤岛，使采购和管理成本日益走高，同时也影响了业务部署的速度。所以，企业也有很多理由“恨”存储。

爱也好，恨也罢，存储这道门槛是所有企业必须跨越的。尤其是在今天，随着云时代的到来，云计算、大数据、物联网和智能终端等技术蓬勃发展，如何以合理的成本实现高效的数据存储和管理，并且适应企业业务的云化发展，已经成为CIO面临的首要问题。

云上云下一致的服务体验

云计算时代，就是软件定义一切的时代，也是一切皆服务的时代。

现在，最流行的词汇就是“数字化转型”。从IT的角度说，数字化转型的核心就是利用IT实现业务的重构，其中业务云化是重中之重。

为了更好地支持云工作负载，就要采用标准化的x86硬件、分布式集群软件，实现横向扩展等。没错！不过，这些都是具体的工具和解决方案。在采用业务云化的产品和解决方案之前，还有更关键的一步，就是先要了解云的本质。

云计算，不再是购买软硬件、一次性支付采购成本，而是交付一种开箱即用的服务，用户可按需使用，并按实际使用量付费。这对用户来说真的是一种由内而外、从下至上的颠覆，从产品的架构设计到使用，从产品的管理维护到资金的使用皆是如此。

作为IT基础架构的重要组成部分之一，存储自然也不例外。在云时代，存储就是一种数据服务。

德国当地时间3月20日，华为在德国举行的一年一度的CeBIT（汉诺威消费电子、信息及通信博览会） 2023上，正式了存储即服务（Storage as a Service，STaaS）解决方案，在业界率先打造无缝跨云的体验，旨在为企业用户提供云上云下体验一致的存储资源服务，以及智能的数据和运维管理，从而帮助企业数据中心向云平滑演进。

其实，在3月10日举行的华为中国生态伙伴大会2023上，华为存储产品线总裁孟广斌在题为“数据按需服务，让云转型更敏捷”的主题演讲中已经提前曝光了华为存储即服务解决方案的一些细节。

如何才能真正做到存储即服务呢？孟广斌谈到了两个关键点：存储资源池虚拟化和资源调度自动化。通常，在存储架构的最底层是各类存储硬件，包括传统的磁盘阵列、混合型阵列、全闪存阵列，还有软件定义存储，以及第三方的存储设备等。正是这种异构的存储环境有时会让用户感到手足无措，也是导致数据孤岛的“元凶”。现在，又加上私有云、公有云等新的资源池，问题就更棘手了。

华为存储即服务解决方案厉害的一手在于，无论什么样的存储设备、介质，都可以被虚拟化成一个统一的资源池，闪存存储与传统存储、高中低端存储互相备份和容灾，数据可以在本地存储与云之间按需流动，通常只有20%～30%的存储利有率，可以提升至70%左右。

华为存储即服务解决方案基于业务咨询和最佳实践，将应用按工作负载分类，给出合理的SLA等级建议，使业务应用与存储之间能够基于SLA进行最佳匹配，避免过度购买，可以节省20%的整体拥有成本。

在这个统一的存储资源池之上，企业可以更好地实现智能的数据管理和服务，具体表现在：将数据资源按照性能、可靠性、数据保护等特性进行智能分类，自动配置给应用程序，简化了传统存储解决方案手动设置的复杂度和操作步骤，在此基础上，实现智能的故障分析、分钟级故障定位和修复，效率提升50%；基于趋势的预测，可实现智能的资源回收，提供数据流动决策建议，并自动执行，进一步简化运维管理。由于具有自助式服务发放功能，新业务上线的时间缩短至分钟级。

在上述这些基础的存储工作做好后，向云进行平滑演进也就水到渠成了。华为存储即服务解决方案具有广泛的生态兼容性，支持多厂商、多类型的存储管理，并提供开放接口，与各种云平台（VMware、Odin、BMC等）集成。华为还倡导创建了OpenSDS联盟，目前Dell EMC、富士通、日立、西部数据、英特尔等厂商已经加入。

孟广斌打比方说，华为存储即服务解决方案就是一个智能的存储“超级大管家”，重点解决了存储云化整合、智能数据管理和服务，以及向云平滑演进等关键问题。

华为STaaS八面玲珑

当前，许多企业都面临“双模IT”的挑战，即一方面要支持传统IT应用，另一方面还要支持云原生应用。华为存储即服务解决方案可谓八面玲珑。

在传统数据中心里，用户可以使用华为的存储即服务解决方案实现存储设备的集中管理，基于统一视图进行运维监控，基于服务目录实现存储资源的自动分配和数据保护，从而提升运维的效率，减少存储管理的人力投入。

而在云数据中心里，华为的存储即服务解决方案更是如鱼得水，可以作为云平台的专业存储管理和服务组件，基于开放的RESTful接口，被业界主流的云平台快速集成，为用户提供块、文件、对象等各类存储服务，以及快照、复制、迁移等数据服务，让用户享受“开箱即用”的便捷。

孟广斌表示，华为看到存储未来的发展趋势有三个核心点：存储服务化、介质闪存化，以及软件定义存储。这些都是业务云化的有力支撑。

通常来说，面向未来的云化业务，客户有三种云存储方案可以选择。第一类，独立的分布式云存储，包括分布式块、分布式文件、分布式对象存储，不过这类存储也有走向多协议融合的趋势。第二类，提供端到端堆栈的私有云。第三类，公有云存储服务。

华为认为，公有云与私有云在未来的很长一段时间内会并存。客户可以灵活地选择华为成熟的私有云存储，以及公有云存储服务，并可形成混合云方案，实现统一管理和灵活迁移。

数据按需服务迈出一大步

在2023年的华为全联接大会上，华为提出了“数据按需服务（Data on Demand）”的理念。这一理念不是以技术为导向，而是以应用为导向。现在，云计算的一种新趋势就是不以资源为中心，而是以应用中心，以让客户轻松地驾驭和使用云为出发点。

数据中心存储方案范文第2篇

【关键词】DAS；NAS；IP-SAN；iSCSI

基于IP技术的存储区域网络架构，决定数据中心存储系统采用IP-SAN架构：IP-SAN无需过多成本、TCP/IP网络技术成熟、统一标准化、较好的高扩展性和管理人性化等特点，比较适合数据中心所需的高速率、高带宽的存储系统组建。下面将通过前期对学院目前数据中心存在的问题以及当前使用要求指标，制定数据中心存储系统解决方案。

1 制定方案

1.1 需求分析

本课题研究以某学院国家骨干示范建设《小型数据中心存储系统》项目为背景，数据中心的设计目标是现有各通信与计算机实训室终端设备和系统对数据中心快速访问并满足大规模数据存储的现实要求。在建设高容量高性能基础上，数据中心对于异构网络的兼容性即高可用性，并且能够以低成本投入高效能应用的要求。

1.2 方案确定

首先确定网络平台：现有的计算机终端基本配备有网络适配器，有的还是千兆网络适配器。IP网络技术成熟，采用iSCSI协议的IP网络存储系统技术起点高。从存储系统的使用要求来看，基于IP技术的存储系统是我们实现低成本高性能的不二选择。以后千、万兆以太网发展起来后，IP网络传输速率将大大提高。

其次确定网络架构：NAS和SAN两种架构形式都能使用IP网络。前者是基于文件的网络存储和文件备份的存储架构，多见于海量存储、高读写吞吐率等。实现文件集中管理、统一存储，它对IP网络环境没有要求。NAS设备可应用于异构网络环境（如FTTX等）而且位置不受限制[1]。网络附加存储的不足在于没有集中备份数据的功能，不能有效支撑数据库应用，最核心的一点是网络附加存储不能支持块级数据传送，它是面向文件级的。IP-SAN把SCSI映射至TCP/IP之上，能够完成SCSI块数据传送于IP网络之中，它采用的是TCP/IP、SCSI协议，利用IP网等，解决了FC-SAN存在的范围扩展问题[2]。IP-SAN有效地解决了当前的存储设备，尽可能地扩展了存储资源，保障了更多的业务应用；较好地解决了困扰DAS与SAN受限地理范围的问题；能够较为有效地利用以太网以及通过网络管理软件解决运维问题[3]。基于上述，本案宜采用IP-SAN存储架构。

IP-SAN协议的确定：存储区域网络技术大体有FCIP、iFCP以及iSCSI三种，FCIP与iFCP主要是存储区域网络技术从FC通道到IP网络的中间临时使用，但是本课题大致应用于数据存储和传输的存储系统和设备，涉及光纤设备和光纤网络较少，三种协议中，只有iSCSI协议与光纤无关，故iSCSI协议在此采用。服务器中的软件，把SCSI数据打包进IP包里面，而后把这个包传送至目标设备，在IP网络上，再由后者将IP包解包还原为SCSI数据。

2 数据中心存储系统的方案设计

依据IP-SAN结构与iSCSI协议相关标准，存储系统结构：软件部分由iSCSl目标器软件、Web管理软件和iSCSI启动器程序（客户端）三部分组成。用户只需安装并启动iSCSl启动器软件，通过TCP网络，就能访问位于Stroage Server上目标资源，也能够使用Web应用程序，管理与配置这些资源。硬件层面，使用IBM服务器相连于吉比特局域网。作为全部IP-SAN中最重要的设备，Stroage Server使用iSCSI协议，支持DATA存储业务于存储用户。结合数据中心应用的服务对象-用户的实际需求，该设备的磁盘容量不能设计太小，还要兼具合适的扩展、容灾能力，适用于千兆局域网络，能够提供热插拔功能。网络层面，采用吉比特网络。

2.1 选择IP-SAN存储服务器

针对存储系统稳定可用方面的需求，我们选用了IBM公司的X3650 M3系列服务器，安装08网络操作系统，采用SATA硬盘接口，8块500G硬盘，这里面使用1个安装操作系统，1个用来做冗余，RAID 5配置在剩余的6块硬盘上。采用Web存储服务管理软件，为用户提供向导式图形化接口，用来申请、注销iSCSI存储服务。

2.2 客户端

鉴于数据中心目前大部分主机的操作系统安装使用情况，采用微软2000，该的Internet Explorer指明要5.0或更高版本。安装微软操作的客户端，iSCSI使用微软免费启动器程序。

3 存储服务器的磁盘阵列配置

根据需求分析，本数据中心存储系统解决方案采用RAID 5配置。比RAID0高的数据安全性能，比RAID 1高的数据读写性能，使其成为了存储性能、数据安全和存储成本兼顾的存储解决方案。与RAID 1不同的是RAID 5多了一个奇偶效验信息[5]。

存储服务器管理软件当前基本都采用了图形化窗口式的设计，管理员不用登录设备配置管理，这样设备既方便使用又安全。它的工作过程为：机器上启用一个名为Servlet的服务，管理员使用JSP网页请求任务，然后Servlet通过TELNET运行目标器程序，再执行管理员的操作。已运行的目标器程序信息还能由此管理软件保存在硬盘上，并拥有自我恢复功能[6]。

iSCSI协议在兼容性、可扩展性、安全性方面的特点，决定了IP-SAN这种存储架构的发展必将大规模的应用于现代IP网络中。随着千兆级、万兆级局域网的发展，IP-SAN势必取得不亚于FC-SAN的传输速率和高带宽。而采用iSCSI的IP存储区域网络解决方案投入较少，IP网络技术相对成熟、扩张方便和管理容易，适合数据中心高性能高带宽存储业务的要求。在学院小型数据中心存储系统的解决方案中，存储服务器采用WINDOWS平台，以不多的软、硬件投入完成了IP-SAN存储系统的设计，后期还可以对系统功能进行扩展和优化。

【参考文献】

[1]李兆虎.网络存储系统仿真研究综述[J].计算机研究与发展，2023（49）.

[2]陈涛，肖侬，刘芳.大规模网络存储系统的数据布局策略研究[J].计算机研究与发展，2009：46-47.

[3]朱洪斌，程杰.数据中心存储网络架构研究[J].电力信息化，2023：22-26.

[4]Chi-Huang Chiu ；Hsien-Tang Lin ；Shyan-Ming Yuan a content delivery system for storage service in cloud environment [EI SCI]International journal of ad hoc and ubiquitous computing.2023，6-8.

数据中心存储方案范文第3篇

回顾最近几年的信息存储技术的发展，真正关键的突破是存储系统的拓扑连接技术的发展和成熟。今天，信息访问拓扑连接技术有很多，比如iSCSI，FCIP，IFCP，SAN，NAS等等，但真正广为认可和广泛应用的成熟技术是SAN技术和NAS技术，SAN技术及NAS技术都是解决信息存储集中化的成熟技术。SAN技术和NAS技术各有所长，分别适合不同应用业务系统,集成的SAN+NAS解决方案是可以满足各个行业客户业务需求的最佳选择。

我们经常接到来自客户这样的提问:作为存储专家请告诉我们究竟应该采用SAN方案,还是采用NAS方案?

面对这样的提问,我们应该怎样应呢？我们不能忙着给出简单的确切回答,而是应该和客户一道从业务需求出发分析存储需求,最后确定整体存储解决方案。SAN和NAS的优势对比如图1所示。

图1SAN和NAS的优势对比

SAN技术发展分析

SAN和NAS适合的应用不同。SAN是传统的DAS技术的发展延续，是适合大量的数据块访问方式的网络存储技术:即信息主要是以块方式存储及管理的应用。SAN和DAS的主要区别在于SAN技术在主机和存储设备之间增加了专用的存储域交换机，构成光纤FC存储域网络，实现网络存储访问。

SAN技术经过几年的发展已经非常成熟, SAN技术吸收传统通道技术和传统网络技术的优势，因此具有如下优势:高速、低延迟、高数据一致性、大数据传输等特性;路由管理、广泛连接性、远距离支持、灵活管理等。

SAN技术的核心是SAN交换机，SAN交换机是存储系统和主机系统之间的桥梁。尽管SAN交换机上也配置CPU和CACHE，SAN交换机上也可以具有自我管理、自我配置等智能软件，但SAN交换机主要作用还是作为数据交换通道。

目前主流的SAN交换机厂商象BAROCADE、MCDATA、CISCO占有存储交换机市场98%以上的份额，这些厂商都很明确SAN交换机的数据交换作用，对于某些象基于交换机的数据镜像、虚拟存储等都还只是在概念探讨和测试中，这种做法是客观负责任。

NAS技术发展分析

NAS是传统网络文件服务器技术的发展延续，是专用的网络文件服务器，是代替传统网络文件服务器市场的新技术、新产品 。

网络文件服务器技术是建立在网络技术发展成熟基础之上的。因此它的访问协议是通用的TCP/IP，今天的NAS产品也是基于TCP/IP协议的文件访问机制。

传统的网络文件服务器总体可以分为两大类:第一类是UNIX网络文件服务器，即支持NFS服务器;第二类是NT网络文件服务器，即支持CIFS服务器

网络文件服务器的出发点是数据共享及保护，但上述的两类网络文件服务器之间较难共享;一个网络文件服务器系统支持的网络访问能力有限，因此当一个网络文件服务器不能满足性能需求时必须再添加新的网络文件服务器，但过多的网络文件服务器造成管理维护的困难及资源浪费;同时传统网络文件服务器对数据保护能力也非常有限（一般是单一主机连接存储介质构成网络文件服务器，存在单点故障，但又很少采用HA模式，可靠性因而很差），丢失数据几乎是很难避免的。

目前市场上的NAS产品基本上可以分成两种模式:专业存储厂商NAS产品及主机厂商NAS产品。

客观地说，专业存储厂商的NAS产品是真正的NAS产品，因为他们都在NAS引擎的微码中内置了NFS和CIFS的支持，是真正的专业网络文件服务器NAS。

目前主要专业NAS厂商有EMC和NETAPP。EMC的NAS产品基于其高可靠性，高性能主要面对的是商业用户;NETAPP的NAS产品由于自身特点主要面向中低端用户。

主机厂商NAS产品不是真正的NAS产品，基本都是采用两台NT（或UNIX）服务器做NAS的引擎，实际是包装过的传统网络文件服务器，因此对CIFS（NFS）支持较好，但对NFS（CIFS）采用模拟方式。因此在性能上没有很好的扩充性，无法大规模文件共享的需求。

存储整合的必要性

目前，SAN技术和NAS技术都是信息整合的手段，二者各有特点，适合不同的市场需求。能否将二者有机结合在一起，满足不同应用的需求，充分发挥网络存储的优势成为广大客户迫切需要。

目前用户一般拥有多台服务器。由于所有的服务器采购时间较早，其存储系统都是直连的模式，而且大部分存储系统都是低档的JBOD产品，这种现状是和以主机为核心设计IT架构的年代相适应的。但随着时间的推移，这种构架的问题已经显现出来了，其问题主要表现为以下五个方面：

第一，由于目前的存储系统是不能实现信息网络存储的低档产品，这样造成各个业务系统信息无法方便共享。

第二，由于分散的独立存储，各个业务系统的存储各自独立，对其管理必须透过其主机系统。

第三，这样分散的独立存储系统不能实现有效信息共享，这样一来在最初配置各自直连系统时必须在系统扩展性和系统投资之间权衡利弊，不能兼顾。

第四，造成目前分散的独立存储系统现状的原因是过去的技术限制，但是在考虑未来系统建设时应该是面向未来的，也就是应该采用网络存储技术，通过网络存储实现信息的有效共享，方便管理，便于扩展，建设高性能，高可靠，高扩展，高兼容的信息存储基础架构。

第五，我们在规划信息系统基础架构时，广大用户都认识到应该采用网络存储技术，即采用SAN或NAS技术实现网络存储。

SAN+NAS集成优势

SAN是存储域的网络，是网络存储技术的核心，业务系统中的核心部分需要高性能、高可靠的数据访问方式，这是SAN技术特长。采用SAN技术，在关键业务系统的主机和存储设备之间通过SAN交换机连接起来，构成网络存储，这就保证了核心业务系统的高性能、高可靠性数据访问需求及未来扩展的灵活性。

但是客户业务系统除了核心的关键业务之外还有更多的非关键业务，这些业务系统也需要存储空间，将这些非关键业务系统的主机也接入SAN结构是不现实的。

同时，大部分非主要的边缘业务系统都是以文件形式访问数据的，是NAS技术的特长。但如果采用纯NAS技术，将导致客户有一个核心SAN网络存储平台及一个核心NAS网络存储平台，客户在NAS存储和SAN存储之间无法实现存储资源的动态调配、信息有效共享，实际上造成两个明显的信息孤岛，不符合信息系统整合的客观需求。

因此能否将NAS技术和SAN技术集成起来成为满足广大客户需求的关键。SAN+NAS集成解决方案就是在统一的SAN架构下，添加NAS引擎。

NAS引擎和其他主要业务系统主机共享统一SAN架构下的存储资源，从而实现在满足主要业务系统的高性能、高可靠数据访问需求的同时，通过添加的NAS引擎兼顾大量边缘业务系统对存储资源的需求，实现真正的存储信息整合。EMC的SAN+NAS就是这样的解决方案。

许多厂商也在尝试探索SAN和NAS整合的解决方案，但直到目前为止，只有作为独立存储厂商的EMC公司的工作取得实效，早在多年前就推出了这样的SAN和NAS集成的解决方案并在实际中获得广泛应用。

SAN+NAS成功案例

某NEWSPAPER网络数据中心

该项目最后配置为四台CX500，四个NS700G及SAN交换机等相关软件硬件产品。客户的需求分为隔离的内外网络数据中心，内外网络拓扑结构对等，其内网的拓扑结构图如图2所示，外网的拓扑结构图和内网类似。

图2内网拓扑结构图

由于该项目行业的特殊性，该项目初期客户首先招的是集成标。EMC公司和集成商一起根据客户的业务需求，为用户设计了SAN+NAS的完美解决方案。集成商公司由于解决方案的优势中了集成标。但是，按照客户原来的设计，中标集成商不意味着是设备提供商，对于集成商在该项目中选择的设备还需进行二次招标。因此二次招标将是各类产品的价格战。

围绕着SAN+NAS解决方案，客户进行了大量市场调研，在市场上寻找SAN+NAS解决方案提供商，经过近一个月的市场调研，客户的结论是:EMC公司的SAN+NAS解决方案是满足客户业务需求的最佳解决方案。

因此在二次招标时唯独EMC产品部分没有进行二次招标，直接进入了商务谈判并最终购买了EMC产品解决方案。

某油田研究院数据中心

该项目最后的配置是一台EMC公司CX700磁盘阵列加一个EMC公司NS702G的NAS引擎。NAS+SAN总体拓扑结构图如图3所示。

图3NAS+SAN总体拓扑结构图

该客户是石油行业的典型客户，其主要业务系统包括资料处理业务及解释业务。资料处理系统需要高带宽数据访问，适合通过SAN方式访问数据;解释业务在60台工作站上进行，各个工作站数据需要共享，数据存储需求带宽较低。

在本项目之前，用户于2002年购买了AUTOPEC产品。该产品属于纯NAS产品，在实际使用中暴露出其严重性能问题，其广大内部使用用户对此提出诸多抱怨。

2004年5月，应客户邀请，EMC公司到客户现场对客户的目前IT环境进行了评估，充分剖析了客户需求及目前的问题所在。最后和用户达成共识:解决目前客户问题的解决方案是SAN+NAS，该解决方案可以满足资料处理系统高带宽需求，同时兼顾了几十台工作站文件共享的需求。

在商务采购阶段，许多EMC公司的友商都想参与该项目。由于价格原因，很多SI也非常想推销价格较便宜的友商产品。但是由于SAN+NAS解决方案的需求使得EMC的解决方案最终为用户所接受。

某汽车厂数据中心

该项目最后的配置是一台EMC公司CX700磁盘阵列加一个EMC公司NS702G的NAS引擎。

该客户是汽车行业的典型客户，其主要业务系统包括CAD/CAM业务及部分ERP业务。ERP业务需要数据库高性能、高可靠块数据访问，较适合通过SAN方式访问数据；CAD/CAM业务系统在许多工作站上实现，数据存储需求带宽较低。

在EMC介入本项目之前，用户和HP，IBM等公司进行了较多接触，但这些厂商推荐的解决方案要么是单纯的SAN方案，要么是单纯的NAS方案。

一方面，单纯的SAN方案可以获得性能、可靠性、安全性的提升，但建立几十台主机（包括工作站）的SAN网络造价太高，同时关键是单纯的SAN方案不能满足用户多台CAD/CAM工作站数据共享的需求，不能令用户满意。另一方面，单纯的NAS方案也令用户不能接受，单纯NAS方案可以满足工作站数据共享的需求，但不满足ERP业务现实需求及未来发展。

数据中心存储方案范文第4篇

（四川文理学院计算机学院，四川达州635000）

摘要：针对大数据下档案存储的现状，通过分析存储档案文档存在重复的原因，提出一种MongoDB存储档案文档的方法，利用MongoDB的GridFs统一处理不同类型和大小的文件，定义3个集合分别存储上传者记录、文件信息记录和分块文件内容，提出存储中通过文件MD5校验码值是否相同来进行去重研究，并实现去重的程序代码，有一定的实际意义。采用的分布式存储数据库增强了档案文档存储系统的可扩展性。实验表明，该方法能有效地去除重复的档案文档，提高查询效率。

关键词 ：MongoDB；MD5；大数据；档案文档去重；GridFs

中图分类号：TN911?34；TP311 文献标识码：A 文章编号：1004?373X（2023）16?0051?05

收稿日期：2023?03?20

基金项目：国家档案局项目：基于大数据的档案数据去重模型与方法研究（2023?X?65）；四川省教育厅一般项目：大数据环境下NoSQL数据库应用研究(14ZB0313）

0 引言

随着信息技术的飞跃发展，各国各地都在大力发展电子政务建设。在此环境下档案局的档案文档也跨入了信息化存储的行列。但档案局的档案类型种类较多，除了纯文本的之外，还有图片、声音、视频、PDF等各种类型的文档，这些文档都是非结构化的数据，在传统的信息系统中，存放这些数据是比较困难的。因此在大数据环境下，设计信息化档案存储系统会首选非结构化的数据库，即NoSQL 数据库。利用NoSQL 家族中的Mon?goDB数据库作为存放档案文档的非结构化数据是较为理想的。MongoDB对存放大量的非结构化数据有很大的优势，但因MongoDB本身就是非结构化的，故在存放信息时会产生重复的数据。有人提出了像在关系数据库中一样建立关键索引来解决重复数据的问题，但在以文档方式存储的数据而言，当数据很大时，这种方式将会有弊端。本文研究的是在存储档案文档之前就重复的数据进行去重处理，然后再存入MongoDB数据库中，这样在数据库中存放的将是非重复的数据。

1 传统的档案存储分析

在原有的存储档案文档信息系统中，主要是把文档以文件的形式存放在文件系统中，然后用原数据信息建立一个档案文件和数据库的链接，并把该链接的路径存储在关系数据库中，如表1和表2所示。

通过表1和表2的分析可知，表2中filePathId与表1中的filePathId 中的字段关联，这样在访问表1 中的某个文件时，只需要访问表2中与filePathId字段关联的记录的fileRealPath的值即可访问该文件。对于以文件系统方式存放的档案文件会产生大量的重复文件。即使在存储的时候能简单的通过人工的方式来检查是否有重复的文件存放，但也不能大面积的检查是否有重复的文件，在这种方式下，存储空间很快会被耗尽，要靠不断的增加存储设备来解决大量档案数据存放的问题，而且不利于管理，数据极其不安全，扩展性较差。人们对此已有逐步的认识，也进行了相应的研究。本文的重点是利用MongoDB 数据库来存储这些非结构化的数据，并且在存放之前就完成对重复档案文档的去重操作。

2 基于MongoDB 的文档存储模型

2.1 MongoDB的存储机制

MongoDB是NoSql家族中的一员，具有模式自由等特性。它与关系数据库一样具有3个层次：分别是数据库层、集合层、文档对象层。分别对应关系数据库中的数据库、表和记录。在MongoDB中文档类似于JSON的键/值对，集合则是一组文档的集合，它们是无模式限制的。MongoDB数据库非常适合实时数据的插入、查询、更新、删除及数据备份等操作。尤其适合充当由几十台或者几百台服务器组成的集群数据库。现在大多数的地理规划等领域都在利用MongoDB数据库进行数据存储。MongoDB数据库不仅支持分布式系统，它本身还支持分片存储数据（Mongod）、客户端请求（Clients）、集群配置（Config Server）和路由协议（Mongos）[1]。它采用的是内存映射的方式作为存储引擎，能有效地提高输入/输出的效率[2]。

2.2 MongoDB数据库中重复数据来源

目前的档案管理系统还处于信息孤岛的层面，各个省市的数据结构不同，存放的方式也不同，惟一能统一的是从市级单位及其下级单位，如区、县、乡、镇单位。利用档案管理系统上传档案文件进行存储的也是这些相关单位。如果同一份档案文档被市级单位分发到其他单位，其他单位会把它作为重要档案文档给上传到档案管理系统中存储起来，这样就会产生多个重复的档案文档。而有部门在不知道的情况下，同一个人上传了几份相同的档案文档；或者利用shp文件批量上传档案文档时遇到其他异常情况，没有一次性的上传完，下次再上传的时候，又是从头开始上传，导致以前的档案文档被重复存储；或者在批量上传的shp文档本身被人为的不小心做成了含有重复的档案文档记录，这样导入shp文件时也会产生重复记录。通过对以上情况的分析可知，档案文档存储时在MongoDB 数据库中产生重复数据的来源主要有以下几点：同一个档案文档被不同的单位、部门重复上传；同一个人对同一个档案文档上传多次；批量档案文档准备过程中人为的产生了重复文档；批量上传时，中断上传，下次再上传时将产生重复文档。

2.3 档案存储模型的建立

档案存储时采用分布式的方式进行上传存储的，各个市、区、县、乡、镇的不同部门可能在不同的时间和地点对档案文档进行上传操作。数据库采用MongoDB数据库，其分布式存储结构如图1所示。

从图1可以看出，各市、县、乡、镇的用户可以随时在不同地点上传档案文档到不同的MongoDB 服务器中，操作方便。档案文档不同于一般的文档，将遵循“谁操作谁负责”的原则。故将设置上传者的权限，且将记录上传者的详细信息：如上传时间、地点等的一些信息。而对于档案文档本身而言其文件大小不能统一标准化，且档案文档的格式有差异，考虑到要处理数据大小和类型都可能不同的档案文档，本文将借助于Mon?goDB 的GridFs 来处理，GridFs 是一种处理大文件的规范，可以存储上百万的文件而不用担心其扩容性[3]。在MongoDB中存放数据时将涉及到3个集合：userInfo.users，fileInfo.files，fileContent.chunks。

userInfo.users 集合用来存放上传档案文档的上传者信息，其结构如下：

集合fileInfo.files中的fileID与集合userInfo.users集合中的upLaodfileID 相同，用来关联上传的文件信息。集合fileContent.chucks中的fileID 与集合fileInfo.files中的fileID相同，用来关联文件存放的具体内容，根据上面3个集合中结构的设计，当一个具有操作权限的用户在某一地点上传了某个档案文件后，将记录该用户上传的详细信息：如操作者，上传的具体区、县、乡的详细地址，上传的日期、文件名、文件的大小、长度、类型等。当该用户再次上传相同的档案文档时，根据表的关联查找，将会做出已在同一地点或不同地点已经上传了相同的档案文件的提示信息。

3 MongoDB 中的去重算法

本算法的设计思想是，根据上传的档案文档判断，无论是否已经被上传过，都会存储上传档案文档操作者的相关信息，即生成一个userInfo.users集合中的一条记录。上传档案文件时为了节省服务器的开销和资源，所上传文档的MD5 校验码值的计算都会在客户端进行。在客户端计算并上传档案文档的MD5校验码值后再在分布式存储数据库中查找遍历fileInfo.files中的每一条记录，查看每条记录中存储的档案文档的MD5 码值是否与将要上传的档案文档的MD5码值相同，如果不同，则将在userInfo.user 集合中存储一条上传者信息的记录，并且把该记录中的“UploadCount”值设置为1。同时生成集合fileInfo.files 中的一条记录，在该记录中通过“fileMD5”存储档案文档的MD5码值。获得要上传的档案文档的大小fileSize，确定档案分块存储的总块数file?ChuckSize。在算法中为了规范，不管文件的大小和类型，均采用统一大小（fixedSize）的分块对档案文档进行存放，即总分块数如下所示：

fileChuckSize=（fileSize%fixedSize）?（fileSize/fixedSize）：（fileSize/fixedSize+1）

并把该值记录到fileInfo.files 集合中对应记录中。然后对档案文档进行上传并对文档内容按固定的分块大小存放到fileContent.chucks集合中，在该集合里会存储fileChuckSize 条记录。如果要上传的档案文档的MD5码值和分布式数据库中存储的fileInfo.files集合中存储的某个记录的fileMD5值相同，则取出该条记录对应的fileID 值并把该值存放到一个临时存储字段temp?FileID 中，已备后期使用。然后提取上传者的信息和tempFileID 的值组合成userInfo.users 集合中的一条记录，并与集合中的其他记录进行比较，如果有相同的记录，则在该条记录的UploadCount值加1。而组合的这条记录将不再存储在userInfo.users集合中。其中Upload?Count值加1是判断该用户是否经常在同一个地点上传相同的档案文档。

如果在该集合中没有相同的记录，则存储该组合好的记录。下次在访问这个档案文档时，通过userInfo.us?ers集合中的upLoadfileID关联到fileInfo.files集合，再通过fileInfo.files 集合中的fileID 关联到fileContent.chucks集合，则顺利访问到需要的档案文档，其过程流程图如图2所示。

根据算法流程图，定义几个类UserInfo，FileInfo，FileContent 分别对应3 个集合，定义操作数据库的类DBObj，定义去重的类RemoveRepeat。

去重的关键代码实现如下：

在代码中定义了findByFileMD5（）方法判断在已经存储的fileInfo.files集合的记录中有没有与将要上传的档案文档的MD5 校验码相同的记录存在。定义方法findRepeatData（）用来检查有无重复上传档案文档上传者信息，即判断在usersInfo.user中有没有重复的数据记录，这些方法在批量导入数据记录时也会调用逐一判断。

4 实验结果与分析

本实验使用Hadoop作为分布式文件系统运行在不同地理位置的10 台主机组成的集群上，在Window7 系统中，采用MyEclipse8.5 做Java 代码开发，分布式数据库MongoDB 作数据存储，采用的是8 核CPU，8 GB 内存，320 GB 硬盘。批量导入使用的是shp文件。shp文件的格式定义同集合文件的格式。对单个的文档上传进行验证无误外，为了对更多的数据进行验证，在shp文件中模拟产生10万，20万，30万数据。结果如图3所示。

该方法在数据去重中达到90%以上，去重效果还比较理想。算法采用的是分布式文件系统，对文件去重效率较高，且系统具有相应的扩展性。

5 结语

本算法中采用分布式文件系统和分布式数据库MongoDB 对档案文档进行存储和去重，利用MongoDB数据库的GridFs来处理不同类型和大小的档案文档，统一对档案文档进行处理。提出利用了去重的算法思想，并通过实验模拟测试去重效果较为理性。该方法具有一定的可行性。为以后大数据的存储的去重有一定的借鉴性。

参考文献

[1] 雷德龙，郭殿升，陈崇成，等.基于MongoDB的矢量空间数据云存储与处理系统[J].地理信息科学，2023（7）：508?514.

[2] 吴秀君.面向电子政务的MongoDB与MySQL混合存储策略[J].计算机与现代化，2023（8）：62?65.

[3] CHODOROW Kristina.MongoDB 权威指南[M].北京：人民邮电出版社，2023.

[4] 郭武士.基于MongoDB GridFS的图片存储方案的实现[J].四川工程职业技术学院学报，2023（4）：41?43.

[5] 卫启云，渠伟勇，黄鸿，等.城市地理编码的部门信息共享与应用实践[J].测绘通报，2023（10）：101?104.

[6] 陈超，王亮，闫浩文，等.一种基于NoSQL 的地图瓦片数据存储技术[J].测绘科学，2023（1）：142?143.

[7] MANBER U. Finding similar files in a large file system [C]//Proceedings of the Winter 1994 USENIX Technical Conference.San Fransisco，CA，USA：[s.n.]，1994：1?10.

[8] BRODER A Z. On the resemblance and containment of docu?ments [C]// Proceedings of the International Conference on Com?pression and Complexity of Sequences. Salerno，Italy：[s.n.]，1997：21?29.

[9] 孙有军，张大兴.海量图片文件存储去重技术研究[J].计算机应用与软件，2023（4）：56?57．

[10] RIVEST R. The MD5 message ? digest algorithm [J]. RFC1321，Internet Engineering Task Force，1992，22（1） ：15?26.

[11] 成功，李小正，赵全军.一种网络爬虫系统中URL去重方法的研究[J].中国新技术新产品，2023（12）：23?24．

[12] 杨祥清.存储系统数据去重策略研究[J].信息通信，2023（8）：132?133.

数据中心存储方案范文第5篇

法规遵从要求和新型的存储密集型应用（如电子邮件、多媒体、生命科学研究和生物统计学）正在合力将数据增长速度提高到前所未有的水平，并且已经使众多企业遭受数据增长失控的困扰。面对这种情况，大多数企业下意识的反应都是试图通过不断提供容量来满足数据增长的挑战，即一旦系统出现“磁盘空间已满”的标志，新的存储系统就会被立即连接到服务器上。但遗憾的是，在同一环境中的其他存储系统却闲置在一旁。这种系统饱和状态和闲置状态并存的分散式存储环境，从投资回报的角度看，无法对设备进行充分的利用，导致了存储设备的投资浪费; 从环保的角度看，为支持分散的存储系统所需的电力、冷却系统和地板空间等环境成本也必将水涨船高，导致了不必要的电力、散热、空间资源的浪费。

采用切实有效的虚拟化技术，数据中心的管理人员可以通过整合存储资源来积极面对失控的数据增长，在为企业存储环境重整秩序的同时节省数据中心的地板空间资源，并能降低数据中心对电力和散热的需求，从而显著减少与环境有关的成本。

日立数据系统(HDS)公司的智能虚拟存储控制器将磁盘介质与提供存储、数据及内容服务的智能控制器分离开来，日立能够为用户提供较强的灵活性，并在构建绿色数据中心方面具有得天独厚的竞争优势。

提高存储密度

存储基础架构对能源的消耗是和磁盘数直接挂钩的，而非存储的数据量，所以容量的密度越大就意味着能耗效率越高，因此利用虚拟化来部署分层存储和实施通用管理架构能够大大提高资源利用率。以HDS的USP为例，它不仅配有功能独特且强大的基于控制器的虚拟化引擎，还可以将控制器与存储介质相分离，允许企业将其DAS、NAS和SAN 都整合到一个存储平台中，使用户可以在短短几秒钟内将存储空间分配（或解除分配）给某个应用。

此外，USP还可以通过一个单一的控制器来管理整个数据中心高达32 PB的存储容量，大大提高了数据中心每平方米所能支持的TB数。在使用单个控制器的前提下，市场上部分同类产品仅能支持0.5 PB，其余产品也不过是1.2 PB。由于HDS的虚拟存储控制器能够通过单一的存储控制器管理庞大的存储量，因此虽然它拥有的处理器数量与市场上同类产品相同，但其单机所支持的存储容量却远远高于同类产品，从而能够带给企业显著的能源、散热及空间效益。据估算，HDS提供的虚拟化和逻辑分区功能能够将数据中心的能源及散热成本降低30%～50%。

减少热源

据Gartner统计，过去数据中心的散热所需电量只要60%，而今天这个数字已经攀升至100%――现在存储器每消耗1瓦电就需要额外1～1.5瓦的电力用于散热。降低数据中心散热需求的关键在于减少热源。存储和服务器机架应当配置成冷热交替排列，否则后排机架就会吸收临近的前排机架所排出的热量。在不采用虚拟化的情况下，管理人员就无法摆脱固定配置，而且还可能不得不加大散热能源的供应。通过利用虚拟化，管理人员就能够重新配置存储机架，不仅不会引起应用中断，还能充分利用更合理的散热配置。HDS提供的基于控制器的虚拟化能在任何环境下将控制器与存储介质相分离，而其他供应商仍局限于只对机柜中的存储器提供支持。HDS同时能够提供外部连接存储虚拟化，这表示企业可以在数据中心之外连接存储设备，从而减少数据中心的热源。

降低其他成本

HDS基于USP V平台率先在企业级虚拟层实现了Thin Provisioning(动态精细化预配置)功能：USP V和Hitachi Dynamic Provisioning (日立动态与配置)软件的结合使用户能够在一个整合的解决方案中同时获得外部存储虚拟化的益处以及由Thin Provisioning带来的电力和冷却成本方面的优势。由于传统的存储管理和主机卷管理都要求存储管理员预先为应用分配足够的存储空间，以便确保业务应用，因此管理员不得不通过过度地分配存储容量来避免因容量不足而导致应用崩溃的风险。但是这种固定的物理卷分配会造成存储容量的极大浪费，也会促使管理员为了克服时间与成本的限制而为现有的卷增加性能或容量，从而带来人为干预所导致的混乱。

USP V 打破了由于过度配置存储容量而造成的局限，它采用面向服务的方法为用户提供了一种新型的卷创建工具。Hitachi Dynamic Provisioning软件能够使用户根据自身所预期的未来需求合理分配虚拟磁盘存储，而无需预先分配专用的物理磁盘存储。如果未来应用需要更多的物理磁盘容量，用户可以在将来以更低的价格购买额外容量，并且透明地实施安装，不会造成其关键任务应用的中断。由于减少了对物理磁盘的需求，大大提高了容量利用率，因此也减少了对“占地面积”的需求，进而为用户大大降低了空间、电力和冷却方面的成本。

USP V还可以与日立 Tiered Storage Manager （分层存储管理软件）相结合，识别并应对不断变化的应用需求挑战，允许数据在存储层之间的频繁迁移以确保其一直处于最佳位置，从而使用户确保其数据始终处于最“环保”的位置。

另外，对于有大规模整合需求的企业用户以及生命科学、互联网服务及娱乐等数据密集型高性能计算领域的用户而言，高性能NAS系统有助于降低电力、散热和数据中心空间资源等成本。日立基于BlueArc技术的高性能NAS平台不仅能配置成集群，还具备先进的内置虚拟化系统，在很大程度上改变了用户的成本组成，能够在很大程度上节省用户的环境资源及成本。

专家点评