JP2020061032A - データベースサーバ管理プログラム、データベースサーバ管理方法、およびデータベースシステム - Google Patents

Abstract

【課題】ＤＢサーバの運用台数の動的な適正化を可能とする。【解決手段】情報処理装置は、複数のレコードが格納されたデータベース内の複数のレコードそれぞれについて、所定期間内のアクセス回数を計数する。次に情報処理装置は、複数のレコードのうち、アクセス回数が閾値以上の高頻度アクセスレコードを抽出する。次に情報処理装置は、高頻度アクセスレコードのデータ量と、データベースサーバ１台あたりの高頻度アクセスレコードを格納するのに利用可能なメモリ容量とに基づいて、データベース内のデータへのアクセス要求の処理に利用する運用データベースサーバの適正台数を決定する。次に情報処理装置は、適正台数となるように、運用データベースサーバの台数を調整する。そして情報処理装置は、台数調整後の運用データベースサーバのメモリに高頻度アクセスレコードを格納する。【選択図】図１５

Description

本発明は、データベースサーバ管理プログラム、データベースサーバ管理方法、およびデータベースシステムに関する。

ＩＣＴ（Information and Communications Technology）では、基幹業務に点在・散在する大量のデータ（ビッグデータ）を効率的に管理することが重要となっている。例えばビッグデータを管理するシステムには、データのアクセス要求に対して、ユーザがストレスを感じない程度の応答性能が求められる。応答性能は、例えばシステムがアクセス要求を受信してからアクセス結果が出力されるまでのレスポンスタイムで表される。

アクセス要求に対する応答性能を向上させる手段の１つとして、例えば管理しているデータをＳＳＤ（Solid State Drive）などの高速アクセス可能な記憶装置に格納することが考えられる。ただし、高速アクセス可能な記憶装置はハードディスク装置より高額であり、ビッグデータと呼ばれるような膨大な量のデータのすべてを高速アクセス可能な記憶装置に格納するのは非現実的である。

ビッグデータのうち、エンドユーザから高頻度で使用されるデータは、全体の一部である場合が多い。そこでアクセス頻度が高いデータを、高速にアクセス可能な記憶領域に格納することで、データアクセスへの応答性能を効率的に向上させることができる。

例えば大容量の外部記憶装置のアクセス速度による情報処理速度の低下を防ぐため、アクセス頻度の高いファイルをメモリ記憶装置に格納する情報処理装置が提案されている。
また、アクセス頻度が一定値以上になった分散データをその分散データ単位に移動させることで分散データの配置の最適化を図るデータベース管理システムも提案されている。

特開平１０−６３５５１号公報 特開平８−３３９３２３号公報

データのアクセス要求への応答性能を維持するには、十分な数のデータベース（ＤＢ：Data Base）サーバを用意することも重要となる。他方、ＤＢサーバが多すぎると、システム内に他のサーバに振り分ける資源が不足し、システム全体の処理効率が低下する可能性がある。従って、データアクセスに対する十分な応答性能を得ることができる最小限のＤＢサーバでシステムを運用するのが適切である。

データアクセスに対する応答性能は、データへのアクセス頻度などのシステムの運用状況の影響を受ける。そのため、所望の応答性能を得るための適切なＤＢサーバ数もリアルタイムに変化する。しかし、従来は、データアクセスに対する十分な応答性能を得るための適切なＤＢサーバ数をリアルタイムに判断する手段がない。そのためシステムの運用状況に応じて、ＤＢサーバの運用台数を動的に適正化することができない。

１つの側面では、本件は、ＤＢサーバの運用台数の動的な適正化を可能とすることを目的とする。

１つの案では、コンピュータに以下の処理を実行させるデータベースサーバ管理プログラムが提供される。
コンピュータは、複数のレコードが格納されたデータベース内の複数のレコードそれぞれについて、所定期間内のアクセス回数を計数する。次にコンピュータは、複数のレコードのうち、アクセス回数が閾値以上の高頻度アクセスレコードを抽出する。次にコンピュータは、高頻度アクセスレコードのデータ量と、データベースサーバ１台あたりの高頻度アクセスレコードを格納するのに利用可能なメモリ容量とに基づいて、データベース内のデータへのアクセス要求の処理に利用する運用データベースサーバの適正台数を決定する。次にコンピュータは、適正台数となるように、運用データベースサーバの台数を調整する。そしてコンピュータは、台数調整後の運用データベースサーバのメモリに高頻度アクセスレコードを格納する。

１態様によれば、ＤＢサーバの運用台数の動的な適正化が可能となる。

第１の実施の形態に係るシステムの一例を示す図である。 ＤＢサーバ管理方法の一例を示す図である。 システム構成の一例を示す図である。 物理サーバのハードウェアの一例を示す図である。 物理サーバの機能を示すブロック図である。 ＤＢ内のデータの一例を示す図である。 高頻度データ記憶部内のデータの一例を示す図である。 高頻度データのＤＢサーバへの展開例を示す図である。 高頻度データの展開処理の手順の一例を示すフローチャートである。 高頻度データか否かの第１の判定例を示す図である。 高頻度データか否かの第２の判定例を示す図である。 高頻度データか否かの第３の判定例を示す図である。 高頻度データか否かの第４の判定例を示す図である。 ＤＢサーバ台数調整処理の手順の一例を示すフローチャートである。 システムの運用の効率化の例を示す図である。 アクセス頻度管理テーブルによるアクセス頻度値の管理例を示す図である。

以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第１の実施の形態〕
図１は、第１の実施の形態に係るシステムの一例を示す図である。情報処理装置１０は、ネットワーク２を介して複数の端末装置１ａ，１ｂ，・・・に接続されている。また情報処理装置１０は、ストレージ装置３に接続されている。

ストレージ装置３にはＤＢ（データベース）３ａが格納されている。ＤＢ３ａには、複数のレコードが含まれる。各レコードには、例えばレコードＩＤ、複数のデータ項目それぞれのデータ、および該当レコード内のデータへのアクセス頻度値が含まれる。アクセス頻度値は、例えば所定期間内におけるレコードへの端末装置１ａ，１ｂ，・・・からのアクセス回数である。

