ファイルシステムの原理

ファイルとハードディスクの管理は、コンピュータ オペレーティング システムの重要な部分です。これは、マイクロソフトが成功への道を歩むきっかけとなった、マイクロソフトが発売した最初のパーソナル コンピュータ PC オペレーティング システムです。このオペレーティング システムは、DOS、ディスク オペレーティング システム、ハードディスク オペレーティング システムと呼ばれていますシステム。毎日コンピュータを使用する場合、ハードディスクが欠かせません。ハードディスクにはサイズ制限があり、通常、より大きなハードディスクでも数テラバイトしかなく、速度制限もあります。より高速なハードディスクでも数百メガバイトしかありません。毎秒。

ファイルはハード ディスクに保存され、ファイルの読み取りおよび書き込みアクセス速度はハード ディスクの物理的制限によって制限されるため、100T の大きなファイルの走査を 1 分で完了するにはどうすればよいでしょうか?

この質問に対する答えを知るには、ファイル システムの原理を知る必要があります。

ソフトウェア開発を行う場合、ファイル システムを扱うことがよくありますが、ファイル システムもソフトウェアの一部です。ファイル システムの設計原則を理解することで、ファイル システムをより適切に使用できるようになります。また、ファイル システムを設計する際には、さまざまな考慮事項が必要になります。ファイル システムも私たちにとって重要であり、自分でソフトウェアを設計する場合には、多くの参考になります。

ハードドライブの物理構造から始めましょう。

ハードディスク

ハードディスクは、データを永続化し、複数回読み書きできる記憶媒体です。ハードディスクには主に 2 つのタイプがあり、1 つはメカニカル ハードディスク、もう 1 つはソリッド ステート ハードディスクです。

メカニカルハードディスクの構造は主にディスク、スピンドル、磁気ヘッドアームで構成され、スピンドルによってディスクが高速回転し、トラック上にデータが記録されます。データの読み取りと書き込みには磁気ヘッドを移動する必要があり、このような機械的動作には少なくとも数ミリ秒かかり、これが機械的ハードディスク アクセスの遅延の主な原因です。

データベースのB+ツリーファイルのように、ファイルのデータがハードディスク上に連続的に格納されていない場合、このファイルを読み込むためにヘッドアームを往復させる必要があり、時間がかかります。ログ ファイルなど、ファイル データが連続して保存される場合、ヘッド アームの移動が少なくなり、連続的に保存されたファイルの読み取りおよび書き込み速度は、離散的に保存された同じサイズのファイルの読み取りおよび書き込み速度よりもはるかに速くなります。

機械式ハードディスクのデータは磁気ディスクに保存されるため、このハードディスクは磁気ディスクとも呼ばれますが、ソリッドステート ハードディスクにはそのような磁気記憶媒体やモーター駆動の機械式ディスクはありません。構造。

このうち、メイン制御チップはポートから入力された命令とデータを処理し、フラッシュメモリ粒子を制御してデータを読み書きします。ソリッドステート ハードディスクは、ヘッド アームを駆動して機械的な物理的動作を行う機械式ハードディスクのようなモーターを持たず、完全に電子的に動作するため、ソリッドステート ハードディスクのアクセス速度は、ソリッドステート ハードディスクのアクセス速度よりもはるかに高速です。メカニカルハードディスク。

ただし、これまでのところ、ソリッド ステート ドライブのコストは機械式ハード ドライブのコストよりも大幅に高いため、実稼働環境では依然として最も重要なストレージ メディアは機械式ハード ドライブです。シナリオにデータ アクセス速度、ストレージ容量、およびコストに対する高い要件がある場合は、ソリッド ステート ドライブとメカニカル ハード ドライブのハイブリッド展開を使用できます。つまり、サーバーにはソリッド ステート ドライブとメカニカル ハード ドライブの両方が搭載されており、さまざまなファイル タイプのストレージ要件を満たします。たとえば、ログ ファイルは機械式ハード ドライブに保存され、システム ファイルとランダムな読み取り/書き込みファイルはソリッド ステート ドライブに保存されます。

ファイルシステム

