したがって、特定のクラウドに多くの時間とエネルギーを投資する前に、そのクラウドでのMongoDBの全体的なパフォーマンス特性を理解することが重要です。この情報を探しましたが見つかりませんでした。そのため、パフォーマンスシリーズの一部としてまとめることにしました。

ベンチマークリグ

このテストでは、AWS、Azure、DigitalOceanを比較することにしました。 2つの異なる構成セットが選択されました。次の表は、マシン構成をまとめたものです。

* マシン構成の詳細については、こちらの「MongoDBホスティング」を参照してください。
** DigitalOceanにはSSDが直接接続されています。

ベンチマークパフォーマンステストは、YCSBワークロードA（重いワークロードを更新）を使用して実行されました。先月、YCSBの設定とそのワークロードについて、非常に詳細な投稿で話しました。

1. すべてのベンチマークテストはスタンドアロン構成で実行されました
2. 両方の構成の場合 500万件のレコードが挿入されました さまざまなレベルのサーバー負荷（クライアントスレッドの数に基づく）
3. 中構成の場合、ワークロードAはデフォルト値（更新50％、読み取り50％）で実行され、操作数は500万でした。 サーバー負荷のさまざまなレベルで。
4. 大規模構成の場合、ワークロードAはデフォルト値（50％更新、50％読み取り）で実行され、操作数は1,000万でした。 サーバー負荷のさまざまなレベルで。

結果

更新の重いワークロードでの挿入パフォーマンスとスループット/レイテンシの特性に基づいた結果について説明します。

パフォーマンスの挿入

ミディアムインスタンス

中規模構成での5Mレコード挿入のスループット/レイテンシー特性：

大規模なインスタンス

大規模構成での5Mレコード挿入のスループット/レイテンシー特性：

パフォーマンスの更新

ミディアムインスタンス

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

テストは、DigitalOceanの場合のみ32スレッドで実行されました。 AWSとAzureは、16スレッドでフラットなライニングでした。ただし、DigitalOceanは、32スレッドまで直線的にスケーリングする印象を与えます。

大規模なインスタンス

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

全体的な分析

1. 予想どおり、DigitalOcean上のMongoDBは、一貫して高いスループットと低レイテンシの特性を備えており、挿入フェーズで他の人を打ち負かし、ローカルSSDドライブから最大のジュースを引き出します。興味深いことに、読み取り/更新フェーズでは非常にうまくいきますが、他のプロバイダーは、特にサーバーの負荷が増加したときに、かなりの競争をします。明らかに、AWS/Azureははるかに高いスループットのネットワークストレージを使用しています。
2. AWSディスクのパフォーマンスを向上させるために、ユーザーはより大きなディスクサイズを使用するか、より多くのプロビジョニングされたIOPSを割り当てることができます。
3. 中規模のインスタンスでは、Azure上のMongoDBは、挿入フェーズと更新/読み取りフェーズの両方で、一貫してAWSよりもはるかに優れているようです。これは驚くべきことでした。ハードウェアはかなり均等に一致しています。大規模なインスタンスでは、AWSのパフォーマンスはAzureよりも著しく優れています。
4. AWSとAzureはどちらも、負荷が増加するにつれてレイテンシーがかなり低下します。 Azureのレイテンシーの低下曲線はかなり良いようです。
5. AWSのパフォーマンスに関するMongoDBのもう1つの興味深い側面は、それがいかに「フラットライン」であるかです。ログスケールでも正常に低下するようです。
6. レイテンシの数値に基づくと、負荷の観点からは、中規模インスタンスと大規模インスタンスの場合、それぞれ8スレッドと16スレッドのスイートスポットのように見えます。