情報処理装置１０は、端末装置１ａ，１ｂ，・・・からのＤＢ３ａ内のデータへのアクセス要求に応じて、ＤＢ３ａ内のデータにアクセスする。例えば情報処理装置１０は、仮想マシンを生成し、生成した仮想マシンを、ＤＢ３ａへのアクセス要求を処理するＤＢサーバとして動作させる。仮想マシンにより実現されたＤＢサーバが、端末装置１ａ，１ｂ，・・・からのアクセス要求に応じてＤＢ３ａ内のデータにアクセスする。

情報処理装置１０は、ＤＢサーバを管理するために記憶部１１と処理部１２とを有する。記憶部１１は、例えば情報処理装置１０が有するメモリである。処理部１２は、例えば情報処理装置１０が有するプロセッサまたは演算回路である。

記憶部１１には、実行されている仮想マシンごとに、その仮想マシンのメインメモリとして使用するメモリ領域１１ａ，１１ｂ，１１ｃが割り当てられている。
処理部１２は、適切なＤＢサーバ台数となるように、ＤＢサーバの台数を動的に調整する。例えば処理部１２は、アクセス頻度値が閾値以上のレコードのデータ量に基づいて、適切なＤＢサーバ台数を計算する。

以下、処理部１２によるＤＢサーバ管理方法について、図２を参照して具体的に説明する。
図２は、ＤＢサーバ管理方法の一例を示す図である。図２に示すＤＢサーバ管理方法は、例えば情報処理装置１０の処理部１２が、ＤＢサーバ管理方法の処理手順が記述されたデータベース管理プログラムを実行することにより実施することができる。

処理部１２は、複数のレコードが格納されたＤＢ３ａ内の複数のレコードそれぞれについて、所定期間内のアクセス回数を計数する。例えば処理部１２は、過去１時間、過去１日間のアクセス回数を計数する。

処理部１２は、ＤＢ３ａに格納された複数のレコードのうち、アクセス回数が閾値以上の高頻度アクセスレコードを抽出する。処理部１２は、例えば抽出した高頻度アクセスレコードの集合を、高頻度データ３ｂとしてストレージ装置３に格納する。高頻度データ３ｂは、ＤＢ３ａ以下のデータ量となる。例えば図２の例では、ＤＢ３ａのデータ量が１ＴＢであるが、高頻度データ３ｂのデータ量は１０ＧＢとなっている。

次に処理部１２は、ＤＢ３ａ内のデータへのアクセス要求の処理に利用する運用ＤＢサーバの適正台数を決定する。例えば処理部１２は、高頻度アクセスレコードのデータ量と、ＤＢサーバ１台あたりの高頻度アクセスレコードを格納するのに利用可能なメモリ容量（サーバメモリ容量）とに基づいて、運用ＤＢサーバの適正台数を決定する。例えば処理部１２は、整数の除法により、高頻度データ３ｂのデータ量をサーバメモリ容量で除算し、剰余を切り上げた値を、運用ＤＢサーバの適正台数とする。例えばサーバメモリ容量が、８ＧＢであるものとする。このとき高頻度データ３ｂのデータ量が１０ＧＢであれば、処理部１２は「１０」を「８」で除算する。すると商「１」、剰余「２」が得られる。この場合、剰余を切り上げた値「２」が、運用ＤＢサーバの適正台数となる。

適正台数を決定すると、処理部１２は、運用ＤＢサーバの台数が適正台数となるように、運用ＤＢサーバの台数を調整する。例えば処理部１２は、決定した台数分の仮想マシンを運用ＤＢサーバとして機能させる。具体的には処理部１２は、運用ＤＢサーバとして運用中の運用中仮想マシンの台数と、適正台数とを比較し、運用中仮想マシンの台数が適正台数に不足している場合、不足分の台数の仮想マシンを、運用ＤＢサーバとして新たに運用を開始させる。また処理部１２は、運用ＤＢサーバとして運用中の運用中仮想マシンの台数と、適正台数とを比較し、適正台数に対して運用中仮想マシンの台数に余剰がある場合、余剰分の台数の運用中仮想マシンの運用ＤＢサーバとしての運用を停止させる。

図２の例では、処理部１２は、仮想マシン１３，１４のＤＢサーバを活性状態とし、仮想マシン１５のＤＢを非活性状態とすることで、適正台数のＤＢサーバを運用ＤＢサーバとして稼働させている。なお、ＤＢサーバの活性状態とは、ＤＢサーバによるデータへのアクセス要求を処理可能な状態である。ＤＢサーバの非活性状態とは、ＤＢサーバによるデータへのアクセス要求を処理できない状態である。

ＤＢサーバの台数の調整が完了すると、処理部１２は、台数調整後の運用ＤＢサーバ（活性状態のＤＢサーバ）のメモリに、高頻度データ３ｂを展開する。すなわち処理部１２は、高頻度データ３ｂに含まれる高頻度アクセスレコードを、ＤＢサーバのメモリに分散格納する。例えば処理部１２は、高頻度データ３ｂを運用ＤＢサーバ台数分に分割し、分割したデータを活性状態のＤＢサーバのメモリに格納する。図２の例では、高頻度データ３ｂを５ＧＢずつの２つのデータに分割し、分割したデータを２台の仮想マシン１３，１４それぞれのメモリに格納する。

端末装置１ａ，１ｂ，・・・は、ＤＢ３ａ内のデータにアクセスする場合、活性状態のＤＢサーバとして機能している仮想マシン１３，１４に対してアクセス要求を送信する。仮想マシン１３，１４は、アクセス要求によるアクセス対象のデータが、自身のメモリ内にあれば、メモリ内のデータにアクセスし、端末装置１ａ，１ｂ，・・・に応答する。例えばアクセス要求がデータのリード要求であれば、仮想マシン１３，１４は、自身のメモリからデータを読み出し、アクセス要求を送信した端末装置にデータを送信する。また、アクセス要求がデータのライト要求であれば、仮想マシン１３，１４は、自身のメモリ内のデータを更新し、アクセス要求を送信した端末装置に処理結果を送信する。仮想マシン１３，１４は、メモリ内のデータを更新した場合、所定のタイミングで更新後のデータをストレージ装置３内のＤＢ３ａに反映する。

