JP2014203280A - データ管理プログラム,データ管理装置およびデータ管理方法 - Google Patents

データ管理プログラム,データ管理装置およびデータ管理方法 Download PDF

Info

Publication number
JP2014203280A
JP2014203280A JP2013079291A JP2013079291A JP2014203280A JP 2014203280 A JP2014203280 A JP 2014203280A JP 2013079291 A JP2013079291 A JP 2013079291A JP 2013079291 A JP2013079291 A JP 2013079291A JP 2014203280 A JP2014203280 A JP 2014203280A
Authority
JP
Japan
Prior art keywords
data
storage
deleted
unit
acquired
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
JP2013079291A
Other languages
English (en)
Other versions
JP6107341B2 (ja
Inventor
山下 大輔
Daisuke Yamashita
大輔 山下
松本 達郎
Tatsuro Matsumoto
達郎 松本
有竹 敬和
Takakazu Aritake
敬和 有竹
菅野 博靖
Hiroyasu Sugano
博靖 菅野
西口 直樹
Naoki Nishiguchi
直樹 西口
輝 板▲崎▼
Hikaru Itazaki
輝 板▲崎▼
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.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2013079291A priority Critical patent/JP6107341B2/ja
Publication of JP2014203280A publication Critical patent/JP2014203280A/ja
Application granted granted Critical
Publication of JP6107341B2 publication Critical patent/JP6107341B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】データへのアクセス速度を向上させる技術を提供する。
【解決手段】格納処理部113は,ストレージ11にキャッシュデータを格納する。格納位置記録部104は,ストレージ11に格納されたキャッシュデータの物理的な格納位置を,管理情報記憶部150の管理情報に記録する。削除処理部103は,ストレージ11に格納されたキャッシュデータを削除する。復元可能性算出部109は,削除されたキャッシュデータの復元可能性を求める。復元データ取得部111は,取得が要求されたデータが削除されたキャッシュデータである場合に,該削除されたデータの復元可能性の高さが所定以上であれば,管理情報から該削除されたデータの格納位置を取得し,ストレージ11の該取得した格納位置からデータを取得する。
【選択図】図3

Description

本発明は,記憶装置に格納されたデータの管理を行うデータ管理プログラム,データ管理装置およびデータ管理方法に関するものである。
例えば,ユーザ装置からウェブ上に存在する様々なリソースやコンテンツにアクセスする場合,遠く離れたウェブ上のサーバへのアクセスとなるため,データの取得に時間がかかる。その待ち時間を短縮するために,ウェブ上のデータをユーザ装置のローカルの記憶装置に一時的に保存しておく,いわゆるキャッシュの技術が広く用いられている。
なお,キャッシュデータを未使用領域に格納してその格納位置を管理し,キャッシュデータを取得する際には,格納位置から取得したキャッシュデータが,オペレーティングシステムが該格納位置を使用したことにより破壊されたかを判断し,破壊されていない場合に該キャッシュデータを出力する技術が知られている。
特開2005−122602号公報
例えば,ウェブなどのユーザ装置の外部にあるデータへの高速なアクセスを図るためには,ユーザ装置において,データをキャッシュしておくキャッシュ領域に記憶装置の領域の多くを割り当て,多くのデータを保存しておくことが望ましい。しかし,記憶装置の領域の多くをキャッシュ領域に割り当ててしまうと,他のプロセスが記憶装置のリソースを使えなくなるという問題がある。そのため,キャッシュ領域として割り当てできる記憶装置の領域は限られ,外部データへのアクセスの速度向上も限られてしまう。
一側面では,本発明は,データへのアクセス速度を向上させる技術を提供することを目的とする。
1態様では,開示するプログラムは,コンピュータを次のように機能させる。すなわち,前記プログラムは,前記プログラムがインストールされて実行されるコンピュータに,記憶装置にデータを格納し,記憶装置に格納されたデータの格納位置を,記憶部に記憶された管理情報に記録し,記憶装置に格納されたデータを削除し,削除されたデータの復元可能性を求め,取得が要求されたデータが削除されたデータである場合に,該削除されたデータの復元可能性の高さが所定以上であれば,管理情報から該削除されたデータの格納位置を取得し,記憶装置の該取得した格納位置からデータを取得する処理を実行させる。
1態様では,データへのアクセス速度が向上する。
本実施の形態によるデータ管理の技術を利用する対象のシステムの例を示す図である。 キャッシュデータの管理の例を説明する図である。 本実施の形態1によるユーザ装置が備えるデータ管理部の構成例を示す。 本実施の形態によるデータ管理部を備えるユーザ装置のハードウェア構成例を示す図である。 本実施の形態1によるファイル管理テーブルの例を示す図である。 本実施の形態によるストレージログ管理テーブルの例を示す図である。 本実施の形態によるデータ管理を説明する図である。 ストレージの使用領域の時間変化の例を示す図である。 本実施の形態のデータ管理部によるタイマ処理フローチャートである。 本実施の形態1のデータ管理部によるキャッシュ制御処理フローチャートである。 本実施の形態1のデータ管理部によるデータ取得処理フローチャートである。 本実施の形態1のデータ管理部による外部データ取得処理フローチャートである。 本実施の形態1のデータ管理部によるキャッシュデータ取得処理フローチャートである。 本実施の形態1のデータ管理部によるデータ復元処理フローチャートである。 本実施の形態2によるキャッシュデータのチャンク化について説明する図である。 本実施の形態2によるユーザ装置が備えるデータ管理部の構成例を示す。 本実施の形態2によるファイル管理テーブルの例を示す図である。 本実施の形態2によるチャンク管理テーブルの例を示す図である。 本実施の形態2のデータ管理部によるキャッシュ制御処理フローチャートである。 本実施の形態2のデータ管理部によるチャンクデータ削除処理フローチャートである。 本実施の形態2のデータ管理部によるデータ取得処理フローチャートである。 本実施の形態2のデータ管理部によるチャンクデータ復元処理フローチャートである。 本実施の形態2のデータ管理部によるチャンクデータ復元処理フローチャートである。
以下,本実施の形態について,図を用いて説明する。
図1は,本実施の形態によるデータ管理の技術を利用する対象のシステムの例を示す図である。
図1に示すシステムにおいて,ユーザ装置10は,例えばPC(Personal Computer )やスマート端末などのユーザが操作するコンピュータである。ユーザ装置10は,ローカルのストレージ11を備える。ストレージ11は,例えばHDD(Hard Disk Drive )やSDD(Solid State Drive )などの記憶装置の一例である。図1に示す例において,ユーザ装置10は,操作するユーザの指示に従って,インターネットなどのネットワーク60を介したウェブ50上のコンテンツやリソースにアクセスする。
例えば,ユーザ装置10は,ウェブ50上のサーバ51にアクセスし,サーバ51のストレージ52にあるデータをダウンロードする。このとき,ユーザ装置10は,ローカルのストレージ11にダウンロードしたデータを一時保存しておく。このように,外部から取得したデータをローカルの記憶装置に一時保存する技術はキャッシュと呼ばれ,一時保存されるデータはキャッシュデータなどと呼ばれる。ユーザが同じデータの利用を再び要求した場合には,ユーザ装置10は,ウェブ50からデータを取得するのではなく,ローカルのストレージ11に格納されたキャッシュデータを取得する。このようなキャッシュの技術により,目的とするデータへのアクセス速度が向上し,データ取得の待ち時間を短くすることができる。
図2は,キャッシュデータの管理の例を説明する図である。
図2には,ストレージ11の全領域を使用領域と空き領域とに分けたイメージが示されている。図2に示すストレージ11のイメージにおいて,全領域は,データの格納が可能なすべての領域を示す。使用領域は,ファイルシステムの管理下で,すでに何らかのデータが格納されている領域を示す。空き領域は,ファイルシステムによるファイル管理下で,データが格納されていない未使用の領域を示す。図2に示すストレージ11のイメージにおいて,キャッシュ領域は,使用領域中で特にキャッシュデータが格納された領域を示す。
なお,図2に示すイメージでは,便宜上,使用領域,空き領域,キャッシュ領域がそれぞれ連続する領域で示されているが,実際のストレージ11上では,様々なデータの格納や削除が繰り返される状況で,各領域がばらばらに入り混じった状態となる。
データのキャッシュを行う場合に,キャッシュするデータの量を無制限とすると,ストレージ11のリソースを,蓄積されたキャッシュデータで消費してしまう可能性がある。そのため,空き領域の容量や全領域に対する割合などに応じてキャッシュ領域を制限したり,あらかじめ決められた容量にキャッシュ領域を制限するなどの制御が行われる。
キャッシュ領域を制限する制御を行う一例として,最近使用したデータを優先的にキャッシュし,長く使用していない古いキャッシュデータを削除する方法がある。例えば,図2の例に示すように,データa,データb,データcの3つのデータがキャッシュデータとしてストレージ11に格納されている状況で,データdがウェブ50からダウンロードされ,使用されたものとする。データdをキャッシュするとキャッシュ領域が制限を超えてしまう場合,最も長く使用していないデータaが削除され,最新のデータdがキャッシュデータとしてストレージ11に格納される。
このようなキャッシュの技術の運用において,ウェブ50から取得するデータへの高速なアクセスのためには,ストレージ11の領域の多くをキャッシュ領域として使用できるようにすることが望ましい。しかし,キャッシュ領域として多くの領域を使用してしまうと,他のプロセスが利用できる空き領域が少なくなってしまい,ストレージ11のリソースを有効に活用できないという問題が発生する。
以下では,ウェブ50から取得するデータへの高速なアクセスとストレージ11のリソースの有効活用を可能とする,本実施の形態によるデータ管理の技術の例を説明する。
なお,以下で説明する本実施の形態によるデータ管理の例は,ユーザ装置10でウェブ50上のオンラインストレージを利用する場合の例である。オンラインストレージは,ユーザが外部のストレージリソースを借りて利用できるようにしたサービスである。このサービスでは,例えば,ユーザは,自身が操作する複数のユーザ装置10から,ネットワーク60を介して自身が借りたストレージリソースにアクセスし,データの読み書きができる。例えば,図1に示すシステムにおいて,サーバ51は,オンラインストレージのサービスを提供するサーバである。サーバ51のストレージ52には,ユーザがユーザ装置10でダウンロードして利用可能なデータが保存されている。
〔実施の形態1〕
図3は,本実施の形態1によるユーザ装置が備えるデータ管理部の構成例を示す。
本実施の形態1のユーザ装置10は,図3に示すデータ管理部100を備える。図3に示すデータ管理部100は,オンラインストレージを利用するアプリケーションによって実現されるデータ管理を行う機能部の一例を示す。
ファイルシステム12は,ユーザ装置10のOS(Operating System)により提供される,ユーザ装置10のリソースを操作する機能である。データ管理部100は,ファイルシステム12を介して,ストレージ11へのデータの格納や,ストレージ11からのデータの取得などを行う。
データ管理部100は,インデックス取得部101,ストレージ監視部102,削除処理部103,格納位置記録部104,データ取得検出部105,データ取得判断部106,キャッシュデータ取得部107,外部データ取得部108,復元可能性算出部109,復元可能性判断部110,復元データ取得部111,データチェック部112,格納処理部113を備える。また,データ管理部100は,管理情報記憶部150,ストレージ情報記憶部160の記憶部を備える。
管理情報記憶部150は,データの管理情報を記憶する記憶部である。データの管理情報には,例えば,ストレージ11に格納されている状態,格納位置,サイズなど,管理対象のデータに関する様々な情報が記録されている。
ストレージ情報記憶部160は,ストレージログ情報を記憶する記憶部である。ストレージログ情報には,例えば,ストレージ11の全領域,使用領域,空き領域の量などの,ストレージ11に関する情報のログが記録されている。
インデックス取得部101は,ウェブ50上のサーバ51から,ユーザ装置10で利用できるデータのリスト情報であるインデックス情報を取得する。ここで取得されるインデックス情報には,例えば,ユーザ装置10で利用できるデータごとのファイル名,ファイルサイズ,データのチェックに使用するハッシュ値などの情報が含まれる。
ストレージ監視部102は,所定のタイミングでストレージ11の情報を取得する。ここで取得するストレージ11の情報は,例えば,ストレージ11の全領域,使用領域,空き領域の量などである。ストレージ監視部102は,得られたストレージ11の情報のログを,ストレージ情報記憶部160のストレージログ情報に記録する。
削除処理部103は,ストレージ11に格納されたデータを削除する。より具体的には,削除処理部103は,ストレージ11に格納されたキャッシュデータの削除をファイルシステム12に依頼する。削除処理部103によるデータの削除は,ファイルシステム12によるファイル管理上の削除であり,ストレージ11に格納されている物理的なデータの消去ではない。
格納位置記録部104は,ストレージ11に格納されたデータの格納位置を,管理情報記憶部150の管理情報に記録する。より具体的には,格納位置記録部104は,ストレージ11に格納されたキャッシュデータの物理的な格納位置の情報を,ファイルシステム12から取得し,管理情報記憶部150の管理情報に記録する。
データ取得検出部105は,データの取得要求を検出する。例えば,ユーザは,ユーザ装置10を操作し,ユーザ装置10で利用したいデータを指定する。このとき,データ取得検出部105は,ユーザに指定されたデータの取得要求を検出する。
データ取得判断部106は,管理情報記憶部150の管理情報を参照し,取得が要求されたデータをどのように取得するかを判断する。例えば,ユーザ装置10のローカルなストレージ11に取得が要求されたデータが存在しない場合,データ取得判断部106は,データを外部のウェブ50から取得すると判断する。また,例えば,取得が要求されたデータがユーザ装置10のローカルなストレージ11にキャッシュデータとして格納されている場合,データ取得判断部106は,そのキャッシュデータをストレージ11から取得すると判断する。また,例えば,取得が要求されたデータがユーザ装置10のローカルなストレージ11から削除されたデータである場合,データ取得判断部106は,ストレージ11の空き領域からのデータの復元を試みると判断する。
キャッシュデータ取得部107は,ストレージ11からキャッシュデータを取得する。外部データ取得部108は,ネットワークを介して,ユーザ装置10の外部からデータを取得する。本実施の形態1では,外部データ取得部108は,ウェブ50からデータを取得する。
復元可能性算出部109は,ストレージ11から削除されたデータの復元可能性を求める。ファイルシステム12によるファイル管理上のデータの削除では,ストレージ11に格納されている物理的なデータは消去されない。ただし,ファイルシステム12によるファイル管理上,データが削除された領域は空き領域となり,ファイルシステム12によって別のデータが書き込まれる可能性がある。そのため,削除されたデータがストレージ11上に復元可能な状態で存在するとは限らない。復元可能性算出部109は,削除されたデータを復元できる可能性を示す値を算出する。
復元可能性判断部110は,取得が要求されたデータがストレージ11から削除されたデータである場合に,その削除されたデータの復元可能性の高さが所定以上であるかを判断する。データの復元可能性の高さが所定以上であれば,復元可能性判断部110は,ストレージ11からデータの復元を行うと判断する。データの復元可能性の高さが所定以上でなければ,復元可能性判断部110は,ユーザ装置10の外部からデータを取得すると判断する。
復元データ取得部111は,取得が要求されたデータがストレージ11から削除されたデータである場合に,その削除されたデータの復元可能性の高さが所定以上であれば,管理情報記憶部150の管理情報から,その削除されたデータの格納位置を取得する。復元データ取得部111は,ストレージ11上の該格納位置からデータを取得する。
データチェック部112は,取得されたデータの正常性をチェックする。より具体的には,データチェック部112は,所定のハッシュ関数を用いて,取得されたデータのハッシュ値を算出する。データチェック部112は,算出されたハッシュ値と,管理情報記憶部150の管理情報に記録された該当データのハッシュ値とを比較する。管理情報記憶部150の管理情報には,あらかじめ正常なデータから算出されたハッシュ値が記録されている。データチェック部112は,双方のハッシュ値が一致する場合には,取得されたデータが正常であると判断し,双方のハッシュ値が一致しない場合には,取得されたデータが正常でないと判断する。
格納処理部113は,ユーザ装置10の外部から取得したデータや,ストレージ11から復元したデータを,ストレージ11に格納する。格納されたデータがキャッシュデータとなる。
図4は,本実施の形態によるデータ管理部を備えるユーザ装置のハードウェア構成例を示す図である。
データ管理部100を実現するユーザ装置10のコンピュータ1は,例えば,CPU(Central Processing Unit )2,主記憶となるメモリ3,記憶装置4,通信装置5,媒体読取・書込装置6,入力装置7,出力装置8等を備える。記憶装置4は,例えばHDD,SSD等の外部記憶装置や補助記憶装置などである。媒体読取・書込装置6は,例えばCD−R(Compact Disc Recordable )ドライブやDVD−R(Digital Versatile Disc Recordable )ドライブなどである。入力装置7は,例えばキーボード・マウス等の入力機器などである。出力装置8は,例えばディスプレイ等の表示装置などである。
図3に示すデータ管理部100およびデータ管理部100が備える各機能部は,コンピュータ1が備えるCPU2,メモリ3等のハードウェアと,ソフトウェアプログラムとによって実現することが可能である。コンピュータ1が実行可能なプログラムは,記憶装置4に記憶され,その実行時にメモリ3に読み出され,CPU2により実行される。
コンピュータ1は,可搬型記録媒体から直接プログラムを読み取り,そのプログラムに従った処理を実行することもできる。また,コンピュータ1は,サーバコンピュータからプログラムが転送されるごとに,逐次,受け取ったプログラムに従った処理を実行することもできる。さらに,このプログラムは,コンピュータ1で読み取り可能な記録媒体に記録しておくことができる。
図5は,本実施の形態1によるファイル管理テーブルの例を示す図である。
図5に示すファイル管理テーブル151は,管理情報記憶部150に記憶された管理情報の一例を示す。ファイル管理テーブル151は,管理対象のデータごとに,ファイルID,ファイル名,キャッシュフラグ,ΔS,ΔS+ ,ファイルサイズ,削除日時,アクセス日時,ハッシュ値,物理アドレス等の情報を持つ。
ファイルIDは,データを一意に識別する識別情報である。ファイル名は,データのファイルに付けられた名称である。キャッシュフラグは,データのキャッシュ状況を示す。キャッシュフラグ“0”は,ウェブ50からのデータ取得が行われておらず,データがストレージ11にキャッシュされていない状況を示す。キャッシュフラグ“1”は,データがウェブ50から取得され,ストレージ11にキャッシュされている状況を示す。キャッシュフラグ“2”は,データがストレージ11に一度キャッシュされた後で,ファイル管理上の削除が行われた状況を示す。
ΔSは,データがストレージ11から削除されたときから最後にストレージ11の情報が取得されたときまでのストレージ11の使用領域の変化量を示す。ΔS+ は,データがストレージ11から削除されたときから最後にストレージ11の情報が取得されたときまでの使用領域の正の変化量の和を示す。ファイルサイズは,データのサイズを示す。削除日時は,データがストレージ11から削除されている場合,その削除された日時を示す。アクセス日時は,データにアクセスした最新の日時を示す。ハッシュ値は,データが正常な状態であるときに所定のハッシュ関数を用いて算出されたハッシュ値である。物理アドレスは,ストレージ11上のデータの物理的な格納位置を示す。
図6は,本実施の形態によるストレージログ管理テーブルの例を示す図である。
図6に示すストレージログ管理テーブル161は,ストレージ情報記憶部160に記憶されたストレージログ情報の一例を示す。ストレージログ管理テーブル161は,ストレージ11から情報を取得したタイミングごとに,ストレージログ管理ID,全領域,使用領域,空き領域,日時等の情報を持つ。
ストレージログ管理IDは,ストレージ11から取得した情報のログを一意に識別する識別情報である。全領域は,ストレージ11の全領域の量を示す。使用領域は,ストレージ11の使用領域の量を示す。空き領域は,ストレージ11の空き領域の量を示す。日時は,ストレージ11の情報を取得した日時を示す。
図7は,本実施の形態によるデータ管理を説明する図である。
本実施の形態において,ウェブ50から取得されたデータは,キャッシュデータとしてストレージ11に格納される。このとき,新たなデータのキャッシュによりキャッシュ領域が制限を超えてしまう場合,図2で説明した例と同様に,キャッシュデータの削除が行われる。ここで行われるキャッシュデータの削除は,ファイルシステム12によるファイル管理上の削除であり,削除されたキャッシュデータの実データは,ファイル管理上の空き領域に残った状態となる。
一般に,ファイルシステム12は,データのファイルとストレージ11上の物理的な格納位置との対応を管理している。例えば,アプリケーションからファイルを指定したデータの読み込みが要求されると,ファイルシステム12は,指定されたファイルに対応するストレージ11上の格納位置からデータを読み出し,アプリケーションに渡す。アプリケーションからファイルを指定したデータ削除が要求されると,ファイルシステム12は,指定されたファイルとストレージ11上の物理的な格納位置との対応を解消する。これにより,削除されたデータの格納領域はファイル管理上の空き領域となるが,ストレージ11上の物理的な格納位置には,ファイル管理上では削除されたデータが実データとして存在する状態となる。
すなわち,ファイル管理上では削除されたデータのストレージ11上の物理的な格納位置が分かれば,その格納位置からバイナリデータを取得して,削除されたデータを復元することが可能である。本実施の形態では,削除されたキャッシュデータのストレージ11上の物理的な格納位置をファイル管理テーブル151で管理し,削除されたキャッシュデータを復元可能な状況にしておく。
例えば,図7に示す例において,当初は,データa,データb,データcの3つのデータが,キャッシュデータとしてストレージ11に格納されていたものとする。その後,ウェブ50からデータd,データe,データfが順に取得され,キャッシュデータとしてストレージ11に格納されるにつれて,古いキャッシュデータであるデータa,データb,データcがストレージ11から削除される。このとき,データa,データb,データcは,ファイルシステム12によるファイル管理上では削除されたことになっているが,図7の破線枠に示すように,ストレージ11の空き領域に実データが残っている状態となる。本実施の形態では,図7に示すように,ファイル管理上の空き領域に存在するデータa,データb,データcの格納位置をファイル管理テーブル151で管理しておくことで,データの復元をできるようにしておく。
このように,本実施の形態のデータ管理では,擬似的にキャッシュ領域を増やすことができるため,ウェブ50から取得するデータへのアクセスの高速化が図れ,同時に他のプロセスでも利用可能な空き領域が確保されるため,ストレージ11のリソースを有効活用できる。
ただし,削除されたキャッシュデータの格納領域はファイル管理上の空き領域とされているため,その空き領域に残っているデータは,その後にユーザ装置10で発生する別のファイルの書き込み処理により,破壊されてしまう可能性がある。そのため,取得が要求されたデータが削除されたキャッシュデータであるときに,その格納位置からバイナリデータを取得しても,そのバイナリデータから元の正しいデータを復元できない場合もある。この場合,ユーザ装置10は,要求されたデータのウェブ50からの取得を,あらためて行うことになる。
このように,まずストレージ11の空き領域からのデータの取得を行い,そのデータが破壊されていたときにはあらためてウェブ50からデータの取得を行うという場合のデータ取得の平均レイテンシTL は,例えば次の式(1)で表すことができる。
L =P・Tv+(1−P)・(Tv+Tw) ・・・(1)
式(1)において,Pは,ストレージ11の空き領域上でのデータの生存率を示す。本実施の形態の例では,削除されたキャッシュデータの復元可能性を示す値の例として,ストレージ11の空き領域上での該データの生存確率,すなわち該データがストレージ11の空き領域上で破壊されていない確率を示す,生存率P(0≦P≦1)を用いるものとする。また,式(1)において,Tvは,ストレージ11の空き領域からデータを取得する際の待ち時間を示す。Twは,ウェブ50からデータを取得する際の待ち時間を示す。
Tvについては,例えば,実際にストレージ11の空き領域からデータを取得した際に掛かった時間のデータを集めて,統計的に見込み時間を求めることができる。また,Twについては,例えば,実際にウェブ50からデータを取得した際に掛かった時間のデータを集めて,統計的に見込み時間を求めることができる。
また,本実施の形態によるデータ管理部100の運用中でも,随時,ストレージ11の空き領域からのデータ取得やウェブ50からのデータ取得が行われるので,そのときに時間の計測を行って計測時間のデータを蓄積し,統計的にTv,Twを求めることもできる。データ管理部100の運用によって求められるTv,Twは,データ管理部100の運用環境に応じた適切な値となる。
ここで,ストレージ11の空き領域からデータを取得することでデータ取得の高速化を図るためには,平均レイテンシTL が,ウェブ50からデータを取得する際の待ち時間Twを下回る必要がある。平均レイテンシTL がウェブ50からデータを取得する際の待ち時間Twを下回る条件の式TL ≦Twと,上記の式(1)とから,次の式(2)が得られる。
P≧Tv/Tw ・・・(2)
式(2)は,ストレージ11の空き領域からデータを取得することでデータ取得の高速化を図るために,生存率Pが満たすべき条件を示している。すなわち,生存率Pが式(2)の条件を満たす場合,ストレージ11の空き領域からデータを取得することによるデータ取得の高速化の効果が期待できる。
例えば,Tv/Twの値を閾値Pthとして,データの生存率Pとの比較判定を行うことで,ストレージ11の空き領域からデータを取得することを試みた方が効率がよいのか,最初からウェブ50からデータを取得した方が効率がよいのかを判断できる。なお,閾値Pthとしては,必ずしもTv/Twの値を用いる必要はなく,例えば,Tv/Twにある係数を掛けた値を用いる,経験的に適切と考えられる値を用いるなどの,任意の設計が可能である。
次に,生存率Pの算出の一例を説明する。ここでは,時刻t0に削除されたデータの,任意時刻Tにおける生存率Pを求めるものとする。このとき,生存率Pは,例えば次の式(3)で求められる。
P=k・(1−FSIZE/SFt0 )((1−ΔS/SFt0 )/ΔS+ ) ・・・(3)
式(3)において,kは係数である。FSIZEは,データのファイルサイズを示す。SFt0は,データが削除された時刻t0 におけるストレージ11の空き領域の量を示す。ΔSは,データが削除された時刻t0 から任意時刻Tまでのストレージ11の使用領域の変化量を示す。ΔS+ は,データが削除された時刻t0 から任意時刻Tまでのストレージ11の使用領域の正の変化量の和を示す。
式(3)では,FSIZEの値が大きいほど,すなわちデータのファイルサイズが大きいほど,生存率Pが低くなる。これは,ストレージ11の空き領域上に残された削除データのサイズが大きいほど,他のデータの書き込みが削除データの領域に重なってしまうことで,削除データが破壊される可能性が高いという状況を反映したものである。
式(3)では,SFt0 の値が大きいほど,すなわちデータが削除された時刻t0 におけるストレージ11の空き領域の量が多いほど,生存率Pが高くなる。これは,ストレージ11の空き領域の量が多いほど,他のデータの書き込みが削除データの領域に重なる可能性が低く,削除データが破壊される可能性が低いという状況を反映したものである。
図8は,ストレージの使用領域の時間変化の例を示す図である。
図8に示すように,データが削除された時刻t0におけるストレージ11の使用領域の量と,任意時刻Tにおけるストレージ11の使用領域の量との差が,ΔSとなる。式(3)では,ΔSの値が大きいほど,すなわちデータ削除後のストレージ11の使用領域の変化量が大きいほど,生存率Pが低くなる。これは,データを削除した後のストレージ11の使用領域の変化量が大きいほど,空き領域上に残された削除データが破壊されている可能性が高いという状況を反映したものである。
図8に示すグラフにおいて,ストレージ11の使用領域は,時刻t0 から時刻t1 では正の変化すなわち増加しており,時刻t1 から時刻t2 では負の変化すなわち減少しており,時刻t2 から時刻Tでは正の変化をしている。このとき,ΔS+ は,時刻t0 から時刻t1 までのストレージ11の使用領域の変化量と,時刻t2 から時刻Tまでのストレージ11の使用領域の変化量との和となる。式(3)では,ΔS+ の値が大きいほど,すなわちデータ削除後のストレージ11の使用領域の正の変化量の和が大きいほど,生存率Pが低くなる。これは,データを削除した後のストレージ11の使用領域の正の変化量が大きいほど,多くの量のデータの書き込みが行われており,空き領域上に残された削除データが破壊されている可能性が高いという状況を反映したものである。なお,ストレージ11の使用領域の負の変化は,ストレージ11から多くの量のデータが削除されている状況を示している。データの削除では,空き領域上に残された削除データは破壊されない。
係数kについては,例えば,実験的にまたは本実施の形態によるデータ管理部100の運用によって,FSIZE,ΔS,ΔS+ ,SFt0 等の各特徴量の値と,実際に空き領域上の削除データが破壊されていたか否かの結果との関係を示すデータを集め,統計的に求めることができる。
なお,削除されたデータの復元可能性を求める式が,必ずしも式(3)の削除されたデータの生存率Pを求める式である必要はない。例えば,FSIZE,ΔS,ΔS+ ,SFt0 等の特徴量のいずれか1つを用いて削除されたデータの復元可能性を求めるようにしてもよいし,他の特徴量を用いて削除されたデータの復元可能性を求めるようにしてもよい。
以下,図9〜図14のフローチャートを用いて,本実施の形態1のデータ管理部100による処理の流れの一例を説明する。
図9は,本実施の形態のデータ管理部によるタイマ処理フローチャートである。
図9に示すフローチャートの処理は,本実施の形態によるデータ管理において,定期的に実行される処理となる。
データ管理部100において,インデックス取得部101は,ウェブ50からインデックス情報を取得する(ステップS10)。ここで取得されるインデックス情報には,該当ユーザのオンラインストレージで保管されており,該当ユーザのユーザ装置10で利用可能なデータのリスト情報となる。
インデックス取得部101は,取得したインデックス情報の内容で,ファイル管理テーブル151を更新する(ステップS11)。例えば,ファイル管理テーブル151にないデータの情報がインデックス情報にある場合,インデックス取得部101は,ファイル管理テーブル151に新たなデータのレコードを追加する。また,例えば,ファイル管理テーブル151にあるデータの情報がインデックス情報にない場合,インデックス取得部101は,ファイル管理テーブル151から該当データのレコードを削除する。また,例えば,インデックス情報でファイルサイズやハッシュ値などの情報が更新されたデータがある場合,インデックス取得部101は,該当データの情報を更新する。
ストレージ監視部102は,ストレージ11の使用領域や空き領域などの情報を取得する(ステップS12)。ストレージ監視部102は,ストレージログ管理テーブル161に,取得したストレージ11の情報のログを記録する(ステップS13)。
ストレージ監視部102は,前回のログから今回のログまでのストレージ11の使用領域の変化量を算出する(ステップS14)。ストレージ監視部102は,算出された使用領域の変化量を用いて,ファイル管理テーブル151のキャッシュフラグが“2”である各データのΔS,ΔS+ を更新する(ステップS15)。ΔSについては,算出された使用領域の変化量がもとのΔSに加えられる。ΔS+ については,算出された使用領域の変化量が正の値である場合にのみ,算出された使用領域の変化量がもとのΔS+ に加えられる。
データ管理部100は,キャッシュ制御処理を行う(ステップS16)。キャッシュ制御処理では,定められたキャッシュ領域の制限に応じて,ストレージ11に格納されたキャッシュデータの削除が行われる。キャッシュ制御処理の詳細については,後述する。
図10は,本実施の形態1のデータ管理部によるキャッシュ制御処理フローチャートである。
データ管理部100において,削除処理部103は,ストレージログ管理テーブル161の最新のログを参照し,ストレージ11の空き領域が,ストレージ11の全領域の1割を下回っているかを判定する(ステップS20)。ここでは,ストレージ11の空き領域がストレージ11の全領域の1割以上となるように,キャッシュ領域のサイズが制御されるものとする。ストレージ11の空き領域が全領域の1割を下回っていなければ(ステップS20のNO),データ管理部100は,処理を終了する。
ストレージ11の空き領域が全領域の1割を下回っていれば(ステップS20のYES),削除処理部103は,ファイル管理テーブル151を参照し,キャッシュデータがあるかを判定する(ステップS21)。ファイル管理テーブル151において,キャッシュフラグが“1”のデータが,キャッシュデータである。キャッシュデータがなければ(ステップS21のNO),データ管理部100は,処理を終了する。
キャッシュデータがあれば(ステップS21のYES),削除処理部103は,削除対象のキャッシュデータを1つ選択する(ステップS22)。例えば,削除処理部103は,ファイル管理テーブル151を参照し,アクセス時刻が最も古いキャッシュデータを削除対象のキャッシュデータとする。
格納位置記録部104は,選択したキャッシュデータの物理アドレスを,ファイルシステム12から取得する(ステップS23)。例えば,OSには,データの物理アドレスを取得するAPI(Application Programming Interface )が用意されている。格納位置記録部104は,取得した物理アドレスを,ファイル管理テーブル151の,選択したキャッシュデータのレコードに記録する(ステップS24)。
削除処理部103は,ファイルシステム12に依頼し,選択したキャッシュデータを削除する(ステップS25)。削除処理部103は,ファイル管理テーブル151を更新する(ステップS26)。ここでは,削除したキャッシュデータについて,ファイル管理テーブル151のキャッシュフラグを“2”にする,削除日時を記録するなどの更新を行う。データ管理部100は,ステップS20の処理に戻る。キャッシュデータがなくなるか,キャッシュ領域の制限が満たされるまでキャッシュ制御処理が繰り返される。
図11は,本実施の形態1のデータ管理部によるデータ取得処理フローチャートである。
データ管理部100において,データ取得検出部105は,データの取得要求を検出する(ステップS30)。例えば,データ取得検出部105は,ユーザ装置10へのユーザの操作指定によるデータの取得要求を検出する。データ取得判断部106は,ファイル管理テーブル151を参照し,取得が要求されたデータのキャッシュフラグを判定する(ステップS31)。
キャッシュフラグが“0”である場合(ステップS31の“0”),データ管理部100は,外部データ取得処理を実行する(ステップS32)。外部データ取得処理は,ユーザ装置10の外部,ここではウェブ50から,ネットワーク60を介してデータを取得する処理である。外部データ取得処理の詳細については,後述する。
キャッシュフラグが“1”である場合(ステップS31の“1”),データ管理部100は,キャッシュデータ取得処理を実行する(ステップS33)。キャッシュデータ取得処理は,ストレージ11に格納されたキャッシュデータを取得する処理である。キャッシュデータ取得処理の詳細については,後述する。
キャッシュフラグが“2”である場合(ステップS31の“2”),データ管理部100は,復元データ取得処理を実行する(ステップS34)。復元データ取得処理は,削除されたキャッシュデータをストレージ11の空き領域から取得する処理である。復元データ取得処理の詳細については,後述する。
図12は,本実施の形態1のデータ管理部による外部データ取得処理フローチャートである。
データ管理部100において,外部データ取得部108は,取得が要求されたデータをウェブ50から取得する(ステップS40)。データチェック部112は,所定の関数を用いて,取得したデータのハッシュ値を算出する(ステップS41)。データチェック部112は,算出したハッシュ値が,ファイル管理テーブル151の該当データのハッシュ値と一致するかを判定する(ステップS42)。
ハッシュ値が一致しない場合(ステップS42のNO),データ管理部100は,ステップS40の処理に戻って再度データの取得を行う。なお,所定回数データの取得を行ってもハッシュ値が一致しない場合,例えば,その旨を示す警告をユーザに提示する。
ハッシュ値が一致する場合(ステップS42のYES),格納処理部113は,取得したデータをストレージ11に格納する(ステップS43)。格納処理部113は,ファイル管理テーブル151を更新する(ステップS44)。ここでは,格納処理部113は,ファイル管理テーブル151における該当データのキャッシュフラグを“1”に更新する。また,格納処理部113は,ファイル管理テーブル151における該当データのアクセス日時を更新する。
図13は,本実施の形態1のデータ管理部によるキャッシュデータ取得処理フローチャートである。
データ管理部100において,キャッシュデータ取得部107は,ストレージ11に格納されている,取得が要求されたデータのキャッシュデータを取得する(ステップS50)。データチェック部112は,所定の関数を用いて,取得したキャッシュデータのハッシュ値を算出する(ステップS51)。データチェック部112は,算出したハッシュ値が,ファイル管理テーブル151の該当データのハッシュ値と一致するかを判定する(ステップS52)。
ハッシュ値が一致しない場合(ステップS52のNO),データ管理部100は,外部データ取得処理を実行する(ステップS53)。外部データ取得処理は,例えば図12の例に示す通りである。キャッシュデータから算出されたハッシュ値がファイル管理テーブル151のハッシュ値と一致しない場合は,例えばキャッシュデータが壊れている場合や,オンラインストレージ上の該当データが更新されている場合などが考えられる。
ハッシュ値が一致する場合(ステップS52のYES),キャッシュデータ取得部107は,ファイル管理テーブル151を更新する(ステップS54)。ここでは,キャッシュデータ取得部107は,ファイル管理テーブル151における該当データのアクセス日時を更新する。
図14は,本実施の形態1のデータ管理部によるデータ復元処理フローチャートである。
データ管理部100において,復元可能性算出部109は,取得が要求されたデータの生存率Pを算出する(ステップS60)。例えば,復元可能性算出部109は,ファイル管理テーブル151やストレージログ管理テーブル161を参照し,上記の式(3)を用いて,生存率Pを算出する。
復元可能性判断部110は,生存率Pが所定の閾値Pth以上であるかを判定する(ステップS61)。生存率Pが所定の閾値Pth以上でない場合(ステップS61のNO),復元可能性判断部110は,該当データがストレージ11の空き領域上で破壊されている可能性が高いと判断する。外部データ取得部108は,外部データ取得処理を実行する(ステップS68)。外部データ取得処理は,例えば図12の例に示す通りである。
生存率Pが所定の閾値Pth以上である場合(ステップS61のYES),復元データ取得部111は,ファイル管理テーブル151から,取得が要求されたデータの物理アドレスを取得する(ステップS62)。復元データ取得部111は,ストレージ11の取得した物理アドレスにアクセスし,バイナリのデータを取得する(ステップS63)。例えば,OSには,物理アドレスを指定してデータ取得するAPIが用意されている。ここで取得するデータのサイズは,ファイル管理テーブル151の該当データのファイルサイズである。
データチェック部112は,所定の関数を用いて,取得したデータのハッシュ値を算出する(ステップS64)。データチェック部112は,算出したハッシュ値が,ファイル管理テーブル151の該当データのハッシュ値と一致するかを判定する(ステップS65)。
ハッシュ値が一致しない場合(ステップS65のNO),データ管理部100は,外部データ取得処理を実行する(ステップS68)。ここで取得されたデータから算出されたハッシュ値がファイル管理テーブル151のハッシュ値と一致しない場合には,例えば,ファイルの書き込みなどにより,データが壊れてしまった可能性が考えられる。外部データ取得処理は,例えば図12の例に示す通りである。
ハッシュ値が一致する場合(ステップS65のYES),格納処理部113は,取得したデータをストレージ11に格納する(ステップS66)。格納処理部113は,ファイル管理テーブル151を更新する(ステップS67)。ここでは,格納処理部113は,ファイル管理テーブル151における該当データのキャッシュフラグを“1”に更新する。また,格納処理部113は,ファイル管理テーブル151における該当データのアクセス日時を更新する。
以上説明した本実施の形態1によるデータ管理の技術では,擬似的にキャッシュ領域を増やすことができるため,ウェブ50から取得するデータへのアクセスの高速化が図れる。さらに,本実施の形態1によるデータ管理の技術では,同時に他のプロセスでも利用可能な空き領域が確保されるため,ストレージ11のリソースを有効活用できる。また,本実施の形態1によるデータ管理の技術では,ストレージ11の空き領域からのデータの復元を実行する前に,該データの復元可能性の高さを判断するので,データ取得のレイテンシが向上する。
〔実施の形態2〕
本実施の形態2によるデータ管理の処理では,前述の実施の形態1によるデータ管理の処理に加えて,削除するキャッシュデータを複数の部分データに分割して管理する処理が行われる。以下では,本実施の形態2によるデータ管理の技術について,主に前述の実施の形態1によるデータ管理の技術と異なる部分を中心に説明を行う。
図15は,本実施の形態2によるキャッシュデータのチャンク化について説明する図である。
ストレージ11の空き領域に残っている削除データは,その一部でも破壊されれば,データの復元が困難となる。そのため,ファイルサイズが大きいキャッシュデータが削除されて,ストレージ11の空き領域に残っている場合,そのデータは,サイズが大きい分だけ,他のファイルの書き込み処理によって部分的にデータが破壊される可能性が高くなってしまう。
このような問題に対処するために,本実施の形態2では,図15に示すように,キャッシュデータに対して,データ複数の部分データに分割するチャンク化を行う。本実施の形態2の例では,チャンク化によってキャッシュデータを分割することにより得られる部分データを,チャンクデータと呼ぶ。
本実施の形態2では,キャッシュデータから生成されたチャンクデータをストレージ11に格納する。ストレージ11に格納されたチャンクデータは,個々に削除され,ストレージ11の空き領域にバラバラのデータとして残る。そのため,他のファイルの書き込みによって一部のチャンクデータが破壊されても,破壊されなかったチャンクデータは復元可能な状態でストレージ11の空き領域に残る。この場合,破壊されなかったチャンクデータに対応するデータのみを,ウェブ50等の外部から取得し,残りは削除されたチャンクデータの復元と,削除されずにストレージ11に格納されたチャンクデータの取得とで,キャッシュデータを復元できる。このような本実施の形態2によるデータ管理の技術によって,目的とするデータへのアクセス速度を向上させることが可能となる。
図16は,本実施の形態2によるユーザ装置が備えるデータ管理部の構成例を示す。
本実施の形態2のユーザ装置10は,図16に示すデータ管理部200を備える。データ管理部200は,インデックス取得部201,ストレージ監視部202,削除処理部203,格納位置記録部204,データ取得検出部205,データ取得判断部206,キャッシュデータ取得部207,外部データ取得部208,復元可能性算出部209,復元可能性判断部210,復元データ取得部211,データチェック部212,格納処理部213,分割部214,結合部215を備える。また,データ管理部200は,管理情報記憶部250,ストレージ情報記憶部260の記憶部を備える。
管理情報記憶部250は,データの管理情報を記憶する記憶部である。本実施の形態2によるデータの管理情報には,前述の実施の形態1によるデータの管理情報に記録される情報に加えて,チャンクデータがストレージに格納されている状態,サイズなどのチャンク化されたデータに関する様々な情報が記録されている。
ストレージ情報記憶部260,インデックス取得部201,ストレージ監視部202については,前述の実施の形態1と同様であるので説明を省略する。
分割部214は,データを複数の部分データに分割する。より具体的には,分割部214は,ストレージ11に格納されるキャッシュデータを,複数のチャンクデータに分割する。分割部214は,得られたチャンクデータをストレージ11に格納する。また,分割部214は,所定のハッシュ関数を用いて,得られた各チャンクデータのハッシュ値を算出する。算出されたハッシュ値は,例えば,チャンクデータの管理情報で管理される。
削除処理部203は,ストレージ11に格納されたデータを削除する。より具体的には,削除処理部203は,ストレージ11に格納されたキャッシュデータの削除や,ストレージに格納されたチャンクデータの削除をファイルシステム12に依頼する。削除処理部203によるデータの削除は,ファイルシステム12によるファイル管理上の削除であり,ストレージ11に格納されている物理的なデータの消去ではない。
格納位置記録部204は,ストレージ11に格納されたデータの格納位置を,管理情報記憶部250の管理情報に記録する。より具体的には,格納位置記録部204は,ストレージ11に格納されたキャッシュデータやチャンクデータの物理的な格納位置の情報を,ファイルシステム12から取得し,管理情報記憶部250の管理情報に記録する。
データ取得検出部205については,前述の実施の形態1と同様であるので,説明を省略する。
データ取得判断部206は,管理情報記憶部250の管理情報を参照し,取得が要求されたデータをどのように取得するかを判断する。例えば,ユーザ装置10のローカルなストレージ11に取得が要求されたデータが存在しない場合,データ取得判断部206は,データを外部のウェブ50から取得すると判断する。また,例えば,取得が要求されたデータがユーザ装置10のローカルなストレージ11にキャッシュデータとして格納されている場合,データ取得判断部206は,そのキャッシュデータをストレージ11から取得すると判断する。また,例えば,取得が要求されたデータがユーザ装置10のローカルなストレージ11から削除されたデータであり,該データがチャンク化されていない場合,データ取得判断部206は,ストレージ11からのデータの復元を試みると判断する。また,例えば,取得が要求されたデータがユーザ装置10のローカルなストレージ11から削除されたデータであり,該データがチャンク化されている場合,データ取得判断部206は,チャンクデータごとにストレージ11からのデータの復元を試みると判断する。
キャッシュデータ取得部207,外部データ取得部208については,前述の実施の形態1と同様であるので,説明を省略する。
復元可能性算出部209は,ストレージ11から削除されたキャッシュデータや,チャンクデータの復元可能性を求める。
復元可能性判断部210は,取得が要求されたデータがストレージ11から削除されたキャッシュデータである場合に,その削除されたキャッシュデータの復元可能性の高さが所定以上であるかを判断する。また,復元可能性判断部210は,取得が要求されたデータがストレージ11から削除されたチャンクデータを含むデータである場合に,その削除されたチャンクデータの復元可能性の高さが所定以上であるかを判断する。データの復元可能性の高さが所定以上であれば,復元可能性判断部210は,ストレージ11からデータの復元を行うと判断する。データの復元可能性の高さが所定以上でなければ,復元可能性判断部210は,ユーザ装置10の外部からデータを取得すると判断する。
復元データ取得部211は,取得が要求されたデータがストレージ11から削除されたキャッシュデータである場合に,その削除されたキャッシュデータの復元可能性の高さが所定以上であれば,管理情報記憶部250の管理情報から,その削除されたキャッシュデータの格納位置を取得する。また,復元データ取得部211は,取得が要求されたデータがストレージ11から削除されたチャンクデータを含むデータである場合に,その削除されたチャンクデータの復元可能性の高さが所定以上であれば,管理情報記憶部250の管理情報から,その削除されたチャンクデータの格納位置を取得する。復元データ取得部211は,ストレージ11上の該格納位置からデータを取得する。
結合部215は,取得が要求されたデータを構成する複数のチャンクデータを結合する。
データチェック部212,格納処理部213については,前述の実施の形態1と同様であるので,説明を省略する。
図17は,本実施の形態2によるファイル管理テーブルの例を示す図である。
図17に示すファイル管理テーブル251は,管理情報記憶部250に記憶された第一の管理情報の一例を示す。ファイル管理テーブル251は,管理対象のデータごとに,ファイルID,ファイル名,キャッシュフラグ,チャンクフラグ,チャンク数,ΔS,ΔS+ ,ファイルサイズ,削除日時,アクセス日時,ハッシュ値,物理アドレス等の情報を持つ。
ファイルID,ファイル名,キャッシュフラグ,ΔS,ΔS+ ,ファイルサイズ,削除日時,アクセス日時,ハッシュ値,物理アドレスについては,図5に示す前述の実施の形態1によるファイル管理テーブル151と同様であるので,説明を省略する。チャンクフラグは,データがチャンク化されているかを示す。チャンクフラグ“0”は,データがチャンク化されていないことを示す。チャンクフラグ“1”は,データがチャンク化されていることを示す。チャンク数は,データがチャンク化されることで生成されたチャンクデータの数を示す。
図18は,本実施の形態2によるチャンク管理テーブルの例を示す図である。
図18に示すチャンク管理テーブル252は,管理情報記憶部250に記憶された第二の管理情報の一例を示す。チャンク管理テーブル252は,管理対象のデータごとに,チャンクID,ファイルID,チャンクキャッシュフラグ,ΔS,ΔS+ ,ファイルサイズ,削除日時,ハッシュ値,物理アドレス等の情報を持つ。
チャンクIDは,チャンクデータを一意に識別する識別情報である。ファイルIDは,チャンクデータが生成されるもととなったデータのファイルIDである。チャンクキャッシュフラグは,チャンクデータのキャッシュ状況を示す。チャンクキャッシュフラグ“1”は,チャンクデータがストレージ11にキャッシュされている状況を示す。チャンクキャッシュフラグ“2”は,チャンクデータがストレージ11に一度キャッシュされた後で,ファイル管理上の削除が行われた状況を示す。
ΔSは,チャンクデータがストレージ11から削除されたときから最後にストレージ11の情報が取得されたときまでのストレージ11の使用領域の変化量を示す。ΔS+ は,チャンクデータがストレージ11から削除されたときから最後にストレージ11の情報が取得されたときまでの使用領域の正の変化量の和を示す。ファイルサイズは,チャンクデータのサイズを示す。削除日時は,チャンクデータがストレージ11から削除されている場合,その削除された日時を示す。ハッシュ値は,削除が行われる前のチャンクデータに対して所定のハッシュ関数を用いて算出されたハッシュ値である。物理アドレスは,ストレージ11上のデータの物理的な格納位置を示す。
なお,ストレージ情報記憶部260に記憶されたストレージログ情報の一例は,前述の実施の形態1と同様に,例えば図6に示すストレージログ管理テーブル161となる。
以下,図19〜図23のフローチャートを用いて,本実施の形態2のデータ管理部200による処理の流れの一例を説明する。
タイマ処理のフローチャートは,前述の実施の形態1の図9に示すタイマ処理フローチャートと,ほぼ同様である。図9のステップS16に示すキャッシュ制御処理の詳細が異なる。
図19は,本実施の形態2のデータ管理部によるキャッシュ制御処理フローチャートである。
データ管理部200において,削除処理部203は,ストレージログ管理テーブル161の最新のログを参照し,ストレージ11の空き領域が,ストレージ11の全領域の1割を下回っているかを判定する(ステップS70)。ストレージ11の空き領域が全領域の1割を下回っていなければ(ステップS70のNO),データ管理部200は,処理を終了する。
ストレージ11の空き領域が全領域の1割を下回っていれば(ステップS70のYES),削除処理部203は,チャンク管理テーブル252を参照し,未削除のチャンクデータがあるかを判定する(ステップS71)。チャンク管理テーブル252において,チャンクキャッシュフラグが“1”のデータが,未削除のチャンクデータである。未削除のチャンクデータがあれば(ステップS71のYES),データ管理部200は,チャンクデータ削除処理を行う(ステップS82)。チャンクデータ削除処理は,ファイル管理上,チャンクデータを削除する処理である。チャンクデータ削除処理の詳細については,後述する。
未削除のチャンクデータがなければ(ステップS71のNO),削除処理部203は,ファイル管理テーブル251を参照し,キャッシュデータがあるかを判定する(ステップS72)。ファイル管理テーブル251において,キャッシュフラグが“1”のデータが,キャッシュデータである。キャッシュデータがなければ(ステップS72のNO),データ管理部200は,処理を終了する。
キャッシュデータがあれば(ステップS72のYES),削除処理部203は,削除対象のキャッシュデータを1つ選択する(ステップS73)。例えば,削除処理部203は,ファイル管理テーブル251を参照し,アクセス時刻が最も古いキャッシュデータを削除対象のキャッシュデータとする。
分割部214は,ファイル管理テーブル251を参照し,選択されたキャッシュデータのファイルサイズが100[MByte]より大きいかを判定する(ステップS74)。ここの例では,ファイルサイズが100[MByte]を超える大きさのキャッシュファイルについてはチャンクを行い,ファイルサイズが100[MByte]以下のキャッシュファイルについてはチャンクを行わないものとする。
選択されたキャッシュデータのファイルサイズが100[MByte]より大きくなければ(ステップS74のNO),格納位置記録部204は,選択したキャッシュデータの物理アドレスを,ファイルシステム12から取得する(ステップS75)。格納位置記録部204は,取得した物理アドレスを,ファイル管理テーブル251の,選択したキャッシュデータのレコードに記録する(ステップS76)。削除処理部203は,ファイルシステム12に依頼し,選択したキャッシュデータを削除する(ステップS77)。削除処理部203は,ファイル管理テーブル251を更新する(ステップS78)。ここでは,削除したキャッシュデータについて,ファイル管理テーブル251のキャッシュフラグを“2”にする,削除日時を記録するなどの更新を行う。データ管理部200は,ステップS70の処理に戻る。キャッシュデータやチャンクがなくなるか,キャッシュ領域の制限が満たされるまでキャッシュ制御処理が繰り返される。
選択されたキャッシュデータのファイルサイズが100[MByte]より大きければ(ステップS74のYES),分割部214は,選択されたキャッシュデータから複数のチャンクデータを生成する(ステップS79)。例えば,キャッシュデータの先頭から100[MByte]ずつの大きさで,チャンクデータを生成していく。分割部214は,ファイルシステム12を介して,ストレージ11にチャンクデータを格納する(ステップS80)。このとき,分割部214は,所定のハッシュ関数を用いて各チャンクデータのハッシュ値を算出し,チャンク管理テーブル252に記録しておく。分割部214は,ファイル管理テーブル251を更新する(ステップS78)。ここでは,チャンク化したキャッシュデータについて,ファイル管理テーブル251のキャッシュフラグを“2”にする,チャンクフラグを“1”にする,チャンク数を記録するなどの更新を行う。データ管理部200は,チャンクデータ削除処理を実行し(ステップS82),ステップS70の処理に戻る。キャッシュデータやチャンクがなくなるか,キャッシュ領域の制限が満たされるまでキャッシュ制御処理が繰り返される。
図20は,本実施の形態2のデータ管理部によるチャンクデータ削除処理フローチャートである。
削除処理部203は,チャンク管理テーブル252を参照し,削除対象のチャンクデータを1つ選択する(ステップS90)。格納位置記録部204は,選択したチャンクデータの物理アドレスを,ファイルシステム12から取得する(ステップS91)。格納位置記録部204は,取得した物理アドレスを,チャンク管理テーブル252の,選択したチャンクデータのレコードに記録する(ステップS92)。
削除処理部203は,ファイルシステム12に依頼し,選択したチャンクデータを削除する(ステップS93)。削除処理部203は,チャンク管理テーブル252を更新する(ステップS94)。ここでは,削除したチャンクデータについて,チャンク管理テーブル252のチャンクキャッシュフラグを“2”にする,削除日時を記録するなどの更新を行う。
図21は,本実施の形態2のデータ管理部によるデータ取得処理フローチャートである。
データ管理部200において,データ取得検出部205は,データの取得要求を検出する(ステップS100)。例えば,データ取得検出部205は,ユーザ装置10へのユーザの操作指定によるデータの取得要求を検出する。データ取得判断部206は,ファイル管理テーブル251を参照し,取得が要求されたデータのキャッシュフラグを判定する(ステップS101)。
キャッシュフラグが“0”である場合(ステップS101の“0”),データ管理部200は,外部データ取得処理を実行する(ステップS102)。外部データ取得処理は,例えば,図12に示す前述の実施の形態1の外部データ取得処理と同様である。
キャッシュフラグが“1”である場合(ステップS101の“1”),データ管理部200は,キャッシュデータ取得処理を実行する(ステップS103)。キャッシュデータ取得処理は,例えば,図13に示す前述の実施の形態1のキャッシュデータ取得処理と同様である。
キャッシュフラグが“2”である場合(ステップS101の“2”),データ管理部200は,取得が要求されたデータのチャンクフラグが“1”であるかを判定する(ステップS104)。
取得が要求されたデータのチャンクフラグが“1”でなければ(ステップS104のNO),データ管理部200は,復元データ取得処理を実行する(ステップS105)。復元データ取得処理は,例えば,図14に示す前述の実施の形態1の復元データ取得処理と同様である。
取得が要求されたデータのチャンクフラグが“1”であれば(ステップS104のYES),データ管理部200は,チャンクデータ復元処理を実行する(ステップS106)。チャンクデータ復元処理は,チャンクデータからもとのデータを復元する処理である。チャンクデータ復元処理の詳細については,後述する。
図22,図23は,本実施の形態2のデータ管理部によるチャンクデータ復元処理フローチャートである。
データ管理部200は,チャンク管理テーブル252を参照し,取得が要求されたデータのチャンクデータを順に1つ選択する(ステップS110)。データ管理部200は,選択されたチャンクデータが,削除されたチャンクデータであるかを判定する(ステップS111)。
選択されたチャンクデータが削除されたチャンクデータでなければ(ステップS111のNO),データ管理部200は,選択されたチャンクデータを,ファイルシステム12を介してストレージ11から取得する(ステップS112)。データ管理部200は,ステップS120の処理に進む。
選択されたチャンクデータが削除されたチャンクデータであれば(ステップS111のYES),復元可能性算出部209は,選択されたチャンクデータの生存率Pを算出する(ステップS113)。例えば,復元可能性算出部209は,チャンク管理テーブル252やストレージログ管理テーブル161を参照し,上記の式(3)を用いて,生存率Pを算出する。
復元可能性判断部210は,生存率Pが所定の閾値Pth以上であるかを判定する(ステップS114)。生存率Pが所定の閾値Pth以上でない場合(ステップS114のNO),復元可能性判断部210は,該当チャンクデータがストレージ11の空き領域上で破壊されている可能性が高いと判断する。外部データ取得部208は,該当チャンクデータをウェブ50から取得する(ステップS119)。例えば,サイズが大きい映像などの分野で,要求された部分データをダウンロードするなどが行われている。データ管理部200は,ステップS120の処理に進む。
生存率Pが所定の閾値Pth以上である場合(ステップS114のYES),復元データ取得部211は,チャンク管理テーブル252から,選択されたチャンクデータの物理アドレスを取得する(ステップS115)。復元データ取得部211は,ストレージ11の取得した物理アドレスにアクセスし,バイナリのデータを取得する(ステップS116)。ここで取得するデータのサイズは,チャンク管理テーブル252の該当チャンクデータのファイルサイズである。
データチェック部212は,所定の関数を用いて,取得したデータのハッシュ値を算出する(ステップS117)。データチェック部212は,算出したハッシュ値が,チャンク管理テーブル252の該当チャンクデータのハッシュ値と一致するかを判定する(ステップS118)。
ハッシュ値が一致する場合(ステップS118のYES),データチェック部212は取得したデータが壊れていないと判断し,データ管理部200は,ステップS120の処理に進む。
ハッシュ値が一致しない場合(ステップS118のNO),外部データ取得部208は,該当チャンクデータをウェブ50から取得する(ステップS119)。ここで取得されたデータから算出されたハッシュ値がチャンク管理テーブル252のハッシュ値と一致しない場合は,例えば,ファイルの書き込みなどにより,データが壊れてしまった可能性が考えられる。
データ管理部200は,取得が要求されたデータを構成するすべてのチャンクデータについて処理が終了したかを判定する(ステップS120)。すべてのチャンクデータについてまだ処理が終了していなければ(ステップS120のNO),ステップS110の処理に戻り,次のチャンクデータの処理に移る。
すべてのチャンクデータについて処理が終了していれば(ステップS120のYES),結合部215は,取得されたチャンクデータを結合する(ステップS121)。結合部215は,チャンク管理テーブル252を更新する(ステップS122)。ここでは,結合部215は,チャンク管理テーブル252から,結合したチャンクデータのレコードを削除する。
データチェック部212は,所定の関数を用いて,結合されたデータのハッシュ値を算出する(ステップS123)。データチェック部212は,算出したハッシュ値が,ファイル管理テーブル251における,取得が要求されたデータのハッシュ値と一致するかを判定する(ステップS124)。
ハッシュ値が一致しない場合(ステップS124のNO),データ管理部200は,外部データ取得処理を実行する(ステップS125)。外部データ取得処理は,例えば図12の例に示す通りである。
ハッシュ値が一致する場合(ステップS124のYES),格納処理部213は,結合したデータをストレージ11に格納する(ステップS126)。格納処理部213は,ファイル管理テーブル251を更新する(ステップS127)。ここでは,格納処理部213は,ファイル管理テーブル251における該当データのキャッシュフラグを“1”に更新する。また,格納処理部213は,ファイル管理テーブル251における該当データのアクセス日時を更新する。
以上,本実施の形態について説明したが,本発明はその主旨の範囲において種々の変形が可能であることは当然である。
例えば,本実施の形態では,オンラインストレージを利用した場合のデータ管理の例を説明したが,これに限るものではない。例えば,ブラウザでインターネットのサイトを閲覧する場合などのインタネットキャッシュや,動画共有サービスでダウンロードしたデータの管理などにも,本実施の形態によるデータ管理の技術を適用可能である。
また,例えば,本実施の形態では,HDDやSSDのストレージ11を格納先としたデータ管理の例を説明したが,管理するデータの格納先がメモリ3であってもよい。
10 ユーザ装置
11 ストレージ
12 ファイルシステム
100,200 データ管理部
101,201 インデックス取得部
102,202 ストレージ監視部
103,203 削除処理部
104,204 格納位置記録部
105,205 データ取得検出部
106,206 データ取得判断部
107,207 キャッシュデータ取得部
108,208 外部データ取得部
109,209 復元可能性算出部
110,210 復元可能性判断部
111,211 復元データ取得部
112,212 データチェック部
113,213 格納処理部
214 分割部
215 結合部
150,250 管理情報記憶部
160,260 ストレージ情報記憶部
50 ウェブ
51 サーバ
52 ストレージ
60 ネットワーク

Claims (7)

  1. コンピュータに,
    記憶装置にデータを格納し,
    前記記憶装置に格納されたデータの格納位置を,記憶部に記憶された管理情報に記録し,
    前記記憶装置に格納されたデータを削除し,
    削除されたデータの復元可能性を求め,
    取得が要求されたデータが削除されたデータである場合に,該削除されたデータの復元可能性の高さが所定以上であれば,前記管理情報から該削除されたデータの格納位置を取得し,前記記憶装置の該取得した格納位置からデータを取得する
    処理を実行させるためのデータ管理プログラム。
  2. 前記コンピュータに,さらに,
    取得が要求されたデータが削除されたデータである場合に,該削除されたデータの復元可能性の高さが所定以下であれば,前記コンピュータの外部からネットワークを介してデータを取得する
    処理を実行させるための請求項1に記載のデータ管理プログラム。
  3. 前記コンピュータに,さらに,
    データを複数の部分データに分割し,
    部分データを前記記憶装置に格納し,
    前記記憶装置に格納された部分データの格納位置を,記憶部に記憶された管理情報に記録し,
    前記記憶装置に格納された部分データを削除し,
    削除された部分データの復元可能性を求め,
    取得が要求されたデータが削除された部分データを含むデータである場合に,該削除された部分データの復元可能性の高さが所定以上であれば,前記管理情報から該削除された部分データの格納位置を取得し,前記記憶装置の該取得した格納位置からデータを取得する
    処理を実行させるための請求項1または2に記載のデータ管理プログラム。
  4. 前記コンピュータに,さらに,
    取得が要求されたデータが削除された部分データを含むデータである場合に,該削除された部分データの復元可能性の高さが所定以下であれば,前記コンピュータの外部からネットワークを介してデータを取得する
    処理を実行させるための請求項3に記載のデータ管理プログラム。
  5. 前記復元可能性を求める処理では,データが削除されたときからの前記記憶装置の使用領域の変化量,データが削除されたときからの前記記憶装置の使用領域の正の変化量の和,削除されたデータのサイズ,または前記記憶装置の空き領域の量の少なくともいずれかを用いて,削除されたデータの復元可能性を求める
    ことを特徴とする請求項1から請求項4までのいずれかに記載のデータ管理プログラム。
  6. データの管理情報を記憶する管理情報記憶部と,
    記憶装置にデータを格納する格納処理部と,
    前記記憶装置に格納されたデータの格納位置を,前記管理情報に記録する格納位置記録部と,
    前記記憶装置に格納されたデータを削除する削除処理部と
    削除されたデータの復元可能性を求める復元可能性算出部と,
    取得が要求されたデータが削除されたデータである場合に,該削除されたデータの復元可能性の高さが所定以上であれば,前記管理情報から該削除されたデータの格納位置を取得し,前記記憶装置の該取得した格納位置からデータを取得する復元データ取得部とを備える
    ことを特徴とするデータ管理装置。
  7. コンピュータが,
    記憶装置にデータを格納し,
    前記記憶装置に格納されたデータの格納位置を,記憶部に記憶された管理情報に記録し,
    前記記憶装置に格納されたデータを削除し,
    削除されたデータの復元可能性を求め,
    取得が要求されたデータが削除されたデータである場合に,該削除されたデータの復元可能性の高さが所定以上であれば,前記管理情報から該削除されたデータの格納位置を取得し,前記記憶装置の該取得した格納位置からデータを取得する処理を実行する
    ことを特徴とするデータ管理方法。
JP2013079291A 2013-04-05 2013-04-05 データ管理プログラム,データ管理装置およびデータ管理方法 Expired - Fee Related JP6107341B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013079291A JP6107341B2 (ja) 2013-04-05 2013-04-05 データ管理プログラム,データ管理装置およびデータ管理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013079291A JP6107341B2 (ja) 2013-04-05 2013-04-05 データ管理プログラム,データ管理装置およびデータ管理方法

Publications (2)

Publication Number Publication Date
JP2014203280A true JP2014203280A (ja) 2014-10-27
JP6107341B2 JP6107341B2 (ja) 2017-04-05

Family

ID=52353667

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013079291A Expired - Fee Related JP6107341B2 (ja) 2013-04-05 2013-04-05 データ管理プログラム,データ管理装置およびデータ管理方法

Country Status (1)

Country Link
JP (1) JP6107341B2 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018526700A (ja) * 2015-09-14 2018-09-13 グーグル エルエルシー コンテンツの記憶および取得用のシステムおよび方法
JP7132590B2 (ja) 2017-03-31 2022-09-07 株式会社新興製作所 読書履歴記録システム

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011160386A (ja) * 2010-02-04 2011-08-18 Panasonic Corp 画像ファイル処理装置、方法、及びプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011160386A (ja) * 2010-02-04 2011-08-18 Panasonic Corp 画像ファイル処理装置、方法、及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
JPN6017002509; 池田 利夫: '2010秋 イチ押し! フリーソフト厳選番付37本' 日経PC21 第15巻,第15号, 20100824, pp.32-35, 日経BP社 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018526700A (ja) * 2015-09-14 2018-09-13 グーグル エルエルシー コンテンツの記憶および取得用のシステムおよび方法
US10887371B2 (en) 2015-09-14 2021-01-05 Google Llc Systems and methods for content storage and retrieval
US11930070B2 (en) 2015-09-14 2024-03-12 Google Llc Systems and methods for content storage and retrieval
JP7132590B2 (ja) 2017-03-31 2022-09-07 株式会社新興製作所 読書履歴記録システム

Also Published As

Publication number Publication date
JP6107341B2 (ja) 2017-04-05

Similar Documents

Publication Publication Date Title
US9996542B2 (en) Cache management in a computerized system
US8706679B2 (en) Co-operative locking between multiple independent owners of data space
US8521986B2 (en) Allocating storage memory based on future file size or use estimates
JP6870246B2 (ja) ストレージ装置、及びストレージ制御装置
KR101717644B1 (ko) 고체-상태 저장 디바이스 상에서 데이터를 캐싱하는 장치, 시스템, 및 방법
US9772949B2 (en) Apparatus, system and method for providing a persistent level-two cache
US7594085B1 (en) Reclaiming data space
US8533158B1 (en) Reclaiming data space by rewriting metadata
US20100077173A1 (en) Linear space allocation mechanisms in data space
GB2518158A (en) Method and system for data access in a storage infrastructure
CN103999058A (zh) 带驱动器系统服务器
US20120265924A1 (en) Elastic data techniques for managing cache storage using ram and flash-based memory
US10489074B1 (en) Access rate prediction in a hybrid storage device
CN113835616A (zh) 应用的数据管理方法、系统和计算机设备
US8862639B1 (en) Locking allocated data space
CN105915595B (zh) 一种集群存储系统存取数据的方法以及集群存储系统
JP6107341B2 (ja) データ管理プログラム,データ管理装置およびデータ管理方法
KR20100115057A (ko) 낸드 플래시 파일 시스템
US20110264848A1 (en) Data recording device
KR101643278B1 (ko) 데이터베이스 시스템에서 스토리지 서버 관리 방법, 장치 및 컴퓨터 판독가능 매체에 저장된 컴퓨터-프로그램
JP6928247B2 (ja) ストレージ制御装置およびストレージ制御プログラム
CN111352590A (zh) 文件存储方法及设备
JP6805501B2 (ja) ストレージ装置
JP6668785B2 (ja) 情報処理システム、記憶制御装置、記憶制御方法および記憶制御プログラム
JP2021076969A (ja) 情報処理装置および情報処理プログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160113

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161101

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20161031

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20161222

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170207

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170220

R150 Certificate of patent or registration of utility model

Ref document number: 6107341

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees