JP2023015968A - インテリジェントなクエリプランキャッシュサイズ管理 - Google Patents

インテリジェントなクエリプランキャッシュサイズ管理 Download PDF

Info

Publication number
JP2023015968A
JP2023015968A JP2021180175A JP2021180175A JP2023015968A JP 2023015968 A JP2023015968 A JP 2023015968A JP 2021180175 A JP2021180175 A JP 2021180175A JP 2021180175 A JP2021180175 A JP 2021180175A JP 2023015968 A JP2023015968 A JP 2023015968A
Authority
JP
Japan
Prior art keywords
cache
size
query execution
execution plan
query
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2021180175A
Other languages
English (en)
Other versions
JP7433281B2 (ja
Inventor
ジェヨン・ウォン
Jaeyeon Won
スン・グン・イ
Sung Gun Lee
サンヒ・イ
Sanghee Lee
ボヨン・ジョン
Jeon Boyeong
ヒョン・ジョ・ユン
Hyung Jo Yoon
ジュンギョン・ソン
Jungyoung Seong
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SAP SE filed Critical SAP SE
Publication of JP2023015968A publication Critical patent/JP2023015968A/ja
Application granted granted Critical
Publication of JP7433281B2 publication Critical patent/JP7433281B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/217—Database tuning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • G06F16/24542—Plan optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • G06F16/24539—Query rewriting; Transformation using cached or materialised query results

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computational Linguistics (AREA)
  • Operations Research (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Figure 2023015968000001
【課題】データベース管理システム（ＤＢＭＳ）におけるクエリプランキャッシュのサイズを管理する改善されたシステム及び方法を提供する。
【解決手段】データベース管理システムは、複数の入来クエリの実行中に、複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間を測定することができ、クエリ実行プランのうちの少なくともいくつかを記憶することができるサイズを有するクエリ実行プランキャッシュを有する。方法は、複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間と理想的なコンパイル時間との間の差を監視する。理想的なコンパイル時間は、クエリ実行プランがクエリ実行プランキャッシュからエビクトされないと仮定することによって、推定される。方法はまた、監視された差に基づいて、クエリ実行プランキャッシュのサイズを調整する。
【選択図】図４

Description

本開示は、概して、データベース管理システムに関し、より具体的には、インテリジェントなクエリプランキャッシュサイズ管理に関する。
クエリプラン(「クエリ実行プラン」とも呼ばれる)は、構造化クエリ言語(SQL)サーバなどのデータベース管理システム(DBMS)が、クエリを完了させるために実行するステップのシーケンスである。クエリがDBMSにおいて初めて実行されるとき、クエリがコンパイルされて、対応するクエリプランが生成され得、対応するクエリプランは、「クエリ実行プランキャッシュ」または単に「プランキャッシュ」とも呼ばれる、「クエリプランキャッシュ」と呼ばれるメモリ中に記憶され得、これらの用語は、本明細書で説明する例のいずれかにおいて互換的に使用され得る。したがって、同じクエリが再び実行されるとき、DBMSは、クエリプランを再生成する必要がない。代わりに、DBMSは、クエリプランキャッシュ中に記憶された、キャッシュされたクエリプランを再使用し、それによって、DBMSの効率を向上させることができる。
クエリプランキャッシュのサイズは、DBMSの性能のために重要であり得る。クエリプランキャッシュのサイズが大きすぎる場合、クエリプランキャッシュ空間の一部が使用されないことがあり、本来なら他の目的のために使用され得た貴重なキャッシュメモリの浪費につながることがある。一方、クエリプランキャッシュのサイズが小さすぎる場合、すべての生成されたクエリプランがクエリプランキャッシュ中に記憶されるとは限らないことがあり、クエリプランのうちのいくつかが、いくつかのエビクションポリシーに従って、クエリプランキャッシュからエビクトされなければならない。結果として、その対応するクエリプランがクエリプランキャッシュからエビクトされた入来クエリがあるとき、そのクエリは、再びコンパイルされなければならず、したがって、クエリ実行の遅延につながることになる。
したがって、DBMSにおけるクエリプランキャッシュのサイズを管理するための改善されたシステムおよび方法の必要が残っている。
本開示の実施形態は、コンピュータ実装方法を提供する。本方法は、
データベース管理システムにおける複数の入来クエリの実行中に、複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間を測定するステップであって、データベース管理システムが、クエリ実行プランのうちの少なくともいくつかを記憶することができるサイズを有する、クエリ実行プランキャッシュを備える、ステップと、
複数の入来クエリのためのクエリ実行プランを生成する、実際のコンパイル時間と理想的なコンパイル時間との間の差を監視するステップであって、理想的なコンパイル時間が、クエリ実行プランがクエリ実行プランキャッシュからエビクトされないと仮定することによって推定される、ステップと、
監視された差に基づいて、クエリ実行プランキャッシュのサイズを調整するステップと
を含む。
例示的なデータベース管理システムの全体的なブロック図である。 例示的なインテリジェントキャッシュマネージャのブロック図である。 インテリジェントなクエリプランキャッシュサイズ管理の例示的な全体的な方法を示すフローチャートである。 実際のコンパイル時間と理想的なコンパイル時間との間の差に基づいて、クエリプランキャッシュサイズを動的に調整するための方法を示すフローチャートである。 いくつかの入来クエリのために累積された、実際のコンパイル時間および理想的なコンパイル時間の例示的なプロットである。 図5に示された、実際のコンパイル時間と理想的なコンパイル時間との間のコンパイル時間差の例示的なプロットである。 図5に示された、入来クエリに対応する、変動するクエリプランキャッシュサイズの例示的なプロットである。 説明する実施形態が実装され得る、例示的なコンピューティングシステムのブロック図である。 本明細書で説明する技術とともに使用され得る、例示的なクラウドコンピューティング環境のブロック図である。
例1 - データベース管理システムの概観
図1は、本明細書で説明するインテリジェントなクエリプランキャッシュサイズ管理技術を実装することができる、例示的なデータベース管理システム100の全体的なブロック図を示す。例示的な一実施形態では、データベース管理システム100は、SQLサーバであり得る。
図示のように、データベース管理システム100は、クエリ処理エンジン130と、1つまたは複数のクライアント110とクエリ処理エンジン130との間のインターフェースの働きをするプロトコルレイヤ120とを含む。たとえば、プロトコルレイヤ120は、それによってクライアント110がクエリ処理エンジン130に接続することができる、サーバ名表示プロトコルを実装することができる。
クエリ処理エンジン130は、キャッシュマネージャ140と、クエリパーサ150と、クエリオプティマイザ160と、クエリエグゼキュータ170とを含み得る。キャッシュマネージャ140は、高速アクセスメモリ空間を表すキャッシュプール190にアクセスすることができる。キャッシュプール190は、以下で説明するように、前にコンパイルされたクエリ実行プランを記憶するように構成された、プランキャッシュ192を含み得る。いくつかの実施形態では、キャッシュプール190はまた、プランキャッシュ192に加えて、データキャッシュを含むこともでき、ここにおいて、データキャッシュは、通常のデータストレージよりもアクセスが高速であるか、またはアクセスの計算コストがより低いそのキャッシュメモリ中に、最近の、またはよく使用されるデータを保つように構成され得る。キャッシュプール190は、データベース管理システム100の主なメモリ消費者であり得、そのサイズは、MinおよびMaxメモリ設定を通して構成され得る。
クライアント110から送信された入来クエリは、クエリがプランキャッシュ192中に記憶された対応する(コンパイルされた)クエリ実行プランを有するか否かを決定するために、キャッシュマネージャ140によって評価され得る。
キャッシュマネージャ140が、入来クエリに対応するプランキャッシュ192中のクエリ実行プランを発見しない場合、入来クエリは、クエリパーサ150によって分析され得、クエリパーサ150は、クエリが構文および/または意味論的誤りを含んでいるか否かをチェックすることができる。入来クエリが、データを変更する有効なトランザクションSQL文(たとえば、SELECT、INSERT、UPDATE、DELETE、MERGEなど)であることを検証した後、クエリパーサ150は、それにおいてクエリが実行され得る、1つまたは複数の実行ツリーを生成することができる。実行ツリーは、どのようにクエリが実行されるようになるかを決定する、対応するクエリ実行プランを生成するために、クエリオプティマイザ160によって使用され得る。クエリオプティマイザ160は、それぞれの実行ツリーに基づいて生成される複数のクエリ実行プランの中で、どのクエリ実行プランが最も最適または効率的なもの(たとえば、CPU使用量、メモリ使用量などに基づいて計算されたクエリコストに関して最も安価であるもの)であるかを決定するように構成され得る。
次いで、決定された(すなわち、最も最適な)クエリ実行プランが、実行のためにクエリエグゼキュータ170に送信され得る。クエリエグゼキュータ170は、データストレージまたはメモリ空間180と通信し、クエリオプティマイザ160によって決定されたクエリ実行プラン中の演算子を実行することができる。データストレージまたはメモリ空間180から取り出されたデータは、プロトコルレイヤ120を介して、クライアント110に返され得る。
本明細書で説明するように、クエリコンパイルは、上記で説明したように、入来クエリを最適なクエリ実行プランに変換するプロセス(たとえば、構文および/または意味論的誤りをチェックすること、実行ツリーを生成すること、ならびに最適なクエリ実行プランを決定すること)を指す。クエリの複雑さ(たとえば、結合されたテーブルの数など)、およびクエリ最適化アルゴリズムに応じて、クエリコンパイル時間が長く(たとえば、数十秒またはそれ以上に)なり得る。したがって、動作効率を向上させるために、同じクエリが将来に再びサブミットされる場合、迅速に取り出され、再使用され得るように、入来クエリに対応するコンパイルされたクエリ実行プラン(すなわち、決定された最も最適なクエリ実行プラン)が、プランキャッシュ192中に記憶され得る。
たとえば、キャッシュマネージャ140が、入来クエリがプランキャッシュ192において対応するクエリ実行プランを有すると決定する場合、そのクエリ実行プランが、プランキャッシュ192から直接フェッチされ、実行のためにクエリエグゼキュータ170に転送され得る。したがって、このシナリオでは、クエリパーサ150およびクエリオプティマイザ160による動作がバイパスされ得る。言い換えれば、前にコンパイルされたそのクエリ実行プランがプランキャッシュ192において利用可能であるので、入来クエリが再コンパイルされる必要がない。
上述のように、プランキャッシュ192は、コンパイルされたクエリ実行プランを記憶することができる。入来クエリについて、キャッシュマネージャ140は、入来クエリが、プランキャッシュ192中に記憶された、コンパイルされたクエリ実行プランを有するか否かをチェックする。yesの場合、このキャッシュされたクエリ実行プランが再使用され得る。これによって、クエリをコンパイルする(すなわち、クエリ実行プランを再生成する)時間がなくなるので、効率を向上させることができる。一方、クエリが、プランキャッシュ192中に記憶された、コンパイルされたクエリ実行プランを有していない場合、クエリがコンパイルされなければならない。次いで、同じクエリが将来再び発生するとき、そのキャッシュされたクエリ実行プランへの高速アクセスが実現可能であるように、コンパイルされたクエリが、プランキャッシュ192中に記憶され得る。言い換えれば、プランキャッシュ192は、通常のメモリストアよりもアクセスが高速であるか、またはアクセスの計算コストがより低いそのキャッシュメモリ中に、最近の、またはよく使用されるクエリ実行プランを保つことによって、性能を向上させることができる。
入来クエリが新しい(すなわち、前にサブミットされていない初めてのクエリである)場合、この新しいクエリは、プランキャッシュ192中に対応するクエリ実行プランを有しておらず、初めてコンパイルされなければならない。一方、入来クエリが古い(すなわち、同じクエリが、前に少なくとも一度サブミットされている)場合、プランキャッシュ192中に対応するコンパイルされたクエリ実行プランがあるか否かは、プランキャッシュ192のサイズと、キャッシュマネージャ140によって採用されたプランエビクションポリシーとに依存し得る。
プランキャッシュ192は、制限されたサイズを有する。したがって、プランキャッシュ192は、すべてのコンパイルされたクエリ実行プランを記憶することが可能であるとは限らないことがある。プランキャッシュ192がその全容量に近づくとき、キャッシュマネージャ140によって実装されたあらかじめ定義されたプランエビクションポリシー(「プランエビクションアルゴリズム」とも呼ばれる)に従って、新しいもののための場所を空けるために、いくつかのクエリ実行プランが、プランキャッシュ192からエビクト(すなわち、除去)されなければならないことがある。エビクションポリシーの効率は、ヒット率(または、ヒット頻度)と呼ばれるメトリックによって測定され得、ヒット率は、キャッシュヒットの数をキャッシュヒットおよびミスの総数によって除算することによって計算され、ヒット率は、コンテンツのための要求を履行することにおいて、キャッシュがどのくらい有効であるかを測定するものである。本明細書で説明するように、プランキャッシュ192からのクエリ実行プランが要求され、プランキャッシュ192がその要求を履行することが可能であるとき、キャッシュヒットが発生する。
たとえば、キャッシュマネージャ140は、ランダムな方法で、プランキャッシュ192からクエリ実行プランをエビクトする、ランダムプランエビクションポリシーを実装することができる。別の例では、キャッシュマネージャ140は、プランキャッシュ192から最初に最長時間未使用のクエリ実行プランを除去する、最長時間未使用(LRU)プランエビクションポリシーを実装することができる。また別の例では、最小頻度使用(LFU)プランエビクションポリシーが使用されることがあり、このポリシーは、使用されることが最も少ない実行ポリシーを最初にエビクトする。さらなる例は、スコアベースのプランエビクションポリシーであり得る。たとえば、クエリ実行プランのためのスコアは、コンパイル時間およびヒット頻度の積を、クエリ実行プランのサイズによって除算したもの(すなわち、スコア=コンパイル時間×ヒット頻度/プランサイズ)として計算され得る。最低スコアをもつクエリ実行プランが、最初にエビクトされ得る(すなわち、クエリ実行プランが、コンパイルするためにより長い時間がかかるか、より頻繁に使用されるか、または小さいサイズを有する場合、エビクトされる可能性が低い)。上記で説明したプランエビクションポリシーは、例示的なものにすぎないことを理解されたい。多数の他のプランエビクションポリシーもまた、キャッシュマネージャ140によって使用され得る。
異なるプランエビクションポリシーは、それらのそれぞれの利点および欠点を有する。エビクションポリシーにかかわらず、プランキャッシュ192のサイズは、制限ファクタであり得る。プランキャッシュ192のサイズが大きすぎる場合、プランキャッシュ空間の一部が使用されないことがあり、本来なら他の目的のために(たとえば、データキャッシュのために)使用され得た貴重なキャッシュメモリの浪費につながることがある。一方、プランキャッシュ192のサイズが小さすぎる場合、クエリ実行プランのうちのいくつかが、いくつかのエビクションポリシーに従って、プランキャッシュ192から頻繁にエビクトされなければならないことがある。結果として、その対応するクエリプランがプランキャッシュ192からエビクトされた入来クエリがあるとき、そのクエリが再びコンパイルされなければならず、したがって、性能の低下につながることになる。
したがって、それは、データベース管理システムにおけるよりインテリジェントなプランキャッシュサイズ管理、および全体的な、より効率的なクエリ動作をサポートする、改善されたキャッシュ管理システムのために有利になる。そのようなインテリジェントなプランキャッシュサイズ管理技術は、多種多様なエンタープライズソフトウェア環境にわたって適用され得る。
例2 - DBMSにおける例示的なインテリジェントキャッシュマネージャ
図2は、データベース管理システムにおけるインテリジェントなプランキャッシュサイズ管理をサポートする、例示的なインテリジェントキャッシュマネージャ200のブロック図を示す。インテリジェントキャッシュマネージャ200は、上記で説明したキャッシュマネージャ140の例示的な一実施形態であり得る。
図示のように、インテリジェントキャッシュマネージャ200は、タイマー262と、時間差トラッカー264と、傾向アナライザ266と、プランキャッシュアジャスタ268とを含み得る。以下でさらに説明するように、タイマー262は、入来クエリの実際のコンパイル時間を測定または追跡することができる。タイマー262はまた、開始時間(たとえば、データベース管理システムがオンにされた時間)から経過した時間を測定または追跡することもできる。
時間差トラッカー264は、入来クエリのための対応する(たとえば、最適化された)クエリ実行プランを生成するために、実際のコンパイル時間と理想的なコンパイル時間との間の時間差を監視するように構成され得る。以下でより十分に説明するように、入来クエリのための理想的なコンパイル時間は、無制限のサイズを有すると仮定されるプランキャッシュから、クエリ実行プランがエビクトされないと仮定して、推定され得る。異なる入来クエリのための実際のコンパイル時間と理想的なコンパイル時間との間の監視された時間差は、インテリジェントキャッシュマネージャ200内であるか、またはキャッシュ空間(たとえば、190)中であるか、または他の場所であり得る、メモリ位置において記憶され得る。
傾向アナライザ266は、入来クエリのための実際のコンパイル時間と理想的なコンパイル時間との間の監視された差の傾向を決定するように構成され得る。傾向は、平坦、ほぼ平坦、または増加中であると決定され得る。いくつかの実施形態では、傾向は、前の時間期間にわたる実際のコンパイル時間と理想的なコンパイル時間との間の監視された時間差の傾きによって測定され得る。一実施形態では、前の時間期間の持続時間は、あらかじめ定義された持続時間であり得る。別の実施形態では、前の時間期間の持続時間は、その間にあらかじめ定義された数の入来クエリがクライアントによってサブミットされる時間期間として決定され得る。
プランキャッシュアジャスタ268は、入来クエリのための実際のコンパイル時間と理想的なコンパイル時間との間の監視された差に基づいて、プランキャッシュ(たとえば、192)のサイズを動的に調整するように構成され得る。以下でより十分に説明するように、いくつかの実施形態では、プランキャッシュのサイズは、たとえば、監視された時間差が前の時間期間にわたってある程度まで増加したとき、増大され得る。いくつかの実施形態では、プランキャッシュのサイズは、たとえば、監視された時間差が前の時間期間にわたって比較的平坦なままであったとき、縮小され得る。いくつかの実施形態では、プランキャッシュサイズの増大および/または縮小は、監視された時間差の傾きに適応可能であり得る。プランキャッシュサイズを増大させることは、余分のキャッシュまたはメモリ空間をプランキャッシュに割り当てること(たとえば、プランキャッシュ192の外部のキャッシュプール190の一部分を、プランキャッシュ192に転用すること)によって達成され得る。プランキャッシュサイズを縮小させることは、プランキャッシュの一部分を除去すること(たとえば、プランキャッシュ192の一部分をキャッシュプール190に解放すること)によって達成され得る。
実際には、システム100およびインテリジェントキャッシュマネージャ200など、本明細書で示されたシステムおよびサブシステムは、追加の機能、より複雑な構成要素などとともに、複雑さにおいて変動し得る。たとえば、キャッシュマネージャ140または200内に、追加の機能があり得る。追加の構成要素が、セキュリティ、冗長性、負荷分散、報告設計などを実装するために含まれ得る。
説明するコンピューティングシステムは、インターネットを含む、ワイヤードまたはワイヤレスネットワーク接続を介してネットワーク化され得る。代替的に、システムは、(たとえば、企業環境、政府環境などにおける)イントラネット接続を通して接続され得る。
システム100、および本明細書で説明する他のシステム/サブシステムのいずれかは、以下で説明するコンピューティングシステムなど、本明細書で説明するハードウェア構成要素(たとえば、処理ユニット、メモリなど)のいずれかとともに実装され得る。本明細書の例のいずれかでは、コンパイル時間、監視された時間差、監視された時間差の傾向および/または傾き、プランキャッシュサイズの増大および/または縮小などが、1つまたは複数のコンピュータ可読記憶媒体、またはコンピュータ可読記憶デバイスにおいて記憶され得る。本明細書で説明する技術は、オペレーティングシステムまたはハードウェアの詳細に対して一般的であり得、説明する特徴を利用するために、任意の様々な環境において適用され得る。
例3 - インテリジェントなクエリプランキャッシュサイズ管理の例示的な全体的な方法
図3は、インテリジェントなクエリプランキャッシュサイズ管理を実装する例示的な全体的な方法のフローチャート300であり、たとえば、図1のシステムによって、または、より具体的には、キャッシュマネージャ140もしくは200によって実施され得る。
310において、方法は、データベース管理システムにおける複数の入来クエリの実行中に、複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間を測定することができる。データベース管理システムは、クエリ実行プランのうちの少なくともいくつかを記憶することができるサイズを有する、クエリ実行プランキャッシュを含み得る。いくつかの実施形態では、入来クエリのコンパイル時間を測定することは、キャッシュマネージャのタイマー(たとえば、262)によって実施され得る。
320において、方法は、複数の入来クエリのためのクエリ実行プランを生成する、実際のコンパイル時間と理想的なコンパイル時間との間の差を監視することができる。本明細書で説明するように、理想的なコンパイル時間は、クエリ実行プランがクエリ実行プランキャッシュからエビクトされないと仮定することによって、推定され得る。このことは、クエリ実行プランキャッシュのサイズが無制限であると仮定される、理想的な状況において発生し得る。
理想的なコンパイル時間の推定は、古いクエリをコンパイルしないことから節約される時間を測定することによって実施され得る。たとえば、入来クエリが新しい場合、クエリ実行プランキャッシュのサイズが無制限である場合でも、この新しいクエリは、初めてコンパイルされなければならない。したがって、理想的なコンパイル時間は、この新しいクエリをコンパイルするための時間の量によって増加することになる。しかしながら、入来クエリが古い場合、前にコンパイルされたそのクエリ実行プランが、クエリ実行プランキャッシュ中に存在しなければならず、その理由は、理想的な状況では、クエリ実行プランキャッシュが無制限のサイズを有し、いかなるクエリ実行プランも決してエビクトしないからである。結果として、この古いクエリは、再コンパイルされる必要がなく、理想的なコンパイル時間は不変のままになる。言い換えれば、古いクエリを再コンパイルするための時間が、理想的な状況において節約される。したがって、理想的なコンパイル時間は、入来クエリをコンパイルすることが可能である下限または最小コンパイル時間を確立する。任意の測定された実際のコンパイル時間は、理想的なコンパイル時間と同じであるか(クエリ実行プランのエビクションが発生しないとき)、または理想的なコンパイル時間よりも大きいか(クエリ実行プランのエビクションが発生するとき)のいずれかになる。
いくつかの実施形態では、複数の入来クエリのための実際のコンパイル時間と理想的なコンパイル時間との間の差は、キャッシュマネージャの時間差トラッカー(たとえば、264)によって監視され得る。加えて、複数の入来クエリのための実際のコンパイル時間と理想的なコンパイル時間との間の差は、キャッシュマネージャ(たとえば、140または200)、またはキャッシュプール(たとえば、190)、または他の場所中であり得る、メモリ位置において記憶され得る。
次いで、330において、監視された差に基づいて、方法は、クエリ実行プランキャッシュのサイズを調整することができる。いくつかの実施形態では、キャッシュマネージャにおける傾向アナライザ(たとえば、266)が、時間期間にわたる監視された時間差の傾向を決定するために使用され得る。監視された時間差の決定された傾向は、プランキャッシュアジャスタ(たとえば、268)によって受信され得、プランキャッシュアジャスタは、以下でより十分に説明するように、それに応じて、クエリ実行プランキャッシュのサイズを動的に増大および/または縮小させることができる。
フローチャート300において説明する方法、および本明細書で説明する他の方法のいずれも、1つまたは複数のコンピュータ可読媒体(たとえば、記憶または他の有形媒体)において記憶されたか、あるいは1つまたは複数のコンピュータ可読記憶デバイスにおいて記憶された、(たとえば、コンピューティングシステムに方法を実施させる)コンピュータ実行可能命令によって実施され得る。そのような方法は、ソフトウェア、ファームウェア、ハードウェア、またはそれらの組合せにおいて実施され得る。そのような方法は、コンピューティングシステム(たとえば、1つまたは複数のコンピューティングデバイス)によって少なくとも部分的に実施され得る。
図示されたアクションは、依然として技術を実装しながら、代替的な観点から説明され得る。たとえば、「受信する」は、異なる観点から「送信する」としても説明され得る。
例4 - 実際のコンパイル時間と理想的なコンパイル時間との間の差に基づいて、クエリプランキャッシュサイズを動的に調整するための例示的な方法
図4は、複数の入来クエリのための実際のコンパイル時間と理想的なコンパイル時間との間の監視された差に基づいて、クエリ実行プランキャッシュのサイズを動的に調整するための例示的な方法のフローチャート400を示す。上述のように、方法は、キャッシュマネージャにおける傾向アナライザ(たとえば、266)とともに、プランキャッシュアジャスタ(たとえば、268)によって実施され得る。
図示のように、410において、方法は、前の時間ウィンドウにわたる実際のコンパイル時間と理想的なコンパイル時間との間の監視された差を受信することができる。一実施形態では、前の時間ウィンドウは、あらかじめ定義された持続時間(たとえば、1秒、10秒、1分など)を有し得る。別の実施形態では、前の時間ウィンドウは、所定の数の入来クエリ(たとえば、1,000クエリ、5,000クエリ、10,000クエリなど)が実行される時間の持続時間に対応し得る。
次いで、前の時間ウィンドウにわたる監視された時間差が評価され得る。たとえば、420において、前の時間ウィンドウにわたる監視された時間差が、時間差における増加が第1のしきい値(TH1)を超えたような程度まで増加したか否かを決定するために、条件チェックが実施され得、第1のしきい値(TH1)は、あらかじめ定義された値(たとえば、20秒、1分など)であり得る。yesの場合、方法は、430に分岐して、プランキャッシュサイズを増大させることができる。noの場合、方法は、440において別の条件チェックを実施して、前の時間ウィンドウにわたる監視された時間差が増加を有していないか、または制限された増加のみを有するか否かを決定することができる。たとえば、方法は、時間差における増加を第2のしきい値(TH2)と比較することができ、第2のしきい値(TH2)もまた、あらかじめ定義された値(たとえば、1秒、10秒など)であり得る。一般に、第2のしきい値(TH2)は、第1のしきい値(TH1)と同じであるか、またはそれよりも小さく、すなわち、TH2≦TH1である。yesの場合、前の時間ウィンドウにおける時間差における増加が無視できるものであるか、または実際のコンパイル時間と理想的なコンパイル時間との間の時間差がほぼ平坦であると決定され得、方法は、450に分岐して、プランキャッシュサイズを縮小させることができる。そうでない場合、方法は、460に分岐することができ、そこで、プランキャッシュサイズにおける変更が発生しない。
TH1=TH2である特殊な場合には、ステップ460が実施されない。言い換えれば、440における条件チェックが(それが420における条件チェックに対して冗長であるので)必要とされず、プランキャッシュサイズは、430において増大するか、または450において縮小するかのいずれかになり得る。
TH1=0である、別の特殊な場合には、前の時間ウィンドウにおける時間差におけるいかなる増加も、430におけるプランキャッシュサイズの増大につながり得る。
TH2=0である、また別の特殊な場合には、方法は、前の時間ウィンドウにわたる時間差において増加がなかった(すなわち、実際のコンパイル時間と理想的なコンパイル時間との間の時間差が、平坦なままである)ときのみ、450においてプランキャッシュサイズを縮小させることができる。
図示されたフローチャート400においては、条件チェック420が条件チェック440の前に実施されるが、代替実施形態では、条件チェック420が条件チェック440の後に実施され得ることを理解されたい。
いくつかの実施形態では、時間差の評価(たとえば、条件チェック420および440)は、連続する、重複しない時間ウィンドウにおいて実施され得る。たとえば、評価は、1分(または、他のあらかじめ定義された持続時間)後ごとに、または1,000クエリ(または、他のあらかじめ定義された数のクエリ)後ごとに実施され得る。他の実施形態では、時間差の評価(たとえば、条件チェック420および440)は、連続する、重複する時間ウィンドウにおいて実施され得る。隣接する時間ウィンドウ間の重複の程度は、あらかじめ定義され得る。たとえば、第1の時間ウィンドウは、0から60秒までの時間期間に対応し得、第2の時間ウィンドウは、1から61秒までの時間期間に対応し得る(すなわち、1秒の重複がある)などとなる。同様に、第1の時間ウィンドウは、クエリ1～1000を含む時間ウィンドウに対応し得、第2の時間ウィンドウは、クエリ11～1011を含む時間ウィンドウに対応し得る(すなわち、10クエリの重複がある)などとなる。
例5 - クエリプランキャッシュサイズの増分または減分の量を決定するための例示的な方法
本明細書の例のいずれかでは、プランキャッシュサイズは、余分のキャッシュまたはメモリ空間をプランキャッシュに割り当てること(たとえば、キャッシュプール190中の余分のキャッシュ空間をプランキャッシュ192に割り当てること)によって増大されるか、あるいは、プランキャッシュの一部分を除去すること(たとえば、プランキャッシュ192の一部分をキャッシュプール190に解放すること)によって縮小され得る。
本明細書の例のいずれかでは、プランキャッシュサイズの増大および/または縮小は、あらかじめ定義された最大および/または最小プランキャッシュサイズ制限内に制約され得る。いくつかの実施形態では、最大および/または最小プランキャッシュサイズ制限は、固定値であり得る。いくつかの実施形態では、最大および/または最小プランキャッシュサイズ制限は、キャッシュプール(たとえば、190)のサイズに適応可能であるように構成され得る。たとえば、プランキャッシュサイズの増大は、固定値(たとえば、1GB、2GB、10GBなど)を有する最大キャッシュサイズ、またはキャッシュプールのサイズのあらかじめ定義された割合(たとえば、50%、60%、75%など)によって制限され得る。同様に、プランキャッシュサイズの縮小は、固定値(たとえば、10MB、100MB、200MBなど)を有する最小キャッシュサイズ、またはキャッシュプールのサイズのあらかじめ定義された割合(たとえば、10%、20%、25%など)によって制限され得る。
本明細書の例のいずれかでは、プランキャッシュサイズの増大または縮小の量が固定され得る。たとえば、プランキャッシュサイズを増大させるために、あらかじめ定義されたサイズ(たとえば、1MB、10MB、25MBなど)の余分のキャッシュが、プランキャッシュに追加され得る。同様に、プランキャッシュサイズを縮小させるために、あらかじめ定義されたサイズ(たとえば、1MB、10MB、25MBなど)を有するキャッシュ部分が、プランキャッシュから除去され得る。
本明細書の例のいずれかでは、プランキャッシュサイズの増大または縮小の量は、現在のプランキャッシュサイズ(すなわち、そのような増大または縮小の前のプランキャッシュのサイズ)に適応可能であるか、または比例し得る。たとえば、プランキャッシュサイズを増大させるために、そのサイズが現在のプランキャッシュサイズのあらかじめ定義された割合(たとえば、0.5%、1%、2%など)である余分のキャッシュが、プランキャッシュに追加され得る。同様に、プランキャッシュサイズを縮小させるために、そのサイズが現在のプランキャッシュサイズのあらかじめ定義された割合(たとえば、0.5%、1%、2%など)であるキャッシュ部分が、プランキャッシュから除去され得る。
本明細書の例のいずれかでは、プランキャッシュサイズの増大または縮小の量は、あらかじめ定義されたサイズ制限と現在のプランキャッシュサイズとの間の差に適応可能であるか、または比例し得る。たとえば、プランキャッシュサイズを増大させるために、余分のキャッシュがプランキャッシュに追加され得、ここにおいて、余分のキャッシュのサイズは、(上記で説明したような)最大キャッシュサイズと現在のプランキャッシュサイズとの間の差のあらかじめ定義された分数(たとえば、1/4、1/3、1/2など)であり得る。同様に、プランキャッシュサイズを縮小させるために、キャッシュ部分がプランキャッシュから除去され得、ここにおいて、キャッシュ部分のサイズは、現在のプランキャッシュサイズと(上記で説明したような)最小キャッシュサイズとの間の差のあらかじめ定義された分数(たとえば、1/8、1/5、1/4など)であり得る。
本明細書の例のいずれかでは、プランキャッシュサイズの増大または縮小の量は、(「参照クエリプラン」とも呼ばれる)プランキャッシュ中に記憶されたクエリ実行プランのサイズに適応可能であるか、または比例し得る。たとえば、プランキャッシュサイズを増大させるために、余分のキャッシュがプランキャッシュに追加され得、ここにおいて、余分のキャッシュのサイズは、参照クエリプランのサイズに比例し(たとえば、50%、100%、200%などであり)得る。同様に、プランキャッシュサイズを縮小させるために、キャッシュ部分がプランキャッシュから除去され得、ここにおいて、キャッシュ部分のサイズは、参照クエリプランのサイズに比例し(たとえば、50%、100%、150%などであり)得る。いくつかの実施形態では、プランキャッシュ中に最後に記憶されたクエリ実行プランが、参照実行プランとして選択され得る。他の実施形態では、参照クエリプランが、他の基準に基づいて選択され得る。たとえば、参照クエリプランは、最も古いクエリ実行プラン、最大のクエリ実行プラン、最大のコンパイル時間に関連付けられたクエリ実行プラン、または最高(または最低)のヒット率に関連付けられたクエリプランなどであるように選択され得る。
本明細書の例のいずれかでは、前の時間ウィンドウにわたる実際のコンパイル時間と理想的なコンパイル時間との間の監視された時間差の傾きは、たとえば、傾向アナライザ266によって測定され得る。いくつかの実施形態では、傾きは、前の時間ウィンドウにおける時間差における合計の増大と、前の時間ウィンドウの持続時間の比として測定され得る。代替的に、傾きは、前の時間ウィンドウにおける時間差における合計の増大と、前の時間ウィンドウにおける入来クエリの総数の比として測定され得る。
図4における条件チェック420および440と同様に、プランキャッシュのサイズは、測定された傾きがあらかじめ定義された第1のしきい値よりも大きい(すなわち、傾きが正である)場合、増大されるか、あるいは測定された傾きが0であるか、またはあらかじめ定義された第2のしきい値よりも小さい場合、縮小され得、ここにおいて、第2のしきい値が、第1のしきい値以下である。いくつかの実施形態では、プランキャッシュサイズの増大の量は、測定された傾きに適応可能であるか、または比例し得る。たとえば、測定された傾きが大きいほど、プランキャッシュサイズの増大が大きくなる。
例6 - クエリプランキャッシュサイズの動的な調整を示す例示的な使用事例
上記で説明したインテリジェントなクエリプランキャッシュサイズ管理の方法をさらに例示するために、例示的な使用事例について、図5～図7を参照して以下で説明する。図5～図7は、例示のためのものにすぎず、必ずしも一定の縮尺で描かれるとは限らないことを理解されたい。たとえば、以下で説明するいくつかの区間の長さおよび/または傾きは、図に示されるものから変動することがある。加えて、図5～図7に示された線形区間のうちのいくつかは、非線形の形状を有することがある。
図5は、いくつかの入来クエリのために累積された、(破線において示された)実際のコンパイル時間510および(直線において示された)理想的なコンパイル時間520の例示的なプロット500を概略的に示す。表示されたx軸は、入来クエリがサブミットされる実行時間である。代替的に、x軸は、入来クエリの数を指すことがある。y軸は、入来クエリの合計コンパイル時間(すなわち、累積されたコンパイル時間)である。
実際のコンパイル時間510は、入来クエリのための累積されたコンパイル時間を測定することによって取得され得る。実際のコンパイル時間510は、実装されたプランエビクションポリシーに依存するようになる。たとえば、初めてコンパイルされなければならない新しいクエリがある場合、または、古いクエリが、プランキャッシュ中に記憶された対応するクエリ実行プランを有していない(すなわち、前にコンパイルされたクエリ実行プランが、実装されたプランエビクションポリシーに従って、プランキャッシュからエビクトされた)場合、実際のコンパイル時間510が増加するようになる。一方、古いクエリが、プランキャッシュ中に記憶された対応するクエリ実行プランを有し、そのクエリが再コンパイルされる必要がないようになる場合、実際のコンパイル時間510は平坦なままになる。上述のように、理想的なコンパイル時間520は、クエリ実行プランがクエリ実行プランキャッシュからエビクトされないと仮定することによって、推定され得る。したがって、新しいクエリは、依然として初めてコンパイルされる必要があるが、古いクエリは再びコンパイルされないようになる。
図示された例では、実行時間(または、入来クエリ)は、6つの区間A、B、C、D、E、およびFに分割され得る。区間AおよびFにおいては、すべての入来クエリが新しい。したがって、実装されたプランエビクションポリシーがあるか否か、またはクエリ実行プランのエビクションがないか否かにかかわらず、これらのクエリは、それらの実行前に初めてコンパイルされなければならない。実際のコンパイル時間510および理想的なコンパイル時間520は、(たとえば、区間Aにおける最初において)互いに重複するようになるか、またはそれらの差530は、(たとえば、後の区間Fにおいて)一定のままになる。区間Bにおいて、いくつかの入来クエリは新しく、いくつかの入来クエリは古い。新しいクエリは、依然としてコンパイルされる必要があるが、古いクエリは、理想的な条件(すなわち、プランエビクションなし)では再コンパイルされる必要がない。しかしながら、古いクエリのうちのいくつかは、実装されたプランエビクションポリシーに基づいて再コンパイルされる必要があり得る。結果として、区間Bにおいて、実際のコンパイル時間510および理想的なコンパイル時間520の相違が生じることになる。区間CおよびEにおいては、すべての入来クエリが古い。これらのクエリが再コンパイルされる必要がないので、理想的なコンパイル時間520は、平坦なままになる。しかしながら、古いクエリのうちのいくつかは、実装されたプランエビクションポリシーに基づいて再コンパイルされる必要が依然としてあり得る。結果として、そのことが、区間CおよびEにおいて、実際のコンパイル時間510および理想的なコンパイル時間520のさらなる相違につながるようになる。区間Dにおいては、すべての入来クエリが古いが、それらがすべて、プランキャッシュ中に記憶された対応するクエリ実行プランを有する(すなわち、実装されたプランエビクションポリシーに従って、エビクションがない)。したがって、実際のコンパイル時間510と理想的なコンパイル時間520との間の差530は、区間Dにおいて一定のままになる。
例示のために、図6は、図5に示された実際のコンパイル時間510と理想的なコンパイル時間520との間のコンパイル時間差530を示す、曲線610をプロットする。図示のように、コンパイル時間差530は、区間A、D、およびFにおいては平坦なままであり、区間B、C、およびEにおいては、傾きの程度が変動しながら増加する。
上記で説明したように、インテリジェントキャッシュマネージャは、前の時間ウィンドウにおける実際のコンパイル時間と理想的なコンパイル時間との間の時間差におけるかなりの増加があった(たとえば、時間差が、あらかじめ定義された第1のしきい値を超える)場合、プランキャッシュサイズを増大させること、または、実際のコンパイル時間と理想的なコンパイル時間との間の時間差が一定もしくはほぼ平坦なままであった(たとえば、時間差が、あらかじめ定義された第2のしきい値を下回る)場合、プランキャッシュサイズを縮小させることを行うように構成され得る。
例示のため、図7は、図5に示された、入来クエリに対応する、変動するプランキャッシュサイズを示す例示的な曲線710をプロットする。図示のように、プランキャッシュサイズは、コンパイル時間差が平坦なままであるとき、区間A、D、およびFにおいて縮小する。対照的に、プランキャッシュサイズは、実際のコンパイル時間と理想的なコンパイル時間との間の時間差が徐々に増加するとき、区間B、C、およびEにおいて増大する。上述のように、異なる方法が、プランキャッシュサイズの増大または縮小の量を決定するために選択され得る(たとえば、プランキャッシュサイズの増大または縮小の量は、固定であるか、またはいくつかのメトリクスに適応可能であり得る)。したがって、各区間における曲線710の傾きもまた、プランキャッシュサイズの増大または縮小の量を決定するために選定された方法に応じて変動し得る。
したがって、プランキャッシュのサイズが、(たとえば、区間A、D、およびFにおいて)大部分の入来クエリのクエリ実行プランを保持するために十分に大きいとき、少数のクエリ実行プランがプランキャッシュからエビクトされるので、クエリ実行の性能に悪影響を及ぼすことなしに、(たとえば、キャッシュリソースをキャッシュプールに解放するために)プランキャッシュサイズが徐々に低減され得る。しかしながら、プランキャッシュが(たとえば、区間B、C、およびEにおいて)著しく低減され、前にコンパイルされたそれらのクエリ実行プランがプランキャッシュからエビクトされたので、いくつかの入来クエリが再コンパイルされる必要があるようになるとき、プランエビクションポリシーの悪影響を低減または軽減するように、プランキャッシュサイズが徐々に増大され得る。
例7 - 例示的な利点
いくつかの利点は、本明細書で説明する技術を介して達成され得る。たとえば、インテリジェントキャッシュマネージャは、プランキャッシュの実際の必要に基づいて、すなわち、それぞれ、プランキャッシュの必要が増すか、または減るにつれて、プランキャッシュサイズを増大または低減しながら、キャッシュプランサイズを動的に調整することができる。このことは重要であり、その理由は、プランキャッシュの必要が実行時間において予測不可能であることがあり、何のクエリがクライアントによってサブミットされるかに応じて、著しく変動し得るからである。結果として、開示する技術は、データベース管理システムの性能を最大にするために、適切なプランキャッシュサイズを継続的に発見(または、最適化)することができる。適切な(または、最適化された)プランキャッシュサイズは、クエリ性能とリソース管理との間の正しいバランスを取ることができ、一方では、クエリプランの頻繁なエビクションと、古いクエリの再コンパイルとを引き起こすほど小さくなく、他方では、貴重なキャッシュメモリリソースを浪費するほど大きくない。本明細書で説明するインテリジェントなプランキャッシュ管理技術は、任意のクエリプランエビクションポリシーを実装する任意のデータベース管理システムに容易に展開され得る。加えて、キャッシュプランサイズの動的な調整の開示する方法は、人間の対話なしに、インテリジェントキャッシュマネージャによって自動的に実施され得る。さらに、キャッシュプランサイズのそのような動的な調整は、オンザフライで、またはリアルタイムで達成され得る(たとえば、キャッシュプランサイズの調整は、前の時間ウィンドウにおける実際のコンパイル時間および理想的なコンパイル時間における時間差を評価した後、1秒の何分の1以内に実現され得る)。
例8 - 例示的なコンピューティングシステム
図8は、説明する革新が実装され得る、好適なコンピューティングシステム800の一例を示す。コンピューティングシステム800は、本開示の使用または機能の範囲についてのいかなる限定も示唆するものではなく、その理由は、これらの革新が多様なコンピューティングシステムにおいて実装され得るからである。
図8を参照すると、コンピューティングシステム800は、1つまたは複数の処理ユニット810、815と、メモリ820、825とを含む。図8においては、この基本構成830が破線内に含まれる。処理ユニット810、815は、本明細書の例において説明する特徴を実施するためなどの、コンピュータ実行可能命令を実行する。処理ユニットは、汎用中央処理ユニット(CPU)、特定用途向け集積回路(ASIC)におけるプロセッサ、または任意の他のタイプのプロセッサであり得る。多重処理システムにおいては、複数の処理ユニットがコンピュータ実行可能命令を実行して、処理能力を増大させる。たとえば、図8は、中央処理ユニット810、ならびにグラフィックス処理ユニットまたはコプロセッシングユニット815を示す。有形のメモリ820、825は、処理ユニット810、815によってアクセス可能な、揮発性メモリ(たとえば、レジスタ、キャッシュ、RAM)、不揮発性メモリ(たとえば、ROM、EEPROM、フラッシュメモリなど)、またはそれらの2つの何らかの組合せであり得る。メモリ820、825は、処理ユニット810、815による実行のために好適なコンピュータ実行可能命令の形態で、本明細書で説明する1つまたは複数の革新を実装するソフトウェア880を記憶する。
コンピューティングシステム800は、追加の特徴を有し得る。たとえば、コンピューティングシステム800は、入力デバイスと、出力デバイスと、ユーザと対話するための通信接続とを含む、ストレージ840と、1つまたは複数の入力デバイス850と、1つまたは複数の出力デバイス860と、1つまたは複数の通信接続870とを含む。バス、コントローラ、またはネットワークなどの相互接続機構(図示せず)は、コンピューティングシステム800の構成要素を相互接続する。典型的には、オペレーティングシステムソフトウェア(図示せず)は、コンピューティングシステム800において実行する他のソフトウェアのための動作環境を提供し、コンピューティングシステム800の構成要素のアクティビティを協調させる。
有形のストレージ840は、リムーバブルまたは非リムーバブルであり得、磁気ディスク、磁気テープもしくはカセット、CD-ROM、DVD、または情報を非一時的な方法で記憶するために使用され得、コンピューティングシステム800内でアクセスされ得る、任意の他の媒体を含む。ストレージ840は、本明細書で説明する1つまたは複数の革新を実装するソフトウェアのための命令を記憶する。
入力デバイス850は、キーボード、マウス、ペン、もしくはトラックボールなどの入力デバイス、音声入力デバイス、走査デバイス、タッチデバイス(たとえば、タッチパッド、ディスプレイなど)、またはコンピューティングシステム800に入力を提供する別のデバイスであり得る。出力デバイス860は、ディスプレイ、プリンタ、スピーカー、CDライター、またはコンピューティングシステム800からの出力を提供する別のデバイスであり得る。
通信接続870は、別のコンピューティングエンティティへの通信媒体を介した通信を可能にする。通信媒体は、コンピュータ実行可能命令、オーディオもしくはビデオ入力もしくは出力、または変調されたデータ信号における他のデータなどの情報を搬送する。変調されたデータ信号は、信号において情報を符号化するような方法でその特性のうちの1つまたは複数が設定または変更されている、信号である。例として、限定ではなく、通信媒体は、電気的、光学的、RF、または他のキャリアを使用することができる。
これらの革新について、プログラムモジュール中に含まれるものなど、コンピュータ実行可能命令が、ターゲットの現実または仮想のプロセッサ上のコンピューティングシステムにおいて実行される(たとえば、1つまたは複数のハードウェアプロセッサ上で最終的に実行される)という文脈で説明することができる。一般に、プログラムモジュールまたは構成要素は、特定のタスクを実施するか、または特定の抽象データ型を実装する、ルーチン、プログラム、ライブラリ、オブジェクト、クラス、構成要素、データ構造などを含む。プログラムモジュールの機能は、様々な実施形態において必要に応じて、プログラムモジュールの間で結合または分離され得る。プログラムモジュールのためのコンピュータ実行可能命令は、ローカルまたは分散コンピューティングシステム内で実行され得る。
提示のために、発明を実施するための形態は、コンピューティングシステムにおけるコンピュータ動作について説明するために、「決定する」および「使用する」のような用語を使用する。これらの用語は、コンピュータによって実施される動作についての高レベルの説明であり、人間によって実施される行為と混同されるべきではない。これらの用語に対応する実際のコンピュータ動作は、実装形態に応じて変動する。
例9 - コンピュータ可読媒体
本明細書のコンピュータ可読媒体のいずれも、非一時的(たとえば、DRAMまたはSRAMなどの揮発性メモリ、磁気ストレージ、光ストレージなどの不揮発性メモリ)、および/または有形であり得る。本明細書で説明する記憶するアクションのいずれも、1つまたは複数のコンピュータ可読媒体(たとえば、コンピュータ可読記憶媒体、または他の有形媒体)中に記憶することによって実施され得る。記憶されるとして説明するもの(たとえば、実施中に作成および使用されたデータ)のいずれも、1つまたは複数のコンピュータ可読媒体(たとえば、コンピュータ可読記憶媒体、または他の有形媒体)中に記憶され得る。コンピュータ可読媒体は、信号からなるものではない実装形態に限定され得る。
本明細書で説明する方法のいずれも、1つまたは複数のコンピュータ可読媒体(たとえば、コンピュータ可読記憶媒体、または他の有形の媒体)、あるいは1つまたは複数のコンピュータ可読記憶デバイス(たとえば、メモリ、磁気ストレージ、光ストレージなど)における(たとえば、その上で記憶された、その上で符号化されたなどの)、コンピュータ実行可能命令によって実施され得る。そのような命令は、コンピューティングデバイスに方法を実施させることができる。本明細書で説明する技術は、様々なプログラミング言語において実装され得る。
例10 - 例示的なクラウドコンピューティング環境
図9は、たとえば、上記で開示したシステムおよび本明細書の他のシステムを含む、説明する技術が実装され得る、例示的なクラウドコンピューティング環境900を示す。クラウドコンピューティング環境900は、クラウドコンピューティングサービス910を備える。クラウドコンピューティングサービス910は、コンピュータサーバ、データストレージリポジトリ、ネットワーキングリソースなど、様々なタイプのクラウドコンピューティングリソースを備え得る。クラウドコンピューティングサービス910は、中央に位置する(たとえば、会社または組織のデータセンターによって提供される)か、または分散する(たとえば、異なるデータセンターなどの異なる位置に位置する、および/または異なる市もしくは国に位置する、様々なコンピューティングリソースによって提供される)ことが可能である。
クラウドコンピューティングサービス910は、コンピューティングデバイス920、922、および924など、様々なタイプのコンピューティングデバイス(たとえば、クライアントコンピューティングデバイス)によって利用される。たとえば、コンピューティングデバイス(たとえば、920、922、および924)は、コンピュータ(たとえば、デスクトップまたはラップトップコンピュータ)、モバイルデバイス(たとえば、タブレットコンピュータまたはスマートフォン)、または他のタイプのコンピューティングデバイスであり得る。たとえば、コンピューティングデバイス(たとえば、920、922、および924)は、クラウドコンピューティングサービス910を利用して、コンピューティング動作(たとえば、データ処理、データストレージなど)を実施することができる。
実際には、クラウドベース、オンプレミスベース、またはハイブリッドのシナリオがサポートされ得る。
例11 - 例示的な実装形態
開示する方法のうちのいくつかの動作について、好都合な提示のために、特定の順番において説明するが、そのような説明の方法は、特定の順序が本明細書で記載する特定の言語によって必要とされない限り、再配列を包含する。たとえば、連続的に説明する動作は、場合によっては再配列されるか、または同時に実施され得る。
例12 - 例示的な実施形態
以下の実施形態のいずれもが実装され得る。
1節. コンピュータ実装方法であって、データベース管理システムにおける複数の入来クエリの実行中に、複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間を測定するステップであって、データベース管理システムが、クエリ実行プランのうちの少なくともいくつかを記憶することができるサイズを有する、クエリ実行プランキャッシュを備える、ステップと、複数の入来クエリのためのクエリ実行プランを生成する、実際のコンパイル時間と理想的なコンパイル時間との間の差を監視するステップであって、理想的なコンパイル時間が、クエリ実行プランがクエリ実行プランキャッシュからエビクトされないと仮定することによって推定される、ステップと、監視された差に基づいて、クエリ実行プランキャッシュのサイズを調整するステップとを含む方法。
2節. 複数の入来クエリのためのクエリ実行プランを生成する、実際のコンパイル時間と理想的なコンパイル時間との間の差を、メモリ位置において記憶するステップをさらに含む、1節の方法。
3節. 複数の入来クエリのためのクエリ実行プランを生成する、実際のコンパイル時間と理想的なコンパイル時間との間の差の傾向を決定するステップをさらに含む、1～2節のいずれか1つの方法。
4節. 傾向を決定するステップが、前の時間期間における差の傾きを決定するステップと、クエリ実行プランキャッシュのサイズを、ステップサイズだけ増大させるステップであって、傾きが0よりも大きい場合、ステップサイズが傾きに比例する、ステップとを含む、3節の方法。
5節. クエリ実行プランキャッシュのサイズを調整するステップが、所定の数の入来クエリを実行した後、監視された差が、あらかじめ定義されたしきい値よりも大きい量だけ増大した場合、クエリ実行プランキャッシュのサイズを増大させるステップを含む、1～4節のいずれか1つの方法。
6節. クエリ実行プランキャッシュのサイズを増大させるステップが、余分のキャッシュをクエリ実行プランキャッシュに割り当てるステップであって、余分のキャッシュのサイズが、クエリ実行プランキャッシュ中に最後に記憶されたクエリ実行プランのサイズに比例する、ステップを含む、5節の方法。
7節. クエリ実行プランキャッシュのサイズを増大させるステップが、余分のキャッシュをクエリ実行プランキャッシュに割り当てるステップであって、余分のキャッシュのサイズが、あらかじめ定義された最大キャッシュサイズと、余分のキャッシュを割り当てる前のクエリ実行プランキャッシュのサイズとの間の差のあらかじめ定義された分数である、ステップを含む、5節の方法。
8節. クエリ実行プランキャッシュのサイズを調整するステップが、所定の数の入来クエリを実行した後、監視された差が、あらかじめ定義されたしきい値よりも大きい量だけ増大しなかった場合、クエリ実行プランキャッシュのサイズを縮小させるステップを含む、1～7節のいずれか1つの方法。
9節. クエリ実行プランキャッシュのサイズを縮小させるステップが、クエリ実行プランキャッシュの中からキャッシュ部分を除去するステップであって、キャッシュ部分が、あらかじめ定義されたサイズを有する、ステップを含む、8節の方法。
10節. クエリ実行プランキャッシュのサイズを縮小させるステップが、クエリ実行プランキャッシュの中からキャッシュ部分を除去するステップであって、キャッシュ部分のサイズが、キャッシュ部分を除去する前の、クエリ実行プランキャッシュのサイズのあらかじめ定義された割合である、ステップを含む、8節の方法。
11節. コンピューティングシステムであって、メモリと、メモリに結合された、1つまたは複数のハードウェアプロセッサと、メモリにロードされたとき、1つまたは複数のハードウェアプロセッサに動作を実施させる命令を記憶する、1つまたは複数のコンピュータ可読記憶媒体とを備え、動作が、データベース管理システムにおける複数の入来クエリの実行中に、複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間を測定することであって、データベース管理システムが、クエリ実行プランのうちの少なくともいくつかを記憶することができるサイズを有する、クエリ実行プランキャッシュを備える、こと、複数の入来クエリのためのクエリ実行プランを生成する、実際のコンパイル時間と理想的なコンパイル時間との間の差を監視することであって、理想的なコンパイル時間が、クエリ実行プランがクエリ実行プランキャッシュからエビクトされないと仮定することによって推定される、こと、および、監視された差に基づいて、クエリ実行プランキャッシュのサイズを調整することを含む、システム。
12節. クエリ実行プランキャッシュのサイズを調整することが、所定の数の入来クエリを実行した後、監視された差が、あらかじめ定義されたしきい値よりも大きい量だけ増大した場合、クエリ実行プランキャッシュのサイズを増大させることを含む、11節のシステム。
13節. クエリ実行プランキャッシュのサイズを増大させることが、余分のキャッシュをクエリ実行プランキャッシュに割り当てることであって、余分のキャッシュのサイズが、クエリ実行プランキャッシュ中に最後に記憶されたクエリ実行プランのサイズに比例する、ことを含む、12節のシステム。
14節. クエリ実行プランキャッシュのサイズを増大させることが、余分のキャッシュをクエリ実行プランキャッシュに割り当てることであって、余分のキャッシュのサイズが、あらかじめ定義された最大キャッシュサイズと、余分のキャッシュを割り当てる前のクエリ実行プランキャッシュのサイズとの間の差のあらかじめ定義された分数である、ことを含む、12節のシステム。
15節. クエリ実行プランキャッシュのサイズを調整することが、所定の数の入来クエリを実行した後、監視された差が、あらかじめ定義されたしきい値よりも大きい量だけ増大しなかった場合、クエリ実行プランキャッシュのサイズを縮小させることを含む、11～14節のいずれか1つのシステム。
16節. クエリ実行プランキャッシュのサイズを縮小させることが、クエリ実行プランキャッシュの中からキャッシュ部分を除去することであって、キャッシュ部分が、あらかじめ定義されたサイズを有する、ことを含む、15節のシステム。
17節. クエリ実行プランキャッシュのサイズを縮小させることが、クエリ実行プランキャッシュの中からキャッシュ部分を除去することであって、キャッシュ部分のサイズが、キャッシュ部分を除去する前の、クエリ実行プランキャッシュのサイズのあらかじめ定義された割合である、ことを含む、15節に記載のシステム。
18節. 動作が、複数の入来クエリのためのクエリ実行プランを生成する、実際のコンパイル時間と理想的なコンパイル時間との間の差の傾向を決定することをさらに含む、11～17節のいずれか1つのシステム。
19節. 傾向を決定することが、前の時間期間における差の傾きを決定すること、および、クエリ実行プランキャッシュのサイズを、ステップサイズだけ増大させることであって、傾きが0よりも大きい場合、ステップサイズが傾きに比例する、ことを含む、18節のシステム。
20節. 1つまたは複数のプロセッサに方法を実施させるコンピュータ実行可能命令を符号化して有する、1つまたは複数のコンピュータ可読媒体であって、方法が、データベース管理システムにおける複数の入来クエリの実行中に、複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間を測定するステップであって、データベース管理システムが、クエリ実行プランのうちの少なくともいくつかを記憶することができるサイズを有する、クエリ実行プランキャッシュを備える、ステップと、複数の入来クエリのためのクエリ実行プランを生成する、実際のコンパイル時間と理想的なコンパイル時間との間の差を監視するステップであって、理想的なコンパイル時間が、クエリ実行プランがクエリ実行プランキャッシュからエビクトされないと仮定することによって推定される、ステップと、監視された差に基づいて、クエリ実行プランキャッシュのサイズを調整するステップとを含み、クエリ実行プランキャッシュのサイズを調整するステップが、所定の数の入来クエリを実行した後、監視された差が増大した場合、クエリ実行プランキャッシュのサイズを増大させるステップと、所定の数の入来クエリを実行した後、監視された差が平坦なままであった場合、クエリ実行プランキャッシュのサイズを縮小させるステップとを含む、コンピュータ可読媒体。
例13 - 例示的な代替形態
いかなる例からの技術も、他の例のうちの任意の1つまたは複数において説明する技術と組み合わせられ得る。開示する技術の原理が適用され得る多数の可能な実施形態に鑑みて、例示する実施形態は、開示する技術の例であり、開示する技術の範囲の限定として解釈されるべきではないことを認識されたい。むしろ、開示する技術の範囲は、以下の特許請求の範囲の範囲および趣旨によって包含されるものを含む。
100 データベース管理システム、システム
110 クライアント
120 プロトコルレイヤ
130 クエリ処理エンジン
140 キャッシュマネージャ
150 クエリパーサ
160 クエリオプティマイザ
170 クエリエグゼキュータ
180 データストレージまたはメモリ空間
190 キャッシュプール
192 プランキャッシュ
200 インテリジェントキャッシュマネージャ、キャッシュマネージャ
262 タイマー
264 時間差トラッカー
266 傾向アナライザ
268 プランキャッシュアジャスタ
270 プランエビクションマネージャ
500 例示的なプロット
510 実際のコンパイル時間
520 理想的なコンパイル時間
530 差、コンパイル時間差
610、710 曲線
800 コンピューティングシステム
810 処理ユニット、中央処理ユニット
815 処理ユニット、グラフィックス処理ユニットまたはコプロセッシングユニット
820、825 メモリ
830 基本構成
840 ストレージ
850 入力デバイス
860 出力デバイス
870 通信接続
880 ソフトウェア
900 クラウドコンピューティング環境
910 クラウドコンピューティングサービス
920、922、924 コンピューティングデバイス

Claims (20)

  1. コンピュータ実装方法であって、
    データベース管理システムにおける複数の入来クエリの実行中に、前記複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間を測定するステップであって、前記データベース管理システムが、前記クエリ実行プランのうちの少なくともいくつかを記憶することができるサイズを有する、クエリ実行プランキャッシュを備える、ステップと、
    前記複数の入来クエリのためのクエリ実行プランを生成する、前記実際のコンパイル時間と理想的なコンパイル時間との間の差を監視するステップであって、前記理想的なコンパイル時間が、クエリ実行プランが前記クエリ実行プランキャッシュからエビクトされないと仮定することによって推定される、ステップと、
    前記監視された差に基づいて、前記クエリ実行プランキャッシュの前記サイズを調整するステップと
    を含む方法。
  2. 前記複数の入来クエリのためのクエリ実行プランを生成する、前記実際のコンパイル時間と前記理想的なコンパイル時間との間の前記差を、メモリ位置において記憶するステップをさらに含む、請求項1に記載の方法。
  3. 前記複数の入来クエリのためのクエリ実行プランを生成する、前記実際のコンパイル時間と前記理想的なコンパイル時間との間の前記差の傾向を決定するステップをさらに含む、請求項1に記載の方法。
  4. 前記傾向を決定するステップが、前の時間期間における前記差の傾きを決定するステップと、前記クエリ実行プランキャッシュの前記サイズを、ステップサイズだけ増大させるステップであって、前記傾きが0よりも大きい場合、前記ステップサイズが前記傾きに比例する、ステップとを含む、請求項3に記載の方法。
  5. 前記クエリ実行プランキャッシュの前記サイズを調整するステップが、所定の数の入来クエリを実行した後、前記監視された差が、あらかじめ定義されたしきい値よりも大きい量だけ増大した場合、前記クエリ実行プランキャッシュの前記サイズを増大させるステップを含む、請求項1に記載の方法。
  6. 前記クエリ実行プランキャッシュの前記サイズを増大させるステップが、余分のキャッシュを前記クエリ実行プランキャッシュに割り当てるステップであって、前記余分のキャッシュのサイズが、前記クエリ実行プランキャッシュ中に最後に記憶されたクエリ実行プランのサイズに比例する、ステップを含む、請求項5に記載の方法。
  7. 前記クエリ実行プランキャッシュの前記サイズを増大させるステップが、余分のキャッシュを前記クエリ実行プランキャッシュに割り当てるステップであって、前記余分のキャッシュのサイズが、あらかじめ定義された最大キャッシュサイズと、前記余分のキャッシュを割り当てる前の前記クエリ実行プランキャッシュの前記サイズとの間の差のあらかじめ定義された分数である、ステップを含む、請求項5に記載の方法。
  8. 前記クエリ実行プランキャッシュの前記サイズを調整するステップが、所定の数の入来クエリを実行した後、前記監視された差が、あらかじめ定義されたしきい値よりも大きい量だけ増大しなかった場合、前記クエリ実行プランキャッシュの前記サイズを縮小させるステップを含む、請求項1に記載の方法。
  9. 前記クエリ実行プランキャッシュの前記サイズを縮小させるステップが、前記クエリ実行プランキャッシュの中からキャッシュ部分を除去するステップであって、前記キャッシュ部分が、あらかじめ定義されたサイズを有する、ステップを含む、請求項8に記載の方法。
  10. 前記クエリ実行プランキャッシュの前記サイズを縮小させるステップが、前記クエリ実行プランキャッシュの中からキャッシュ部分を除去するステップであって、前記キャッシュ部分のサイズが、前記キャッシュ部分を除去する前の、前記クエリ実行プランキャッシュの前記サイズのあらかじめ定義された割合である、ステップを含む、請求項8に記載の方法。
  11. コンピューティングシステムであって、
    メモリと、
    前記メモリに結合された、1つまたは複数のハードウェアプロセッサと、
    前記メモリにロードされたとき、前記1つまたは複数のハードウェアプロセッサに動作を実施させる命令を記憶する、1つまたは複数のコンピュータ可読記憶媒体とを備え、前記動作が、
    データベース管理システムにおける複数の入来クエリの実行中に、前記複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間を測定することであって、前記データベース管理システムが、前記クエリ実行プランのうちの少なくともいくつかを記憶することができるサイズを有する、クエリ実行プランキャッシュを備える、こと、
    前記複数の入来クエリのためのクエリ実行プランを生成する、前記実際のコンパイル時間と理想的なコンパイル時間との間の差を監視することであって、前記理想的なコンパイル時間が、クエリ実行プランが前記クエリ実行プランキャッシュからエビクトされないと仮定することによって推定される、こと、および
    前記監視された差に基づいて、前記クエリ実行プランキャッシュの前記サイズを調整すること
    を含む、システム。
  12. 前記クエリ実行プランキャッシュの前記サイズを調整することが、所定の数の入来クエリを実行した後、前記監視された差が、あらかじめ定義されたしきい値よりも大きい量だけ増大した場合、前記クエリ実行プランキャッシュの前記サイズを増大させることを含む、請求項11に記載のシステム。
  13. 前記クエリ実行プランキャッシュの前記サイズを増大させることが、余分のキャッシュを前記クエリ実行プランキャッシュに割り当てることであって、前記余分のキャッシュのサイズが、前記クエリ実行プランキャッシュ中に最後に記憶されたクエリ実行プランのサイズに比例する、ことを含む、請求項12に記載のシステム。
  14. 前記クエリ実行プランキャッシュの前記サイズを増大させることが、余分のキャッシュを前記クエリ実行プランキャッシュに割り当てることであって、前記余分のキャッシュのサイズが、あらかじめ定義された最大キャッシュサイズと、前記余分のキャッシュを割り当てる前の前記クエリ実行プランキャッシュの前記サイズとの間の差のあらかじめ定義された分数である、ことを含む、請求項12に記載のシステム。
  15. 前記クエリ実行プランキャッシュの前記サイズを調整することが、所定の数の入来クエリを実行した後、前記監視された差が、あらかじめ定義されたしきい値よりも大きい量だけ増大しなかった場合、前記クエリ実行プランキャッシュの前記サイズを縮小させることを含む、請求項11に記載のシステム。
  16. 前記クエリ実行プランキャッシュの前記サイズを縮小させることが、前記クエリ実行プランキャッシュの中からキャッシュ部分を除去することであって、前記キャッシュ部分が、あらかじめ定義されたサイズを有する、ことを含む、請求項15に記載のシステム。
  17. 前記クエリ実行プランキャッシュの前記サイズを縮小させることが、前記クエリ実行プランキャッシュの中からキャッシュ部分を除去することであって、前記キャッシュ部分のサイズが、前記キャッシュ部分を除去する前の、前記クエリ実行プランキャッシュの前記サイズのあらかじめ定義された割合である、ことを含む、請求項15に記載のシステム。
  18. 前記動作が、前記複数の入来クエリのためのクエリ実行プランを生成する、前記実際のコンパイル時間と前記理想的なコンパイル時間との間の前記差の傾向を決定することをさらに含む、請求項11に記載のシステム。
  19. 前記傾向を決定することが、前の時間期間における前記差の傾きを決定すること、および、前記クエリ実行プランキャッシュの前記サイズを、ステップサイズだけ増大させることであって、前記傾きが0よりも大きい場合、前記ステップサイズが前記傾きに比例する、ことを含む、請求項18に記載のシステム。
  20. 1つまたは複数のプロセッサに方法を実施させるコンピュータ実行可能命令を符号化して有する、1つまたは複数のコンピュータ可読媒体であって、前記方法が、
    データベース管理システムにおける複数の入来クエリの実行中に、前記複数の入来クエリのためのクエリ実行プランを生成する実際のコンパイル時間を測定するステップであって、前記データベース管理システムが、前記クエリ実行プランのうちの少なくともいくつかを記憶することができるサイズを有する、クエリ実行プランキャッシュを備える、ステップと、
    前記複数の入来クエリのためのクエリ実行プランを生成する、前記実際のコンパイル時間と理想的なコンパイル時間との間の差を監視するステップであって、前記理想的なコンパイル時間が、クエリ実行プランが前記クエリ実行プランキャッシュからエビクトされないと仮定することによって推定される、ステップと、
    前記監視された差に基づいて、前記クエリ実行プランキャッシュの前記サイズを調整するステップと
    を含み、
    前記クエリ実行プランキャッシュの前記サイズを調整するステップが、所定の数の入来クエリを実行した後、前記監視された差が増大した場合、前記クエリ実行プランキャッシュの前記サイズを増大させるステップと、前記所定の数の入来クエリを実行した後、前記監視された差が平坦なままであった場合、前記クエリ実行プランキャッシュの前記サイズを縮小させるステップとを含む、コンピュータ可読媒体。
JP2021180175A 2021-07-20 2021-11-04 インテリジェントなクエリプランキャッシュサイズ管理 Active JP7433281B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/381,059 2021-07-20
US17/381,059 US11971889B2 (en) 2021-07-20 2021-07-20 Intelligent query plan cache size management

Publications (2)

Publication Number Publication Date
JP2023015968A true JP2023015968A (ja) 2023-02-01
JP7433281B2 JP7433281B2 (ja) 2024-02-19

Family

ID=80682340

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021180175A Active JP7433281B2 (ja) 2021-07-20 2021-11-04 インテリジェントなクエリプランキャッシュサイズ管理

Country Status (4)

Country Link
US (1) US11971889B2 (ja)
EP (1) EP4123461A1 (ja)
JP (1) JP7433281B2 (ja)
CN (1) CN115640312A (ja)

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6999958B2 (en) * 2002-06-07 2006-02-14 International Business Machines Corporation Runtime query optimization for dynamically selecting from multiple plans in a query based upon runtime-evaluated performance criterion
US7502775B2 (en) * 2006-03-31 2009-03-10 International Business Machines Corporation Providing cost model data for tuning of query cache memory in databases
US8548986B2 (en) * 2010-03-19 2013-10-01 Microsoft Corporation Adaptive row-batch processing of database data
US20170139991A1 (en) * 2015-11-16 2017-05-18 Linkedin Corporation Dynamic query plan based on skew
US10467152B2 (en) 2016-05-18 2019-11-05 International Business Machines Corporation Dynamic cache management for in-memory data analytic platforms
JP7006013B2 (ja) 2017-08-22 2022-01-24 富士通株式会社 データ提供プロラム、データ提供方法、及びデータ提供装置
US10922316B2 (en) * 2018-06-13 2021-02-16 Amazon Technologies, Inc. Using computing resources to perform database queries according to a dynamically determined query size
US12013856B2 (en) * 2018-08-13 2024-06-18 Amazon Technologies, Inc. Burst performance of database queries according to query size
US11061902B2 (en) * 2018-10-18 2021-07-13 Oracle International Corporation Automated configuration parameter tuning for database performance
US11188538B2 (en) * 2018-12-27 2021-11-30 Teradata Us, Inc. Dynamic generated query plan caching
CN113227986B (zh) * 2019-01-30 2024-06-18 阿里巴巴集团控股有限公司 存储查询计划的方法和系统及查询数据库系统的方法
US11704316B2 (en) * 2019-05-31 2023-07-18 Qubole, Inc. Systems and methods for determining peak memory requirements in SQL processing engines with concurrent subtasks
US11308100B2 (en) * 2019-06-25 2022-04-19 Amazon Technologies, Inc. Dynamically assigning queries to secondary query processing resources
US11036740B2 (en) * 2019-09-11 2021-06-15 Sap Se Database management system query plan cache management

Also Published As

Publication number Publication date
US11971889B2 (en) 2024-04-30
US20230021502A1 (en) 2023-01-26
CN115640312A (zh) 2023-01-24
JP7433281B2 (ja) 2024-02-19
EP4123461A1 (en) 2023-01-25

Similar Documents

Publication Publication Date Title
JP5744707B2 (ja) メモリ使用量照会ガバナのためのコンピュータ実装方法、コンピュータ・プログラム、およびシステム（メモリ使用量照会ガバナ）
US9330012B2 (en) Allocation enforcement in a multi-tenant cache mechanism
EP2002343B1 (en) Multi-cache cooperation for response output caching
US8601216B2 (en) Method and system for removing cache blocks
US8918602B2 (en) Dynamically altering time to live values in a data cache
US9208094B2 (en) Managing and sharing storage cache resources in a cluster environment
US9195599B2 (en) Multi-level aggregation techniques for memory hierarchies
US8402223B2 (en) Cache eviction using memory entry value
US20200125491A1 (en) Techniques for handling requests for data at a cache
US20130297884A1 (en) Enhancing data processing performance by cache management of fingerprint index
US11556536B2 (en) Autonomic caching for in memory data grid query processing
EP4123473A1 (en) Intelligent query plan cache size management
US20150142845A1 (en) Smart database caching
Zulfa et al. Caching strategy for Web application–a systematic literature review
US8954969B2 (en) File system object node management
US7908268B2 (en) Predictive database pool preparation
JP7433281B2 (ja) インテリジェントなクエリプランキャッシュサイズ管理
US20090320036A1 (en) File System Object Node Management
US7120776B2 (en) Method and apparatus for efficient runtime memory access in a database
KR102319718B1 (ko) 동적 매니코어 파티셔닝 장치 및 방법
CN114547037A (zh) 数据图表缓存方法、介质、装置和计算设备
Deora et al. Architecture of Cloud Server with Cache on Server

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221116

TRDD Decision of grant or rejection written
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20231226

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240109

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240206

R150 Certificate of patent or registration of utility model

Ref document number: 7433281

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150