すべてのプロダクト
Search
ドキュメントセンター

ApsaraDB RDS:高速クエリキャッシュ

最終更新日:Jan 11, 2024

高速クエリキャッシュは、ネイティブMySQLクエリキャッシュに基づいてAlibaba Cloudによって開発されたクエリキャッシュです。 高速クエリキャッシュは、新しいデザインと新しい実装メカニズムを使用して、ApsaraDB RDSインスタンスのクエリパフォーマンスを向上させます。

前提条件

背景情報

クエリキャッシュは、CPUリソースを節約し、クエリを高速化するように設計されています。 返された結果セットを持つ各修飾文のテキストを格納します。 同一のSQLステートメントが後で受信された場合、データベースシステムは、クエリキャッシュから結果セットを直接検索する。 これにより、SQL文の解析、最適化、再実行が不要になります。

ネイティブMySQLクエリキャッシュには、設計と実装に関して次の欠点があります。

  • 多数の同時クエリを高いパフォーマンスで処理することはできません。 複数のCPUコアが構成されている場合、同時クエリの数が多いとパフォーマンスが低下する可能性があります。
  • メモリリソースを効率的に利用したり、メモリリソースをすばやく回収したりできません。 これは、メモリリソースの浪費を引き起こす。
  • キャッシュヒット率が低い場合、クエリのパフォーマンスは向上せず、大幅に低下する場合もあります。

上記の欠点により、ネイティブMySQLクエリキャッシュは広く使用されていません。 最新のMySQLバージョン8.0では提供されなくなりました。 対照的に、高速クエリキャッシュには次の利点があります。

  • 最適化された同時実行制御

    グローバルロック機構が削除されました。 このメカニズムは、ネイティブMySQLクエリキャッシュで使用され、スレッドの実行を同期させます。 高速クエリキャッシュは、再設計された同期メカニズムを使用します。 このメカニズムにより、ApsaraDB RDSは複数のCPUコアの構成を活用し、多数の同時クエリを高いパフォーマンスで処理できます。

  • 最適化されたメモリ管理

    ネイティブMySQLクエリキャッシュのメモリ事前割り当てメカニズムが削除されました。 高速クエリキャッシュは、動的でより柔軟なメモリ割り当てメカニズムを使用します。 このメカニズムにより、ApsaraDB RDSは無効なメモリリソースを迅速に回収できます。 これにより、メモリ使用量が増加します。

  • 最適化されたキャッシュ

    高速クエリキャッシュは、キャッシュの使用状況を動的に監視します。 次に、高速クエリキャッシュは、取得したキャッシュ使用量に基づいてキャッシュポリシーを調整します。 これにより、キャッシュヒット率が低い場合や、RDSインスタンスが読み取り要求と書き込み要求の両方を処理する場合にパフォーマンスが低下するのを防ぎます。

高速クエリキャッシュは、クエリのパフォーマンスを向上させるために、さまざまなビジネスシナリオで使用できます。 ただし、ネイティブMySQLクエリキャッシュは同じサポートを提供しません。

高速クエリキャッシュの有効化

ApsaraDB RDSコンソールでquery_cache_typeおよびquery_cache_sizeパラメーターを設定することで、高速クエリキャッシュを有効にできます。

パラメーター説明
query_cache_type高速クエリキャッシュを制御するために使用されるスイッチ。 有効な値:
  • 0: 高速クエリキャッシュを無効にします。 デフォルト値です。
  • 1: 高速クエリキャッシュを有効にします。 SQL_NO_CACHEオプションを使用して、SQL文のキャッシュをスキップできます。
  • 2: 高速クエリキャッシュを無効にします。 SQL_CACHEオプションを使用して、指定されたSQL文のテキストおよび結果セットのみをキャッシュできます。
query_cache_size高速クエリキャッシュに割り当てられるメモリスペースのサイズ。 有効な値: 0 ~ 10485760000 値は1024の倍数でなければなりません。 単位:バイト

