記事のディレクトリ
序文
私は、外部アプリケーションを使用してHadoopのファイルシステムとして互換性のためにどのようにオゾンを説明する前に、我々はオゾンファイルシステムを呼んでいるもの。：オゾンファイルシステムが、キーオゾンで基盤となるストレージ形式を変更していないが、本質的には、それだけで、ツリーからのオゾンのボリュームへのパス、バケツ、鍵変換（詳細記事はここで見ることができます作られているされてオゾンファイルシステムの内部の仕組みを分析を達成）。基礎となるファイルを維持しながら、だから我々は、伝統的な意味での名前空間の組織形態に完全準拠のツリーでそれ以上の主要なオゾンの形で格納されたオブジェクトことができますか？本論文では、このコミュニティの著者は、現在実装プロセスで、オゾンの暫定計画について話をします。
名前空間の概要オゾンFS
まずオゾンFS名前空間と呼ばれるものを導入し、オゾンFS名前空間は、私たちがオゾン内のFileSystemの名前空間のサポートを実現する意味します。FS名前空間では、コンテンツとメタデータ情報のテーブルを持っているだけでなく、それらの間でファイルの組織と管理を上下。
オゾンFS名前空間のための既存のオゾンファイルシステムの実装と比較し、以下のような利点と欠点があります。
利点は：ファイル操作をより効率的に、名前空間ファイルシステム形式自体、より高い柔軟性を実現します。オゾンファイルシステムは既存のパスだけ外これを行うには、プレフィックスマッチング処理トラバーサル方法を使用して、ディレクトリレベルの操作で行われるパッケージング変換処理は、効率的なアプローチではありません。
短所：オゾンを導入した名前空間のフォームは、潜在的なオゾンのパフォーマンス上の問題を引き起こす可能性があります。変更は、既存の治療のためのFS名前空間マネージャーオゾン内部メタデータを更新されますので。
オゾンFS名前空間の設計
オゾンFS名前空間私たちは以下を見て構造の具体的な設計。この設計では、コミュニティは、2つのテーブルの分離は、ここで我々は単にディレクトリテーブルとファイルテーブルと呼ばれ、それぞれディレクトリとファイルをメタデータ情報を格納します。
例えば、情報フォーマットオゾンFS名前空間に格納された「/a/b/c/d/1.txt」という名前のファイルパス、ディレクトリ表の4つの入力項目、ファイルの表1のGe入力項目。
4つのディレクトリテーブルエントリ：A、B、C、D 。
1つのファイルテーブルエントリ：1.TXT。
エントリの個別の項目の光が十分ではありません、我々はまた、それらの組織の関係を欠いています。オゾンは、それが属している親ディレクトリの追加の節約prefix属性情報、親ディレクトリ情報のIDでここに表されています。
[親ユニーク-ID] / [ディレクトリ名] => [ディレクトリ一意のID]
ファイル情報は、上記と同様の示しています。
[親ユニーク-ID] / [ファイル名] => [OMのKeyInfo]
例えば次のよう/a/b/c/d/1.txtでは、実際のディレクトリテーブル、ファイルテーブルの格納形式は次のようになります。
ディレクトリ表：
| 接頭辞 | ID |
|---|---|
| / | 99 |
| 99 / A | 100 |
| 100 / B | 101 |
| 101 / C | 102 |
ファイルテーブル：
| ファイル名 | 主なメタデータ |
|---|---|
| 102 / 1.TXT | KeyInfo |
接頭辞は、エントリの各ディレクトリエントリの親ディレクトリパス部分は、単に、64ビット（8バイト）を使用するので、スペースの大幅なコスト削減を提供する上記の形式で格納されたデジタルIDによって表すことができます。例えば、32の平均値は、ファイル名をバイト場合、256バイト、100ワットファイルの消費の総経路長の256ギガバイト（= 2 ^ 30×256バイト）空間へ。プレフィックスモードは、我々は唯一のストレージの32バイトを使用する場合には、唯一のプレフィックスIDに8つのバイトを格納するための、その中に32GBまでの空間、私たちは、32バイトを使用する必要が。
しかし、メモリは他の分野で2つの欠陥を生じさせます。
- 操作を挿入する各ファイルのパスはディレクトリテーブル、ファイルテーブルの複数の挿入テーブルになりますが、フォローアップの親ディレクトリのが既に存在する場合は、親ディレクトリの挿入操作が近い、単一の挿入操作に、省略することができます。
- 徐々にファイルテーブル情報のパスを横断する必要が見つけます。すべての最終的なファイルのディレクトリ情報を取得するためのステップダウンバイステップを見つける必要があるので、そこに表には、レコードディレクトリエントリはありませんが、分割された預金カットオフので。従来の単一のディレクトリエントリとして良好と検索性能効率の名前空間に提示されるわけではありません。
しかし、道の構造全体、前述の新FS名前空間の何よりも空間と時間、空間でのシステムトレードオフ未満、保存する必要があり、効率が少し低下します。
オゾンFS名前空間の同時実行制御
オゾンFS名前空間は、実際の使用シナリオでは、ディレクトリ内のファイルのいくつかの非常に大規模なストレージのオーダーであるために同時実行制御FS名前空間がアップ見過ごすことができないため、そこです。
現在のプログラムは動作条件が再帰的にディレクトリを削除考慮せずに、同時実行制御は、ディレクトリのディレクトリレベルを行うことができるコミュニティです。簡単に言えば、ディレクトリレベルディレクトリにすべての私の運転制御は、基本的には、ロック粒度レベルの最小レベルである、動作しています。しかし、これの閉鎖のための制御はまた、我々はグローバルロックを導入する必要があり、アトミック性を確保するために、クロスディレクトリ間の操作が名前に変更します。一般的には、グローバルなロック制御が存在しないことを前提にして、彼らは更新されたディレクトリ・レベルのロックに合わせて業務を行っています。
引用文
[1] https://issues.apache.org/jira/browse/HDDS-2939。オゾンFSの名前空間
