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

PolarDB:高速クエリキャッシュ

最終更新日:May 23, 2024

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

制限事項

PolarDBクラスターでは、次のいずれかのバージョンを使用する必要があります。

  • リビジョンバージョンが8.0.1.1.5以降のPolarDB for MySQL 8.0クラスター。

  • リビジョンバージョンが5.7.1.0.15以降のPolarDB for MySQL 5.7クラスター。

  • リビジョンバージョンが5.6.1.0.29以降のPolarDB for MySQL 5.6クラスター。

説明

クラスターバージョンを確認する方法の詳細については、「エンジンバージョンの照会」をご参照ください。

問題と解決策

クエリキャッシュは、CPUリソースを節約してクエリの応答時間を短縮し、クエリを最適化するのに役立つキャッシュポリシーです。 クエリキャッシュは、条件を満たす各クエリステートメントから取得した結果セットをキャッシュするように設計されています。 結果セットが別のクエリによってヒットした場合、キャッシュされた結果セットはクエリキャッシュから読み取られて返されます。 これにより、ステートメントを再度分析、最適化、および実行する必要がなくなります。

MySQLのネイティブクエリキャッシュには、設計と実装に関連する次の問題があります。

  • MySQLのネイティブクエリキャッシュは、多数の同時クエリを高速で処理することができません。 同時実行性の高いシナリオでは、複数のCPUコアが構成されている場合、処理速度がさらに低下する可能性があります。

  • MySQLのネイティブクエリキャッシュは、最も早い機会にメモリリソースを適切に管理したり、メモリリソースを再利用したりできません。 これにより、メモリ使用量が少なくなります。

  • キャッシュヒット率が低い場合、クエリのパフォーマンスを向上させることができず、パフォーマンスが低下する可能性があります。

したがって、MySQLのネイティブクエリキャッシュは広く使用されていません。 この機能はMySQL 8.0では提供されなくなりました。 代わりに、高速クエリキャッシュ機能が開発され、MySQLのネイティブクエリキャッシュに基づいてPolarDB用に最適化されています。 この機能には次の利点があります。

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

    MySQLクエリキャッシュで使用されるグローバルロックメカニズムは非推奨です。 高速クエリキャッシュ機能は、新しいロックフリーメカニズムを使用してデータを同期します。 これにより、複数のCPUコアの機能と、同時実行性の高いシナリオでのパフォーマンスが保証されます。

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

    ネイティブMySQLクエリキャッシュで使用されるメモリ事前割り当てメカニズムは廃止されました。 高速クエリキャッシュ機能は、より柔軟な動的メモリ割り当てメカニズムを使用します。 このメカニズムにより、無効なメモリリソースをすばやく再利用でき、メモリリソースを有効に使用できます。

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

    高速クエリキャッシュ機能は、キャッシュの使用状況を動的に検出し、キャッシュポリシーをリアルタイムで調整します。 これにより、キャッシュヒット率が低い場合、またはクラスターが読み取り要求と書き込み要求の両方を処理する場合のシナリオで、安定したクエリパフォーマンスが保証されます。

PolarDBの高速クエリキャッシュ機能を有効にして、ビジネス要件に基づいてクエリのパフォーマンスを向上させることができます。

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

PolarDBは、さまざまな仕様のクラスターで使用される高速クエリキャッシュ用にさまざまなメモリサイズを提供します。 高速クエリキャッシュ機能を有効にするには、loose_query_cache_typeパラメーターを設定するだけです。 詳細については、「クラスターパラメーターとノードパラメーターの指定」をご参照ください。

説明
  • PolarDB for MySQL 8.0で高速クエリキャッシュ機能を有効にするには、loose_query_cache_typeパラメーターをONに設定するだけです。

  • PolarDB for MySQL 5.6または5.7で高速クエリキャッシュ機能を有効にするには、query_cache_typeパラメーターを1に設定するだけです。

性能比較