高速クエリキャッシュは余分なメモリスペースを占有します。 高速クエリキャッシュを設定するときは、innodb_buffer_pool_sizeパラメーターも再設定することをお勧めします。

  1. innodb_buffer_pool_sizeパラメーターを、このパラメーターの元の値の90% に設定します。 メモリ空間の縮小10% は、query_cache_sizeパラメーターで指定されるクエリキャッシュサイズとして使用されます。 たとえば、innodb_buffer_pool_sizeパラメーターの元の値が {DBInstanceClassMemory * 7/10} の場合、このパラメーターを {DBInstanceClassMemory * 63/100} に設定します。 詳細については、「ApsaraDB RDS For MySQLインスタンスのInnoDBバッファプールのサイズの変更」をご参照ください。
  2. query_cache_sizeパラメーターを設定します。 詳細は、「インスタンスパラメーターの変更」をご参照ください。
    • 結果セットサイズを正確に見積もることができる場合は、query_cache_sizeパラメーターを結果セットサイズの20% に等しい値に設定できます。
    • 結果セットのサイズを正確に推定できない場合は、query_cache_sizeパラメーターをinnodb_buffer_pool_sizeパラメーターの値の10% に等しい値に設定できます。
    説明 RDSインスタンスの仕様を変更しても、新しい仕様に基づいてquery_cache_sizeパラメーターの値は変更されません。 仕様の変更が適用されたら、すぐにこのパラメーターを再設定する必要があります。
  3. query_cache_typeパラメーターを1に設定します。 これにより、高速クエリキャッシュを有効にできます。 詳細は、「インスタンスパラメーターの変更」をご参照ください。

ネイティブMySQLクエリキャッシュと高速クエリキャッシュのパフォーマンスを比較する