このようにして、情報処理装置１０は、高い応答性能を維持しながら、ＤＢサーバの運用台数を動的に適正化することができる。すなわち情報処理装置１０は、アクセス頻度が閾値以上の高頻度アクセスレコードを仮想マシンのメモリに格納しておくことで、データへのアクセス要求に対応する応答性能を向上させている。しかも情報処理装置１０は、高頻度データ３ｂのデータ量に基づいて、最小限の台数のＤＢサーバのみが運用されるように、運用ＤＢサーバの台数を動的に調整している。これにより無駄に多くの仮想マシンをＤＢサーバとして運用することがなくなり、情報処理装置１０内のハードウェア資源を有効活用することができる。

ハードウェア資源が有効活用されることにより、データ量の増加に伴うシステムの規模の拡大を抑止することができ、システム価格の上昇も抑止することができる。すなわち、より安価に、ユーザの要求する応答性能を満たすシステムの構築が可能となる。

しかも高頻度アクセスレコードの集合を高頻度データ３ｂとして纏め、高頻度データ３ｂのデータ量に基づいて、運用ＤＢサーバの台数を決定するため、適正な台数を正確に求めることができる。すなわち、ＤＢ３ａ内の各レコードには複数のデータが含まれており、レコードのデータサイズが不均一な場合がある。そのような場合に、例えば「高頻度アクセスレコードの数×所定のデータサイズ」で得た値を高頻度データ３ｂのデータ量としてしまうと、算出されるデータ量と、実際の高頻度アクセスレコードの総データ量とに大きな差が生じる可能性がある。高頻度データ３ｂのデータ量が不正確であれば、高頻度データ３ｂのデータ量に基づいて決定する運用ＤＢサーバの台数の正確性も低下する。それに対して、高頻度アクセスレコードの集合を高頻度データ３ｂに纏めることで、高頻度アクセスレコードの実際のデータサイズの総量を、高頻度データ３ｂのデータ量として正確に求めることができる。その結果、運用ＤＢサーバの適正な台数が決定できる。

〔第２の実施の形態〕
次に第２の実施の形態について説明する。第２の実施の形態は、ビッグデータへのアクセスのストレスのない応答性能を実現し、かつコンピュータ資源の有効活用により、効率的に運用可能なシステムである。

図３は、システム構成の一例を示す図である。ネットワーク２０を介して、物理サーバ１００と複数の端末装置３１，３２，・・・とが接続されている。物理サーバ１００には、ストレージ装置２００が接続されている。物理サーバ１００は、仮想マシンを用いて端末装置３１，３２，・・・に対するサービスを提供する。例えば物理サーバ１００で実行される仮想マシンは、Ｗｅｂサーバ、アプリケーションサーバ、またはＤＢサーバとして機能する。ＤＢサーバとして機能する仮想マシンは、ストレージ装置２００内のＤＢを管理する。例えばＤＢサーバは、端末装置３１，３２，・・・からのデータへのアクセス要求に応じて、ストレージ装置２００内へのデータの書き込み、またはストレージ装置２００からのデータの読み出しを行う。

図４は、物理サーバのハードウェアの一例を示す図である。物理サーバ１００は、プロセッサ１０１によって装置全体が制御されている。プロセッサ１０１には、バス１０９を介してメモリ１０２と複数の周辺機器が接続されている。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、例えばＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、またはＤＳＰ（Digital Signal Processor）である。プロセッサ１０１がプログラムを実行することで実現する機能の少なくとも一部を、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）などの電子回路で実現してもよい。

メモリ１０２は、物理サーバ１００の主記憶装置として使用される。メモリ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ１０２には、プロセッサ１０１による処理に利用する各種データが格納される。メモリ１０２としては、例えばＲＡＭ（Random Access Memory）などの揮発性の半導体記憶装置が使用される。

バス１０９に接続されている周辺機器としては、ストレージ装置１０３、グラフィック処理装置１０４、入力インタフェース１０５、光学ドライブ装置１０６、機器接続インタフェース１０７およびネットワークインタフェース１０８がある。

ストレージ装置１０３は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置１０３は、コンピュータの補助記憶装置として使用される。ストレージ装置１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置１０３としては、例えばＨＤＤ（Hard Disk Drive）やＳＳＤを使用することができる。

グラフィック処理装置１０４には、モニタ２１が接続されている。グラフィック処理装置１０４は、プロセッサ１０１からの命令に従って、画像をモニタ２１の画面に表示させる。モニタ２１としては、有機ＥＬ（Electro Luminescence）を用いた表示装置や液晶表示装置などがある。

入力インタフェース１０５には、キーボード２２とマウス２３とが接続されている。入力インタフェース１０５は、キーボード２２やマウス２３から送られてくる信号をプロセッサ１０１に送信する。なお、マウス２３は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。

光学ドライブ装置１０６は、レーザ光などを利用して、光ディスク２４に記録されたデータの読み取りを行う。光ディスク２４は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク２４には、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。

機器接続インタフェース１０７は、物理サーバ１００に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース１０７には、メモリ装置２５やメモリリーダライタ２６を接続することができる。メモリ装置２５は、機器接続インタフェース１０７との通信機能を搭載した記録媒体である。メモリリーダライタ２６は、メモリカード２７へのデータの書き込み、またはメモリカード２７からのデータの読み出しを行う装置である。メモリカード２７は、カード型の記録媒体である。

ネットワークインタフェース１０８は、ネットワーク２０に接続されている。ネットワークインタフェース１０８は、ネットワーク２０を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。

物理サーバ１００は、以上のようなハードウェア構成によって、第２の実施の形態の処理機能を実現することができる。図３に示した端末装置３１，３２，・・・も、物理サーバ１００と同様のハードウェアにより実現することができる。また、第１の実施の形態に示した情報処理装置１０（図１参照）も、図４に示した物理サーバ１００と同様のハードウェアにより実現することができる。

