数据库iops存储能指标(衡量数据库性能的重要指标)

一、磁盘性能指标mbs和iops换算吗

两者不能换算。

IOPS(Input/Output Operations Per Second)，即每秒进行读写（I/O）操作的次数。

而MB（全称MByte），计算机中的一种储存单位读作“兆”。数据单位MB与Mb。

简单来说，IOPS代表固态盘的读写速度，MB代表固态盘的内存大小。两者不能换算，就像“一个物体的长度和重量”不能换算一样。

扩展资料：

1、IOPS(Input/Output Per Second)即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。

2、随机读写频繁的应用，如小文件存储(图片)、OLTP数据库、邮件服务器，关注随机读写性能，IOPS是关键衡量指标。顺序读写频繁的应用，传输大量连续数据，如电视台的视频编辑，视频点播VOD(Video On Demand)，关注连续读写性能。数据吞吐量是关键衡量指标。

3、IOPS和数据吞吐量适用于不同的场合：

读取10000个1KB文件，用时10秒 Throught(吞吐量)=1MB/s，IOPS=1000追求IOPS

读取1个10MB文件，用时0.2秒 Throught(吞吐量)=50MB/s, IOPS=5追求吞吐量

参考资料：百度百科-IOPS

二、衡量数据库性能的重要指标

具体来说，本文包括以下内容:

事务

查询性能

用户和查询冲突

容量

配置

NoSQL数据库

事务

事务可以观察真实用户的行为：能够在应用交互时捕获实时性能。众所周知，测量事务的性能包括获取整个事务的响应时间和组成事务的各个部分的响应时间。通常我们可以用这些响应时间与满足事务需求的基线对比，来确定当前事务是否处于正常状态。

如果你只想衡量应用的某个方面，那么可以评估事务的行为。所以，尽管容器指标能够提供更丰富的信息，并且帮助你决定何时对当前环境进行自动测量，但你的事务就足以确定应用性能。无需向应用程序服务器获取 CPU的使用情况，你更应该关心用户是否完成了事务，以及该事务是否得到了优化。

补充一个小知识点，事务是由入口点决定的，通过该入口点可以启动事务与应用进行交互。

一旦定义了事务，会在整个应用生态系统中对其性能进行测量，并将每个事务与基线进行比对。例如，我们可能会决定当事务的响应时间与基线相比，一旦慢于平均响应时间的两个标准差是否就应该判定为异常，如图1所示。

图1-基于基线评估当前事务响应时间

用于评估事务的基线与正在进行的事务活动在时间上是一致的，但事务会由每个事务执行来完善。例如，当你选定一个基线，在当前事务结束之后，将事务与平均响应时间按每天的小时数和每周的天数进行对比，所有在那段时间内执行的事务都将会被纳入下周的基线中。通过这种机制，应用程序可以随时间而变化，而无需每次都重建原始基线；你可以将其看作是一个随时间移动的窗口。

总之，事务最能反映用户体验的测量方法，所以也是衡量性能状况最重要的指标。

查询性能

最容易检测到查询性能是否正常的指标就是查询本身。由查询引起的问题可能会导致时间太长而无法识别所需数据或返回数据。所以不妨在查询中排查以下问题。

1.选择过多冗余数据

编写查询语句来返回适当的数据是远远不够的，很可能你的查询语句会返回太多列，从而导致选择行和检索数据变得异常缓慢。所以，最好是列出所需的列，而不是直接用 SELECT*。当需要在特定字段中查询时，该计划可能会确定一个覆盖索引从而加快结果返回。覆盖索引通常会包含查询中使用的所有字段。这意味着数据库可以仅从索引中产生结果，而不需要通过底层表来构建。

另外，列出结果中所需的列不仅可以减少传输的数据，还能进一步提高性能。

2.表之间的低效联接

