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

YCSBでMongoDBをベンチマークする方法は？

    システムパフォーマンスの特性について話している間、ほとんどのDBaaSプロバイダーは、システムがプロビジョニングされているハードウェアに関する情報の提供に制限されています。このようなシステムの変数の数を考えると、クラウドベースの展開の実際のスループット/遅延特性について正確に話すことは確かに困難です。仮想化環境、予測不可能なワークロード、ネットワークレイテンシ、さまざまな地域は、考慮事項のほんの一部です。

    ただし、MongoDBデプロイメントの実際のパフォーマンスを十分に理解しておくことをお勧めします。これにより、アプリケーションのニーズに基づいて正確にプロビジョニングできるようになります。さまざまなDBaaSプロバイダーを実際に比較して、最大限の「見返り」を得ていることを確認できます。

    このブログは、MongoDBクラスターでいくつかの基本的なパフォーマンスベンチマークを実行するための入門書です。 YCSBベンチマークテストを構成および実行し、結果を解釈する方法の詳細について説明します。そのインスピレーションは、MongoDB3.0のパフォーマンスの向上に関する最近のMongoDBブログから得られました。

    YCSBは、Yahoo！で開発された人気のあるJavaオープンソース仕様およびプログラムスイートです。さまざまなNoSQLデータベースの相対的なパフォーマンスを比較します。そのワークロードは、NoSQLデータベースのさまざまな比較研究で使用されています。

    YCSBの設定

    このセクションと以降のセクションでは、お気に入りのDBaaSプロバイダーシステムでYCSBテストをセットアップ、構成、実行するためのステップバイステップのプロセスについて説明します。

    ワークロードテストを実行するには、インターネットの待ち時間を回避するために、できればMongoDBクラスターと同じ地理的な場所にクライアントマシンが必要です。 Mongoクラスターを適切にロードするために複数のスレッドを実行するには、適切な量のジュースがある構成を選択してください。マシンには、最新バージョンのJava、Maven、およびgitがインストールされている必要があります。

    手順：

    • Java、Maven、またはgitがシステムにまだインストールされていない場合は、それらをインストールします。特定のOSで利用可能なドキュメントを参照してください。 Javaバージョンと互換性のあるMavenバージョンをインストールしていることを確認してください。すべての依存関係が正しく機能していることをテストします。例：
    $ javac -version
javac 1.8.0_25
$ mvn -version
Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c; 2015-03-14T01:40:27+05:30)
Maven home: /usr/local/Cellar/maven/3.3.1/libexec
Java version: 1.8.0_25, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.10.2", arch: "x86_64", family: "mac"
$ git --version
git version 1.9.5 (Apple Git-50.3)
    • YCSBのGithubページで提案されているように、YCSBのtarアーカイブを取得できます。ただし、ソースからビルドすることをお勧めします。手順は、YCSBのMongoDBREADMEに記載されています。これは、後でクラウドプロバイダーのMongoDB認証を有効にするのに役立ちます。
    git clone git://github.com/brianfrankcooper/YCSB.git
cd YCSB
mvn clean package
    • 注：`mvn clean package`の場合 または`mvn clean install` 「mapkeeper」パッケージの検索エラーが原因でコマンドが失敗する、pom.xmlの「mapkeeper」エントリの2つのインスタンスを削除またはコメントアウトする ルートレベルで。詳細については、このGithubの問題をご覧ください。
    • ビルドが成功すると、YCSBテストを実行する準備が整います！

    認証の有効化

    ほとんどのMongoDBプロバイダーは、デフォルトでMongoDB認証を提供しており、それを無効にする方法はありません。残念ながら、YCSBは現在MongoDB認証をサポートしていません。クライアントの実装自体は、現在、ほとんどの場合、非推奨のAPI呼び出しを使用しています。ニーズを満たすために、新しいMongoDB固有のYCSBプロパティ'mongodb.auth'を追加しました。 それをサポートするための数行のコードとともに。変更は非常に簡単で、差分はここにあります。デフォルトのMongoDB固有のYCSBプロパティがここに一覧表示されます。

    mvnを使用してパッケージを再ビルドします 変更が完了したら、もう一度。 Mavenを使用してYCSBを構築する方法については、上記のセクションを参照してください。

    テストの実行

    YCSB wikiのこのセクションには、次のアクティビティとその後のアクティビティが詳細にリストされています。ここでは、他の指針とともにそれらについて簡単に説明します。

    • 次のステップは、実行するワークロードの種類を選択することです。 YCSBwikiのコアワークロードセクションを読んで理解するために時間をかけてください。それらはここに要約されています：
      • ワークロードA：重いワークロードを更新する：読み取り/書き込みの50/50％の組み合わせ
      • ワークロードB：主にワークロードを読み取ります：読み取り/書き込みの95/5％の組み合わせ
      • ワークロードC：読み取り専用：100％読み取り
      • ワークロードD：最新のワークロードを読む：最近の挿入でより多くのトラフィック
      • ワークロードE：短距離：短距離ベースのクエリ
      • ワークロードF：読み取り-変更-書き込み：既存のレコードの読み取り、変更、更新
    • 明らかに、コアプロパティを使用して個々のワークロードを微調整できます。ワークロードを選択し、アプリケーションの特性に一致するものに一致するようにプロパティを微調整することをお勧めします。 （この比較研究では、興味深い「微調整された」ワークロードを多数選択しました）。また、最初のセクションで説明したMongoDBブログも参照してください。 （私たちのテストでは、デフォルトの読み取り/更新比率でワークロードAを取得します。）
    • テスト自体が適切な時間実行されるように、操作の数（プロパティ「operationcount」）を選択します。 30分以内に終了するテストは、システムの一般的なパフォーマンスの良い指標にはなりません。
    • YCSBが実行するスレッドの適切な数を選択します。これは、クライアントマシンがどれだけ優れているか、MongoDBクラスターがどれだけの負荷をかけることができるか、実際のアプリケーションをどれだけ代表しているかによって異なります。さまざまなスレッドに対してベンチマークテストを実行します。
    • ロードフェーズを実行します。実行する予定の操作の数に近いレコード数（プロパティ「recordcount」）を選択してデータベースに挿入します。挿入に時間がかかりすぎないように、適切な数のスレッドを選択してください。たとえば、
      ./bin/ycsb load mongodb -s -P workloads/workloada -p recordcount=10000000 -threads 16 -p
 mongodb.url="mongodb://user:[email protected]:9999,server2.example.com:9999/dbname" -p 