物理サーバ１００は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第２の実施の形態の処理機能を実現する。物理サーバ１００に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、物理サーバ１００に実行させるプログラムをストレージ装置１０３に格納しておくことができる。プロセッサ１０１は、ストレージ装置１０３内のプログラムの少なくとも一部をメモリ１０２にロードし、プログラムを実行する。また物理サーバ１００に実行させるプログラムを、光ディスク２４、メモリ装置２５、メモリカード２７などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ１０１からの制御により、ストレージ装置１０３にインストールされた後、実行可能となる。またプロセッサ１０１が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。

第２の実施の形態では、物理サーバ１００は、例えばハイパーバイザにより、複数の仮想マシンを立ち上げる。物理サーバ１００は、複数の仮想マシンの一部をＤＢサーバとして使用する。そして、ＤＢサーバがストレージ装置２００に格納したデータへのアクセスを行う。

物理サーバ１００では、ＤＢサーバによるストレージ装置２００内のデータアクセス頻度を管理し、データアクセス頻度に応じてＤＢサーバ数を動的に変更する。データアクセス頻度に応じたＤＢサーバ数の動的変更方法について、以下に詳細に説明する。

図５は、物理サーバの機能を示すブロック図である。物理サーバ１００は、データコントローラ１１０、リソースコントローラ１２０、仮想マシン１３１，１３２，・・・，１４１，１４２，・・・，１５１，１５２，・・・を有している。

仮想マシン１３１，１３２，・・・は、ストレージ装置２００内のデータを管理するＤＢサーバとして動作している。動作中のＤＢサーバを、活性状態のＤＢサーバと呼ぶこともある。仮想マシン１４１，１４２，・・・は、ＤＢサーバとしての機能を備えているが、現在は動作していない。動作していないＤＢサーバを、非活性状態のＤＢサーバと呼ぶこともある。仮想マシン１５１，１５２，・・・は、ＤＢサーバ以外の用途で使用されている。

例えば仮想マシン１５１，１５２，・・・は、Ｗｅｂサーバまたはアプリケーションサーバとして動作している。仮想マシン１５１がＷｅｂサーバの場合、仮想マシン１５１は、端末装置３１，３２，・・・からのサービス提供要求を受信し、サービス提供要求に応じた処理を行う。仮想マシン１５１は、サービス提供要求に応じた処理においてＤＢ２１０内のデータへのアクセスが発生した場合、活性状態のＤＢサーバである仮想マシン１３１，１３２，・・・のいずれかにアクセス要求を送信する。

なお仮想マシン１５１，１５２，・・・は、データコントローラ１１０から、アクセス要求の送信先となる仮想マシンの判断基準を取得することができる。例えば活性ＤＢサーバとして機能する仮想マシン１３１，１３２，・・・が高頻度データの一部をオンメモリで記憶している場合がある。この場合、データコントローラ１１０は、どのレコードがどの仮想マシンに記憶されているのかを示す情報を、ＤＢサーバへのアクセス要求を出力する仮想マシン１５１，１５２，・・・に通知する。仮想マシン１５１，１５２，・・・は、データコントローラ１１０から取得した情報に基づいて、アクセス対象のデータをオンメモリで記憶している仮想マシンを判断し、該当する仮想マシンにアクセス要求を送信する。

仮想マシン１３１，１３２，・・・は、オンメモリとして記憶しているレコード内のデータへのアクセス要求があった場合、メインメモリ内のデータに対してアクセスを行い、アクセス要求して応答する。仮想マシン１３１，１３２，・・・は、オンメモリとして記憶していないレコード内のデータへのアクセス要求があった場合、ＤＢ２１０内のデータに対してアクセスを行い、アクセス要求して応答する。

データコントローラ１１０は、ストレージ装置２００内のデータを管理する。例えばデータコントローラ１１０は、管理対象の全データを、ストレージ装置２００内のＤＢ２１０に格納する。またデータコントローラ１１０は、ＤＢ２１０内のデータに対するアクセスを監視し、ＤＢ２１０内のレコードごとのアクセス頻度を計算する。そしてデータコントローラ１１０は、ＤＢ２１０内のデータのうち、アクセス頻度が閾値以上のデータ（高頻度データ）を、高頻度データ記憶部２２０にコピーする。データコントローラ１１０は、高頻度データ記憶部２２０内のデータを、活性状態のＤＢサーバとして使用されている仮想マシン１３１，１３２，・・・のメインメモリに展開する。仮想マシン１３１，１３２，・・・のメインメモリは、物理サーバ１００のメモリ１０２の記憶領域の一部である。仮想マシン１３１，１３２，・・・はプロセッサ１０１によって実行されている。仮想マシン１３１，１３２，・・・それぞれを動作させるとき、プロセッサ１０１は、仮想マシン１３１，１３２，・・・内のメインメモリに展開したデータについては、外部インタフェースを介さずに、メモリ１０２内のアドレスの指定により直接アクセスできる。

リソースコントローラ１２０は、高頻度データのサイズに基づいて、活性状態のＤＢサーバとして使用する仮想マシン数を制御する。例えばリソースコントローラ１２０は、高頻度データのサイズと、仮想マシンの１台あたりのデータ展開可能なメモリサイズとを比較して、適切なＤＢサーバの台数を決定する。具体的には、リソースコントローラ１２０は、高頻度データのサイズを仮想マシンの１台あたりのデータ展開可能なメモリサイズで除算する。リソースコントローラ１２０は、除算の剰余を切り上げた値を、適切なＤＢサーバの台数とする。

リソースコントローラ１２０は、適切なＤＢサーバの台数に対して、活性状態のＤＢサーバの台数に過不足があれば、ＤＢサーバの活性化または非活性化を行う。例えばリソースコントローラ１２０は、活性状態のＤＢサーバの台数が不足していれば、非活性状態のＤＢサーバの少なくとも一部を活性化させ、活性状態とする。またリソースコントローラ１２０は、活性状態のＤＢサーバの台数に余剰があれば、活性状態のＤＢサーバの一部を非活性化させ、非活性状態とする。なおリソースコントローラ１２０は、高頻度データのサイズが「０」の場合であっても、少なくとも１台はＤＢサーバを活性状態とする。