联接会导致数据库将多组数据带到内存中进行比较，这会产生多个数据库读取和大量 CPU。根据表的索引，联接还可能需要扫描两个表的所有行。如果写不好两个大型表之间的联接，就需要对每个表进行完整扫描，这样的计算量将会非常大。其他会拖慢联接的因素包括联接列之间存在不同的数据类型、需要转换或加入包含 LIKE的条件，这样就会阻止使用索引。另外，还需注意避免使用全外联接；在恰当的时候使用内部联接只返回所需数据。

3.索引过多或过少

如果查询优化没有可用的索引时，数据库会重新扫描表来产生查询结果，这个过程会生成大量的磁盘输入/输出（I/O）。适当的索引可以减少排序结果的需要。虽然非唯一值的索引在生成结果时，不能像唯一索引那样方便。如果键越大，索引也会变大，并通过它们创建更多的磁盘 I/O。大多数索引是为了提高数据检索的性能，但也需要明白索引本身也会影响数据的插入和更新，因为所有相关联的指标都必须更新。

4.太多的SQL导致争用解析资源

任何 SQL查询在执行之前都必须被解析，在生成执行计划之前需要对语法和权限进行检查。由于解析非常耗时，数据库会保存已解析的 SQL来重复利用，从而减少解析的耗时。因为 WHERE语句不同，所以使用文本值的查询语句不能被共享。这将导致每个查询都会被解析并添加到共享池中，由于池的空间有限，一些已保存的查询会被舍弃。当这些查询再次出现时，则需要重新解析。

用户和查询冲突

数据库支持多用户，但多用户活动也可能造成冲突。

1.由慢查询导致的页/行锁定

为了确保查询产生精确的结果，数据库必须锁定表以防止在运行读取查询时再发生其他的插入和更新行为。如果报告或查询相当缓慢，需要修改值的用户可能需要等待至更新完成。锁提示能帮助数据库使用最小破坏性的锁。从事务数据库中分离报表也是一种可靠的解决方法。

2.事务锁和死锁

当两个事务被阻塞时会出现死锁，因为每一个都需要使用被另一个占用的资源。当出现一个普通锁时，事务会被阻塞直到资源被释放。但却没有解决死锁的方案。数据库会监控死锁并选择终止其中一个事务，释放资源并允许该事务继续进行，而另一个事务则回滚。

3.批处理操作造成资源争夺

批处理过程通常会执行批量操作，如大量的数据加载或生成复杂的分析报告。这些操作是资源密集型的，但可能影响在线用户的访问应用的性能。针对此问题最好的解决办法是确保批处理在系统使用率较低时运行，比如晚上，或用单独的数据库进行事务处理和分析报告。

容量

并不是所有的数据库性能问题都是数据库问题。有些问题也是硬件不合适造成的。

1. CPU不足或 CPU速度太慢

更多 CPU可以分担服务器负载，进一步提高性能。数据库的性能不仅是数据库的原因，还受到服务器上运行其他进程的影响。因此，对数据库负载及使用进行审查也是必不可少的。由于 CPU的利用率时时在变，在低使用率、平均使用率和峰值使用率的时间段分别检查该指标可以更好地评估增加额外的 CPU资源是否有益。

2. IOPS不足的慢磁盘

磁盘性能通常以每秒输入/输出操作（IOPS）来计。结合 I/O大小，该指标可以衡量每秒的磁盘吞吐量是多少兆。同时，吞吐量也受磁盘的延迟影响，比如需要多久才能完成请求，这些指标主要是针对磁盘存储技术而言。传统的硬盘驱动器（HDD）有一个旋转磁盘，通常比固态硬盘（SSD）或闪存更慢。直到近期，SSD虽然仍比 HDD贵，但成本已经降了下来，所以在市场上也更具竞争力。

3.全部或错误配置的磁盘

众所周知，数据库会被大量磁盘访问，所以不正确配置的磁盘可能带来严重的性能缺陷。磁盘应该适当分区，将系统数据目录和用户数据日志分开。高度活跃的表应该区分以避免争用，通过在不同磁盘上存放数据库和索引增加并行放置，但不要将操作系统和数据库交换空间放置在同一磁盘上。

