minio元数据实现单独存储2

有人问我第一篇为什么不实现将元数据增删改查底层全部替换，详见第一篇minio元数据实现单独存储。
我本身属于一个很懒的人，能坚持写博客已属实不易，写博客也是想到哪写到哪，第一篇中minio元数据分离的实现代码非常简单，当然也可以全部元数据增删改查底层全部替换，但是需要大量测试，下面讲讲大概如何实现底层全部替换，以及我第一篇中的优缺点。

一.minio元数据增删改查底层全部替换实现

首先找到storage-interface.go这个文件，然后找到StorageAPI接口，此接口存在几个操作元数据方法如下：

	DeleteVersion(ctx context.Context, volume, path string, fi FileInfo, forceDelMarker bool) error//删除元数据
	DeleteVersions(ctx context.Context, volume string, versions []FileInfoVersions) []error//删除元数据
	WriteMetadata(ctx context.Context, volume, path string, fi FileInfo) error//写元数据
	UpdateMetadata(ctx context.Context, volume, path string, fi FileInfo, opts UpdateMetadataOpts) error//更新元数据
	ReadVersion(ctx context.Context, volume, path, versionID string, readData bool) (FileInfo, error)//读元数据
	ReadXL(ctx context.Context, volume, path string, readData bool) (RawFileInfo, error)//读元数据，不解释它读取的数据。相当于ReadVersion()的原始调用。
	RenameData(ctx context.Context, srcVolume, srcPath string, fi FileInfo, dstVolume, dstPath string) (uint64, error)//修改文件path

StorageAPI接口有几个实现类，只要关心xl-storage.go这个文件的实现即可，以上方法修改起来并不难，可以将底层全部替换成第三方组件，比如mongo，redis等，但需要大量测试minio各类场景，此全量替换的优点是minio元数据将不在保存到服务器上，将大大减少服务器文件存储，以及提升读写性能，但这种改造需要大量测试以及熟知minio，一旦改动有bug或许是灾难性的。

二.minio元数据实现单独存储第一篇的优缺点

优点：改造简单，不改变存储结构，同时提升读minio元数据的性能。
缺点：虽然改造简单，但是并未减少服务器文件的数据量，当minio读取文件时，还是会受到文件量的影响。

三.liunx下的文件系统

Linux 文件系统设计了两个数据结构来管理这些不同种类的文件：
1.inode(index node)：索引节点，inode 是用来记录文件的 metadata，所谓 metadata 在 Wikipedia 上的描述是 data of data，其实指的就是文件的各种属性，比如 inode 编号、文件大小、访问权限、修改日期、数据的位置等。
2.dentry(directory entry)：目录项，dentry 用来记录文件的名字、inode 指针以及与其他 dentry 的关联关系。

四.LOSF问题根源

衡量存储系统性能主要有两个关键指标，即IOPS和数据吞吐量。IOPS (Input/Output Per Second) 即每秒的输入输出量 ( 或读写次数 ) ，是衡量存储系统性能的主要指标之一。 IOPS 是指单位时间内系统能处理的 I/O 请求数量，一般以每秒处理的 I/O 请求数量为单位， I/O 请求通常为读或写数据操作请求。随机读写频繁的应用，如 OLTP( OnlineTransaction Processing ) ，IOPS 是关键衡量指标。另一个重要指标是数据吞吐量( Throughput )，指单位时间内可以成功传输的数据数量。对于大量顺序读写的应用，如VOD( VideoOn Demand )，则更关注吞吐量指标。

传统磁盘本质上一种机械装置，如 FC, SAS, SATA 磁盘，转速通常为 5400 / 7200 / 10K / 15K rpm不等。影响磁盘的关键因素是磁盘I/O服务时间，即磁盘完成一个I/O请求所花费的时间，它由寻道时间、旋转延迟和数据传输时间三部分构成。因此可以计算磁盘的IOPS= 1000 ms/ (Tseek + Troatation + Ttransfer)，如果忽略数据传输时间，理论上可以计算出磁盘的最大IOPS。当I/O访问模式为随机读写时，寻道时间和旋转延迟相对于顺序读写要明显增加，磁盘IOPS远小于理论上最大值。定义有效工作时间Pt=磁盘传输时间/磁盘I/O服务时间，由此可知随机读写单个文件效率要低于连续读写多个文件。对于磁盘文件系统来说，无论读写都存在元数据操作。以EXTx文件系统写数据为例，向磁盘写入数据进行大量的元数据操作，包括更新inode目录、目录、inode和数据块位图等。定义有效数据读写率Pd=所需数据/实际磁盘读写数据，其中实际磁盘读写数据为磁盘元数据与所需数据之和。当操作连续大文件时，对元数据的操作开销可被庞大的数据操作开销分摊，但小文件的有效读写率小于大文件的，当小文件数量急剧增加时，对大量元数据的操作会严重影响系统的性能。
从上面对磁盘介质的分析可以看出，磁盘最适合顺序的大文件I/O读写模式，但非常不适合随机的小文件I/O读写模式，这是磁盘文件系统在海量小文件应用下性能表现不佳的根本原因。

所以以上元数据是否保存在文件服务器上，是影响性能的一个重要指标。