なお、図５に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
図６は、ＤＢ内のデータの一例を示す図である。例えばＤＢ２１０には複数のデータテーブル２１１，２１２，・・・が格納されている。データテーブル２１１のテーブル名は「Ｔａｂｌｅ＃１」であり、データテーブル２１２のテーブル名は「Ｔａｂｌｅ＃２」である。

複数のデータテーブル２１１，２１２，・・・それぞれには、複数のレコードが登録されている。各レコードには、レコードＩＤ、データ項目ごとのデータ、およびカウント項目ごとのアクセス頻度値が含まれる。レコードＩＤは、データテーブル内でのレコードの識別番号である。データ項目には、項目名（項目Ａ、項目Ｂなど）が付与されており、項目名に対応するデータが各レコードに設定されている。

カウント項目は、アクセス回数のカウント期間ごとに設けられている。図６の例では、カウント項目として、過去１時間のアクセス回数（アクセス回数／１時間）、過去１日のアクセス回数（アクセス回数／１日）、過去１年のアクセス回数（アクセス回数／１年）、過去のアクセスの総数（アクセス回数／通年）がある。各カウント項目には、対応するカウント期間内でのレコード内のデータへのアクセス回数が設定される。計数されたアクセス回数が、カウント期間内におけるアクセス頻度値である。

なおアクセス回数は、データコントローラ１１０によってカウントされる。例えばデータコントローラ１１０は、活性状態のＤＢサーバとして機能する仮想マシン１３１，１３２，・・・に入力されたアクセス要求を監視し、所定のタイミングで、アクセス対象のデータを含むレコードのアクセス回数を更新する。アクセス回数の更新タイミングは、アクセス要求の受信時、高頻度データのＤＢサーバへの展開処理の実行時などである。例えばデータコントローラ１１０は、アクセス要求のイベントのログを記録しておき、ログに基づいて、カウント項目ごとに、アクセス対象のレコード内のデータに対する過去のカウント期間内でのアクセス回数を計数する。そしてデータコントローラ１１０は、カウント項目に対応するカウント期間内で計数した値を、カウント項目のアクセス頻度値として設定する。

図７は、高頻度データ記憶部内のデータの一例を示す図である。例えば高頻度データ記憶部２２０には、複数のデータテーブル２２１，２２２，・・・が格納されている。データテーブル２２１のテーブル名は「Ｔａｂｌｅ＃１」であり、データテーブル２２２のテーブル名は「Ｔａｂｌｅ＃２」である。

高頻度データ記憶部２２０内の複数のデータテーブル２２１，２２２，・・・それぞれは、ＤＢ２１０内の同じテーブル名のデータテーブル２１１，２１２，・・・に対応する。そして複数のデータテーブル２２１，２２２，・・・には、対応するＤＢ２１０内のデータテーブル２１１，２１２，・・・に含まれるレコ−ドのうち、データのアクセス頻度が高頻度であるレコードが含まれている。各レコードには、レコードＩＤとデータ項目ごとのデータとが含まれる。レコードＩＤは、ＤＢ２１０内の対応するデータテーブル内でのレコードの識別番号である。データ項目には、項目名（項目Ａ、項目Ｂなど）が付与されており、項目名に対応するデータが各レコードに設定されている。

高頻度データ記憶部２２０に格納されたデータは、例えばレコード単位で活性状態のＤＢサーバ内のメモリに分散して格納される。
図８は、高頻度データのＤＢサーバへの展開例を示す図である。活性状態のＤＢサーバとして機能している仮想マシン１３１，１３２，・・・それぞれは、メインメモリとして使用するメモリ１３１ａ，１３２ａ，・・・を有している。メモリ１３１ａ，１３２ａ，・・・には、高頻度データ記憶部２２０に格納されているレコードのコピーが格納されている。例えばメモリ１３１ａ，１３２ａ，・・・には、レコードの取得元のデータテーブルのテーブル名に対応付けて、高頻度データ記憶部２２０内でのレコードの内容（レコードＩＤと項目名ごとのデータ）が格納されている。

次にデータコントローラ１１０が実行する高頻度データのＤＢサーバの内部メモリへの展開処理について説明する。なお、高頻度データの展開処理は、例えば所定周期で繰り返し実行される。

図９は、高頻度データの展開処理の手順の一例を示すフローチャートである。以下、図９に示す処理をステップ番号に沿って説明する。
［ステップＳ１１］データコントローラ１１０は、ＤＢ２１０から、未選択のレコードを１つ選択する。

［ステップＳ１２］データコントローラ１１０は、選択したレコードのカウント項目ごとのアクセス回数を取得する。
［ステップＳ１３］データコントローラ１１０は、取得したアクセス回数に基づいて、選択したレコード内のデータが、高頻度にアクセスされる高頻度データか否かを判断する。例えばデータコントローラ１１０には、１以上のカウント項目について、高頻度データか否かの判定基準として、アクセス回数の閾値が設定されている。データコントローラ１１０は、閾値が設定されているカウント項目ごとに、そのカウント項目のアクセス回数と閾値とを比較する。データコントローラ１１０は、少なくとも１つのカウント項目において、アクセス回数が閾値以上となっている場合、選択したレコード内のデータが高頻度データであると判定する。

例えば図６に示すようなデータがＤＢ２１０に格納されているものとする。図６の例では、レコードＩＤ「１」のレコードの１時間あたりのアクセス回数は「１４３」、１日あたりのアクセス回数は「３，４３２」、１年あたりのアクセス回数は「１，２５２，６８０」である。レコードＩＤ「２」のレコードの１時間あたりのアクセス回数は「２」、１日あたりのアクセス回数は「４８」、１年あたりのアクセス回数は「１７，５２０」である。レコードＩＤ「３」のレコードの１時間あたりのアクセス回数は「４６」、１日あたりのアクセス回数は「６，３００」、１年あたりのアクセス回数は「２，２９９，５００」である。

