Tablestore:テストモデル

テストケースには以下が含まれます。

• ランダム書き込み: テストは SyncClient.putRow を呼び出します。各リクエストには 1 行のデータが含まれ、1 時間持続します。
• バッチ書き込み: テストは SyncClient.batchWriteRow を呼び出します。各リクエストには 200 行のデータが含まれ、1 時間持続します。
• ランダム読み取り: テストは BatchWriteRow を呼び出して各パーティションに 20 GB のデータを書き込み、次に SyncClient.getRow を呼び出します。各リクエストは 1 行のデータを読み取り、30 分持続します。
• ランダム範囲読み取り: テストは BatchWriteRow を呼び出して各パーティションに 20 GB のデータを書き込み、次に SyncClient.getRange を呼び出します。各リクエストは 100 行のデータを読み取り、30 分持続します。

すべてのテストケースは、ネットワーク環境の影響を避けるために、Tablestore インスタンスの内部ネットワークアドレスに直接リクエストを送信します。

このパフォーマンステストは、サービスパフォーマンスの限界テストではありません。このテストでは、Tablestore サーバーのスロットリング対策はトリガーされません。Tablestore の自動ロードバランシング機能により、単一のテーブルで提供されるサービス機能の水平スケールアップが保証されます。大規模なパフォーマンステストでは、バックエンドのスロットリングがトリガーされ、高額な料金が発生する可能性があります。大規模なパフォーマンステストを実行する予定の場合は、チケットを提出 して、費用対効果を確保しながら結果を取得してください。

Tablestore の BatchWriteRow 操作は、パーティションごとに並行して処理されます。各パーティションに書き込まれるデータは、ディスク上の単一の書き込み操作です。BatchWriteRow リクエストをデータパーティションキーで集約して、各 BatchWriteRow の書き込みディスク操作を削減し、書き込みパフォーマンスを効果的に向上させることをお勧めします。

ランダム読み取りテストケースとランダム範囲読み取りテストケースでは、データは書き込まれません。テストが進むにつれて、キャッシュヒット率が向上します。低負荷のシナリオでは、キャッシュヒット率はゆっくりと増加します。したがって、テストはディスク I/O 機能と密接に関連しています。高負荷のシナリオでは、キャッシュヒット率は急速に増加します。したがって、テストはディスク I/O 機能との関連性が低くなります。

BatchWriteRow および GetRange テストケースは、大量のネットワーク帯域幅を占有します。Tablestore インスタンスの読み取りまたは書き込みのパフォーマンスが予想よりも低い場合は、ネットワーク帯域幅が完全に占有されているかどうかを確認してください。

Tablestore の読み取りパフォーマンスは、データ量とキャッシュヒット率の影響を大きく受けます。したがって、一部のシナリオでは、GetRow および GetRange テストケースの制限を超える場合があります。これら 2 つのテストケースによって生成されたパフォーマンスデータを複製できます。このレポートのデータは、同様のシナリオで参考として使用できます。実際の読み取りスループット、書き込みスループット、またはレイテンシがこのレポートのデータと大きく異なる場合は、Tablestore 担当者に連絡して原因の分析を依頼してください。