アプリケーション開発者はハードディスクを直接操作する必要はなく、オペレーティング システムを通じてファイル形式でハードディスク上のデータに読み書きアクセスできます。ファイルシステムはハードディスクスペースをブロックに分割し、各ファイルはいくつかのブロックを占有し、ファイル制御ブロックFCBを通じて各ファイルが占有するハードディスクデータブロックを記録します。

alt

このファイル制御ブロックは、Linux オペレーティング システムの i ノードです。ファイルにアクセスする場合は、ファイルの i ノード情報を取得し、inode 内のファイル データ ブロック インデックス テーブルを検索し、ハード ディスクに従ってハードディスクにアクセスする必要があります。インデックスに記録されているディスクアドレス情報と、データの読み書きを行います。

i ノードには、ファイルのアクセス権、所有者、変更時刻、ファイル サイズなどのファイル属性情報と、ファイル データ ブロックのハードディスク アドレス インデックスが記録されます。i ノードの構造は固定されており、記録できるハードディスク アドレス インデックスの数も固定で、15 インデックスのみです。このうち、最初の 12 インデックスはデータ ブロックのアドレスを直接記録し、13 番目のインデックスはインデックス アドレスを記録します。つまり、インデックス ブロックが指すハードディスク データ ブロックにはファイル データが直接記録されませんが、ファイル データ ブロックのインデックス テーブルを記録します。次の図に示すように、各インデックス テーブルには 256 個のインデックスを記録できます。14 番目のインデックスは 2 次インデックス アドレスを記録し、15 番目のインデックスは 3 次インデックス アドレスを記録します。

alt

このようにして、各 i ノードには最大 12+256+256*256+256*256*256 個のデータ ブロックを保存できます。各データ ブロックのサイズが 4k の場合、つまり 1 つのファイルの最大サイズは 70G を超えません。 、データ ブロックを拡大できる場合でも、ファイル サイズは 1 台のハードディスクの容量によって制限されます。この場合、Linux ファイル システムは、最初に提案した 100T の大きなファイルの走査を 1 分間で完了することはできません。

では、より強力な解決策はあるのでしょうか?

RAID

RAID,即独立硬盘冗余阵列,将多块硬盘通过硬件RAID卡或者软件RAID的方案管理起来,使其共同对外提供服务。RAID的核心思路其实是利用文件系统将数据写入硬盘中不同数据块的特性,将多块硬盘上的空闲空间看做一个整体,进行数据写入,也就是说,一个文件的多个数据块可能写入多个硬盘。

根据硬盘组织和使用方式不同,常用RAID有五种,分别是RAID 0、RAID 1、RAID 10、RAID 5和RAID 6。

alt

RAID 0将一个文件的数据分成N片,同时向N个硬盘写入,这样单个文件可以存储在N个硬盘上,文件容量可以扩大N倍,(理论上)读写速度也可以扩大N倍。但是使用RAID 0的最大问题是文件数据分散在N块硬盘上,任何一块硬盘损坏,就会导致数据不完整,整个文件系统全部损坏,文件的可用性极大地降低了。

RAID 1则是利用两块硬盘进行数据备份,文件同时向两块硬盘写入,这样任何一块硬盘损坏都不会出现文件数据丢失的情况,文件的可用性得到提升。

RAID 10结合RAID 0和RAID 1,将多块硬盘进行两两分组,文件数据分成N片,每个分组写入一片,每个分组内的两块硬盘再进行数据备份。这样既扩大了文件的容量,又提高了文件的可用性。但是这种方式硬盘的利用率只有50%,有一半的硬盘被用来做数据备份。

RAID 5针对RAID 10硬盘浪费的情况,将数据分成N-1片,再利用这N-1片数据进行位运算,计算一片校验数据,然后将这N片数据写入N个硬盘。这样任何一块硬盘损坏,都可以利用校验片的数据和其他数据进行计算得到这片丢失的数据,而硬盘的利用率也提高到N-1/N。

RAID 5可以解决一块硬盘损坏后文件不可用的问题,那么如果两块文件损坏?RAID 6的解决方案是,用两种位运算校验算法计算两片校验数据,这样两块硬盘损坏还是可以计算得到丢失的数据片。