4.内存不足

有限或不恰当的物理内存分配会影响数据库性能。通常我们认为可用的内存更多，性能就越好。监控分页和交换,在多个非繁忙磁盘中建立多页面空间，进一步确保分页空间分配足够满足数据库要求；每个数据库供应商也可以在这个问题上提供指导。

5.网速慢

网络速度会影响到如何快速检索数据并返回给终端用户或调用过程。使用宽带连接到远程数据库。在某些情况下，选择 TCP/IP协议而不是命名管道可显著提高数据库性能。

配置

每个数据库都需设置大量的配置项。通常情况下，默认值可能不足以满足数据库所需的性能。所以，检查所有的参数设置，包括以下问题。

1.缓冲区缓存太小

通过将数据存储在内核内存，缓冲区缓存可以进一步提高性能同时减少磁盘 I/O。当缓存太小时，缓存中的数据会更频繁地刷新。如果它再次被请求，就必须从磁盘重读。除了磁盘读取缓慢之外，还给 I/O设备增添了负担从而成为瓶颈。除了给缓冲区缓存分配足够的空间，调优 SQL查询可以帮助其更有效地利用缓冲区缓存。

2.没有查询缓存

查询缓存会存储数据库查询和结果集。当执行相同的查询时，数据会在缓存中被迅速检索，而不需要再次执行查询。数据会更新失效结果，所以查询缓存是唯一有效的静态数据。但在某些情况下，查询缓存却可能成为性能瓶颈。比如当锁定为更新时，巨大的缓存可能导致争用冲突。

3.磁盘上临时表创建导致的 I/O争用

在执行特定的查询操作时，数据库需要创建临时表，如执行一个 GROUP BY子句。如果可能，在内存中创建临时表。但是，在某些情况下，在内存中创建临时表并不可行，比如当数据包含 BLOB或 TEXT对象时。在这些情况下，会在磁盘上创建临时表。大量的磁盘 I/ O都需要创建临时表、填充记录、从表中选择所需数据并在查询完成后舍弃。为了避免影响性能，临时数据库应该从主数据库中分离出来。重写查询还可以通过创建派生表来减少对临时表的需求。使用派生表直接从另一个 SELECT语句的结果中选择，允许将数据加到内存中而不是当前磁盘上。

NoSQL数据库

NoSQL的优势在于它处理大数据的能力非常迅速。但是在实际使用中，也应该综合参考 NoSQL的缺点，从而决定是否适合你的用例场景。这就是为什么NoSQL通常被理解为「不仅仅是 SQL」，说明了 NoSQL并不总是正确的解决方案，也没必要完全取代 SQL，以下分别列举出五大主要原因。

1.挑剔事务

难以保持 NoSQL条目的一致性。当访问结构化数据时，它并不能完全确保同一时间对不同表的更改都生效。如果某个过程发生崩溃，表可能会不一致。一致事务的典型代表是复式记账法。相应的信贷必须平衡每个借方，反之亦然。如果双方数据不一致则不能输入。NoSQL则可能无法保证「收支平衡」。

2.复杂数据库

NoSQL的支持者往往以高效代码、简单性和 NoSQL的速度为傲。当数据库任务很简单时，所有这些因素都是优势。但当数据库变得复杂，NoSQL会开始分解。此时，SQL则比 NoSQL更好地处理复杂需求，因为 SQL已经成熟，有符合行业标准的接口。而每个 NoSQL设置都有一个唯一的接口。

3.一致联接

当执行 SQL的联接时，由于系统必须从不同的表中提取数据进行键对齐，所以有一个巨大的开销。而 NoSQL似乎是一个空想，因为缺乏联接功能。所有的数据都在同一个表的一个地方。当检索数据时，它会同时提取所有的键值对。问题在于这会创建同一数据的多个副本。这些副本也必须更新，而这种情况下，NoSQL没有功能来确保更新。

