(57)【要約】【課題】データ再配置に伴うストレージ装置への書き戻し頻度を低減させる技術を提供する。【解決手段】コンピュータがデータに対するアクセス要求の履歴に基づいて、データをグループ化するグループ化情報を生成し、データの追加、更新、または削除の要求を示す変更要求または該データの属するグループの変更に応じて、メモリ上に存在するグループに含まれるデータのうち、該変更要求または該変更処理により変更されたデータをバッファに蓄積し、書き込みについての設定条件に基づいて、前記グループ化情報に含まれるグループ毎に、前記バッファに蓄積された前記データを前記格納装置に書き込むか否かを判定することにより、上記課題の解決を図る。【選択図】図１
2017162194.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータに、
データに対するアクセス要求の履歴に基づいて、該データをグループ化するグループ化情報を生成し、
データの追加、更新、及び削除を含むデータの変更を要求する変更要求または該データの属するグループの変更処理に応じて、メモリ上に存在するグループに含まれるデータのうち、該変更要求または該変更処理により変更されたデータを示す変更データをバッファに蓄積し、
書き込みについての設定条件に基づいて、前記グループ化情報に含まれるグループ毎に、前記バッファに蓄積された前記変更データを格納装置に書き込むか否かを判定する
処理を実行させるデータ管理プログラム。
【請求項２】
前記蓄積された変更データを前記格納装置に書き込むと判定した場合、該蓄積された変更データの属するグループに関する情報を前記グループ化情報に反映する
ことを特徴とする請求項１に記載のデータ管理プログラム。
【請求項３】
前記蓄積された変更データを前記格納装置に書き込むと判定した場合、該蓄積された変更データを、該変更データに対応する前記メモリ上の前記グループに反映して前記格納装置に書き込む
ことを特徴とする請求項１に記載のデータ管理プログラム。
【請求項４】
前記書き込みについての設定条件は、前記バッファの空き容量またはグループ毎の変更データのデータ総量に基づく条件である
ことを特徴とする請求項１に記載のデータ管理プログラム。
【請求項５】
データに対するアクセス要求の履歴に基づいて、該データをグループ化するグループ化情報を生成するグループ化部と、
データの追加、更新、及び削除を含むデータの変更を要求する変更要求または該データの属するグループの変更処理に応じて、メモリ上に存在するグループに含まれるデータのうち、該変更要求または該変更処理により変更されたデータを示す変更データをバッファに蓄積する蓄積部と、
書き込みについての設定条件に基づいて、前記グループ化情報に含まれるグループ毎に、前記バッファに蓄積された前記変更データを格納装置に書き込むか否かを判定する判定部と、
を備えることを特徴とするデータ管理装置。
【請求項６】
コンピュータが、
データに対するアクセス要求の履歴に基づいて、該データをグループ化するグループ化情報を生成し、
データの追加、更新、及び削除を含むデータの変更を要求する変更要求または該データの属するグループの変更処理に応じて、メモリ上に存在するグループに含まれるデータのうち、該変更要求または該変更処理により変更されたデータを示す変更データをバッファに蓄積し、
書き込みについての設定条件に基づいて、前記グループ化情報に含まれるグループ毎に、前記バッファに蓄積された前記変更データを格納装置に書き込むか否かを判定する
ことを特徴とするデータ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書は、データ管理プログラム、データ管理装置、及びデータ管理方法に関する。
【背景技術】
【０００２】
ストレージ装置は、サイズの小さなデータへの不規則なアクセスにおけるスループットが低く、シーケンシャルアクセスのコストに比べて、ランダムアクセスのコストが高い。このスループットを向上させる技術として、キャッシュ技術がある。
【０００３】
キャッシュ技術は、処理速度の速い制御装置が低速の記憶装置からデータをより速く読み出す場合にメモリを使用して処理時間を短縮する技術である。制御装置が低速の記憶装置からデータを読み出した場合、その読み出したデータを一時的にメモリに保持しておくことで、次回からはハードディスクより読み書きが早いメモリからデータを読み出せる。
【０００４】
キャッシュ技術の１つとして、Least Recently Used（ＬＲＵ）キャッシュ技術がある。ＬＲＵキャッシュ技術は、小容量で高速な記憶装置（例えば、キャッシュメモリ）がいっぱいになったとき、その中にあるデータのうち、不使用の時間が最も長いデータを大容量で低速な記憶装置（例えば、主記憶装置）に保存する、というのが基本のアルゴリズムである。ＬＲＵキャッシュ技術は、アプリケーションプログラムのロジックを知らなくても効果を得られるアルゴリズムであり、短期間のうちに（キャッシュに載っているうちに）同じデータに繰り返しアクセスする場合にのみ効果を発揮する。キャッシュメモリの量によってデータのキャッシュ生存期間が決まるが、そのキャッシュ生存期間を超えるサイクルでの繰り返しアクセスには効果がない。
【０００５】
メモリの容量を超えて大量データを処理する場合、ディスクへのアクセスが多発することで、データ処理性能が大きく劣化する。
【０００６】
そこで、キャッシュ技術の１つとして、アクセス履歴に基づき、関連性のあるデータを同一のセグメントに取りまとめ、データの再配置を行う技術（以降、データ再配置技術）がある（例えば、特許文献１）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】国際公開第２０１３／１１４５３８号
【特許文献２】特開平１０−１６１９３８号公報
【特許文献３】特開２００１−３４５３５号公報
【特許文献４】特開８−１３７７５３号公報
【特許文献５】特開２００９−１０４６８７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
データ再配置技術は、データを再配置することにより、次回以降のアクセスにおけるリードコストを削減する技術であるが、データの再配置には一定のコストがかかる。データの再配置によるメリットと、データの再配置によるコストとの関係は、データアクセスの状況（データアクセスを行うアプリケーションプログラムの性質）により異なる。
【０００９】
アプリケーションによるライトと再配置によるライトは一度に行うことが可能なので、再配置によるライトのコストの隠蔽が可能である。しかし、たとえば、アプリケーションプログラム（以下、「アプリケーション」と称する。）がライトをしない、あるいは、少量のライトしか行わない場合は、再配置によるライトのコストの隠蔽が十分できないため、ＬＲＵ等の他の技術と比較してコストが大きくなる。その一方で、データの再配置を行わなければ、再配置によるメリットは得られないため、再配置を抑止することも不適切である。
【００１０】
本発明の一側面として、データ再配置に伴うストレージ装置への書き戻し頻度を制御する技術を提供する。
【課題を解決するための手段】
【００１１】
本発明の一側面に係るデータ管理装置は、グループ化部、蓄積部、判定部を含む。グループ化部は、データに対するアクセス要求の履歴に基づいて、データをグループ化するグループ化情報を生成する。蓄積部は、データの変更を要求する変更要求またはデータの属するグループの変更処理に応じて、メモリ上に存在するグループに含まれるデータのうち、変更要求または変更処理により変更されたデータを示す変更データをバッファに蓄積する。データの変更は、データの追加、更新、及び削除を含む。判定部は、書き込みについての設定条件に基づいて、グループ化情報に含まれるグループ毎に、バッファに蓄積された変更データを格納装置に書き込むか否かを判定する。
【発明の効果】
【００１２】
本発明の一側面によれば、データ再配置に伴うストレージ装置への書き戻し頻度を低減させることができる。
【図面の簡単な説明】
【００１３】
【図１】本実施形態におけるデータ管理装置の一例を示す。
【図２】本実施形態におけるデータ管理装置のハードウェア構成例である。
【図３】本実施形態におけるデータ管理装置の機能構成例である。
【図４】本実施形態におけるデータ配置テーブルの一例である。
【図５】本実施形態におけるバッファグループの一例を示す。
【図６】本実施形態における更新量テーブルの一例を示す。
【図７Ａ】本実施形態におけるデータの更新（削除を含む）またはデータの再配置を行ってグループを更新する場合のフロー（その１）を示す。
【図７Ｂ】本実施形態におけるデータの更新（削除を含む）またはデータの再配置を行ってグループを更新する場合のフロー（その２）を示す。
【図８】本実施形態における対象グループのキャッシュを破棄する場合のフローを示す。
【図９】バッファグループエントリ別処理（Ｓ２２，Ｓ５４）のフローを示す。
【図１０】本実施形態におけるグループの読み込み処理のフローを示す。
【図１１】本実施形態におけるバッファグループの残り容量が少なくなった場合の処理フローを示す。
【図１２】本実施形態の実施例について説明するための図である。
【発明を実施するための形態】
【００１４】
データ再配置技術では、関連するデータをグループ化し、ストレージに連続した領域として格納する。
【００１５】
データにアクセスする場合は、ストレージからデータが、所属するグループ毎に、読み出されてメモリにキャッシュされる。キャッシュされたグループに含まれるデータへのアクセスは、1度のランダムアクセスで済むことが期待される。グループは単一のデータよりもサイズが大きくなるのでアクセスコストが増加するが、ランダムアクセスのコストと比較すると増加分はわずかである。
【００１６】
メモリ上において関連性の強いデータが検出された場合は、データがメモリ上にキャッシュされている間に、随時、グルーピングの内容が変更される（データが所属するグループが変更される）。これをデータの再配置と呼ぶ。
【００１７】
メモリの空き容量が不足した場合は、アクセスのないグループから順に、キャッシュから破棄される。グループの変更が行われた場合（所属するデータが更新された場合、もしくは再配置によってグルーピングが更新された場合）は、ＬＲＵにて、グループ単位にディスクに書き戻される（ライトバックされる）。
【００１８】
これにより、メモリにキャッシュされているグループに含まれるデータへは、グループがストレージに書き戻されるまでは、追加のストレージアクセスのコスト無しでアクセスできるため、アクセスコストが削減できる。つまり何個のデータにアクセスしても、グループへのアクセスコスト1回分≒データへのアクセスコスト１つ分で賄える。
【００１９】
また、グループがキャッシュに載っている短期間のうちに、同じグループに属するデータにアクセスする場合に効果を発揮する。すなわち、ＬＲＵのように同一データへの再アクセスでなく、同一グループへの再アクセスであれば、異なるデータへのアクセスであってよい。また、     先読みキャッシュ技術のような効果を得られる。
【００２０】
ここで、データ間の関連性を示す値として、グループがキャッシュに載っている間に何個のデータがアクセスされたかを「データ再利用数」と呼ぶ。また、あるアプリケーションプログラム（以下、「アプリケーション」と称する。）においてデータ再配置技術が使用されている場合のデータ再利用数の平均値を「平均データ再利用数」と呼ぶ。
【００２１】
また、キャッシュ効果はデータ再配置技術でもＬＲＵキャッシュ技術でも同じく発生するため、同一データへの繰り返しアクセスは１個としてカウントする。
【００２２】
ところが、データ再配置技術の仕組みは高コストであり、ＬＲＵキャッシュの性能を上回るための条件が厳しい。以下に、例を用いて条件を検証する。
【００２３】
例えば、シーケンシャルリード／ライト共に100MB/s、ランダムリード／ライト共に10msのハードディスクドライブ（HDD）があるとする。各データは、サイズ1KBであるとする。このときの、ＬＲＵの場合のコストは、以下の通りである。
（ＬＲＵの場合のコスト）
・データ1つのリードのコストは、10[ms]+1[KB]/100[MB/s]=10[ms]+0.01[ms]=10.01[ms]となる。初回のリードにコストが発生し、キャッシュにデータが載っている場合はコスト0となる。
・データ1つのライトのコストは、10[ms] + 1[KB]/100[MB/s]=10[ms]+0.01[ms]=10.01[ms]（リードのコストと等しい。）となる。コストは最後のライトバック時にのみ発生し、それまではコスト0である。
（データ再配置技術の場合のコスト）
【００２４】
一方、データ再配置技術の場合のコストは、以下のようになる。ここで、グループサイズ=1MBとする。
・グループ全体をストレージからリードするコストは、10[ms]+1[MB]/100[MB/s]=20[ms]である。
・グループ全体をストレージにライトするコストも10[ms]+1[MB]/100[MB/s]=20[ms]である。
・データを一つ読み出すだけでもそのデータが所属するグループ全体を読み出す必要がある。
【００２５】
所属するグループがキャッシュに載っていなかった場合において、ライトバックが必要である場合のコストは、20[ms]+20[ms]=40msとなる。これは、データ1つのリードのコスト10.01[ms]の約４倍であることから、再利用数が4以上でないとＬＲＵキャッシュの性能を上回ることができない。
【００２６】
また、データ再配置技術では、平均データ再利用数を高めるために積極的に再配置が行われるため、基本的にはこの値となる。
【００２７】
また、所属するグループがキャッシュに載っていなかった場合において、ライトバックが不要の場合のコストは、20[ms]である。このケースでは、データ1つのリードのコスト10.01[ms]の約２倍であるから、再利用数が2以上でよい。再配置が発生せず、ライトも一切発生しなかった場合の話で、このケースはほとんどない。
・上記コストは初回のみ発生し、所属するグループがキャッシュに載っている場合0[ms]となる。
・データ1つをライトする場合のコストは、リードの場合と同じく20[ms]+20[ms]=40msとなる。この場合でも、再利用率が4以上でないとコストの回収を図ることができない。
【００２８】
リードが必要ない場合のコストは20msで、再利用数は2以上でよいが、再配置にはどうしてもリードが必要になること、グループ内に一つでも更新されないデータがある場合は一度グループを読み出す必要があるため、この条件は基本的に発生しない。
【００２９】
以上より、本例では通常 再利用数4という高い数字を達成しないと、データ再配置のコストを吸収しＬＲＵの性能を上回ることができない、ということが分かる。ただし、特殊な条件では再利用数2を達成すればよいことになる。
【００３０】
また、グループサイズ=100KBとした場合は、グループのリード・ライトのコストが11[ms]となり、再利用数は通常2.2、特殊な条件で1.1を達成すればよいが、グループに所属するデータの数が1/10となるため、この場合でも達成は難しい。
【００３１】
このようにデータ再配置技術の仕組みにおけるリード／ライドには、高コストがかかる。次に、データ再配置技術の仕組みにおけるリード／ライドのコストを、アプリケーションの性質毎に考察する。
【００３２】
（１）リード・ライトが共にほとんど発生しないアプリケーションの場合
この場合では、データ再配置技術が改善しようとするスループット性能問題が発生しない。
【００３３】
（２）リードがほとんど発生しないが、ライトは多く発生するアプリケーションの場合
リード時、再配置されたグループをまとめ読みすることにより、リードのコストが削減されるが、アクセス全体におけるリードの比率が小さいため、性能改善は微小なものとなる。
【００３４】
一方、再配置されて更新されたグループのライトバックは、アプリケーションが発生させるライトに隠蔽することができるので、見かけ上、再配置のコストは極めて小さくなる。
よって、性能改善率は小さめにとどまる。
【００３５】
（３）リード・ライトが共に多く発生するアプリケーションの場合
リード時、再配置されたグループをまとめ読みすることにより、リードのコストが削減され、性能向上する。
【００３６】
一方、再配置されて更新されたグループのライトバックは、アプリケーションが発生させるライトに隠蔽することができるので、見かけ上、再配置のコストは極めて小さくなる。
このため、このケースでは大きく性能改善できる。
【００３７】
（４）リードが多く発生するが、ライトがほとんど発生しないアプリケーションの場合
リード時と同様に、再配置されたグループをまとめ読みすることにより、リードのコストが削減され、性能向上する。
【００３８】
一方、再配置されて更新されたグループのライトバックは、アプリケーションが発生させるライトに隠蔽することができず、データ再配置技術が単独で発生させるケースが多発する。このため再配置のコストは見かけ上きわめて大きくなる。
【００３９】
この結果、性能改善が微小なレベルにとどまるか、もしくは性能が悪化するケースが出てくる。
【００４０】
このように、上記（１）〜（３）の場合と比べて、上記（４）の場合では、性能が悪化するケースがある。
【００４１】
次に、データ再配置技術とバッファリングとによる対応について考察する。
・ライトのコストを下げる代表的手法としてバッファリングによるまとめ書きがあり、これによりライトバックされるグループの数を減らすことはできなくてもライトバックの回数を減らしてコストを下げることができるように見える。
・しかしながらデータ再配置技術はもともとまとめ書きを用いた性能向上を狙っており、データをグループ化してまとめ書きするものである。このグループをさらにまとめ書きするとなると、以下の理由からうまく行かない。
【００４２】
まとめ書きのためのグループをさらに複数個まとめ書きするため、一度の書き込みサイズは巨大になり、シーケンシャルアクセス性能の影響が大きくなり高コストとなる。
【００４３】
もともと上述の再配置技術が想定している状況では、更新されたデータの総サイズ、つまり本来のまとめ書きが必要なサイズは小さい。このため単にＬＲＵを採用し更新されたデータだけをライトバックする場合、その書き込みサイズは小さくて済む。つまりリードとライトがまんべんなく発生する状況よりもむしろ低コストで済む。よって相対的にもデータ再配置技術とバッファリングとは、ＬＲＵに対して不利となる。
【００４４】
バッファリングによるライトコスト削減を効果的に行うには、更新されたグループが溜まるのを待ってまとめて書く必要がある。しかしながら、まとめ書きのためのグループをさらに複数個キープし更新されたグループが溜まるのを待つという処理は、メモリを大きく圧迫する。言い換えれば、このバッファリング処理にあまり多くのメモリを割けないので、あまり待てず効率的なまとめ書きにならない。
【００４５】
このようにデータ再配置技術は、データをグループ化することにより、特にリードコストを削減する技術である。データを再配置し、より効率の良いグループ化に変更していく処理は、随時行われる。再配置により、次回以降のアクセスにおけるリードコストが削減される。ライトコストの削減も可能であるが、バッファリングなど簡素な技術で同等の効果を得られる。
【００４６】
しかしながらデータの再配置には、少なくないコストがかかる。特に、再配置して更新されたグループを書き戻す処理が主なコストである。このため、アプリケーションが発生させるリード・アプリケーションが更新したデータのライトと、再配置によって更新されたグループのライトをセットで行って、このコストを隠蔽するのがデータ再配置技術の基本的な設計思想である。
【００４７】
このため、データの再配置によるメリットと、データの再配置に伴うコストの関係は、データアクセスの状況（つまりデータアクセスを行うアプリケーションの性質）により異なってくる。例えば、ライトをしない、あるいは、少量のライトしか行わないアプリケーションにおいては、再配置に伴うライトをセットで行うことが難しくなり再配置に伴うコストを十分に隠蔽できなくなる、つまり見かけ上、コストが大きくなる。この結果、データ再配置技術はＬＲＵなど他の技術より不利となる。一方、再配置を行わなければコストは発生しないが再配置によるメリットも得られないため、再配置を抑止することも不適切である。
【００４８】
以下に、本実施形態の詳細について説明する。
図１は、本実施形態におけるデータ管理装置の一例を示す。データ管理装置１は、グループ化部２、蓄積部３、判定部４を含む。
【００４９】
グループ化部２は、データに対するアクセス要求の履歴に基づいて、データをグループ化するグループ化情報を生成する。グループ化部２の一例として、後述する、解析判断部２２、関係性解析部２３、配置決定部２４、及び再配置部２５が挙げられる。グループ化情報の一例として、後述するデータ配置テーブル３１が挙げられる。
【００５０】
蓄積部３は、データの変更を要求する変更要求またはデータの属するグループの変更処理に応じて、メモリ上に存在するグループに含まれるデータのうち、変更要求または変更処理により変更されたデータを示す変更データをバッファに蓄積する。データの変更は、追加、更新、及び削除を含む。蓄積部３の一例として、後述するライトバック制御部２６が挙げられる。
【００５１】
判定部４は、書き込みについての設定条件に基づいて、グループ化情報に含まれるグループ毎に、バッファに蓄積された変更データを格納装置に書き込むか否かを判定する。判定部４の一例として、後述するライトバック制御部２６が挙げられる。
【００５２】
このように構成することにより、データ再配置に伴うストレージ装置への書き戻し頻度を低減させることができる。
【００５３】
判定部４は、蓄積された変更データを格納装置に書き込むと判定した場合、蓄積された変更データの属するグループに関する情報をグループ化情報に反映する。判定部４は、蓄積された変更データを格納装置に書き込むと判定した場合、蓄積された変更データを、変更データに対応するメモリ上のグループに反映して格納装置に書き込む。
【００５４】
このように構成することにより、バッファにおいてバッファグループとして蓄積した更新情報をキャッシュ上のグループに反映すると共に、グループ化情報にも反映することができる。
【００５５】
図２は、本実施形態におけるデータ管理装置のハードウェア構成例である。データ管理装置１１は、例えば制御装置１２と、メモリ装置（以下、「メモリ」と称する。）１３と、ストレージ装置１４とを含む。また、データ管理装置１１は、通信ネットワーク（以下、「ネットワーク」と称する）１６を介して情報処理装置の一例であるクライアントコンピュータ（以下、「クライアント」と称する）１５に接続されている。
【００５６】
制御装置１２は、例えば、プログラムカウンタや命令デコーダ、各種演算器、ＬＳＵ（Load Store Unit）、汎用レジスタ等を有する演算処理装置としてのＣＰＵ（Central Processing Unit）等のプロセッサである。
【００５７】
メモリ１３は、ストレージ装置１４に比して高速にアクセス可能な記憶装置である。メモリ１３としては、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ等である。ストレージ装置１４は、例えば、ＨＤＤ（Hard Disk Drive）等のメモリ１３に比してアクセス速度が低速なディスク装置である。
【００５８】
ストレージ装置１４には、データ管理装置１１が提供するデータがグループ単位で記憶されている。本実施形態の一例として、グループとは、データへのアクセス要求（以下、アクセス要求と称する）の履歴により関連性が認められるデータの集合であり、後述するように制御装置１２の処理によって内容が更新される。アクセス要求は、リード（READ）アクセス要求及びライト（WRITE）アクセス要求を含む。なお、本実施形態の一例として、このようにアクセス履歴に基づいてデータをグループ化しているが、これに限定されず、他の情報に基づいてデータをグループ化してもよい。
【００５９】
メモリ１３には、例えばストレージ装置１４に格納されたグループのうち高頻度にアクセスされるグループがストレージ装置１４から読み出されて格納される。これによって、データ管理装置１１は、入力されたアクセス要求に対して高速にデータを出力することができる。
【００６０】
データ管理装置１１は、上記の構成に加えて、ＢＩＯＳ（Basic Input/Output System）を格納したＲＯＭ、プログラムメモリ等を有する。制御装置１２が実行するプログラムは、ネットワーク１６を介して取得されてもよいし、可搬型メモリ装置やＣＤ−ＲＯＭ等のコンピュータ読み取り可能な可搬型記録媒体がデータ管理装置１１に装着されることにより取得されてもよい。
【００６１】
図３は、本実施形態におけるデータ管理装置の機能構成例である。上述の通り、データ管理装置１１は、制御装置１２、メモリ１３、ストレージ装置１４を含む。
【００６２】
メモリ１３は、キャッシュ領域３５とバッファ３６とを含む。キャッシュ領域３５は、ストレージ装置１４から読み出された複数のグループをキャッシングして、一時的に格納する領域である。
【００６３】
バッファ３６は、キャッシュ領域３５に保持されたグループに含まれるデータのうち、追加、更新、または削除されたデータ（すなわち、グループの更新部分またはグループの変更部分という。）をバッファグループ３７として記憶する。
【００６４】
メモリ１３は、データ配置テーブル３１、関係性管理テーブル３２、更新量テーブル３３、閾値情報３４を保持する。
【００６５】
データ配置テーブル３１は、データを特定するキーと、そのデータが属するグループとの対応関係を示す情報を格納する。関連性管理テーブル３２は、リクエストで指定されたデータ毎に、前回リクエストで指定されたデータを順次関係付けて、累積したその関係付けの情報を管理するテーブルである。更新量テーブル３３は、キャッシュ領域３５に保持されているグループのデータ更新の総量を記録する。
【００６６】
閾値情報３４は、本実施形態で用いる閾値を含む。閾値情報３４は、バッファグループの空き容量について事前に設定された閾値Ｔ１と、グループ毎の更新データ総量について事前に設定された閾値Ｔ２とを含む。
【００６７】
制御装置１２は、本実施形態にかかるプログラムを実行することにより、要求受付部２１、解析判断部２２、関係性解析部２３、配置決定部２４、再配置部２５、ライトバック制御部２６として機能する。
【００６８】
要求受付部２１は、クライアント１５等の要求元から入力されたリクエストに応じてメモリ１３を検索し、メモリ１３にリクエストで指定されたレコードがなければさらにストレージ装置１４を検索し、リクエストで指定されたレコードを要求元に送信する。なお、リクエストは、クライアント１５が送信するだけでなく、データ管理装置１１において実行されているプロセスその他の主体がリクエストの発行元となる場合もあり得る。また、入出力装置がデータ管理装置１１に接続されている場合、ユーザが入出力装置に対してリクエストを入力することも想定される。
【００６９】
リクエストが入力されると、要求受付部２１は、まずメモリ１３からリクエストで指定されたデータを検索する。リクエストで指定されたデータがメモリ１３上に存在する場合に、要求受付部２１は、そのデータをメモリ１３から読み出して要求元に返信する。
【００７０】
また、要求受付部２１は、リクエストで指定されたデータがメモリ１３上に存在しない場合には、ストレージ装置１４からリクエストで指定されたデータを検索する。入出力管理部２２は、リクエストで指定されたデータがストレージ装置１４上に存在する場合に、データ配置テーブル３１を用いて、リクエストで指定されたデータの属するグループに含まれる全データをストレージ装置１４から読み出す。そして、要求受付部２１は、その読み出したグループに含まれる全データのうち、リクエストで指定されたデータを要求元に返信する。このとき、要求受付部２１は、その読み出したグループに含まれる全データをメモリ１３に格納する。
【００７１】
なお、上記では、要求受付部２１は、ストレージ装置１４から読み出したグループに含まれる全データをメモリ１３へ格納する処理を、リクエストがあったタイミングで行う場合について説明したが、これに限定されない。例えば、要求受付部２１は、一定期間のアクセス頻度を取得してアクセス頻度が高いグループを優先的にストレージ装置１４から読み出してメモリ１３に格納してもよい。
【００７２】
解析判断部２２は、関係性管理テーブル３２を用いて、連続するリクエスト間で指定された各データが属するグループが同一かどうかを判定することにより、関連性解析部２３に関連性の解析を行わせるか否かを決定する。
【００７３】
関連性解析部２４は、解析判断部２２の判定結果に応じて、関係性管理テーブル３２から、今回のリクエストで指定されたデータの属するグループの各データと、前回のリクエストで指定されたデータの属するグループの各データとの関連性を解析する。
【００７４】
再配置決定部２４は、その解析結果に基づいて、データの所属するグループの決定を行う。再配置部２５は、関連性解析部２４の決定に従い、データ配置テーブル３１のグループの配置を更新する。
【００７５】
ライトバック制御部２６は、バッファグループ３７に蓄積されたその更新されたグループの更新部分のサイズ総量とバッファグループ３７の残り容量とに基づいて、次の判断を行う。すなわち、ライトバック制御部２６は、今回分を含めたこれまでの更新部分をまとめてグループをストレージ装置１４に書き戻すか、今回分の更新部分をバッファグループ３７に記録したままにして書き戻しを抑止するかを判断する。なお、本実施形態では、グループの更新が発生した場合、ライトバック制御部２６は、グループを直接更新せず、バッファグループ３７に一時的に記録しているとする。
【００７６】
図４は、本実施形態におけるデータ配置テーブルの一例である。データ配置テーブル３１は、「キー」、「所属するグループ」の項目を含む。「キー」は、データを特定する一意の情報である。「所属するグループ」は、キーによって特定されるデータが所属するグループを示す。
【００７７】
バッファグループは名前が特殊で、バッファグループかそうでないかを簡単に区別できるようにする。例えば、図４では、バッファグループは「グループＺ」で示される。
【００７８】
図５は、本実施形態におけるバッファグループの一例を示す。バッファグループ３７は、上述したように、キャッシュ領域３５に保持されたグループのうち、書き戻しの対象となるグループ（バッファグループ３７）内のデータの更新部分または追加されたデータを記憶する。
【００７９】
バッファ３６において、バッファグループ３７のエントリは、「キー」、「データ本体」、「本来所属するグループ」の項目を含む。「キー」は、データを特定する一意の情報を格納する。「データ本体」は、更新後のデータまたは新たに追加されたデータを格納する。「本来所属するグループ」は、更新前または追加前にデータが所属していたグループを格納する。なお、データが新たに追加された場合、所属するグループが存在しないので、「本来所属するグループ」は空白となる。
【００８０】
図６は、本実施形態における更新量テーブルの一例を示す。更新量テーブル３３は、キャッシュ領域３５に保持されているグループのデータ更新の総量を記憶するが、キャッシュ領域３５に保持されていないグループのデータ更新総量を記憶してもよい。
【００８１】
更新量テーブル３３は、「グループ」、「バッファグループに一時保管されたデータ量」の項目を含む。「グループ」は、キャッシュ領域３５に保持されているグループの名称を格納するが、キャッシュ領域３５に保持されていないグループの名称を記憶してもよい。
【００８２】
「バッファグループに一時保管されたデータ量」は、バッファグループ３７に一時保管されたグループのデータ量を記憶する。
【００８３】
図７Ａ及び図７Ｂは、本実施形態におけるデータの更新（削除を含む）またはデータの再配置を行ってグループを更新する場合のフローを示す。
【００８４】
要求受付部２１は、対象データの更新または削除についてのリクエストを受け取ると、データ配置テーブル３１に基づいて、対象データが所属するグループを確認する（Ｓ１）。
【００８５】
確認の結果、対象データがバッファグループ３７以外のグループに所属する場合（Ｓ２で「ＹＥＳ」）、要求受付部２１は、次の処理を行う。ここでは、キャッシュ領域３５に対象データが存在しない場合には、要求受付部２１は、対象データの所属するグループをストレージ装置１４から読み込み、キャッシュ領域３５に載せる（Ｓ３）。
【００８６】
データの更新またはデータの再配置を行う場合、ライトバック制御部２６は、グループを直接更新せず、バッファグループ３７に、追加・更新・削除された対象データが本来所属するグループと、対象データのデータ本体との組を記録する（Ｓ４）。
【００８７】
なお、対象データが削除された場合は、データ本体ではなく削除された旨を示すフラグを記録する。またデータの再配置（グループ間のデータ移動）は、一方のグループからのデータ削除、及びもう一方のグループへの新規データの追加として扱われる。
【００８８】
ライトバック制御部２６は、更新量テーブル３３において、対象データの所属するグループの、バッファグループ３７における更新データの総量の値の記録を更新する（Ｓ５）。
【００８９】
ライトバック制御部２６は、データ配置テーブル３１において、対象データのグループを、バッファグループ３７を示すグループ名に更新する。すなわち、ライトバック制御部２６は、データ配置テーブル３１に、対象データをバッファグループ３７に再配置したものとして記録する（Ｓ６）。
【００９０】
Ｓ２での確認の結果、対象データがバッファグループ３７に所属する場合（Ｓ２で「ＮＯ」）、要求受付部２１は、次の処理を行う。すなわち、要求受付部２１は、バッファグループ３７から、対象データに対応するエントリ（本来所属するグループと、追加・更新・削除された対象データ本体との組）を検索する（Ｓ７）。
【００９１】
ライトバック制御部２６は、検索されたエントリについて、対象データのデータ本体の部分を更新する（Ｓ８）。
【００９２】
ライトバック制御部２６は、更新量テーブル３３において、対象データが本来所属するグループの、バッファグループにおける更新データの総量の値の記録を更新する（Ｓ９）。
【００９３】
Ｓ６またはＳ９の終了後、ライトバック制御部２６は、Ｓ６またはＳ９において、更新量テーブル３３において更新した、グループの更新データ総量が閾値Ｔ２を超えているかを判定する（Ｓ１０）。更新した更新データ総量が閾値Ｔ２を超えていない場合（Ｓ１０で「ＮＯ」）、本フローは終了する。
【００９４】
更新した更新データ総量が閾値Ｔ２を超えている場合（Ｓ１０で「ＹＥＳ」）、ライトバック制御部２６は、バッファグループ３７に記録された、そのグループの更新部分を、キャッシュ領域内の対応するグループに反映し、グループを更新する（Ｓ１１）。
【００９５】
ライトバック制御部２６は、バッファグループ３７の「本来所属するグループ」に基づいて、データ配置テーブル３１において、そのグループの更新部分に対応するデータの所属グループを本来のグループ名に変更する（Ｓ１２）。
【００９６】
ライトバック制御部２６は、更新量テーブル３３において、そのグループの、バッファグループ３７における更新データの総量の値の記録を０に更新する（Ｓ１３）。
【００９７】
ライトバック制御部２６は、バッファグループ３７を保持していたバッファを開放し（本来所属するグループと、追加・更新・削除されたデータ本体との組）、バッファグループの空き領域の値も更新する（Ｓ１４）。
【００９８】
ライトバック制御部２６は、Ｓ１１で更新されたグループをストレージ装置１４に書き戻す（Ｓ１５）。
【００９９】
グループをキャッシュ領域３５から破棄する場合、ライトバック制御部２６は図８の処理を行う（Ｓ１６）。
【０１００】
図８は、本実施形態における対象グループのキャッシュを破棄する場合（Ｓ１６）のフローを示す。ライトバック制御部２６は、バッファグループ３７の空き容量が閾値Ｔ１を超えておらず、かつ破棄対象のグループの更新データ総量が閾値Ｔ２を超えていないかを判定する（Ｓ２１）。バッファグループ３７の空き容量が閾値Ｔ１を超えておらず、かつ破棄対象のグループの更新データ総量が閾値Ｔ２を超えていない場合（Ｓ２１で「ＹＥＳ」）、ライトバック制御部２６は、キャッシュ領域３５から対象グループの内容を破棄する（Ｓ２３）。
【０１０１】
バッファグループ３７の空き容量が閾値Ｔ１を超えている、または破棄対象のグループの更新データ総量が閾値Ｔ２を超えている場合（Ｓ２１で「ＮＯ」）、ライトバック制御部２６は、バッファグループエントリ別処理を行う（Ｓ２２）。Ｓ２２の詳細については、図９で説明する。
【０１０２】
Ｓ２２の処理後、ライトバック制御部２６は、キャッシュ領域３５から対象グループの内容を破棄する（Ｓ２３）。
【０１０３】
図９は、バッファグループエントリ別処理（Ｓ２２，Ｓ５４）のフローを示す。バッファグループ３７の各エントリのうち、本来所属するグループに含まれるデータのエントリそれぞれについて、ライトバック制御部２６は、以下のＳ３１〜Ｓ３６の処理を行う。
【０１０４】
まず、ライトバック制御部２６は、バッファグループ３７の１エントリを参照し、そのエントリのバッファグループ３７の項目「データ本体」に、削除済みを示すフラグが格納されているかを判定する（Ｓ３１）。
【０１０５】
そのエントリのバッファグループ３７の項目「データ本体」に、削除済みを示すフラグが格納されている場合（Ｓ３１で「ＹＥＳ」）、ライトバック制御部２６は、次の処理を行う。すなわち、ライトバック制御部２６は、項目「本来所属するグループ」で示される、キャッシュ領域３５内にあるグループからそのフラグが付与されているキーに対応するデータを削除する（Ｓ３３）。
【０１０６】
ライトバック制御部２６は、データ配置テーブル３１から、その削除したデータのキーに対応するエントリを削除する（Ｓ３３）。
【０１０７】
Ｓ３１において、そのエントリのバッファグループ３７の項目「データ本体」に、削除済みを示すフラグが格納されていない場合（Ｓ３１で「ＮＯ」）、ライトバック制御部２６は、次の処理を行う。すなわち、ライトバック制御部２６は、項目「データ本体」に格納されているデータ本体を用いて、キャッシュ領域３５内にあるそのグループに対応するデータ本体を更新する（Ｓ３４）。
【０１０８】
ライトバック制御部２６は、バッファグループ３７の「本来所属するグループ」に基づいて、データ配置テーブル３１において、グループ内の更新部分に対応するデータの所属グループを本来のグループに変更する（Ｓ３５）。
【０１０９】
Ｓ３３またはＳ３５の終了後、ライトバック制御部２６は、今回処理したエントリをバッファグループ３７から削除する（Ｓ３６）。
【０１１０】
Ｓ３１〜Ｓ３６の処理の終了後、ライトバック制御部２６は、バッファグループの空き領域の値を更新する（Ｓ３７）。
【０１１１】
図１０は、本実施形態におけるグループの読み込み処理のフローを示す。要求受付部２１は、グループをストレージ装置１４から読み込み、キャッシュに載せる（Ｓ４１）。
【０１１２】
ライトバック制御部２６は、バッファグループ３７に一時記録した更新後のデータ本体のグループ毎のサイズ総量を算出し、更新量テーブル３３の「バッファグループに一時保管されたデータ量」に記録する（Ｓ４２）。ここでは、ストレージ装置１４にあるグループは更新サイズ総量を保持しないことを前提としているが、保持することとしてグループ本体共にストレージ装置１４に書き込みまたはストレージ装置１４から読み出すこととしてもよい。
【０１１３】
図１１は、本実施形態におけるバッファグループの残り容量が少なくなった場合の処理フローを示す。バッファグループ３７の残り容量が少なくなったことを検知した場合、または、定期的に、ライトバック制御部２６は、以下の処理を実行する。
【０１１４】
バッファグループ３７の空き容量が閾値Ｔ１を超えていない場合（Ｓ５１で「ＹＥＳ」）、本フローは終了する。
【０１１５】
バッファグループ３７の空き容量が閾値Ｔ１を超えている場合（Ｓ５１で「ＮＯ」）、ライトバック制御部２６は、更新量テーブル３３を参照して、バッファグループ３７において、更新データ総量が最も多いグループ（対象グループ）を１つ選出する（Ｓ５２）。
【０１１６】
その更新データ総量が最も多いグループがメモリ１３に載っている場合（Ｓ５３で「ＹＥＳ」）、ライトバック制御部２６は、図９の処理を行う（Ｓ５４）。
【０１１７】
その更新データ総量が最も多いグループがメモリ１３に載っていない場合（Ｓ５３で「ＮＯ」）、ライトバック制御部２６は、キャッシュ領域３５に新しいグループを作成する。
【０１１８】
ライトバック制御部２６は、バッファグループ３７に記録された、その対象グループの更新部分を全て、キャッシュ領域３５にて新規に作成されたグループに反映し、対象グループを更新する（Ｓ５６）。
【０１１９】
ライトバック制御部２６は、バッファグループの該当領域は開放し（本来所属するグループと、追加・更新・削除されたデータ本体との組）、バッファグループ３７も空き領域の値も更新する（Ｓ５７）。
【０１２０】
ライトバック制御部２６は、データ配置テーブル３１において、その対象グループの更新部分に対応するデータの所属グループ名を新規に作成したグループ名に変更する（Ｓ５８）。
【０１２１】
ライトバック制御部２６は、その新規に作成したグループの、バッファグループ３７における更新データの総量の値の記録を０に更新する（Ｓ５９）。
【０１２２】
ライトバック制御部２６は、その新規に作成したグループをストレージ装置１４に書き戻す。このとき、キャッシュ領域に保持されている新規に作成したグループは破棄しない（Ｓ６０）。その後、Ｓ５１へ戻る。
【０１２３】
なお、再配置によりデータをグループ間で移動する場合、移動前のグループからはデータを削除、移動後のグループにはデータを追加したものとして扱う。バッファグループ３７には作成と削除でエントリを二重に記録し、データ配置テーブル３１には移動後のグループのみ記録する。
【０１２４】
以下に本実施形態の実施例を説明する。
図１２は、本実施形態の実施例について説明するための図である。図１２（Ａ）に示すように、グループＸにはデータｘ１＝１，ｘ２＝２，・・・、が格納されている。グループＹにはｙ１＝１０，ｙ２＝２０，・・・が格納されている。バッファグループＢは最初、空であるとする。現状、グループＸ及びＹは更新されておらず（グループＸ及びＹの更新データの総量はそれぞれ、０である）、ストレージ装置１４上に記録されている内容とキャッシュ領域３５上に展開されている情報が一致しており、ライトバックの必要が無いものとする。例では簡単のため、二つの閾値は共に無限大であるとする。またデータのサイズは全て１とする。
【０１２５】
図１２（Ｂ）は、ｘ１＝１００に変更された場合の状態を示す。バッファグループＢは空であるので、変更の内容はバッファグループＢに記録される。また、グループＸの更新データの総量＝１となる。また、データ配置テーブルにおいて、ｘ１の所属グループがバッファグループＢに変更される。
【０１２６】
図１２（Ｃ）は、ｘ２が削除された場合の状態を示す。これもバッファグループＢに記録される。削除も更新データの総量を増加させるので、グループＸの更新データの総量＝２となる。また、データ配置テーブルにおいて、ｘ２の所属グループがバッファグループＢに変更される。
【０１２７】
図１２（Ｄ）は、ｙ１をグループＹからグループＸへ移動した状態を示す。グループＸ，Ｙのデータの変更について、グループＸ，Ｙを直接更新せず、バッファグループＢに記録される。これにより、グループＸの更新データの総量＝３、グループＹの更新データの総量＝１となる。また、データ配置テーブルにおいて、ｙ１の所属グループがバッファグループＢに変更される。
【０１２８】
図１２（Ｅ）は、グループＸをキャッシュから破棄した場合の状態を示す。グループＸは更新されているので、そのままキャッシュを破棄することはできない。この場合、バッファグループＢ内の更新情報が、キャッシュ領域３５にあるグループＸに反映されて、ｘ１＝１００、ｙ１＝１０に更新され、ストレージ装置１４にライトバックされる。これにより、グループＸの更新データの総量＝０となる。また、バッファグループＢからグループＸについての更新情報が削除される。また、データ配置テーブルにおいて、ｘ１，ｙ１の所属グループがバッファグループＸに変更される。
【０１２９】
このように、本実施形態では、更新されたグループを、キャッシュから破棄する度に毎回ストレージに書き戻すのではない。本実施形態では、ライトバック制御部２６は、更新されたデータの総量が少ない場合には、更新部分とその更新されたデータが本来所属するグループ名とをキャッシュ上の別領域（バッファグループ）に記録する。同時に、ライトバック制御部２６は、データ配置テーブル３１に、データとグループの対応を記録する代わりに、どのバッファグループに記録したかを記録する。この時、更新された内容をバッファグループに保持しているため、このグループは、ストレージ装置１４への書き戻しが不要となり、単にキャッシュから破棄される。
【０１３０】
また、同じグループについてストレージから読み出しと、キャッシュからの破棄とが繰り返えされるとそのグループの更新部分がバッファグループに蓄積されていく。そのため、ある程度更新部分が蓄積されたところで更新部分を含めてグループをストレージ装置１４へ書き戻す。そして、バッファグループ上の更新部分とその更新部分（更新データ）が本来所属するグループの記録が破棄される。
【０１３１】
これにより、グループをキャッシュから破棄する度に書き戻しが発生していたのを、破棄数回〜数十回に対して一度のみ書き戻す。その結果、ライトのコスト削減、つまりデータ再配置技術を用いた場合でもコスト削減が可能となる。
【０１３２】
本実施形態によれば、ある更新されたグループのキャッシュを破棄するとき、グループのライトバックを制御するライトバック制御部２６は、次を行う。すなわち、ライトバック制御部２６は、バッファグループ３７に蓄積されたその更新されたグループの更新部分のサイズ総量とバッファグループの残り容量とに基づいて、次の判断を行う。ライトバック制御部２６は、今回分を含めたこれまでの更新部分をまとめてグループを書き戻すか、今回分の更新部分をバッファグループに記録したままにして書き戻しを抑止するかを判断する。ここで、グループの更新が発生した場合、グループを直接更新せず、バッファグループに一時的に記録している、と仮定する。
【０１３３】
これにより、グループの書き戻しの実行、もしくは今回分の更新部分をバッファグループに記録したままにすることによって、データ再配置技術によるグループの書き戻しの回数を削減することができる。
【０１３４】
本実施形態の適用前では、ライトが全く発生しないまたはライトがほとんど発生しないアプリケーションにおいて、本来グループがキャッシュから破棄される毎に発生していたライトにより性能が劣化していた。本実施形態を適用することにより、数回〜数十回分のライトを一度にまとめて回数を削減できるようになり、性能が向上する。
【０１３５】
なお、本発明は、以上に述べた実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の構成または実施形態を取ることができる。
【符号の説明】
【０１３６】
１      データ管理装置
２      グループ化部
３      蓄積部
４      判定部
１１    データ管理装置
１２    制御装置
１３    メモリ
１４    ストレージ装置
１５    クライアント
１６    ネットワーク
２１    要求受付部
２２    解析判断部
２３    関係性解析部
２４    配置決定部
２５    再配置部
２６    ライトバック制御部
３１    データ配置テーブル
３２    関係性管理テーブル
３３    更新量テーブル
３４    閾値情報
３５    キャッシュ領域
３６    バッファ
【図１】
2017162194.tif 000003
【図２】
2017162194.tif 000004
【図３】
2017162194.tif 000005
【図４】
2017162194.tif 000006
【図５】
2017162194.tif 000007
【図６】
2017162194.tif 000008
【図７Ａ】
2017162194.tif 000009
【図７Ｂ】
2017162194.tif 000010
【図８】
2017162194.tif 000011
【図９】
2017162194.tif 000012
【図１０】
2017162194.tif 000013
【図１１】
2017162194.tif 000014
【図１２】
2017162194.tif 000015