实践中,使用最多的是RAID 5,数据被分成N-1片并发写入N-1块硬盘,这样既可以得到较好的硬盘利用率,也能得到很好的读写速度,同时还能保证较好的数据可用性。使用RAID 5的文件系统比简单的文件系统文件容量和读写速度都提高了N-1倍,但是一台服务器上能插入的硬盘数量是有限的,通常是8块,也就是文件读写速度和存储容量提高了7倍,这远远达不到1分钟完成100T文件的遍历要求。

那么,有没有更给力的解决方案呢?

分布式文件系统

我们再回过头看下Linux的文件系统:文件的基本信息,也就是文件元信息记录在文件控制块inode中,文件的数据记录在硬盘的数据块中,inode通过索引记录数据块的地址,读写文件的时候,查询inode中的索引记录得到数据块的硬盘地址,然后访问数据。

如果将数据块的地址改成分布式服务器的地址呢?也就是查询得到的数据块地址不只是本机的硬盘地址,还可以是其他服务器的地址,那么文件的存储容量就将是整个分布式服务器集群的硬盘容量,这样还可以在不同的服务器上同时并行读取文件的数据块,文件访问速度也将极大的加快。

这样的文件系统就是分布式文件系统,分布式文件系统的思路其实和RAID是一脉相承的,就是将数据分成很多片,同时向N台服务器上进行数据写入。针对一片数据丢失就导致整个文件损坏的情况,分布式文件系统也是采用数据备份的方式,将多个备份数据片写入多个服务器,以保证文件的可用性。当然,也可以采用RAID 5的方式通过计算校验数据片的方式提高文件可用性。

我们以Hadoop分布式文件系统HDFS为例,看下分布式文件系统的具体架构设计。

alt

HDFS的关键组件有两个,一个是DataNode,一个是NameNode。

DataNode负责文件数据的存储和读写操作,HDFS将文件数据分割成若干数据块(Block),每个DataNode存储一部分数据块,这样文件就分布存储在整个HDFS服务器集群中。应用程序客户端(Client)可以并行对这些数据块进行访问,从而使得HDFS可以在服务器集群规模上实现数据并行访问,极大地提高了访问速度。在实践中,HDFS集群的DataNode服务器会有很多台,一般在几百台到几千台这样的规模,每台服务器配有数块硬盘,整个集群的存储容量大概在几PB到数百PB。

NameNode负责整个分布式文件系统的元数据(MetaData)管理,也就是文件路径名、访问权限、数据块的ID以及存储位置等信息,相当于Linux系统中inode的角色。HDFS为了保证数据的高可用,会将一个数据块复制为多份(缺省情况为3份),并将多份相同的数据块存储在不同的服务器上,甚至不同的机架上。这样当有硬盘损坏,或者某个DataNode服务器宕机,甚至某个交换机宕机,导致其存储的数据块不能访问的时候,客户端会查找其备份的数据块进行访问。

有了HDFS,可以实现单一文件存储几百T的数据,再配合大数据计算框架MapReduce或者Spark,可以对这个文件的数据块进行并发计算。也可以使用Impala这样的SQL引擎对这个文件进行结构化查询,在数千台服务器上并发遍历100T的数据,1分钟都是绰绰有余的。

总结

文件系统从简单操作系统文件,到RAID,再到分布式文件系统,其设计思路其实是具有统一性的。这种统一性一方面体现在文件数据如何管理,也就是如何通过文件控制块管理文件的数据,这个文件控制块在Linux系统中就是inode,在HDFS中就是NameNode。

另一方面体现在如何利用更多的硬盘实现越来越大的文件存储需求和越来越快的读写速度需求,也就是将数据分片后同时写入多块硬盘。单服务器我们可以通过RAID来实现,多服务器则可以将这些服务器组成一个文件系统集群,共同对外提供文件服务,这时候,数千台服务器的数万块硬盘以单一存储资源的方式对文件使用者提供服务,也就是一个文件可以存储数百T的数据,并在一分钟完成这样一个大文件的遍历。

本文由 mdnice 多平台发布

おすすめ

転載: blog.csdn.net/qq_35030548/article/details/131179877