さまざまなテストケースで同じ条件で、異なるクエリキャッシュ構成と1秒あたりのクエリ (QPS) を比較します。 これらのクエリキャッシュ設定は、QC-OFF (クエリキャッシュが有効になっていない) 、MySQL-QC (ネイティブMySQLクエリキャッシュが有効になっている) 、およびFast-QC (高速クエリキャッシュが有効になっている) です。

  • テスト環境: 4 CPUコアと8 GBのメモリを備えた専用RDSインスタンス
  • テストツール: SysBench
  • テストデータサイズ: 250 MB (合計25テーブル、1テーブルあたり40,000レコード)
  • テストケース1: キャッシュヒット率が100% の読み取りクエリのQPSをテストします。

    oltp_point_selectスクリプトが使用されます。 主キーに基づくPOINT SELECTステートメントのみを実行します。 さらに、クエリのキャッシュサイズを512 MBに設定してください。 このサイズはテストデータサイズよりも大きく、キャッシュヒット率を100% にすることができます。 このテストケースでは、同時クエリの数に基づいてQPSがどれだけ増加するかに注目します。

    表1. QPS for読み取りクエリのキャッシュヒット率が100%
    同時クエリの数QCオフMySQL-QC (QC-OFFと比較してQPSの増加)高速QC (QPSの増加と比較してQC-OFF)
    18,0938,771 (8.38%)9,261 (14.43%)
    862,26265,686 (5.50%)75,313 (20.96%)
    1697,08373,027 (-24.78%)139,323 (43.51%)
    3297,33760,567 (-37.78%)200,978 (106.48%)
    64106,,28360,216 (-43.34%)221,659 (108.56%)
    12810778162,844 (-41.69%)231,409 (114.70%)
    256106,69463,832 (-40.17%)222,187 (108.25%)
    512101,73364,866 (-36.24%)203,789 (100.32%)
    102489,54862,291 (-30.44%)203,542 (127.30%)
    QPS for read queries with a cache hit ratio of 100%
    説明 テスト結果に基づいて、同時クエリの数が増加すると、ネイティブMySQLクエリキャッシュのQPSは大幅に減少します。 ただし、高速クエリキャッシュのQPSは減少せず、最大100% 増加することもあります。
  • テストケース2: キャッシュヒット率が80% を超える読み取りクエリのQPSをテストします。

    oltp_read_onlyスクリプトが使用されます。 それぞれが複数のレコードを返す範囲クエリを含むクエリを実行します。 さらに、クエリのキャッシュサイズを512 MBに設定してください。 このサイズは、十分なメモリ空間を確保し、キャッシュヒット率が80% 以上に達することを可能にする。 このテストケースでは、同時クエリの数に基づいてQPSがどれだけ増加するかに注目します。

    表2. QPS for読み取りクエリのキャッシュヒット率が80% を超える
    同時クエリの数QCオフMySQL-QC (QC-OFFと比較してQPSの増加)高速QC (QPSの増加と比較してQC-OFF)
    15,0996,467 (26.83%)7,022 (37.71%)
    828,78228,651 (-0.46%)45,017 (56.41%)
    1635,33331,099 (-11.98%)66,770 (88.97%)
    3234,86427,610 (-20.81%)67,623 (93.96%)
    6435,50327,518 (-22.49%)75,981 (114.01%)
    12835,74427,733 (-22.41%)80,396 (124.92%)
    25635,68527,738 (-22.27%)80,925 (126.78%)
    51235,30827,398 (-22.40%)79,323 (124.66%)
    102434,04426,861 (-22.10%)75,742 (122.48%)
    QPS for read queries with a cache hit ratio higher than 80%
    説明 テスト結果に基づいて、同時クエリの数が増加すると、ネイティブMySQLクエリキャッシュのQPSは大幅に減少します。 ただし、高速クエリキャッシュのQPSは100% を超えて増加する可能性があります。
  • テストケース3: キャッシュヒット率が約10% の読み取りクエリのQPSをテストします。

    oltp_read_onlyスクリプトが使用されます。 それぞれが複数のレコードを返す範囲クエリを含むクエリを実行します。 さらに、クエリのキャッシュサイズを16 MBに設定してください。 このサイズにより、メモリスペースが不足し、大量のキャッシュデータが削除されます。 これにより、キャッシュヒット率を約10% に低下させることができる。 このテストケースでは、同時クエリの数に基づいてQPSがどれだけ減少するかに注目します。

    表3. QPS for読み取りクエリのキャッシュヒット率が約10%
    同時クエリの数QCオフMySQL-QC (QC-OFFと比較してQPSの増加)高速QC (QPSの増加と比較してQC-OFF)
    15,0044,727 (-5.54%)5,199 (3.90%)
    828,79522,542 (-21.72%)28,578 (-0.75%)
    1635,45524,064 (-32.13%)35,682 (0.64%)
    3234,52621,330 (-38.22%)35,871 (3.90%)
    6435,51419,791 (-44.27%)36,051 (1.51%)
    12835,98319,519 (-45.75%)36,253 (0.75%)
    25635,69519,168 (-46.30%)36,337 (1.80%)
    51235,18218,420 (-47.64%)35,972 (2.25%)
    102433,91520,168 (-40.53%)34,546 (1.86%)
    QPS for read queries with a cache hit ratio of about 10%
    説明 テスト結果に基づいて、同時クエリの数が増加すると、ネイティブMySQLクエリキャッシュのQPSは大幅に減少します。 減少はせいぜい50% に近づいています。 しかし、高速クエリキャッシュのQPSは、ほんの少ししか減少しない。
  • テストケース4: 読み取りおよび書き込みクエリのQPSをテストします。

    oltp_read_writeスクリプトが使用されます。 テーブルの更新を含むトランザクションを実行します。 これらの頻繁な更新により、キャッシュされたデータが削除されます。 したがって、設定済みのクエリキャッシュは無効と見なされます。 このテストケースでは、同時クエリの数に基づいてQPSがどれだけ減少するかに注目します。

    表4. QPS for read and write queries
    同時クエリの数QCオフ高速QC (QPSの増加と比較してQC-OFF)
    14,1524,098 (-1.30%)
    821,35921,195 (-0.77%)
    1626,02025,548 (-1.81%)
    3227,59526,996 (-2.17%)
    6429,22928,733 (-1.70%)
    12829,26528,828 (-1.49%)
    25629,91129,616 (-0.99%)
    51229,14828,816 (-1.14%)
    102429,20428,824 (-1.30%)
    QPS for read and write queries
    説明 テスト結果に基づいて、同時の読み取りおよび書き込みクエリの数が増加すると、高速クエリキャッシュのQPSはわずかな量だけ減少します。

実践ガイドライン