他の条件が同じ場合は、高速クエリキャッシュ機能が有効 (PolarDB-QCシナリオ) または無効 (QC-OFFシナリオ) の場合、1秒あたりのクエリ数 (QPS) を確認します。

  • テスト環境

    • テストでは、8コアと64 GBのメモリを備えたPolarDB for MySQL 8.0 Cluster Editionクラスターが使用されます。

    • 高速クエリキャッシュのメモリ容量は4 GBです。

  • テストツール

    Sysbench

  • テストデータ

    • 各テーブルに40,000行の25のテーブル。

    • 各テーブルに400,000行の25のテーブル。

  • テストケース

    rand-typeパラメーターがspecialまたはuniformに設定されている場合は、次の組み込みsysbenchケースを使用してQPSをテストします。

    • oltp_read_only

    • oltp_point_select

    • oltp_read_write

  • テスト結果と説明

    キャッシュヒット率が高く、同時クエリの数が多い場合、クラスターのQPSは大幅に増加します。 高速クエリキャッシュ機能を有効にすると、ケース1、3、4、5、および7では、キャッシュヒット率は63% 〜99% になり、クラスターのQPSは53% 〜106% に増加します。 高速クエリキャッシュ機能を有効にすると、メモリ使用量が多くなります。 ケース7では、特殊oltp_point_selectテストにおいて、テストデータ量が多い場合にキャッシュヒット率が99% に達する。 この場合、QPSは著しく増加する。 キャッシュヒット率が低い場合、ケース2及びケース6では、クラスタのQPSが3% 以下低下する。 これは、高速クエリキャッシュ機能が同時実行シナリオのQPSにほとんど影響を与えないことを示しています。 クラスターが多数の同時読み取りおよび書き込み要求を処理すると、クラスターのQPSは2% 以下に減少します。

    説明

    次のテストデータは、クラスターのプライマリノードにのみ関連しています。

    • ケース1: 25テーブル × 40,000行、rand-type = special oltp_read_only 1

    • ケース2: 25テーブル × 40,000行、rand-type = uniform oltp_read_only 2

    • ケース3: 25テーブル × 40,000行、rand-type = special oltp_point_select 3

    • ケース4: 25テーブル × 40,000行、rand-type = uniform oltp_point_select 4

    • ケース5: 25テーブル × 400,000行、rand-type = special oltp_read_only 5

    • ケース6: 25テーブル × 400,000行、rand-type = uniform oltp_read_only 6

    • ケース7: 25テーブル × 400,000行、rand-type = special oltp_point_select 7

    • ケース8: 25テーブル × 400,000行、rand-type = uniform oltp_point_select 8

    • ケース9: 25テーブル × 400,000行、rand-type = special oltp_read_write 9

実践ガイドライン

  • 適用シナリオ

    • 高速クエリキャッシュ機能は、読み取りのQPSを増やすために使用されます。 書き込みよりも多くの読み取りを処理するシナリオでは、高速クエリキャッシュ機能を有効にすることをお勧めします。 SQL_CACHEキーワードを使用して、書き込み要求よりも多くの読み取り要求を受信するテーブルに対して高速クエリキャッシュ機能を有効にすることもできます。 PolarDBクラスターが少数の読み取りリクエストを処理し、多数の書き込みリクエストを処理する場合、PolarDBクラスターのデータは頻繁に更新されます。 この場合、高速クエリキャッシュ機能を有効にすると、クラスターのクエリパフォーマンスが約2% 低下する可能性があります。

    • 高速クエリキャッシュ機能を有効にすると、メモリ使用量が多くなります。 これは、必要な更新が少なく、大量の同時読み取りを受け取るシナリオに適用されます。 この機能により、同時読み取りのクエリパフォーマンスが大幅に向上します。

  • loose_query_cache_typeパラメーターを使用して高速クエリキャッシュ機能を管理する

    MySQLクエリキャッシュは、loose_query_cache_typeパラメーターに基づいて管理できます。 このパラメーターを使用して、高速クエリキャッシュを管理することもできます。

    パラメーター

    説明

    loose_query_cache_type

    オフ

    高速クエリキャッシュ機能は無効になっています。 この値がデフォルトです。

    オン

    デフォルトでは、高速クエリキャッシュ機能はデータクエリに使用されます。 ただし、SQL_NO_CACHEキーワードを指定して、クラスターが高速クエリキャッシュから結果を取得できないようにすることができます。

    需要

    デフォルトでは、高速クエリキャッシュ機能はデータクエリには使用されません。 ただし、SQL_CACHEキーワードを使用して、指定したステートメントの高速クエリキャッシュ機能を有効にできます。

    説明

    ビジネス要件に基づいて、特定のセッションに対してloose_query_cache_typeパラメーターを指定できます。

    • PolarDBクラスターが少数の読み取りリクエストを処理し、多数の書き込みリクエストを処理する場合、またはクラスターデータが頻繁に更新される場合は、loose_query_cache_typeOFFに設定します。

    • PolarDBクラスターが多数の繰り返し低速クエリを処理する場合、またはキャッシュヒット率が高い場合は、loose_query_cache_typeONに設定します。

    • PolarDBクラスターが少数の繰り返しクエリを処理する場合は、loose_query_cache_typeDEMANDに設定します。 SQL_CACHEキーワードを使用して、特定のステートメントの高速クエリキャッシュ機能を有効にできます。 サンプルコード:

      SELECT SQL_CACHE id, name FROM customer;
  • query_cache_lease_timeパラメーターを使用して、高速クエリキャッシュのリース時間を管理します。

    高速クエリキャッシュ機能は、クエリキャッシュメモリを動的に再利用します。 これにより、キャッシュ機構によって占有されるメモリリソースの量が減少する。 query_cache_lease_timeで指定された期間 (秒単位) 中に、期限切れでないクエリキャッシュがクエリによってヒットしなかった場合、キャッシュはリース時間に達した後に解放されます。 この場合、クエリキャッシュのメモリリソースが再利用されます。 デフォルト値は3600で、1時間に相当します。

互換性

高速クエリキャッシュ機能は、グローバル一貫性 (高性能モード) 機能と互換性があります。 グローバル整合性 (高性能モード) のためのMTT最適化機能が有効にされ、高速クエリキャッシュおよびグローバル整合性 (高性能モード) 機能の両方が有効にされる場合、MTT最適化機能は無効になる。 グローバル整合性 (ハイパフォーマンスモード) 機能の詳細については、「概要」をご参照ください。