4. Schema设计的灵活性

由于 NoSQL不需要 schema，所以在某些情况下也是独一无二的。在以前的数据库模型中，程序员必须考虑所有需要的列能够扩展，能够适应每行的数据条目。在 NoSQL下，条目可以有多种字符串或者完全没有。这种灵活性允许程序员迅速增加数据。但是，也可能存在问题，比如当有多个团体在同一项目上工作时，或者新的开发团队接手一个项目时。开发人员能够自由地修改数据库，也可能会不断实现各种各样的密钥对。

5.资源密集型

NoSQL数据库通常比关系数据库更加资源密集。他们需要更多的 CPU储备和 RAM分配。出于这个原因，大多数共享主机公司都不提供 NoSQL。你必须注册一个 VPS或运行自己的专用服务器。另一方面，SQL主要是在服务器上运行。初期的工作都很顺利，但随着数据库需求的增加，硬件必须扩大。单个大型服务器比多个小型服务器昂贵得多，价格呈指数增长。所以在这种企业计算场景下，使用 NoSQL更为划算，例如那些由谷歌和 Facebook使用的服务器。

三、存储性能和空间利用率哪个重要

最大限度地挖掘存储系统的性能潜力是用户永远的追求，但是，面对众多性能优化技术，还必须考虑到底是性能重要还是空间利用率重要。

在当前经济形势低迷的大背景下，挖掘现有存储系统的性能潜力成为用户的必然选择，不过追求性能只是一个方面。

看到的现象是大多数存储系统的空间利用率还不到50%，而且存储控制器的处理能力也只用到一小部分，这些都是让用户不可接受的事实。

在数据中心应用领域，通过服务器整合以及虚拟化技术，物理服务器的资源已经被最大化的利用起来，与此相反的是，存储效率低下的问题却成为用户的痛点。

若要实现服务器虚拟化的高效率，存储系统就必须跟得上，这是一个必要的前提，因此服务器虚拟化应用推动着存储技术向更高效的方向发展。

在虚拟化环境中，当前端服务器数量不断增加，后端存储阵列的不足便暴露出来，尤其表现在缺乏细粒度的分配和调动空间资源的能力方面。

因此，如果用户希望对数据中心进行高度整合，那么服务器虚拟化技术和高效的存储技术二者缺一不可。

存储效率是一个综合性的指标，实现最佳的存储效率意味着要在有效存储空间以及可用处理资源两方面都有出色表现，通常也是各产品之间相互竞争的重点。

StorageIO高级分析师GregSchulz说，“为了达到应用所需的IOPS能力，有些存储系统被设计得很大，通过大量磁盘的并发来提升IOPS，可是空间利用率却非常低，反之，追求空间利用率的最大化往往需要借助存储精简技术，比如压缩和重复数据删除等等，但是这些功能会对系统性能带来负面的影响“。

因此，达成高效的存储就需要在容量和性能之间寻找一个平衡点，根据应用需求的不同，对容量、处理能力、性能以及成本进行控制和优化。

保证存储效率有哪些基本条件优化存储系统的性能，本质上就是要尽可能地提高存储处理资源的利用率，同时尽量消除系统的瓶颈或阻塞。

随着处理资源利用率的增加，剩余的处理资源以及响应额外处理请求的能力相应的就会降低。

而且如果缓冲区太小，那么系统达到性能上限（瓶颈）的可能性就非常大。

举个例子来说，一个平均处理资源利用率在50%的磁盘阵列不太可能触及性能上限（瓶颈），而对于一个利用率达到80%的系统来说，这个可能性就要大得多。

高效存储技术及其对性能、容量和成本的影响由存储厂商或第三方公司提供的内嵌在存储系统内部或在外部附加的运行报告、监控以及存储分析功能是十分重要的，它们可以帮助用户更好的了解系统的运行情况，避免系统过度（过高）配置，并减少很多后期维护工作。

