クエリ パフォーマンスの最適化
フェデレーティッドデータベースインスタンスのパフォーマンスは、次の要因に影響されます。
S 3内のデータの構造と、フェデレーティッドデータベースインスタンス構成でそれを表現する方法。
データファイルのサイズ。
データファイルの形式と構造。
S3 のデータ構造
管理を容易にするために、データがパーティションに論理的にグループ化されていることを確認します。 Atlas Data Federation は、パーティション構文で指定したフィールド値を使用して作成したパーティションを使用します。 パーティション構造がクエリ パターンにマッピングされ、パーティション構造が databases.[n].collections.[n].dataSources.[n].pathで定義されていることを確認することで、フェデレーティッドデータベースインスタンスのパフォーマンスを向上させることができます。 パーティションには、頻繁にクエリを実行するフィールドを選択し、最初の位置の最も頻繁にクエリが実行されるフィールドから、最後の位置のクエリが最も少ないフィールドの順に並べ替えます。
databases.[n].collections.[n].dataSources.[n].pathにリストされるフィールドの順序は、 複合インデックスと同様に重要です。 指定されたパスは、最初に最初のフィールドの値によって分割されたデータに対応し、次に次のフィールドの値によって分割されたデータに対応します。
例
たとえば、 software 、 computer 、 OSフィールドと という名前のS3バケット上のパーティションがあるコレクションで、最初にsoftware metrics 、次にcomputerフィールド、次にOSフィールドという名前の S3 バケット上のパーティションがあるとします。フィールドのマルチキー インデックスの図。
metrics |--software |--computer |--OS
Atlas Data Federation は、次のフィールドのクエリにパーティションを使用します。
softwareフィールドsoftwareフィールドとcomputerフィールドsoftwareフィールドとcomputerフィールドとOSフィールド
Atlas Data Federation はパーティションを使用して、 フィールドとsoftware OSフィールドに対するクエリをサポートできます。ただし、この場合、クエリが フィールドと フィールドのみで実行されている場合とは異なり、Atlas Data Federationsoftware computerはクエリの効率的ではありません。パーティションは順番に解析されます。クエリが特定のパーティションを省略する場合、Atlas Data Federation はそのパーティションに続くパーティションの使用効率を低下させます。 softwareとOSのクエリではcomputerが省略されるため、Atlas Data Federation は、このクエリをサポートするためにOSパーティションよりもsoftwareパーティションを効率的に使用します。
Atlas Data Federation は、 databases.[n].collections.[n].dataSources.[n].pathで指定されていないフィールドに対するクエリをサポートするためにパーティションを使用することはできません。 また、Atlas Data Federation は、 softwareフィールドがない次のフィールドを含むクエリをサポートするためにパーティションを使用することはできません。
computerフィールドOSフィールド、またはcomputerフィールドとOSフィールド。
パーティションを構成 のパーティション属性にマッピングすることで、Data Federation のパフォーマンスを向上させることができます。 パーティション属性（フォルダーに似たS3プレフィックスの部分）をクエリ属性にマッピングすることで、Atlas Data Federation はクエリに関連するデータを含むファイルを選択的に開くことができます。 これにより、クエリにかかる時間が短縮され、コストが削減されます。これは、 Data FederationがAmazon Web Servicesから読み取ってダウンロードするファイルが少なくなるためです。
例
次の構造を持つS3バケットmetricsについて考えてみましょう。
metrics |--hardware |--software |--computer |--phone
構成で/metrics/{metric_type string}/*を定義することで、「メトリクス型」のパーティション属性を設定できます。 {metric_type: software}を含むクエリを発行すると、Data Federation はプレフィックス/softwareを持つファイルのみを処理し、プレフィックス/hardwareを持つファイルを無視します。
次に、 構成 で/metrics/{metric_type string}/{software_type string}を定義することで、「ソフトウェア タイプ」のパーティション属性を設定できます。 {metric_type: software, software_type: computer}を含むクエリを発行すると、Data Federation はプレフィックス/phoneを持つファイルを無視します。
パーティション属性をコレクションdatabases.[n].collections.[n].dataSources.[n].pathにマッピングする方法の詳細については、「 S3 データのパスの定義 」を参照してください。
データファイル サイズ
Atlas Data Federation が取り扱う各ファイルには、一定量のコンピューティング リソースが必要です。 フェデレーティッドデータベースインスタンス ストアに小さなデータファイルが多数含まれている場合、必要なリソースが複合化され、パフォーマンスが低下する可能性があります。 あるいは、Data Federation が不要なデータをダウンロードして処理するため、大きなデータファイルが多い場合は問題が発生します。
ほとんどのユースケースでは、パフォーマンスのあるファイル サイズは100 ～ 200 MBです。
データファイル形式
フェデレーティッドデータベースインスタンスは、いくつかのデータファイル形式をサポートしています。 特定のファイル形式を圧縮したり、クエリのファイル内容を最適化したりすることで、パフォーマンスを向上させることができます。
圧縮
データファイルを圧縮すると、ダウンロードにかかる時間が短縮されます。 ダウンロード時間を短縮すると、非圧縮データを解析する場合よりもパフォーマンス上の利点が得られます。
ファイル構造
Partquet 、 アブロ と ORC ファイルにはファイル自体に関するメタデータが含まれているため、アプリケーションはファイルの内容をさまざまな方法で走査できます。実行するクエリと一致するようにデータファイルを構造化すると、Atlas Data Federation はこのメタデータを活用して適切なデータにすばやく移動できます。
これらの形式のうち、 Parquet ファイルは、Parquet の行グループと列グループを解析するように最適化されているため、フェデレーティッドデータベースインスタンスに最高のパフォーマンスとスペース効率を提供します 。