再生したクエリキャッシュがあります。実装の制限を受けることはありません。クエリがキャッシュ可能でなくても問題がなく、他のバッファやキャッシュで使用メモリを回収する場合を除き、クエリキャッシュを有効にしておくことをおすすめします。さまざまなその他の予測が難しいコンシューマーが使用します。マネージドサービスプロセスに特有のデータベースエンジンバッファやキャッシュなどです。このメモリの一部に空きがあるか空きにできる可能性があります。つのキャッシュが、多数のテーブルを有するワークロードと特に関連があります。このキャッシュの設定を誤ると、パフォーマンスや安定性の問題を引き起こす可能性があります。開かれたテーブルのハンドラーの構造体をユーザーアクティビティの結果として保存します。各セッションでテーブルは個別に開かれるため、複数の同時セッションがアクセスしている場合、キャッシュには同じテーブルの複数アイテムが含まれることがあります。個のオープンテーブルに増やしました。これはソフトリミットです。基づき、かなりのメモリコンシューマーとなる可能性があります。この現象はワークロードがデータベースで実行している同時セッションの数により増幅されます。アクティブなテーブルを持つほど、テーブルの定義がキャッシュされやすくなります。個の定義に増やしました。そのため、このキャッシュはかなりのメモリコンシューマーとなる可能性があります。何十万ものテーブルを使用するワークロードにより、大半のテーブルがアクティブの場合はデフォルトの値を超えてこのキャッシュのサイズを増やす誘因もあります。このキャッシュサイズもソフトリミットです。データベースエンジンが親子の外部キー関連テーブルのテーブル定義を削除することはありません。そのため、キャッシュの合計サイズはキャッシュサイズ制限を上回ることがあります。クラスターで操作できるテーブル数を制限することができます。インスタンスクラスを使用してキャッシュを受け入れる必要がある可能性があります。クエリキャッシュまたはバッファプールに割り当てられたメモリ量を減らして相殺する必要がある可能性があります。すると今度は、メモリ量を減らしたことでワークロードのパフォーマンスに別の面で影響を与える可能性があります。メモリに入れる動作中のデータセット量が少ないからです。「多すぎる」テーブル数を正確に特定するのは困難です。以下の例では、このような現象の一部をよく表しています。テストの強化されたモニタリングメトリクスで報告された空きメモリを示しています。分間のみ実行しました。このテストに関し、次のコマンドがデータベースとテーブルをテスト実行前に作成します。リソースはテスト中にほぼすべて消費されました。バッファプールを事前に割り当て、上記のテストではすでにウォームアップされていました。メモリ消費は、テーブルキャッシュと多数のアクティブテーブルが関わる際に起こる各接続の増幅効果によるものがほとんどでした。パラメータがテーブルキャッシュのサイズを制御します。デフォルトで、このパラメータは以下の式を使用して設定されます。6,000比較のため、以下の図で類似のテストを示しています。テーブルにのみアクセスしているという点です。以下の例では、多数のテーブルが使用される際のテーブル定義キャッシュの影響を示しています。万の簡易なテーブルを作成します。つの短い文字列があります。クラスターで実行するアクティビティは他になく、空のクラスターで開始されます。ワークロードが増えるにつれ、どのくらい空きメモリが減るかを確認できます。キャッシュ制限に達すると安定します。パラメータがテーブル定義キャッシュのサイズを制御します。デフォルトで、このパラメータは以下の式を使用して設定されます。20,000結論として、実際に統合できるテーブル数は複数の要因によって決まります。アクティブに使用されているテーブル数、利用可能なメモリ量、サポートが必要な同時接続数がその要因です。メモリのようなサーバーリソース使用率に影響を与える点についていくつか説明しました。ワークロードの統合自体が使用率の増加を引き起こします。データベースのシャード数が減ると、残りのデータベースシャードのそれぞれにさらに多くの同時接続が確立される可能性があります。各統合データベースは、クエリボリュームの増加の読み込みや書き込みを行い作業量が増えます。内部サーバー接続プール機能やスレッドの多重送信機能を備えており、何千もの同時接続を処理する際に競合を減らし、スケーラビリティを向上させるのに役立ちます。同時接続を設定することができます。選択により、実質的な最大数をそれよりも少ない数に制限する可能性があります。ステートメントに基づいたその他のメモリ構造でさまざまなメモリ量を消費します。この消費は確定的なものではなく、このブログ記事のはじめに説明した他の構造のように、同量の利用可能なメモリを得るために競合します。大きく、高いスループットのワークロードを実現するための接続使用率の最適化について有効なアドバイスが記載されています。検討する際は、多くの要素が関連します。すべてを網羅するリストはありませんが、統合を実装するお手伝いをする際に確認する一般的な検討事項を上記のトピックに記載しています。それぞれのワークロードは異なるため、実際の統合を行う際の制限はケースにより異なります。ベストプラクティスとして、デフォルトからの設定変更を生産スケールで徹底的にテストし、パフォーマンスと信頼性において定量可能なプラスの影響が確認できる場合のみ実装する必要があります。設定を引き継ぐ際に特に有効です。同じ動作をしない可能性があるためです。サービスのスペシャリストソリューションアーキテクトです。使用する場面でソリューションの価値を向上させる手助けをしています。機会均等法を順守しています。平等に採用しています。