尤其是当用户需要优化性能或者按需增加处理资源时，这些组件的作用就会体现的非常明显。

对此，StorageIO高级分析师GregSchulz评价道：“无论是性能问题还是容量问题，好好利用存储厂商或第三方公司提供的工具都是十分重要的。

”这些工具不仅能够帮助用户定位性能的问题，更重要的方面在于它们可以帮助用户选择出最恰当的解决方案。

衡量一套存储系统的性能并不能依赖某个单一指标，而要考虑多种组合因素，它们每一项都对应用程序访问数据的速度有所影响。

其中，IOPS、吞吐带宽和访问延迟这三项指标是最关键的。

不过，指标数据究竟是好是坏还要考虑应用环境的差异，包括工作负载的类型（随机请求或者顺序请求）、数据块的大小、交易类型（读或是写），以及其他相关的能够影响性能的因素都依赖于应用程序本身的特点。

比方说，如果是流媒体视频应用，那么大文件快速顺序读性能和大数据块是最重要的；

而如果是虚拟化应用环境，那么随机读性能通常是最主要的考察指标。

下面的部分，将纵览那些可以优化性能并且提高存储资源利用率的技术，这里没有独门秘籍，因为每一种方法都有其优点和缺点。

通过堆砌磁盘数量来提高性能磁盘驱动器是一种机械装置，读写磁头通过在高速旋转盘片的内道和外道之间往复移动来寻找并读写数据。

即使是转速最快的15000转磁盘，其磁头机械臂的重定位时间延迟都会有数毫秒之多，因此每个磁盘的IOPS值最多只有几百个，吞吐带宽则局限在100MB/秒以内。

通过将数据分布在多个磁盘上，然后对多个磁盘同步进行读写访问是一种常见的扩展性能的方法。

通过增加磁盘的个数，系统整体的IOPS和带宽值也会等比例提升。

加之，有些存储厂商还提供shortstr好ing这样的可以缩短磁头机械臂移动距离的技术。

此类技术可以将数据集中放置在磁盘盘片的外道区域，结果是磁头移动的距离大大缩短，对数据访问的性能具有十分明显的提升作用。

可是，当通过利用大量的磁盘并发以及short-str好ing磁头短距离移动技术达成既定的性能目标之后，会发现其代价是非常高昂的，此外，由于仅仅使用了盘片的外道空间，所以存储的空间利用率会非常差。

早在SSD固态盘技术出现之前，利用大量的磁盘并发以及short-str好ing磁头短距离移动技术来满足应用的性能要求是最普遍的办法，即使在今天，这种方案依然被大量使用，原因是SSD固态盘的成本太高，所以用户依然青睐磁盘而不是SSD。

NatApp技术和战略总监MikeRiley就说：“对于顺序访问大数据块和大文件这样的应用，使用磁盘通常性价比更高。

”RAID及wide-striping技术对效率的影响很多用户容易忽视一点，即RAID和RAID级别其实都会对性能和容量产生影响。

通过改变RAID级别来提升存储性能或者空间的利用率是一种很现实的选择。

校验盘的数量、条带的大小、RAID组的尺寸以及RAID组内数据块大小都会影响性能和容量。

RAID技术对性能和容量的影响都熟悉那些常见的RAID级别及其特点，但还有一些不常见的技术趋势值得关注，这些都与讨论的存储效率有关。

首先，RAID组的尺寸会影响性能、可用性以及容量。

通常，大的RAID组包含的磁盘数量更多，速度也更快，但是，当出现磁盘故障后，大RAID组也需要更多的时间用来重建。

每隔几年，磁盘的容量都会翻一番，其结果是RAID重建的时间也相应变的更长，在数据重建期间出现其他磁盘故障的风险也变得更大。