このとき高頻度データが「１時間あたり１００アクセス以上」と定義されている場合、データコントローラ１１０は、レコードＩＤ「１」のレコードは高頻度データであり、レコードＩＤ「２」、「３」のレコードは高頻度データではないと判定する。高頻度データが「１日あたり５，０００アクセス以上」と定義されている場合、データコントローラ１１０は、レコードＩＤ「３」のレコードが高頻度データであり、レコードＩＤ「１」、「２」のレコードは高頻度データではないと判定する。高頻度データが「１年あたり１，０００，０００アクセス以上」と定義されている場合、データコントローラ１１０は、レコードＩＤ「１」、「３」のレコードが高頻度データであり、レコードＩＤ「２」のレコードは高頻度データではないと判定する。

データコントローラ１１０は、選択したレコード内のデータが高頻度データである場合、処理をステップＳ１４に進める。またデータコントローラ１１０は、選択したレコード内のデータが高頻度データではない場合、処理をステップＳ１５に進める。

［ステップＳ１４］データコントローラ１１０は、選択したレコードを高頻度データ記憶部２２０にコピーする。
［ステップＳ１５］データコントローラ１１０は、ＤＢ２１０内のすべてのレコードを選択したか否かを判断する。データコントローラ１１０は、未選択のレコードがある場合、処理をステップＳ１１に進める。またデータコントローラ１１０は、すべてのレコードが選択済みであれば、処理をステップＳ１６に進める。

［ステップＳ１６］データコントローラ１１０は、高頻度データ記憶部２２０に格納されている高頻度データのサイズを示す情報を出力する。出力された情報は、リソースコントローラ１２０に送信される。リソースコントローラ１２０は、高頻度データのサイズに基づいてＤＢサーバ台数の調整処理を行う。

［ステップＳ１７］データコントローラ１１０は、リソースコントローラ１２０によるＤＢサーバ台数の調整処理が完了したか否かを判断する。例えばデータコントローラ１１０は、リソースコントローラ１２０からＤＢサーバ台数調整完了の通知を受信した場合、ＤＢサーバ台数の調整処理が完了したと判断する。データコントローラ１１０は、ＤＢサーバ台数の調整処理が完了した場合、処理をステップＳ１８に進める。またデータコントローラ１１０は、ＤＢサーバ台数の調整処理が完了していなければ、ステップＳ１７の処理を繰り返す。

［ステップＳ１８］データコントローラ１１０は、高頻度データをＤＢサーバのメモリに展開する。例えばデータコントローラ１１０は、高頻度データ記憶部２２０内のレコードを、ＤＢサーバの台数分のグループに均等に分ける。各グループに含まれるデータのサイズは、高頻度データのサイズをＤＢサーバの台数で除算した値となる。データコントローラ１１０は、各グループそれぞれをＤＢサーバに割り当て、グループに含まれるレコードを割り当てたＤＢサーバのメモリに転送する。

このようにしてレコードごとに、アクセス頻度値（所定期間内のアクセス回数）に基づいて高頻度データか否かを判断し、高頻度データがＤＢサーバのメモリに展開される。なおアクセス頻度値は時間経過に伴って変化する。そのため１つのレコードについて、ある時点では高頻度データであると判定された場合であっても、別の時点では高頻度データではないと判定される場合がある。以下、図１０〜図１３を参照し、高頻度データか否かの判定の時間変化について具体的に説明する。

図１０は、高頻度データか否かの第１の判定例を示す図である。図１０には、「２０１８年８月２７日９時００分」におけるレコードＩＤ「１」のレコードを示している。この時点ではレコードＩＤ「１」のレコードの１時間あたりのアクセス回数は「０」、１日あたりのアクセス回数は「０」である。

図１０の例では、高頻度データの条件が「１時間あたり１００アクセス以上」の場合、レコードＩＤ「１」のレコードは高頻度データに該当しない。また高頻度データの条件が「１日あたり５，０００アクセス以上」の場合も、レコードＩＤ「１」のレコードは高頻度データに該当しない。

図１１は、高頻度データか否かの第２の判定例を示す図である。図１１には、「２０１８年８月２７日１０時００分」におけるレコードＩＤ「１」のレコードを示している。この時点ではレコードＩＤ「１」のレコードの１時間あたりのアクセス回数は「１４２」、１日あたりのアクセス回数は「１４２」である。

図１１の例では、高頻度データの条件が「１時間あたり１００アクセス以上」の場合、レコードＩＤ「１」のレコードは高頻度データに該当する。また高頻度データの条件が「１日あたり５，０００アクセス以上」の場合、レコードＩＤ「１」のレコードは高頻度データに該当しない。

図１２は、高頻度データか否かの第３の判定例を示す図である。図１２には、「２０１８年８月２７日１１時００分」におけるレコードＩＤ「１」のレコードを示している。この時点ではレコードＩＤ「１」のレコードの１時間あたりのアクセス回数は「４，８９７」、１日あたりのアクセス回数は「５，０３９」である。

図１２の例では、高頻度データの条件が「１時間あたり１００アクセス以上」の場合、レコードＩＤ「１」のレコードは高頻度データに該当する。また高頻度データの条件が「１日あたり５，０００アクセス以上」の場合にも、レコードＩＤ「１」のレコードは高頻度データに該当する。

図１３は、高頻度データか否かの第４の判定例を示す図である。図１３には、「２０１８年８月２７日１２時００分」におけるレコードＩＤ「１」のレコードを示している。この時点ではレコードＩＤ「１」のレコードの１時間あたりのアクセス回数は「９４」、１日あたりのアクセス回数は「５，１３３」である。

図１３の例では、高頻度データの条件が「１時間あたり１００アクセス以上」の場合、レコードＩＤ「１」のレコードは高頻度データに該当しない。また高頻度データの条件が「１日あたり５，０００アクセス以上」の場合、レコードＩＤ「１」のレコードは高頻度データに該当する。

図１０〜図１３に示したように、時間の経過に伴って、高頻度データに該当しないレコードが高頻度データになったり、逆に高頻度データのレコードが高頻度データに該当しなくなったりする。このような動的変化が、ＤＢ２１０内のすべてのレコードについて生じる。その結果、高頻度データのサイズは、時間経過に伴って動的に変化する。そして、動的に変化する高頻度データのサイズに応じてＤＢサーバの台数が調整され、調整後のＤＢサーバのメモリに、高頻度データが展開される。