結果セットのサイズを正確に見積もることができれば、上記のテストケースを使用してQPSを評価できます。 これには、SQL_CACHEオプションを使用して指定されたテーブルで高速クエリキャッシュを有効にする場合も含まれます。 次のヒントでは、高速クエリキャッシュの使用方法について詳しく説明します。

  • さまざまなシナリオで高速クエリキャッシュを有効にします。
    • 高速クエリキャッシュは、読み取りクエリのQPSを増やすことを目的としています。 RDSインスタンスが多数の読み取りクエリを処理し、少数の書き込みクエリを処理する場合は、高速クエリキャッシュを有効にすることを推奨します。 それ以外の場合は、SQL_CACHEオプションを使用して、多数の読み取りクエリを受け取るが少数の書き込みクエリを受け取るテーブルに対してのみ高速クエリキャッシュを有効にすることをお勧めします。 RDSインスタンスが少数の読み取りクエリを処理し、多数の書き込みクエリを処理する場合、RDSインスタンスのデータは頻繁に更新されます。 この場合、高速クエリキャッシュは、わずかなQPS減少を引き起こし得る。
    • 高速クエリキャッシュによってもたらされるQPSの増加は、キャッシュヒット率に基づいて変化する。 RDSインスタンスの高速クエリキャッシュを有効にする前に、InnoDBバッファプールのヒット率を取得することを推奨します。 ヒット率が80% より低い場合は、高速クエリキャッシュを有効にしないことを推奨します。 InnoDBバッファプールのヒット率は、次の式を使用して計算されます。ヒット率= (1-Innodb_buffer_pool_readsパラメーターの値 /Innodb_buffer_pool_read_requestsパラメーターの値) x 100% 。 TABLE_STATISTICSテーブルから各テーブルの読み取り /書き込み比率を取得することもできます。 テーブルの読み書き比率が高い場合は、SQL_CACHEオプションを使用して、テーブルの高速クエリキャッシュを有効にできます。 TABLE_STATISTICSテーブルの表示方法の詳細については、「Performance Insight」をご参照ください。
  • query_cache_typeパラメーターを使用して高速クエリキャッシュを管理します。

    ビジネスシナリオに基づいて、特定のセッションにquery_cache_typeパラメーターを設定できます。

    • RDSインスタンスが少数の読み取りクエリを処理し、多数の書き込みクエリを処理する場合、RDSインスタンスのデータは頻繁に更新されます。 この場合、query_cache_typeパラメーターをグローバルに0に設定することを推奨します。
    • RDSインスタンスのデータサイズが小さく、クエリタイプが固定され、ヒット率が高い場合は、query_cache_typeパラメーターをグローバルに1に設定することを推奨します。
    • RDSインスタンスのデータサイズが大きく、クエリタイプが変更され、ヒット率が不安定な場合は、query_cache_typeパラメーターを2に設定することを推奨します。 さらに、SQL_CACHEオプションを使用して、指定されたSQL文に対してのみ高速クエリキャッシュを有効にすることを推奨します。
  • query_cache_sizeパラメーターを使用して、適切なクエリキャッシュサイズを指定します。

    query_cache_sizeパラメーターは、SQL文と密接に関連しています。 それぞれが複数のレコードを返すクエリの結果をキャッシュする場合は、データサイズの数倍のクエリキャッシュサイズを指定する必要があります。 範囲クエリを実行しない場合は、次のテストを実行して、データサイズとquery_cache_sizeパラメーターの関係を評価できます。

    • テスト環境: 4 CPUコアと8 GBのメモリを備えた専用RDSインスタンス (InnoDBバッファプールのサイズは、innodb_buffer_pool_sizeパラメーターを使用して6 GBに設定されています) 。
    • テストツール: SysBench
    • テストデータサイズ: 10 GB (合計100テーブル、1テーブルあたり400,000レコード)

    テストケース: query_cache_sizeパラメーターを使用して異なるキャッシュサイズを指定し、キャッシュサイズごとにoltp_point_selectスクリプトを実行します。 64個のスレッドを同時に実行してデータを照会します。 この場合、テストデータには、ホットデータが含まれ20% 。 これにより、異なるキャッシュサイズ (query_cache_size) がQPSに与える影響を得ることができます。 実際の結果セットサイズは、テストデータサイズに基づいて2.5 GBです。

    表5. QPSの異なるキャッシュサイズ
    query_cache_size (MB)QCオフ高速QCヒット率高速QC (QPSの増加と比較してQC-OFF)
    6498,23622%99,440 (1.23%)
    12898,23645%114,155 (16.21%)
    25698,23672%140,668 (43.19%)
    51298,23682%151,260 (53.98%)
    102498,,23684%153,866 (56.63%)
    20489823687%159,597 (62.46%)
    409698,23692%169,412 (72.45%)

    query_cache_sizeパラメーターの値に関係なく、高速クエリキャッシュのパフォーマンスは低下しません。 具体的には、高速クエリキャッシュは、キャッシュヒット率に関係なく、プライマリキークエリに対してネイティブMySQLクエリキャッシュよりも大幅に高いパフォーマンスを提供します。 いくつかの状況では、パフォーマンスは90% 以上増加することさえあります。 キャッシュヒット率が90% 未満の場合、高速クエリキャッシュはネイティブMySQLクエリキャッシュよりも高いパフォーマンスを提供し、範囲クエリおよびORDER BY句を含むクエリのために多数のCPUリソースを節約します。