MongoDBのベンチマーク-NoSQLパフォーマンスの推進

データベースシステムは、アプリケーションの実行を成功させるための重要なコンポーネントです。したがって、それらを含むすべての組織には、アプリケーションのダウンタイムやパフォーマンスの低下につながる可能性のある巨大な複雑化にエスカレートする前に、一貫した監視とマイナーな後退の処理を通じてこれらのDBMのスムーズなパフォーマンスを確保する義務があります。

データベースが正常に動作しているときに、データベースに実際に問題が発生するかどうかをどのように判断できるかを尋ねる場合があります。さて、それは私たちがこの記事で議論しようとしていることであり、私たちはそれをベンチマークと呼んでいます。ベンチマークは基本的に、これらのパラメータが期待されるパフォーマンスレベルを満たしているかどうかを判断するために、いくつかのテストデータといくつかのリソースプロビジョニングを使用して一連のクエリを実行しています。

MongoDBには標準のベンチマーク手法がないため、独自のハードウェアでクエリをテストする際に解決する必要があります。ベンチマークプロセスから印象的な数値が得られる場合もありますが、実際のクエリを使用してデータベースを実行する場合は別のケースになる可能性があるため、注意が必要です。

ベンチマークの背後にある考え方は、さまざまな構成オプションがパフォーマンスにどのように影響するか、これらの構成の一部を微調整して最大のパフォーマンスを実現し、この実装を改善するためのコストを見積もる方法についての一般的な考え方を理解することです。さらに、アプリケーションはユーザーの観点から時間とともに増加し、おそらく提供されるデータの量は、この時間の前に何らかの容量計画を行う必要があります。データの増加傾向を認識した後、この膨大に増加するデータの要件をどのように満たすかについて、ベンチマークを実行する必要があります。

MongoDBのベンチマークに関する考慮事項

1. 今日の最新のアプリケーションの典型的な表現であるワークロードを選択します。最新のアプリケーションは日々複雑化しており、これはデータ構造に伝達されます。つまり、データの表示も時間とともに変化します。たとえば、オブジェクトや配列に単純なフィールドを格納します。複雑なデータに関連するレイテンシーやスループットの低下などの問題にエスカレートする可能性があるため、デフォルトまたは標準以下のデータベース構成でこのデータを操作することは非常に簡単ではありません。したがって、ベンチマークを実行するときは、アプリケーションを明確に表すデータを使用する必要があります。
2. 書き込みを再確認します。すべてのデータ書き込みがデータ損失を許さない方法で行われたことを常に確認してください。これは、データの一貫性を確保することでデータの整合性を向上させるためであり、特に本番環境に最も適しています。
3. 個々のノードのRAM容量を確実に超える「ビッグデータ」データセットを表すデータボリュームを使用します。テストワークロードが大きい場合は、データベースパフォーマンスの将来の期待を予測するのに役立つため、十分に早い段階で容量計画を開始できます。

方法論

ベンチマークテストには、ここからダウンロードできるいくつかの大きな位置データが含まれ、Robo3tソフトウェアを使用してデータを操作し、必要な情報を収集します。このファイルには、テストに十分な500を超えるドキュメントが含まれています。 Ubuntu Linux 12.04 Intel Xeon-SandyBridge E3-1270-Quadcore 3.4GHz専用サーバー（32GB RAM、Western Digital WD Caviar RE4 1TBスピニングディスク、Smart XceedIOPS 256GB SSD）でMongoDBバージョン4.0を使用しています。最初の500個のドキュメントを挿入しました。

以下の挿入コマンドを実行しました

db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:0})
db.getCollection('location').insertMany([<document1, <document2>…<document500>],{w:1})

懸念事項を書く

書き込みの懸念は、この場合のスタンドアロンMongoDBへの書き込み操作のためにMongoDBから要求された確認応答レベルを表します。高スループット操作の場合、この値を低く設定すると、書き込み呼び出しが非常に高速になるため、要求の待機時間が短縮されます。一方、値が高く設定されている場合、書き込み呼び出しは遅くなり、その結果、クエリの待機時間が長くなります。これについての簡単な説明は、値が低い場合、mongodのクラッシュ、ネットワークエラー、または匿名のシステム障害が発生した場合に書き込みが失われる可能性について心配する必要がないということです。この場合の制限は、これらの書き込みが成功したかどうかわからないということです。一方、書き込みの懸念が高い場合は、エラー処理プロンプトが表示されるため、書き込みが確認されます。確認応答は、サーバーが書き込み処理を受け入れたことを示す単なる受信です。

