sql >> データベース >  >> NoSQL >> MongoDB

XFSとEXT4–AWSEC2でのMongoDBパフォーマンスの比較

    AWSは、MongoDBのデプロイを管理するための非常に人気があり、信頼できるクラウドプラットフォームですが、XFSとEXT4の問題により、多くの開発者は、どのLinuxファイルシステムがアプリケーションに最高のパフォーマンスを提供するのか疑問に思っています。本番環境へのデプロイに関するMongoDBの公式ガイドでは、特にWiredTigerストレージエンジンをデプロイする場合に、LinuxでXFSファイルシステムを使用することを推奨しています。ただし、この推奨事項では、パフォーマンスの向上を期待する理由や、どのようなパフォーマンスの向上が見込めるのかについては説明されていません。 XFSでのMongoDBのパフォーマンスを定量的に調査して、EXT4がAWSEC2インスタンスに適しているかどうかを比較できるようにすることでその根底にあることにしました。

    XFSファイルシステム

    XFSは、1993年にSGIで開発され、2002年にLinuxに移植された、高度にスケーラブルで高性能な64ビットジャーナリングファイルシステムです。最大9エクサバイトの高度に並列化されたI / Oとファイルシステムのサイズをサポートし、ファイルシステムのメタデータのみをジャーナルします。ユーザーデータではありません。 XFSの主なパフォーマンス向上機能は次のとおりです。

      • 割り当てグループを介した並列アクセスにより、複数のスレッドが同じボリュームで同時にI/Oを実行できるようになります。
      • エクステントベースの割り当てにより、断片化とメタデータサイズが削減され、I / O操作がますます少なくなるため、I/Oパフォーマンスが向上します。
      • 割り当ての遅延により、データの隣接性とパフォーマンスが向上します。書き込みを組み合わせてエクステントを大きなチャンクに割り当てることで断片化が減少し、ランダムに書き込まれたファイル(メモリマップされたファイルなど)を連続して割り当てることができます

    探索するXFS機能は他にもたくさんあり、XFSのWebサイトとXFSユーザーガイドで詳細を確認できます。

    MongoDBでのパフォーマンステストの実行

    以前の投稿で学んだように、さまざまなクラウドプロバイダー間でのMMAPに基づくMongoDBパフォーマンスの詳細な比較など、MongoDBパフォーマンスのベンチマークにYCSBを使用しています。以前に使用していたのと同じYCSBのワークロードを使用することにしました:ワークロードA(更新量が多い:50%の読み取り+ 50%の更新)。ワークロードの挿入フェーズでは、100%の書き込みワークロードのパフォーマンスが測定され、ロードフェーズでは、実際のワークロード(50/50%の読み取り/更新)に対するパフォーマンスが測定されます。

    テストは同期MongoDBドライバーで実行され、LinuxディストリビューションはAmazon Linux(4.4.44-39.55.amzn1.x86_64)でした。テストにはWiredTigerを実行しているMongoDBバージョン3.2.10を選択しました。これは、WTがより良いゲインが期待される場所であり、2つの異なるハードウェアリグでテストを実行したためです。

    • 高速ディスク :MongoDBがストレージにRAID0構成のSSDディスクを使用していたAWSEC2c3.largeインスタンス(ScaleGridクラスターサイズHighPerfLargeにマップ)。
    • 中速ディスク :MongoDBがEBS(Elastic Block Store)を使用していたAWS EC2 m3.mediumインスタンスは、300 IOPSに設定されたIOPSプロビジョニングされたディスクです(ScaleGridクラスターサイズMediumにマップされます)。

    注:仮想化環境でのあらゆる種類のパフォーマンステストは、一粒の塩で行う必要があります。ここでの目的は、これらの環境でのパフォーマンスの数値をベンチマークすることではなく、同じ仮想化環境でのEXT4とXFSのパフォーマンスの違いを定量的に測定することです。

    高速SSDディスク

    高性能リグで次のテストを実行しました:

    1. 600万を挿入 さまざまなサーバー負荷での記録(YCSBクライアントスレッドの数を変えることによる)。
    2. 操作数1,000万でワークロードを実行 さまざまなサーバー負荷で記録します。

    SSDディスクのパフォーマンス結果

    高性能構成での6Mレコード挿入のスループット/レイテンシー特性:

    高性能構成での10Mの書き込み/更新操作のスループット/レイテンシー特性:

    SSDディスクの観察

    • XFSは、挿入フェーズとワークロード実行の両方で非常に高速です。スレッド数が少ない場合は、EXT4よりも50%も高速です。負荷が増加するにつれて、両方のファイルシステムは基盤となるハードウェアのスループットによって制限されましたが、XFSは依然としてそのリードを維持していました。
    • XFSとEXT4の両方の遅延は、両方の実行で同等でした。すべての数値はマイクロ秒単位であることに注意してください。

    低速のEBSプロビジョニングIOPSディスク(300 IOPS)

    次のテストは、中型のパフォーマンスリグで実行されました。

    1. 300万を挿入 さまざまなサーバー負荷での記録(YCSBクライアントスレッドの数を変えることによる)。
    2. 操作数500万でワークロードを実行 さまざまなサーバー負荷で記録します。

    ハイエンド構成での経験から、XFSはこのリグでもまともなリードを持っていると期待していました。

    IOPSディスクパフォ​​ーマンスの結果

    メディア構成での3Mレコード挿入のスループット/レイテンシー特性:

    メディア構成での5M書き込み/更新操作のスループット/レイテンシー特性:

    IOPSディスクの観察

    • XFSは同等ですが、中規模の構成ではEXT4よりわずかに遅れています。このレベルのシステムリソースでは、XFSのパフォーマンスの最適化は実際には違いがないようです。パフォーマンスの向上を期待して、より小さなインスタンスにXFSをデプロイすることを検討している場合、これは重要な観察事項です。

    AWSEC2でのXFSとEXT4

    パフォーマンスの観点から、XFSは、実際に利用できる高速ディスクと組み合わせると、確かに力の乗数になります。ローエンドからミッドエンドのシステムの場合、パフォーマンスを向上させることはあまりできないようです。


    1. Docker:Dockerボリュームを保存するフォルダーを変更します

    2. JSONドキュメントの配列からMongoDBにドキュメントをインポートする

    3. HDFSチュートリアル–初心者向けのHDFSの完全な紹介

    4. HerokuにデプロイするときにTravisがRediscache_storeを使用して接続に失敗するのはなぜですか?