メタデータは、データを説明するデータ、データおよび情報リソースに関する説明情報として定義されます。
メタデータは、他のデータに関するデータ、または特定のリソースに関する情報を提供するために使用される構造化データです。メタデータは、情報リソースやデータなどのオブジェクトを記述するデータです。その使用目的は、リソースを識別すること、ネットワーク上の大量のデータの効率的な管理を実現することです。リソース、使用済みリソースの検索、統合組織、および効果的な管理。
現在、メタデータ管理にはいくつかの一般的に使用されているソリューションがあります: 中央ノード管理メタデータ、分散管理メタデータ、およびメタデータフリー設計。この記事では、次の 3 つのソリューションの特徴について説明します。
分散 (ストレージ) システムを設計する場合、セントラル ノードの使用は非常にシンプルで明確なソリューションです。セントラル ノードには通常、メタデータのストレージとクエリ、クラスター ノードのステータス管理、意思決定、およびその他の機能が備わっています。 ; 
利点:
A. メタデータの集中管理により、クラスターの運用および保守管理の統計分析要件を簡単に処理できます。
B. 中央ノードはユーザーデータのステータス情報を記録します。メタデータ) を拡張するときに、再バランス操作を実行しないことを選択できます (再バランスによるデータ移行により、パフォーマンスに大きなオーバーヘッドが生じる可能性があります)。それでも通常どおり対処できます。
欠点と解決策:
a。分散システムの設計において最もタブーな問題の 1 つは、セントラル ノードの単純な設計によってもたらされる問題です。 ; 解決策: (1) アクティブ/スタンバイ モデルを使用するか、増分または完全データ同期に同期または非同期方式 (TFS、mfs、HDFS2.0 など) を使用するか、リモート共有ストレージ (HDFS2.0 など) を使用します。 、リモート ストレージには高可用性が必要です);
b. 集中型セントラル ノード自体のハードウェア機能には、拡張 (スケールアップ) の上限があり、これにより、この問題については、クライアントがメタデータをキャッシュしたり、キャッシュ クラスターを使用したりしても、一部のシナリオ (大量の小さなファイルなど) では、この問題が依然として存在します。 解決策: (1) ハードウェアを最適化してアップグレードします。 SSD、大容量メモリ、その他のマシンの使用など。 (2) この問題に直面した場合は、分散管理メタデータ ソリューションの使用を検討してください。
2. メタデータの分散管理
は、メタデータがシャーディングされ、ストレージの管理に分散ノードが使用される点を除き、セントラル ノード ソリューションの利点を維持しながら、上限の問題を解決します。
デメリット
このようなシステムは比較的まれであり、システム自体が複雑な構造を持っています。実装も困難です。
a. システムには、メタデータ ノードとデータ ノードという 2 つの比較的独立した分散ノードが含まれており、各ノードで構成される分散モジュールは、分散 CAP 原則のトレードオフに直面する必要があります。スケーラブルであること、特にメタデータの一貫性
b. メタデータ ノードはデータ ノードのステータスを共同で維持し、ステータスが変化したときに一貫した決定を下す必要があり、これらはシステムの設計と実装に大きな課題をもたらします。
c. さらに、大量のメタデータに必要なストレージ設備にも無視できないコストがかかります
上記の 2 つのソリューションは、データ (つまりメタデータ) の状態を記録して維持するという同じ考えを持っています。データをアドレス指定するときに最初にメタデータ サーバーにクエリを実行し、次に実際のデータにアクセスします。
主に ceph を例として挙げますが、これは上記の 2 つのアイデアとは異なります。このタイプのシステムは、アルゴリズムを使用してアドレス指定を計算します。アドレス指定アルゴリズムの入力パラメータの 1 つは、クラスターの状態を何らかの形式で記述したものです (データ ノードの分散トポロジ、重み、プロセスの状態など)。一般的なアルゴリズムには、一貫したハッシュと Ceph RADOS システムの CRUSH アルゴリズムが含まれます。このタイプのアルゴリズムは通常、ユーザー データを直接管理しません。代わりに、論理シャーディング構造の中間層 (一貫したハッシュのリング セグメントや配置など) が導入されます。その粒度はより大きく、その数は制限されており、比較的固定されており、ユーザーがアクセスするデータはこれらのシャードの 1 つにのみ属し、その後、いくつかのユーザー データが管理および維持されます。このようなシステムには中央構成管理ノード (ceph rados モニターなど) もあり、クラスターやシャードなどの重要な状態の管理と保守のみを提供し、メタデータのストレージは提供しません。前述したように、システムは論理シャーディングやクラスターのステータスなどの情報を管理および維持するだけで済み、ユーザー データを管理するためのメタデータを保存する必要がなく、大量のメタデータが存在する場合にシステムの拡張性が大幅に向上します。これは、データ シナリオで特に顕著です。
B. アドレス指定アルゴリズムに必要なパラメータ データの量は少なく、クライアントは、アドレス指定のパフォーマンスを回避することで、複数のクライアントの並列アドレス指定の目的を達成できます。ボトルネック;
短所分析:
a. クラスターが拡張された場合 (または重みが変更された場合でも)、特にデータ規模が大きいクラスター (PB レベルを超える) では、再バランスを実行する必要があります。その結果、クラスターは高負荷状態になります。これにより、クラスターの負荷が高くなり、通常のビジネス リクエストのレイテンシーや IOP などのパフォーマンス指標が低下します。ただし、クラスターの拡張を実行する場合、再バランスが望ましくない場合もあります (クラスターの容量が不十分な場合など)。この点に関して、一般的な戦略は、拡張が必要な場合は、新しいクラスターを直接作成し、手動介入と電流制限を通じてクラスターの負荷を軽減することです。リバランスの基本的な理由として、拡張によってクラスターのステータスが変化し、その結果、アドレス指定アルゴリズムの結果と最終的なデータの分布も変化する必要があると考えられます。データの位置はアドレス指定アルゴリズムによって計算され、位置は比較的固定されており、手動で調整することはほとんどできません。ただし、データの全体的な分布は通常、重みを変更することで変更できます。
c 中央の構成管理ノードはシャードのみを管理します。統計分析の要件は、データノード情報を定期的に収集し、保存および維持することで実現する必要があります。
要約: 上記の比較分析を通じて、3 つのタイプのシステムのアドレッシング戦略は、システム自体に対応する長所と短所をもたらします。それらは完璧ではありませんが、システム設計とビジネスにおいてそれぞれ適切なシナリオとビジネスを持っています。その際には総合的な検討が必要となります。