即使是带有双校验机制，允许两块磁盘同时出现故障的RAID6也存在风险增加的问题，况且，RAID6对性能的影响还比较大。

有一个更好的办法是完全打破传统RAID组和私有校验盘的概念，比如，NetApp的DynamicDiskPools（DDP）技术，该技术将数据、校验信息以及闲置空间块分散放置在一个磁盘池中，池中所有的磁盘会并发处理RAID重建工作。

另一个有代表性的产品是HP的3PAR存储系统，3PAR采用了一种叫做widestriping的技术，将数据条块化之后散布在一大堆磁盘上，同时磁盘自身的裸容量又细分成若干小的存储块（chunklet）。

3PAR的卷管理器将这些小的chunklet组织起来形成若干个micro-RAID（微型RAID组），每个微型RAID组都有自己的校验块。

对于每一个单独的微型RAID组来说，其成员块（chunklet）都分布在不同的磁盘上，而且chunklet的尺寸也很小，因此数据重建时对性能的冲击和风险都是最小的。

固态存储毫无疑问，SSD固态存储的出现是一件划时代的“大事儿“，对于存储厂商来说，在优化性能和容量这两个方面，SSD技术都是一种全新的选择。

与传统的磁盘技术相比，SSD固态盘在延迟指标方面有数量级上的优势（微秒对毫秒），而在IOPS性能上，SSD的优势甚至达到了多个数量级（10000以上对数百）。

Flash技术（更多的时候是磁盘与flash的结合）为存储管理员提供了一种更具性价比的解决方案，不必像过去那样，为了满足应用对性能的高要求而不得不部署大批量的磁盘，然后再将数据分散在磁盘上并发处理。

SSD固态盘最佳的适用场景是大量数据的随机读操作，比如虚拟化hypervisor，但如果是大数据块和大文件的连续访问请求，SSD的优势就没有那么明显了。

EMC统一存储部门负责产品管理与市场的高级副总裁EricHerzog说：“Flash的价格仍然10倍于最高端的磁盘，因此，用户只能酌情使用，而且要用在刀刃上。

”目前，固态存储有三种不同的使用方式：第一种方式，用SSD固态盘完全代替机械磁盘。

用SSD替换传统的磁盘是最简单的提升存储系统性能的方法。

如果选择这个方案，关键的一点是用户要协同存储厂商来验证SSD固态盘的效果，并且遵循厂商提供的建议。

如果存储系统自身的处理能力无法承载固态存储的高性能，那么SSD有可能会将整个系统拖垮。

因为，如果SSD的速度超出了存储控制器的承受范围，那么很容易出现性能（I/O阻塞）问题，而且会越来越糟。

另一个问题涉及到数据移动的机制，即的数据在什么时候、以何种方式迁移到固态存储上，或从固态存储上移走。

最简单但也最不可取的方法是人工指定，比如通过手动设定将数据库的日志文件固定存放在SSD固态存储空间，对于比较老的存储系统来说，这也许是唯一的方式。

在这里推荐用户使用那些自动化的数据分层移动技术，比如EMC的FAST（FullyAutomatedStorageTiering）。

第二种方式，用Flash（固态存储芯片）作为存储系统的缓存。

传统意义上的DRAM高速缓存容量太小，因此可以用Flash作为DRAM的外围扩展，而这种利用Flash的方式较之第一种可能更容易实现一些。

Flash缓存本身是系统架构的一个组成部分，即使容量再大，也是由存储控制器直接管理。

而用Flash作缓存的设计也很容易解决数据分层的难题，根据一般的定义，最活跃的数据会一直放置在高速缓存里，而过期的数据则驻留在机械磁盘上。

与第一种方式比较，存储系统里所有的数据都有可能借助Flash高速缓存来提升访问性能，而第一种方式下，只有存放在SSD固态盘中的数据才能获得高性能。

初看起来，用Flash做高速缓存的方案几乎没有缺陷，可问题是只有新型的存储系统才支持这种特性，而且是选件，因此这种模式的发展受到一定的制约。