mongodb.auth="true"
      • ‘load ‘フラグは、これがロードランであることを示します。
      • ‘s ‘フラグは10秒間隔でステータスを出力します
      • ‘recordcount ‘は1,000万に設定されています。
      • ‘threads ‘クライアントスレッドの数を16に設定します。
      • ‘mongodb.auth ‘は、MongoDB認証を有効にするために作成したプロパティです。
    • 覚えておいてください
      • stdoutをファイルにリダイレクトします。
      • 「screen」を使用する ‘または同等の方法で、これらの操作の実行中にセッションが失われないようにします
    • データの読み込みフェーズが完了すると、ワークロードを実行する準備が整います。例：
    ./bin/ycsb run mongodb -s -P workloads/workloada -p 
mongodb.url="mongodb://user:[email protected]:9999,server2.example.com:9999/dbname" -p
 mongodb.auth="true" -p operationcount=10000000 -threads 2
    • さまざまな数のスレッドで実行を繰り返します。後で比較できるように、結果をリダイレクトすることを忘れないでください。たとえば2、4、8、16、32スレッドのテストを繰り返しました。

    結果の分析

    このYCSB wikiページの最後のセクションでは、結果の分析について説明しています。最も興味深い情報は、全体的なスループットと95/99％のパーセンタイルレイテンシです。通常、スレッドの数を増やすと、ゲインがフラットになり、レイテンシが許容できなくなるまでスループットが向上します。たとえばこれは、ベンチマークしようとしたテストシステムのスループットとレイテンシーとスレッド数のプロットです。選択されたワークロードはワークロードAと約300万回の操作でした。

    グラフから、このMongoDBサーバーの負荷の観点からは、16スレッドがおそらく「スイートスポット」であると結論付けることができます。それを超えると、スレッド数が指数関数的に増加してもスループットラインはフラットになり、レイテンシーは許容できないほど大きくなります。

    いくつかの指針：

    • クラウド全体のシステムパフォーマンスをより正確に把握するには、これらのテストを自動化してから繰り返すことが、1日のさまざまなポイントです。パフォーマンス特性は1日を通して大幅に変化する可能性があることに気づきました。
    • 2つの潜在的なDBaaSプロバイダーを比較するときは、同じ地域にあるクライアントマシンとDBaaSクラスターを選択していることを確認してください。クラスターは同様の構成である必要があります。また、テストは1日のさまざまな時間に実行することを忘れないでください。

    次のステップ

    この分野でさらに多くの作業を行う際に調査する予定のいくつかの事項を次に示します。

    • 複数のマシンからのワークロードを並行して実行する：大容量のMongoDBクラスターをロードしようとすると、単一のクライアントマシンでは不十分です。 YCSBは現在、複数のマシンからのワークロードを並行して実行する簡単な方法を提供していません。ただし、手動で行うことはできます。これは、大規模なクラスターにデータをロードしようとするときにも役立ちます。
    • データセットのサイズ：MongoDBシステムのメモリに対するデータベースのサイズは、より大きなデータセットの場合にMongoDBがディスクに到達する必要があることを考えると、絶対スループット/レイテンシーの特性を変更します。
    • 個々のレコードのサイズ：レコードサイズが大きい場合、特にサポートされている最大レコードサイズに近い場合は、パフォーマンス特性が重要になります。これは、主にリードモディファイライトバック操作を行うアプリケーション（ワークロードFなど）にとって重要な場合があります。
    • 代替のMongoDBドライバー：現在、2つの異なるDBaaSプロバイダーを比較することに関心があったため、より効率的なデータベースドライバーを使用することは試みませんでした。明らかに、最新のより効率的なドライバーを使用すると、はるかに優れた絶対数を実現できます。これは、システムから最後の1オンスのジュースを抽出しようとするアプリケーションにとって興味深いものです。このブログでは、非同期MongoDBドライバーを使用したYCSBによるパフォーマンス改善の測定について説明しています。
    • 代替ベンチマークツール：MongoDBのSysbenchは、私たちが興味深いと思うツールです。私たちは他の人を見ています。


    1. 類似の単語をグループ化するための良い戦略は何ですか？

    2. MongoDBでサブストリングを置き換える2つの方法

    3. Mac上のmongodbデータベースの場所

    4. Redisでのトランザクションとウォッチステートメント