次に、高頻度データのサイズを示す情報を取得したリソースコントローラ１２０によるＤＢサーバ台数の調整処理について詳細に説明する。
図１４は、ＤＢサーバ台数調整処理の手順の一例を示すフローチャートである。以下、図１４に示す処理をステップ番号に沿って説明する。

［ステップＳ２１］リソースコントローラ１２０は、データコントローラ１１０から高頻度データのサイズを示す情報を取得する。リソースコントローラ１２０は、取得した情報から高頻度データのサイズを認識する。

［ステップＳ２２］リソースコントローラ１２０は、メモリ展開可能な最大データサイズを算出する。例えばリソースコントローラ１２０は、ＤＢサーバ１台あたりの、データ展開に使用可能なメモリ容量に、ＤＢサーバの台数を乗算する。リソースコントローラ１２０は、その乗算結果を、メモリ展開可能な最大データサイズとする。

［ステップＳ２３］リソースコントローラ１２０は、ＤＢサーバが不足するか否かを判断する。例えばリソースコントローラ１２０は、ステップＳ２２で求めた最大データサイズと高頻度データのサイズとを比較する。リソースコントローラ１２０は、最大データサイズが高頻度データのサイズ未満の場合、ＤＢサーバ不足であると判断する。リソースコントローラ１２０は、ＤＢサーバ不足の場合、処理をステップＳ２４に進める。またリソースコントローラ１２０は、ＤＢサーバ不足ではない場合、処理をステップＳ２５に進める。

［ステップＳ２４］リソースコントローラ１２０は、非活性状態のＤＢサーバの活性化処理を行う。例えばリソースコントローラ１２０は、まずＤＢサーバの不足数を計算する。具体的にはリソースコントローラ１２０は、高頻度データのサイズから最大データサイズを減算した値（不足容量）を、ＤＢサーバの１台あたりのデータ展開に使用可能なメモリ容量で除算する。リソースコントローラ１２０は、除算結果の剰余を切り上げた値を、ＤＢサーバの不足数とする。リソースコントローラ１２０は、非活性状態のＤＢサーバの中から不足数分のＤＢサーバを選択し、選択したＤＢサーバを活性状態に変更する。リソースコントローラ１２０は、その後、処理をステップＳ２７に進める。

［ステップＳ２５］リソースコントローラ１２０は、ＤＢサーバに余剰があるか否かを判断する。例えばリソースコントローラ１２０は、最大データサイズから高頻度データのサイズを減算する。リソースコントローラ１２０は、減算で得られた値（余剰容量）が、ＤＢサーバの１台あたりのデータ展開に使用可能なメモリ容量以上であれば、ＤＢサーバの余剰があると判断する。リソースコントローラ１２０は、ＤＢサーバの余剰がある場合、処理をステップＳ２６に進める。またリソースコントローラ１２０は、ＤＢサーバの余剰がない場合、処理をステップＳ２７に進める。

［ステップＳ２６］リソースコントローラ１２０は、ＤＢサーバの非活性化処理を行う。例えばリソースコントローラ１２０は、まずＤＢサーバの余剰数を計算する。具体的にはリソースコントローラ１２０は、余剰容量を、ＤＢサーバの１台あたりのデータ展開に使用可能なメモリ容量で除算する。リソースコントローラ１２０は、除算結果の剰余を切り捨てた値を、ＤＢサーバの余剰数とする。リソースコントローラ１２０は、活性状態のＤＢサーバの中から余剰数分のＤＢサーバを選択し、選択したＤＢサーバを非活性状態に変更する。

［ステップＳ２７］リソースコントローラ１２０は、データコントローラ１１０に、ＤＢサーバ台数調整処理の完了通知を送信する。
このように、活性状態のＤＢサーバが不足していれば、リソースコントローラ１２０は、非活性状態のＤＢサーバを活性化することで、活性状態のＤＢサーバ数を増加させる。また活性状態のＤＢサーバに余剰があれば、リソースコントローラ１２０は、活性状態のＤＢサーバを非活性化することで、活性状態のＤＢサーバ数を減少させる。これにより、データへのアクセス要求に対する良好な応答性能を維持しながら、システム全体の運用を効率化することができる。

図１５は、システムの運用の効率化の例を示す図である。図１５の例は、高頻度データのサイズが減少した場合におけるコンピュータ資源の有効利用による運用の効率化を図るものである。

物理サーバ１００は、仮想マシン１３１〜１３４を用いて、内部で複数のコンピュータシステムを構築することができる。初期状態では、仮想マシン１３１〜１３３は第１システム１００ａに含まれ、仮想マシン１３４は第２システム１００ｂに含まれるものとする。

第１システム１００ａでは、瞬間的な高頻度データの最大サイズになったとき、３台の仮想マシン１３１〜１３３で実行得されるＤＢサーバが活性状態となる。高頻度データは、仮想マシン１３１〜１３３それぞれにおける、メモリ内の高頻度データの格納可能領域に、ほとんど空き領域なしで格納されている。なお仮想マシン１３１〜１３３のメモリには、高頻度データ以外のプログラムやデータも格納されており、高頻度データの格納可能領域は、仮想マシン１３１〜１３３それぞれのメモリの一部の領域である。

その後、第１システムの運用状況が平常状態となり、高頻度データのサイズが減少したものとする。このときＤＢサーバ台数の調整処理を実施しない場合の仮想マシン１３１〜１３３の状態を、比較例として図１５の右側上段に示し、ＤＢサーバ台数の調整処理を実施する場合の仮想マシン１３１〜１３３の状態を、図１５の右側下段に示す。

ＤＢサーバ台数の調整を行わない場合、３台のＤＢサーバのメモリには大量の空き領域が発生する。ＤＢサーバ台数の調整を行った場合、図１５の例では２台のＤＢサーバが非活性状態に変更されている。高頻度データは、活性状態の１台のＤＢサーバのメモリに展開される。これにより第１システム１００ａの運用において、ＤＢサーバとして使用する仮想マシン台数が３台から１台に減少する。このように平常状態では、活性状態のＤＢサーバは１台で十分であり、第１システム１００ａにおけるＤＢサーバの維持費は、１台分で済む。