私たちのテストでは、書き込みの懸念を低く設定すると、クエリは最小0.013ミリ秒、最大0.017ミリ秒で実行されました。この場合、書き込みの基本的な確認応答は無効になりますが、ソケットの例外やトリガーされた可能性のあるネットワークエラーに関する情報を取得できます。

書き込みの懸念が高く設定されている場合、実行時間は最小0.027ミリ秒、最大0.031ミリ秒で、戻るまでにほぼ2倍の時間がかかります。この場合の確認応答は保証されていますが、100％ディスクジャーナルに到達しているわけではありません。したがって、この場合、ジャーナルがディスクにフラッシュされない可能性がある100ミリ秒のウィンドウが原因で、書き込み損失の可能性は50％になります。

ジャーナル

これは、障害が発生した場合に耐久性を提供することにより、データの損失を防ぐ手法です。これは、ディスク上のジャーナルファイルへの先行書き込みログによって実現されます。書き込みの懸念が高く設定されている場合に最も効率的です。

回転するディスクの場合、ジャーナル処理を有効にした場合の実行時間は少し長くなります。たとえば、テストでは、上記の同じ操作で約0.251ミリ秒でした。

ただし、SSDの実行時間は、同じコマンドの場合は少し短くなります。私たちのテストでは、約0.207ミリ秒でしたが、データの性質によっては、回転するディスクの3倍の速度になる場合があります。

ジャーナル処理を有効にすると、ジャーナルへの書き込みが行われたことを確認し、データの耐久性を確保します。その結果、書き込み操作はmongodのシャットダウン後も存続し、書き込み操作の耐久性が保証されます。

高スループット操作の場合、w =0に設定することで、クエリ時間を半分にすることができます。それ以外の場合、データが記録されていることを確認する必要がある場合、または障害後に復活した場合に備えて、w=1を設定する必要があります。

複製

書き込みの懸念の確認は、レプリカセット内のプライマリおよびセカンダリである複数のノードに対して有効にできます。これは、書き込みパラメーターにどの整数が値付けされるかによって特徴付けられます。たとえば、w =3の場合、Mongodは、クエリがメインノードと2つのスレーブから確認応答を受信することを確認する必要があります。 1より大きい値を設定しようとして、ノードがまだ複製されていない場合、ホストを複製する必要があるというエラーがスローされます。

レプリケーションには、実行時間が長くなるような遅延の後退が伴います。上記の単純なクエリの場合、w =3の場合、平均実行時間は270msに増加します。この推進要因は、ネットワーク遅延の影響を受けるノード間の応答時間の範囲、3つのノード間の通信オーバーヘッド、および輻輳です。さらに、3つのノードはすべて、結果を返す前に互いに終了するのを待ちます。したがって、実稼働環境では、パフォーマンスを向上させたい場合は、それほど多くのノードを関与させる必要はありません。タグを使用して構成ファイルに指定がない限り、MongoDBはどのノードを確認するかを選択する責任があります。

スピニングディスクとソリッドステートディスク

上記のように、SSDディスクは、関連するデータによっては、回転するディスクよりも非常に高速です。場合によっては3倍速くなることがあるため、必要に応じて支払う価値があります。ただし、特に膨大なデータを処理する場合は、SSDを使用する方がコストがかかります。 MongoDBは、マウント可能なディレクトリへのデータベースの保存をサポートしているため、SSDを使用できるというメリットがあります。 SSDを採用し、ジャーナリングを有効にすることは、優れた最適化です。

結論

実験では、書き込みの懸念を無効にすると、データ損失の可能性を犠牲にしてクエリの実行時間が短縮されることが確実でした。一方、書き込み懸念を有効にした場合、無効にした場合の実行時間はほぼ2倍になりますが、データが失われないことが保証されます。さらに、SSDがスピニングディスクよりも高速であることを正当化することができます。ただし、システム障害が発生した場合のデータの耐久性を確保するために、書き込みの懸念を有効にすることをお勧めします。レプリカセットの書き込みに関する懸念事項を有効にする場合は、アプリケーション側のパフォーマンスが低下する可能性があるため、数値を大きく設定しすぎないでください。