szhbsd 什么样的商业存储产品才能更适用区块链存储的应用？首先我们先要区分存储系统。市场上的存储系统有多种分类方法，常见的分类方式是按照架构和协议区分的。
从架构上分为Scale-up（纵向扩展）集中式和Scale-out（横向扩展）分布式两类。Scale-up架构受存储控制器扩展数量限制，常见的多为2控或4控的产品，其IO性能及磁盘扩展能力受限于控制器的数量。Scale-up架构的混闪和全闪存磁盘阵列，适用于对延迟较敏感但对存储容量和并发带宽要求一般的中小规模数据存储场景。
相反，Scale-out架构存储利用通用的以太网或高性能IB网络技术，存储节点（控制器）的数量可以从几十个扩展到几百甚至几千个，其存储性能和容量并不取决于单个存储节点的能力，而是聚合集群中所有节点的资源。分布式存储系统就是Scale-Out架构最典型的产品形态。
存储系统从协议上可分为块、文件、对象等几种类型。块存储为上层应用提供卷级裸设备存储空间，存储资源具有独享性，延迟较低、单个卷的存储空间一般不超过几十个TB，适用于数据库、虚拟化等典型应用场景；文件存储为上层应用提供目录级共享存储空间，取决于不同的文件系统，单个目录的空间大小可从TB到PB甚至EB级，适用于各类非结构化数据应用场景；与文件系统类似，对象存储同样为上层应用提供共享的存储空间，用于非结构化数据存储应用场景。
所以适合海量非结构化数据的存储系统包括分布式文件和分布式对象两类，但两者在数据组织结构和访问协议等方面存在显著差异。由于海量非结构化数据应用场景非常多，对存储系统的要求不同，具体选用哪种类型的存储，还需要对分布式文件和对象进行更详细的分析和对比。
成熟的分布式存储系统会随着业务场景的发展而不断完善。从起源上来看，分布式文件和对象都是随着大型互联网公司业务的快速扩张同步发展起来的，旨在解决其海量非结构化数据所带来的扩展性、可靠性和成本等瓶颈。
分布式文件系统
分布式文件系统的起源是Google于2003年发表的一篇论文《The Google File System》，其核心目标是设计一款具有高扩展能力和容错能力的高性能文件系统。该系统可以运行在廉价的商用硬件上，为前端大量客户端提供高性能、高可用的文件共享服务，解决海量非结构化数据的存储问题。
业界是这样定义分布式文件系统：基于一个单一并行文件系统组合多个存储节点为存储集群，为多个客户端的并发高带宽数据访问提供单一命名空间存储池。数据分散存储到集群中的多个节点上，基于数据自愈技术为客户端应用提供高可靠和高可用的数据服务，并可实现性能和容量的线性扩展。
分布式文件系统具有如下几个显著特性：
1、?高性能
分布式文件系统利用存储集群中所有节点的处理和IO性能提供高带宽并发数据访问，成熟的商业产品聚合访问带宽高达TB级，可以支持数千甚至数万节点的并发访问。
2、?易扩展
分布式文件系统可以便捷地在集群中添加数据节点，实现存储系统性能和容量的线性增加，存储节点可以扩展至数百甚至数千个，存储容量扩展至数百PB甚至EB级。
3、?高可靠、可用性
存储系统不依赖于单个设备的可靠性，采用集群架构，确保系统中无单点故障；同时支持副本以及N+M纠删码等数据保护技术，确保数据可用性；存储系统具有一定的硬件故障与数据故障的冗余自愈能力。
4、?高性价比
存储节点基于工业标准商用服务器，硬件的成本大幅降低。
5、?开放兼容性
提供NAS、FTP、HTTP等通用文件共享访问协议。
分布式对象存储系统
分布式对象存储系统定义如下：以对象结构来存储数据的存储系统，前端服务器客户端通过协议（例如HTTP）或者API接口（例如S3、Swift）进行访问。从概念上来说，对象与文件一样，都包括内容和元数据。与文件相比，对象通常支持更丰富的元数据，用户或应用可为对象设置用于管理、数据挖掘和数据迁移的元数据属性。
分布式对象存储系统与文件系统的差异
与分布式文件一样，分布式对象同样采用Scale-out分布式集群架构，具有易扩展、高可靠和高性价比等优势，其与文件系统在使用上的不同主要体现在如下几个方面：
1、支持的存储访问协议不同
分布式对象采用更加专用的协议（比如HTTP）或者API接口（例如S3或是Swift）进行访问，相比通用的NAS文件协议，需要前端应用做针对性的适配和接口定制开发。
2、支持的数据读写模式不同
与文件系统不同，分布式对象不支持数据的随机读取和写入，仅可针对整个文件做put或是get操作，这种模式基本把分布式对象限定在有限的数据写入后，有限的读取、极少修改的应用场景，例如互联网的云盘、备份归档以及法规遵从等温冷数据应用场景。
3、数据结构不同
文件采用树形目录结构，可以满足应用多级目录嵌套使用模式，但是随着嵌套层次和文件数量的增加，读取和存储数据时需要更长访问路径，当访问的文件过小时，单个文件访问性能受影响较大。
对象采用扁平目录结构，不支持多层嵌套的数据组织结构，只保留二级或是三级目录结构，只需要一个ID就能直接获取对象，这种数据结构在千亿级别海量小文件应用场景中会体现出一定的性能优势。
另外，对象目录结构更容易支持元数据定制，对象存储非常适合于与对象有关联性元数据的应用场景，对象存储允许为一个对象设置唯一的元数据属性，基于该元数据信息，可以从一个海量非结构化数据卷中快速的定位与读取该对象。
技术的发展并不是互相割裂、一成不变的，而是在相互借鉴中共同促进和发展。在分布式对象中应用比较广的N+M纠删码技术已成为分布式文件系统的标配，跨地域部署和数据容灾等功能也被越来越多成熟的分布式文件系统所支持。分布式文件系统利用高速SSD存储介质、元数据集群和小文件聚合等技术，支持的文件系统规模从十亿级向千亿级迈进，小文件访问性能提升明显；分布式对象也在利用高速SSD存储介质，进一步提升数据读取性能，从冷数据逐步向温、热数据应用场景推进。
分布式文件和对象的技术差异在逐步缩小。分布式文件由于其支持随机读写模式、协议的广泛兼容性、类似本地硬盘的展现形式更符合用户的使用习惯，在商业市场下有着普及性和大规模的应用案例，应用成熟度非常高。开源文件系统有Lustre、Gluster、BeeGFS和Ceph等，国内外专业存储厂商均开发了成熟的商用存储产品。
分布式对象受限于一写多读数据访问模式、专用的接口协议、扁平化的数据组织架构，其适用的应用场景远不如文件系统广泛。规模化的应用仅集中在有能力深度定制优化和开发的有限互联网场景中，比如Facebook自研的用于海量图片存储的HeyStack、Amazon研制的支撑其云业务的S3等。从技术实现层面而言，分布式对象的实现难度较低，开源产品有Ceph、Swift、Minio等，主要应用场景归纳如下：1、结合云应用提供业务数据的备份归档存储；2、金融证券、医疗等行业应用的法规遵从性文件的归档。另外商用的对象存储应用多以小规模、冷数据等限制性场景为主，对于数据写入和读取的实时效率要求并不高。
去中心化存储系统的“成色”由存储规模、数据IO性能、可靠性、在线扩容时间、数据重建影响等几个要素直接决定，具备大规模部署案例的分布式存储产品才能够经得起此类应用长期的考验。
从区块链IPFS实际应用的技术需求来看：
1、采用分布式对象存储意味着应用需要根据存储厂商对象接口API或SDK单独开发与维护。当前去中心化存储应用中，上层软件多样且迭代速度较快，已有软件环境也存在着频繁强制升级的现状，任何上层软件的变更都可能导致对象接口的迭代完善甚至重新开发，工作量巨大，运维
2、行业内大部分分布式对象系统是基于开源Ceph构建，以Ceph为代表的对象存储系统一般仅支持基于连接数的负载均衡策略，而商业全自研的文件系统可支持基于连接数、存储容量、节点负载等多维度的存储负载均衡，在多并发、存储性能异常时，可根据实际场景选择更优的负载均衡模式，以提升存储效率。
3、实际应用中1个扇区（Sector）文件大小是32GB。对象存储单次put上传的对象最大为5GB，对于32GB文件，对象存储系统必须在客户端上拆分成多段（如4个单独8GB）后，再进行并发传输；多个分段上传至存储系统后，再次合并成最终的Sector。多个Sector合并过程势必会对存储性能和数据抽取时间有较大影响，直接会影响Winning PoST完成时间，从而降低出块效率。
4、扇区文件（Sector）和扇区索引文件（Sector Cache）存在关联性，若采用优化手段增强其关联性，则会极大提升存储性能。对象存储需要多个桶分别存储扇区文件和扇区索引文件，一般需要通过人为设置桶的属性及大量桶之间的关联绑定。业务数据量增长迅速，额外的设置与调整，同样给业务运行及系统运维造成极大影响，这在实际应用中也是很难完成的。
综上分析，基于应用当前需求和特点，Filecoin的存储系统更适合采用成熟的分布式文件系统构建。另外，同时支持文件、对象、块协议的分布式统一存储将成为发展趋势，也为去中心化存储未来的多模式应用提供了技术可行性。
最后，笔者认为在选择合作的存储厂商时，首先，应关注其是否有专业的存储研发团队和完善的技术服务体系；其次，应具备超大规模系统部署和运维经验、快速应用适配定制和深度优化实力；最后，有着长远的分布式存储产品发展规划和资源投入。这样的存储厂商才能帮助用户搭建长期可靠的数据存储环境，支持去中心化存储市场和应用的快速发展与普及。