ＤＢサーバが非活性状態となった仮想マシン１３２，１３３の一部は、第１システム１００ａから除外し、第２システム１００ｂで利用することもできる。図１５の例では、仮想マシン１３２が第２システム１００ｂに移動している。第２システム１００ｂでは、２台の仮想マシン１３２，１３４によって２台のＤＢサーバを運用することで、応答性能などの性能向上を図ることができる。第１システム１００ａにおいて非活性状態となったＤＢサーバを第２システム１００ｂで利用することで資源の有効活用が可能となり、システム全体としての運用効率が向上する。

このように高頻度データの増減に併せて、動的にＤＢサーバ台数を調整することで、応答性能などのシステムの性能を維持しながら、資源の有効活用が可能となる。その結果、ビッグデータへのアクセス要求に対する良好な応答性能を有するシステムを安価に構築することが可能となる。

〔その他の実施の形態〕
第２の実施の形態では、仮想マシンによりＤＢサーバを実行しているが、仮想マシンに代えて物理マシンを用いてもよい。また第２の実施の形態では１台の物理サーバ１００で複数の仮想マシンを実行しているが、複数の物理サーバで、１システムとして機能する複数の仮想マシンを実行することもできる。

また第２の実施の形態では、ＤＢ２１０内のレコードにカウント項目を設け、アクセス頻度値を設定しているが、アクセス頻度値を別テーブル（アクセス頻度管理テーブル）で管理することもできる。

図１６は、アクセス頻度管理テーブルによるアクセス頻度値の管理例を示す図である。図１６の例では、ＤＢ２１０ａに複数のデータテーブル２１１ａ，２１２ａ，・・・とアクセス頻度管理テーブル２１３とが格納されている。データテーブル２１１ａ，２１２ａ，・・・には、レコードＩＤとデータ項目ごとのデータとを含むレコードが格納されている。アクセス頻度管理テーブル２１３には、複数のデータテーブル２１１ａ，２１２ａ，・・・内のレコードごとに、テーブル名、レコードＩＤ、およびカウント項目ごとのアクセス頻度値が格納されている。アクセス頻度管理テーブル２１３内のアクセス頻度値は、テーブル名とレコードＩＤとの組により、データテーブル２１１ａ，２１２ａ，・・・内のレコードと関連付けられている。

以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の２以上の構成（特徴）を組み合わせたものであってもよい。

１ａ，１ｂ，・・・ 端末装置
２ ネットワーク
３ ストレージ装置
３ａ ＤＢ
３ｂ 高頻度データ
１０ 情報処理装置
１１ 記憶部
１１ａ〜１１ｃ メモリ領域
１２ 処理部
１３〜１５ 仮想マシン

Claims (6)

1. コンピュータに、
   複数のレコードが格納されたデータベース内の前記複数のレコードそれぞれについて、所定期間内のアクセス回数を計数し、
   前記複数のレコードのうち、アクセス回数が閾値以上の高頻度アクセスレコードを抽出し、
   前記高頻度アクセスレコードのデータ量と、データベースサーバ１台あたりの前記高頻度アクセスレコードを格納するのに利用可能なメモリ容量とに基づいて、前記データベース内のデータへのアクセス要求の処理に利用する運用データベースサーバの適正台数を決定し、
   前記適正台数となるように、前記運用データベースサーバの台数を調整し、
   台数調整後の前記運用データベースサーバのメモリに前記高頻度アクセスレコードを格納する、
   処理を実行させるデータベースサーバ管理プログラム。
2. 前記運用データベースサーバの台数の調整では、前記適正台数分の仮想マシンを前記運用データベースサーバとして機能させる、
   処理実行させる請求項１記載のデータベースサーバ管理プログラム。
3. 前記運用データベースサーバの台数の調整では、前記運用データベースサーバとして運用中の運用中仮想マシンの台数と、前記適正台数とを比較し、前記運用中仮想マシンの台数が前記適正台数に不足している場合、不足分の台数の仮想マシンを、前記運用データベースサーバとして新たに機能させる、
   請求項２記載のデータベースサーバ管理プログラム。
4. 前記運用データベースサーバの台数の調整では、前記適正台数に対して前記運用中仮想マシンの台数に余剰がある場合、余剰分の台数の前記運用中仮想マシンに対し、前記運用データベースサーバとしての運用を停止させる、
   請求項３記載のデータベースサーバ管理プログラム。
5. コンピュータが、
   複数のレコードが格納されたデータベース内の前記複数のレコードそれぞれについて、所定期間内のアクセス回数を計数し、
   前記複数のレコードのうち、アクセス回数が閾値以上の高頻度アクセスレコードを抽出し、
   前記高頻度アクセスレコードのデータ量と、データベースサーバ１台あたりの前記高頻度アクセスレコードを格納するのに利用可能なメモリ容量とに基づいて、前記データベース内のデータへのアクセス要求の処理に利用する運用データベースサーバの適正台数を決定し、
   前記適正台数となるように、前記運用データベースサーバの台数を調整し、
   台数調整後の前記運用データベースサーバのメモリに前記高頻度アクセスレコードを格納する、
   データベースサーバ管理方法。
6. 複数のレコードが格納されたデータベースを記憶するストレージ装置と、
   前記データベース内の前記複数のレコードそれぞれについて、所定期間内のアクセス回数を計数し、前記複数のレコードのうち、アクセス回数が閾値以上の高頻度アクセスレコードを抽出し、前記高頻度アクセスレコードのデータ量と、データベースサーバ１台あたりの前記高頻度アクセスレコードを格納するのに利用可能なメモリ容量とに基づいて、前記データベース内のデータへのアクセス要求の処理に利用する運用データベースサーバの適正台数を決定し、前記適正台数となるように、前記運用データベースサーバの台数を調整し、台数調整後の前記運用データベースサーバのメモリに前記高頻度アクセスレコードを格納する情報処理装置と、
   を有するデータベースシステム。
   

Images