与此相反，看到用Flash做大容量磁盘的高速缓存（而不是系统的高速缓存）反而成为更普遍的存储架构设计选择，因为它可以将高容量和高性能更好的融合。

IBM存储软件业务经理RonRiffe说：“在一套磁盘阵列中，只需要增加2-3%的固态存储空间，几乎就可以让吞吐带宽提高一倍。

”在服务器中使用Flash存储卡。

数据的位置离CPU和内存越近，存储性能也就越好。

在服务器中插入PCIeFlash存储卡，比如Fusion-IO，就可以获得最佳的存储性能。

不太有利的一面是，内置的Flash存储卡无法在多台服务器之间共享，只有单台服务器上的应用程序才能享受这一好处，而且价格非常昂贵。

尽管如此，仍然有两个厂商对此比较热衷，都希望将自己的存储系统功能向服务器内部扩展。

一个是NetApp，正在使其核心软件DataOntap能够在虚拟机hypervisor上运行；

另一个是EMC，推出的功能叫做VFCache（原名叫ProjectLightning）。

显而易见，这两家公司的目标是通过提供服务器端的Flash存储分级获得高性能，而这种方式又能让用户的服务器与提供的外部存储系统无缝集成。

存储加速装置存储加速装置一般部署在服务器和存储系统之间，既可以提高存储访问性能，又可以提供附加的存储功能服务，比如存储虚拟化等等。

多数情况下，存储加速装置后端连接的都是用户已有的异构存储系统，包括各种各样的型号和品牌。

异构环境的问题是当面临存储效率低下或者性能不佳的困扰时，分析与评估的过程就比较复杂。

然而，存储加速装置能够帮助已有磁盘阵列改善性能，并将各种异构的存储系统纳入一个统一的存储池，这不但可以提升整个存储环境的整体性能、降低存储成本，而且还可以延长已有存储的服役时间。

最近由IBM发布的SmartCloudVirtualStorageCenter是此类产品的代表，它将IBM的存储虚拟化软件SVC（SANVolumeController）以及存储分析和管理工具集成在一个单独的产品中。

SmartCloudVirtualStorageCenter可以将各种异构的物理存储阵列纳入到一个虚拟存储池中，在这个池之上创建的卷还支持自动精简配置。

该装置不但可以管理连接在其后的存储阵列中的Flash固态存储空间，而且SmartCloudVirtualStorageCenter自身内部也可以安装Flash固态存储组件。

通过实时存储分析功能，SmartCloudVirtualStorageCenter能够识别出I/O访问频繁的数据以及热点区域，并能够自动地将数据从磁盘迁移到Flash固态存储上，反向亦然。

用户可以借助SmartCloudVirtualStorageCenter的这些功能大幅度的提高现有的异构混合存储系统环境的性能和空间利用率。

与IBMSmartCloudVirtualStorageCenter类似的产品还有Alacritech和Avere，它们都是基于块或基于文件的存储加速设备。

日益增加的存储空间利用率利用存储精简技术，可以最大化的利用起可用的磁盘空间，存储精简技术包括自动精简配置、瘦克隆、压缩以及重复数据删除等等。

这些技术都有一个共同的目标，即最大程度的引用已经存在的数据块，消除或避免存储重复的数据。

然而存储精简技术对系统的性能稍有影响，所以对于用户来说，只有在明确了性能影响程度并且能够接受这种影响的前提下，才应该启动重复数据删除或数据压缩的功能。

性能和容量：密不可分存储系统的性能和空间利用率是紧密相关的一对参数，提升或改进其中的一个，往往会给另一个带来负面的影响。

因此，只有好好的利用存储分析和报表工具，才能了解存储的真实性能表现，进而发现系统瓶颈并采取适当的补救措施，这是必要的前提。

总之，提高存储效率的工作其实就是在性能需求和存储成本之间不断的寻找平衡。