(57)【要約】【課題】データ移動の際のユーザービリティ低下を抑制しつつ、データ移動のパフォーマンスを向上させる。【解決手段】データの処理に係る実行可否を制御する制御手段と、前記制御手段による制御に応じて前記データを移動させる移動手段と、前記移動手段による前記データの移動に係る状態情報を管理する管理手段と、前記制御手段により処理が許可されているデータに対する処理を前記データの移動元で実行するか、又は前記データの移動先で実行するかを、前記管理手段により管理されている前記状態情報に基づいて切り替える切り替え手段と、を有し、前記移動手段は、前記制御手段により処理が許可されていないデータを一括で移動させる一括移動手段と、前記制御手段により処理が許可されているデータを分割して移動させる分割移動手段と、を有することによって課題を解決する。【選択図】図９
2015138334.tif 000002
【特許請求の範囲】
【請求項１】
データの処理に係る実行可否を制御する制御手段と、
前記制御手段による制御に応じて前記データを移動させる移動手段と、
前記移動手段による前記データの移動に係る状態情報を管理する管理手段と、
前記制御手段により処理が許可されているデータに対する処理を前記データの移動元で実行するか、又は前記データの移動先で実行するかを、前記管理手段により管理されている前記状態情報に基づいて切り替える切り替え手段と、
を有し、
前記移動手段は、
前記制御手段により処理が許可されていないデータを一括で移動させる一括移動手段と、
前記制御手段により処理が許可されているデータを分割して移動させる分割移動手段と、
を有するサーバー装置。
【請求項２】
前記分割移動手段は、前記制御手段により処理が許可されているデータを、予め定められた量ずつに分割して移動させる請求項１記載のサーバー装置。
【請求項３】
ネットワークを介して通信可能な情報処理装置からのリクエストに対するデータへのアクセスに係る履歴を解析してアクセス間隔を求める第１の解析手段を更に有し、
前記分割移動手段は、前記制御手段により処理が許可されているデータを、前記第１の解析手段により求められた前記データに対するアクセス間隔内で移動が終わる量ずつに分割して移動させる請求項１記載のサーバー装置。
【請求項４】
前記制御手段は、データの時刻情報が示す時刻が予め定められた処理可能期間に含まれる場合、前記データの処理を許可し、前記時刻が前記処理可能期間に含まれない場合、前記データの処理を許可しないようにデータの処理に係る実行可否を制御する請求項１乃至３何れか１項記載のサーバー装置。
【請求項５】
ネットワークを介して通信可能な情報処理装置からのリクエストに対するデータへのアクセスと処理とに係る履歴を解析して前記データの処理可能期間を求める第２の解析手段を更に有し、
前記制御手段は、データの時刻情報が示す時刻が前記第２の解析手段により求められた処理可能期間に含まれる場合、前記データの処理を許可し、前記時刻が前記処理可能期間に含まれない場合、前記データの処理を許可しないようにデータの処理に係る実行可否を制御する請求項１乃至３何れか１項記載のサーバー装置。
【請求項６】
前記管理手段は、データの移動に係る状態が、移動済み、移動中、未移動の何れであるかを示す前記状態情報を管理し、
前記切り替え手段は、前記処理が許可されているデータの前記状態情報が移動済みを示している場合、前記データの処理に係る実行先を前記データの移動先に切り替え、前記データの前記状態情報が移動中又は未移動の何れかを示している場合、前記実行先を前記データの移動元に切り替える請求項１乃至５何れか１項記載のサーバー装置。
【請求項７】
ネットワークを介して通信可能な情報処理装置からデータの処理に関する要求を受信する受信手段と、
前記切り替え手段により切り替えられた前記データの処理に係る実行先において、前記受信手段により受信された前記要求に応じた処理を実行する実行手段と、
を更に有する請求項１乃至６何れか１項記載のサーバー装置。
【請求項８】
前記移動手段は、前記制御手段による制御に応じて、ネットワークを介して通信可能な記憶装置に記憶されているデータを、ネットワークを介して通信可能な他の記憶装置へ移動させる請求項１乃至７何れか１項記載のサーバー装置。
【請求項９】
第１のサーバー装置と、第２のサーバー装置とを含むデータ管理システムであって、
前記第１のサーバー装置は、
データの処理に係る実行可否を制御する制御手段と、
前記制御手段により処理が許可されているデータに対する処理を前記データの移動元で実行するか、又は前記データの移動先で実行するかを、前記データの移動に係る状態情報に基づいて切り替える切り替え手段と、
を有し、
前記第２のサーバー装置は、
前記制御手段による制御に応じてデータを移動させる移動手段と、
前記移動手段による前記データの移動に係る状態情報を管理する管理手段と、
を有し、
前記移動手段は、
前記制御手段により処理が許可されていないデータを一括で移動させる一括移動手段と、
前記制御手段により処理が許可されているデータを分割して移動させる分割移動手段と、
を有するデータ管理システム。
【請求項１０】
サーバー装置が実行するデータ管理方法であって、
データの処理に係る実行可否を制御する制御ステップと、
前記制御ステップによる制御に応じて前記データを移動させる移動ステップと、
前記移動ステップによる前記データの移動に係る状態情報を管理する管理ステップと、
前記制御ステップにより処理が許可されているデータに対する処理を前記データの移動元で実行するか、又は前記データの移動先で実行するかを、前記管理ステップにより管理されている前記状態情報に基づいて切り替える切り替えステップと、
を含み、
前記移動ステップは、
前記制御ステップにより処理が許可されていないデータを一括で移動させる一括移動ステップと、
前記制御ステップにより処理が許可されているデータを分割して移動させる分割移動ステップと、
を含むデータ管理方法。
【請求項１１】
第１のサーバー装置と、第２のサーバー装置とを含むデータ管理システムにおけるデータ管理方法であって、
前記第１のサーバー装置が、データの処理に係る実行可否を制御する制御ステップと、
前記第２のサーバー装置が、前記制御ステップによる制御に応じて前記データを移動させる移動ステップと、
前記第２のサーバー装置が、前記移動ステップによる前記データの移動に係る状態情報を管理する管理ステップと、
前記第１のサーバー装置が、前記制御ステップにより処理が許可されているデータに対する処理を前記データの移動元で実行するか、又は前記データの移動先で実行するかを、前記管理ステップにより管理されている前記状態情報に基づいて切り替える切り替えステップと、
を含み、
前記移動ステップは、
前記制御ステップにより処理が許可されていないデータを一括で移動させる一括移動ステップと、
前記制御ステップにより処理が許可されているデータを分割して移動させる分割移動ステップと、
を含むデータ管理方法。
【請求項１２】
コンピュータに、
データの処理に係る実行可否を制御する制御ステップと、
前記制御ステップによる制御に応じて前記データを移動させる移動ステップと、
前記移動ステップによる前記データの移動に係る状態情報を管理する管理ステップと、
前記制御ステップにより処理が許可されているデータに対する処理を前記データの移動元で実行するか、又は前記データの移動先で実行するかを、前記管理ステップにより管理されている前記状態情報に基づいて切り替える切り替えステップと、
を実行させ、
前記移動ステップは、
前記制御ステップにより処理が許可されていないデータを一括で移動させる一括移動ステップと、
前記制御ステップにより処理が許可されているデータを分割して移動させる分割移動ステップと、
を含むプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバー装置、データ管理システム、データ管理方法及びプログラムに関する。
【背景技術】
【０００２】
一般的に、データベースシステムにおいては、１つのデータベースシステムに格納可能なデータ量が制限されることが多い。これは、パフォーマンスの低下を防ぐためや、データベースシステムのバックアップにかかる時間を制限するためである。１つのデータベースシステムに格納されるデータ量が想定以上に増加し、上述の制限値を超えてデータが格納されるような場合には、データ量が制限値を超えるデータベースシステムに格納されたデータの一部を、他のデータベースシステムに移動させることが必要となる。また、一般的に、移動中のデータに対して参照更新要求があった場合には、その要求が拒絶されることが多いが、これはユーザービリティの低下につながる。
特許文献１に記載の技術は、移動済みのファイルに対する参照更新要求があった場合には、移動先のデータに対して処理を行い、未移動のファイルに対する参照更新要求があった場合には、移動元のデータに対して処理を行う。このようにすることで、この技術は、データが移動中であったとしても、そのデータに対して操作を行うことができるようになり、ユーザービリティを向上させることができる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平７−１１４４４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
特許文献１に記載の技術は、全ての移動対象のデータに対して更新が可能である。この技術をデータベースシステムに適応させた場合、レコード（データベースの行）を、予め定められた一定量ずつ移動させることが必要となる。これは、大量のレコードを一度に移動させている最中に、その移動中のレコードに対して更新処理が実施された場合に、それらのレコードを再移動させる必要があるためである。しかしながら、データベースシステムにおいて、予め定められた一定量ずつレコードを移動させた場合、一括で大量に移動させる場合と比べ、移動に関するパフォーマンスが低下する。このように、データ移動の際のユーザービリティと、データ移動のパフォーマンスとの両立が困難であるという問題がある。
本発明は、データ移動の際のユーザービリティ低下を抑制しつつ、データ移動のパフォーマンスを向上させることを目的とする。
【課題を解決するための手段】
【０００５】
そこで、本発明のサーバー装置は、データの処理に係る実行可否を制御する制御手段と、前記制御手段による制御に応じて前記データを移動させる移動手段と、前記移動手段による前記データの移動に係る状態情報を管理する管理手段と、前記制御手段により処理が許可されているデータに対する処理を前記データの移動元で実行するか、又は前記データの移動先で実行するかを、前記管理手段により管理されている前記状態情報に基づいて切り替える切り替え手段と、を有し、前記移動手段は、前記制御手段により処理が許可されていないデータを一括で移動させる一括移動手段と、前記制御手段により処理が許可されているデータを分割して移動させる分割移動手段と、を有する。
【発明の効果】
【０００６】
本発明によれば、データ移動の際のユーザービリティ低下を抑制しつつ、データ移動のパフォーマンスを向上させることができる。
【図面の簡単な説明】
【０００７】
【図１】システム構成の一例を示す図である。
【図２】ハードウェア構成の一例を示す図である。
【図３】機能構成等の一例を示す図である。
【図４】データ量管理テーブルの一例を示す図である。
【図５】データベース管理テーブルの一例を示す図である。
【図６】データステータス管理テーブルの一例を示す図である。
【図７】テナント管理テーブルの一例を示す図である。
【図８】リクエスト処理の一例を示すフローチャートである。
【図９】実施形態１の書き込み制御処理の一例を示すフローチャートである。
【図１０】読み込み制御処理の一例を示すフローチャートである。
【図１１】実施形態１のデータ移動処理の一例を示すフローチャートである。
【図１２】実施形態２のアクセス履歴管理テーブルの一例を示す図である。
【図１３】アクセス履歴解析結果テーブルの一例を示す図である。
【図１４】アクセス履歴解析処理の一例を示すフローチャートである。
【図１５】実施形態２のデータ移動処理の一例を示すフローチャートである。
【図１６】実施形態３のアクセス履歴管理テーブルの一例を示す図である。
【図１７】書き込み可能期間管理テーブルの一例を示す図である。
【図１８】書き込み可能期間解析処理の一例を示すフローチャートである。
【図１９】実施形態３の書き込み制御処理の一例を示すフローチャートである。
【発明を実施するための形態】
【０００８】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
＜実施形態１＞
図１は、本実施形態のシステム構成の一例を示す図である。
データ管理システム６は、Ｗｅｂサーバー装置（以下、Ｗｅｂサーバー）２、バッチサーバー装置（以下、バッチサーバー）３、複数のデータベースシステム４、５を含む。ここでいうデータベースシステム４、５は、記憶装置の一例である。
クライアント（情報処理装置）１は、ネットワーク７を介してＷｅｂサーバー２に接続され、ブラウザや専用のアプリケーションを用いてＷｅｂサーバー２と通信する。
Ｗｅｂサーバー２には、ＨＴＴＰ、ＳＯＡＰ等のプロトコルに準拠したＷｅｂサービスがホストされている。このＷｅｂサービスは、クライアント１からのデータの書き込み／更新／取得に関するリクエスト（要求）を受付け、そのリクエストに対応したデータ処理（書き込み／更新／読み込み）を、データベースシステム４、５に対して実施する。また、このＷｅｂサービスは、その結果をクライアント１に送信することができる。
【０００９】
バッチサーバー３は、データの移動を実施するためのサーバーである。本実施形態では、Ｗｅｂサーバー２とバッチサーバー３とが別のサーバーとして表現されているが、これらは同一のサーバー内で動作するような構成であってもよい。
データ管理システム６は、１つ以上のデータベースシステム４、５を含む。複数のデータベースシステム４、５のうち、１つのデータベースシステム４には、データの移動制御や、データ量を管理するためのテーブルと、実データを管理するためのテーブルとが格納されている。その他のデータベースシステム５には、実データを管理するためのテーブルが格納されている。以後、データベースシステムが増えた場合においても、そのデータベースシステムには、データベースシステム５と同様に実データを管理するためのテーブルが存在することとなる。
【００１０】
図２は、Ｗｅｂサーバー２のハードウェア構成の一例を示す図である。
Ｗｅｂサーバー２は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１、直接記憶部２０２、間接記憶部２０３、及びネットワークインターフェース２０４を有する。
ＣＰＵ２０１は、Ｗｅｂサーバー２を制御するユニットである。ＣＰＵ２０１は、間接記憶部２０３に格納されているプログラムを実行することにより、Ｗｅｂサーバー２の機能及び後述するＷｅｂサーバー２のフローチャートに係る処理を実現する。なお、ＣＰＵ２０１は、マルチプロセッサでもよい。
直接記憶部２０２は、ＣＰＵ２０１がプログラムを実行する際に使用するワークメモリであり、ＣＰＵ２０１が実行するプログラムは直接記憶部２１２にロードされる。直接記憶部２０２は、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）により実現される。
【００１１】
間接記憶部２０３は、アプリケーションプログラム、及びＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）プログラムを含む各種のプログラムを格納している。また、間接記憶部２０３は、データ管理システム６で実行される処理に要する閾値等を含む各種の値に関するデータも予め格納している。間接記憶部２０３に格納されている各種プログラムは、ＣＰＵ２０１により直接記憶部２０２にロードされて実行される。間接記憶部２０３は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）、又はＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）により実現される。
ネットワークインターフェース２０４は、ネットワーク７に接続されており、ネットワーク７に接続されている他の装置と通信可能である。
なお、図１のデータ管理システム６に含まれるバッチサーバー３、複数のデータベースシステム４、５も同様のハードウェア構成をしている。
即ち、バッチサーバー３のＣＰＵ２０１は、バッチサーバー３の間接記憶部２０３に格納されているプログラムを実行することにより、バッチサーバー３の機能及び後述するバッチサーバー３のフローチャートに係る処理を実現する。
また、データベースシステム４、５のＣＰＵ２０１は、データベースシステム４、５の間接記憶部２０３に格納されているプログラムを実行することにより、データベースシステム４、５の機能を実現する。データベースシステム４、５の間接記憶部２０３には、データの管理に関する各種のテーブル等が格納されている。
【００１２】
図３は、図１のシステムにおける機能構成等の一例を示す図である。
まず、Ｗｅｂサーバー２の機能について説明する。
リクエスト受信部２１は、クライアント１からのリクエストを受け付ける。リクエスト受信部２１は、受け付けたリクエストが書き込み／更新に関するものであれば、リクエストに関するデータを書き込み制御部２２に渡す。また、リクエスト受信部２１は、リクエストが読み込みに関するものであれば、リクエストに関するデータをデータステータス取得部２３に渡す。
書き込み制御部２２には、予め書き込み可能期間（処理可能期間）が設定されている。書き込み可能期間とは、データの書き込み／更新を行うことができる期間を意味する。例えば、現在が１月３１日で、書き込み可能期間が３０日だとした場合には、Ｗｅｂサーバー２は、１月１日以前のデータに対する更新を行うことができず、また、１月１日以前の時刻情報を持つデータをデータベースへ書き込むことができない。書き込み制御部２２は、書き込み／更新対象のデータの時刻と、書き込み可能期間とを比較し、書き込み／更新処理の実行可否、即ち、書き込み／更新処理を許可するか否かを判断する。なお、上記の時刻情報は、対象のデータに含まれていてもよいし、対象のデータと関連付けられていてもよい。
【００１３】
データステータス取得部２３は、データステータス管理テーブル４５から、データの移動に関するステータス情報（状態情報）を取得し、取得したステータス情報を処理対象データベース切り替え部２４に渡す。
処理対象データベース切り替え部２４は、データステータス取得部２３が取得したステータス情報と、リクエストにおける処理対象のデータの期間情報とを基に、前記データの処理を行う対象のデータベースシステムを決定する。即ち、処理対象データベース切り替え部２４は、前記データの処理を前記データの移動元のデータベースシステムで実行するか、又は移動先のデータベースシステムで実行するかを決定し、前記データの実行先を決定したデータベースシステムに切り替える。
データ操作部２５は、処理対象データベース切り替え部２４から渡されたデータベース情報を基に、前記データベース情報が示すデータベースに接続し、リクエストに応じた処理を実行する。
レスポンス送信部２７は、書き込み制御部２２や、データ操作部２５の処理結果を、クライアント１に送信する。
【００１４】
次に、バッチサーバー３の機能について説明する。
まず、データ量取得／更新部３１は、データテーブル４１、５１に格納されているデータのデータ量を定期的に算出して取得し、その値をデータ量管理テーブル４３に書き込む。このとき、データ量取得／更新部３１は、データ量として、全データのデータ容量を求めるのではなく、ある単位毎にデータ量を求める。例えば図４のデータ量管理テーブル４３の場合、データ量取得／更新部３１は、単位をテナント（組織）とし、テナント毎に、そのテナントに紐づくデータのデータ量を算出している。本実施形態においては、データ量算出の単位、及び後述するデータ移動の単位をテナント（組織）としているが、単位はこれに限る必要はなく、例えばユーザー名等の他の単位を用いてもよい。
データ移動決定部３２は、データ量管理テーブル４３からデータ（データ量情報）を取得し、データ量がデータベースシステムに格納可能なデータ容量の制限値を超えているか否かを確認する。もし、データ量が制限値を超えていた場合には、データ移動決定部３２は、データの移動を決定する。このとき、データ移動決定部３２は、最もデータ量が少ないテナントのデータを移動対象のデータとして決定する。
【００１５】
接続情報取得部３３は、データ移動決定部３２からデータ移動開始の命令を受け、テナント管理テーブル４４、及びデータベース管理テーブル４２から、移動対象のテナントのデータが格納されているデータベースシステムへ接続するための接続情報を取得する。
データ一括移動部３４は、接続情報取得部３３から渡された接続情報を基に、データベースシステムに接続し、データテーブルにアクセスする。その後、データ一括移動部３４は、データ移動決定部３２が移動対象としたテナントのデータのうち、書き込み可能期間外の全データを移動先の他のデータベースシステムへ一括で移動させる（一括移動処理）。ここで、書き込み可能期間は、Ｗｅｂサーバー２の場合と同様に、バッチサーバー３の各機能に静的に予め定義されている。
分割データ移動部３５は、書き込み可能期間内のデータから、予め定義されたレコード数ずつ、データを移動させる（分割移動処理）。
データステータス更新部３６は、移動処理の前後で、データの移動状況等が管理されているデータステータス管理テーブル４５に格納されているデータを更新する。
接続情報更新部３７は、分割データ移動部３５からの移動完了の通知を受け、テナント管理テーブル４４の情報を更新する。
【００１６】
次に、データベースシステム４、５について説明する。
データベースシステム４は、データベース管理テーブル４２、データ量管理テーブル４３、テナント管理テーブル４４、データステータス管理テーブル４５、及び一つ以上のデータテーブル４１を格納している。
データベースシステム５は、一つ以上のデータテーブル５１を格納している。
データベースシステムが増えた場合には、それらのデータベースシステムは、データベースシステム５のように１つ以上のデータテーブルを格納する構成となる。それぞれのテーブルの詳細については後述する。
なお、図３のアクセス履歴記録部２８、アクセス履歴解析部３８、アクセス履歴管理テーブル４６、及びアクセス履歴解析結果テーブル４７については、後述の実施形態２で説明する。また、書き込み可能期間解析部３９、及び書き込み可能期間管理テーブル４８については、後述の実施形態３で説明する。
【００１７】
以下、上述の各種テーブルの詳細について説明する。
図４は、データ量管理テーブル４３の一例を示す図である。
データ量管理テーブル４３は、データを移動させる単位、本実施形態においてはテナント毎にデータ量を管理するためのテーブルである。データ量管理テーブル４３は、テナントＩＤ４１１、計測した日付４１２、データ量４１３、及びそのデータが管理されているデータベースシステムのＤＢ（ＤａｔａＢａｓｅ）ＩＤ４１４の４項目から構成される。例えば、レコード４０１の場合、テナントＩＤがｔ１となるデータは、２０１３／１／５時点で、１０００ＭＢｙｔｅの容量で、ＤＢＩＤが１となるデータベースシステム内に格納されていることになる。
図５は、データベース管理テーブル４２の一例を示す図である。
データベース管理テーブル４２は、各データベースシステムに割り振られたＤＢＩＤ３１１、及びそのデータベースシステムにアクセスするための接続情報（接続文字列）３１２を管理するためのテーブルである。
【００１８】
図６は、データステータス管理テーブル４５の一例を示す図である。
データステータス管理テーブル４５は、移動対象のテナントのデータの、移動中／移動済み／未移動といったステータスを管理するためのテーブルである。データステータス管理テーブル４５は、次の６つの項目から構成される。移動対象のテナントＩＤ５１１、移動中／移動済み／未移動を表すステータス５１３、ステータス５１３に該当するデータ期間５１２、移動元ＤＢＩＤ５１４、移動先ＤＢＩＤ５１５、及び再移動を実施するか否かの再移動フラグ５１６の６つの項目である。例えば、レコード５０１は、テナントＩＤがｔ１のテナントのデータのうち、２０１３／１／５  １３：００から２０１３／１／１４  １２：００までのデータは移動済みであることを表している。また、レコード５０２は、テナントＩＤがｔ１のテナントのデータのうち、２０１３／１／１４  １２：００から２０１３／２／１  ３：００までのデータは移動中であることを表している。更に、レコード５０３のデータは、テナントＩＤがｔ１のテナントのデータのうち、２０１３／２／１  ３：００以降のデータは未だ移動していないことを表している。ステータスが未移動のデータに関しては、データ期間５１２の範囲に開始時刻を表す時刻だけが記録され、それ以降の全てのデータが未移動であることを表す。
再移動フラグ５１６は、データの移動中にその期間のデータに対して書き込みや更新が行われた場合に、ｔｒｕｅに変更される。再移動フラグ５１６がｔｒｕｅとなっている場合には、その期間のデータを、再度、移動先のデータベースシステムに移動させる必要があることを表している。
【００１９】
図７は、テナント管理テーブル４４の一例を示す図である。
テナント管理テーブル４４は、データベースシステム内に格納されるテナントのＩＤ６１１、及びそのテナントのデータが格納されるデータベースシステムのＤＢＩＤ６１２を管理するためのテーブルである。テナント管理テーブル４４では、データを移動させる単位、本実施形態においてはテナント毎にデータが作成される。例えば、レコード６０１は、テナントＩＤがｔ１のデータは、ＤＢＩＤが１のデータベースシステムに格納されていることを表している。
データテーブル４１、５１について説明する。
データテーブル４１、５１は、データ管理システム６が実際に管理するデータを格納しておくためのテーブルである。例えば、オンラインショッピングシステムであれば、データテーブル４１、５１は、ユーザーの購買履歴であったり、商品リストであったりする。データテーブル４１、５１には、時刻に関するカラムが含まれている必要がある。上述した書き込み制御部２２は、このカラムに記録されている時刻と、現在時刻とを比較し、書き込み／更新処理の実行可否を決定する。データテーブル４１、５１は、この時刻に関するカラムが含まれていれば、その他のカラムについてはどのような仕様であってもよい。
【００２０】
次に、図８、９、１０を用いて、本実施形態におけるＷｅｂサーバー２がクライアント１からリクエストを受け付けた際の処理について説明する。また、図１１を用いて、バッチサーバー３によるデータの移動処理について説明する。
図８は、Ｗｅｂサーバー２のリクエスト処理の一例を示すフローチャートである。
Ｓ７０１では、リクエスト受信部２１は、クライアント１からのリクエストを受け付ける。
Ｓ７０２では、リクエスト受信部２１は、リクエスト内容が、データの書き込み／更新に関するものであるか、又はデータの読み込みに関するものであるかを判断する。リクエスト受信部２１は、リクエスト内容がデータの書き込み／更新に関するものであった場合、Ｓ７０３の書き込み制御処理に遷移する。Ｓ７０３の処理の詳細については、図９を用いて後述する。また、リクエスト受信部２１は、リクエスト内容がデータの読み込みに関するものであった場合、Ｓ７０４の読み込み制御処理に遷移する。Ｓ７０４の処理の詳細については、図１０を用いて後述する。
【００２１】
図９は、図８のＳ７０３における書き込み制御処理の一例を示すフローチャートである。
Ｓ８０１では、書き込み制御部２２は、書き込むデータに含まれる時刻情報が示す時刻、又は更新するデータに含まれる時刻情報が示す時刻と、書き込み可能期間とを比較する。以後、書き込むデータに含まれる時刻情報が示す時刻、及び更新するデータに含まれる時刻情報が示す時刻を"リクエスト時刻"と称する。上述したように、書き込み可能期間は、本システム内に静的に予め定められているものとする。書き込み制御部２２は、比較の結果、リクエスト時刻が書き込み可能期間内に含まれる場合は、Ｓ８０３に遷移し、書き込み可能期間内に含まれない場合は、Ｓ８０２に遷移する。
Ｓ８０２では、書き込み制御部２２は、書き込みを拒絶し、エラーが発生した旨をレスポンス送信部２７に通知する。
Ｓ８０３では、データステータス取得部２３は、データステータス管理テーブル４５からデータ（ステータス情報）を取得する。このとき、データステータス取得部２３は、クライアント１からのリクエストにて指定された書き込み／更新対象のデータのテナントＩＤと合致するテナントＩＤ５１１のデータを取得する。以後、上記の書き込み／更新対象のデータのテナントＩＤを"書き込みテナントＩＤ"と称する。データステータス取得部２３は、取得したデータが０件の場合は、Ｓ８１０に遷移し、取得したデータが１件以上存在する場合は、Ｓ８０４に遷移する。
【００２２】
Ｓ８０４では、処理対象データベース切り替え部２４は、リクエスト時刻とＳ８０３で取得されたデータとを基に、リクエスト時刻に該当する期間におけるデータの移動状況のステータス５１３を確認する。処理対象データベース切り替え部２４は、確認の結果、ステータス５１３が未移動を示している場合には、Ｓ８０５に遷移し、ステータス５１３がそれ以外、即ち、移動済み又は移動中を示している場合には、Ｓ８０６に遷移する。
Ｓ８０５では、データ操作部２５は、Ｓ８０３で取得されたデータに記載されている移動元ＤＢＩＤ５１４に基づいてデータベース管理テーブル４２から取得した接続文字列を用いてデータベースシステムにアクセスし、処理を実行する。データ操作部２５は、処理が完了すると、結果をレスポンス送信部２７に通知する。
Ｓ８０６では、処理対象データベース切り替え部２４は、リクエスト時刻とＳ８０３で取得されたデータとを基に、リクエスト時刻に該当する期間におけるデータの移動状況のステータス５１３を確認する。処理対象データベース切り替え部２４は、確認の結果、ステータス５１３が移動中を示している場合には、Ｓ８０７に遷移し、ステータス５１３が移動済みを示している場合には、Ｓ８０９に遷移する。
【００２３】
Ｓ８０７では、データ操作部２５は、Ｓ８０３で取得されたデータに記載されている移動元ＤＢＩＤ５１４に基づいてデータベース管理テーブル４２から取得した接続文字列を用いてデータベースシステムにアクセスし、処理を実行する。
Ｓ８０８では、データ操作部２５は、データステータス管理テーブル４５の再移動フラグ５１６をｔｒｕｅに設定する。
Ｓ８０９では、データ操作部２５は、Ｓ８０３で取得されたデータに記載されている移動先ＤＢＩＤ５１５に基づいてデータベース管理テーブル４２から取得した接続文字列を用いてデータベースシステムにアクセスし、処理を実行する。
Ｓ８１０では、処理対象データベース切り替え部２４は、書き込みテナントＩＤ５１１に基づいてテナント管理テーブル４４からＤＢＩＤ６１２を取得する。更に、処理対象データベース切り替え部２４は、前記取得したＤＢＩＤ６１２に基づいてデータベース管理テーブル４２から接続文字列を取得する。
Ｓ８１１では、データ操作部２５は、Ｓ８１０で取得された接続文字列を用いてデータベースシステムにアクセスし、クライアント１からのリクエスト内容に応じた処理を実行する。
Ｓ８１２では、レスポンス送信部２７は、処理結果をクライアント１に送信する。
【００２４】
図１０は、図８のＳ７０４における読み込み制御処理の一例を示すフローチャートである。
Ｓ９０１では、データステータス取得部２３は、データステータス管理テーブル４５からデータ（ステータス情報）を取得する。
Ｓ９０２では、データステータス取得部２３は、Ｓ９０１で取得したデータに含まれるテナントＩＤ５１１の中に、リクエストで指定された読み込み対象となるテナントＩＤが存在するか否かを確認する。以後、上記の読み込み対象となるテナントＩＤを"読み込みテナントＩＤ"と称する。データステータス取得部２３は、読み込みテナントＩＤが存在する場合には、Ｓ９０４に遷移し、存在しない場合には、Ｓ９０３に遷移する。
Ｓ９０３では、処理対象データベース切り替え部２４は、テナント管理テーブル４４から、読み込みテナントＩＤに等しいテナントＩＤ６１１に対応するＤＢＩＤ６１２を取得する。
Ｓ９０４では、処理対象データベース切り替え部２４は、Ｓ９０１で取得されたデータから、読み込みテナントＩＤと、取得対象のデータの期間とに基づいて検索したデータのステータス５１３を確認する。以後、取得対象のデータの期間を"読み込みリクエスト期間"と称する。処理対象データベース切り替え部２４は、確認の結果、ステータス５１３が移動済みを示していない場合は、Ｓ９０５に遷移し、ステータス５１３が移動済みを示している場合は、Ｓ９０６に遷移する。
【００２５】
Ｓ９０５では、処理対象データベース切り替え部２４は、Ｓ９０１で取得されたデータから、読み込みテナントＩＤと、取得対象のデータの期間とに基づいて検索したデータの移動元ＤＢＩＤ５１４を取得する。
Ｓ９０６では、処理対象データベース切り替え部２４は、Ｓ９０１で取得されたデータから、読み込みテナントＩＤと、取得対象のデータの期間とに基づいて検索したデータの移動先ＤＢＩＤ５１５を取得する。
Ｓ９０７では、処理対象データベース切り替え部２４は、Ｓ９０３、Ｓ９０５又はＳ９０６で取得したＤＢＩＤに基づいてデータベース管理テーブル４２から接続文字列を取得する。
Ｓ９０８では、データ操作部２５は、Ｓ９０７で取得された接続文字列を用いて、データベースシステムへアクセスし、クライアント１からのリクエストに応じたデータを取得し、結果をレスポンス送信部２７へ通知する。
Ｓ９０９では、レスポンス送信部２７は、データ操作部２５から渡された結果をクライアントに送信する。
【００２６】
以上、Ｗｅｂサーバー２は、図８、９、１０のフローチャートに係る処理を実行することで、書き込み可能期間外のデータへの書き込み／更新処理を禁止することが可能となる。また、Ｗｅｂサーバー２は、データの移動に関する状態を移動中／移動済み／未移動のステータスで管理し、それぞれのステータスに応じて処理対象のデータベースシステムを切り替えることで、データの再移動の発生を抑止することが可能となる。
【００２７】
次に、図１１を用いて、バッチサーバー３によるデータの移動処理について説明する。
図１１は、本実施形態におけるバッチサーバー３のデータ移動処理の一例を示すフローチャートである。
Ｓ１００１では、データ移動決定部３２は、データ量管理テーブル４３からＤＢＩＤ毎にデータ量の和を求める。
Ｓ１００２では、データ移動決定部３２は、Ｓ１００１で求めたデータ量の和が、予め定められたデータ量の上限値（閾値）を超えているか否かをチェックする。データ移動決定部３２は、データ量の和が上限値を超えているデータベースシステムが存在する場合には、Ｓ１００３に遷移し、存在しない場合には、処理を終了する。
Ｓ１００３では、データ移動決定部３２は、データ量の和が上限値を超えたＤＢＩＤを含むデータ量管理テーブル４３のレコードの中で、最もデータ量の少ないレコードのテナントＩＤを取得する。
Ｓ１００４では、接続情報取得部３３は、Ｓ１００３で取得されたテナントＩＤに基づいてテナント管理テーブル４４からＤＢＩＤを取得する。
Ｓ１００５では、接続情報取得部３３は、Ｓ１００４で取得したＤＢＩＤに基づいてデータベース管理テーブル４２から接続文字列を取得する。
【００２８】
Ｓ１００６では、データ一括移動部３４は、Ｓ１００５で取得された接続文字列を用いてデータベースシステムへアクセスし、Ｓ１００３で取得されたテナントＩＤを持つデータのうち、書き込み可能期間外のデータを一括で移動先のデータベースシステムへ移動させる。
Ｓ１００７では、データステータス更新部３６は、データステータス管理テーブル４５にデータを書き込む。このとき、データステータス更新部３６は、書き込むデータのテナントＩＤ５１１をＳ１００３で取得されたテナントＩＤとする。また、データステータス更新部３６は、書き込むデータ期間５１２を書き込み可能期間の中で未だ移動していないデータの中で最も過去の時刻とする。また、データステータス更新部３６は、ステータス５１３を未移動とする。また、データステータス更新部３６は、移動元ＤＢＩＤ５１４をＳ１００４で取得されたＤＢＩＤとし、移動先ＤＢＩＤ５１５をＳ１００１でデータ量の和が求められた際に最も少ないデータ量となったＤＢＩＤとする。更に、データステータス更新部３６は、再移動フラグをｆａｌｓｅとする。
Ｓ１００８では、分割データ移動部３５は、Ｓ１００７で書き込まれたデータ期間５１２以降の時刻を示す時刻情報を持つ予め定められた一定数のデータを、データベースシステムのデータテーブルから取得する。このとき、分割データ移動部３５が取得するデータ数は、静的に予め定められているものとする。
【００２９】
Ｓ１００９では、データステータス更新部３６は、Ｓ１００８で取得されたデータの時刻のうち、最も過去の時刻と最も新しい時刻とを求め、その範囲をデータステータス管理テーブル４５のデータ期間５１２に書き込む。このとき、データステータス更新部３６は、テナントＩＤ５１１をＳ１００３で取得されたテナントＩＤとし、ステータス５１３を移動中とする。
Ｓ１０１０では、データステータス更新部３６は、データステータス管理テーブル４５の中で、テナントＩＤ５１１がＳ１００３で取得されたテナントＩＤと等しく、ステータス５１３が未移動となっているレコードのデータ期間を、Ｓ１００９で求めた最も新しい時刻に変更する。
Ｓ１０１１では、分割データ移動部３５は、Ｓ１００８で取得したデータのうち、最も新しい時刻未満となる時刻情報を持つデータを、移動先のデータベースシステムに移動させる。ここで、最も新しい時刻未満の時刻情報を持つデータのみを移動させるのは、分割データ移動部３５が次のデータ移動時に最も新しい時刻のデータを移動させるためである。
【００３０】
Ｓ１０１２では、データステータス更新部３６は、データステータス管理テーブル４５の再移動フラグ５１６をチェックする。データステータス更新部３６は、再移動フラグ５１６がｔｒｕｅの場合、即ち、移動中にデータの格納、又は更新が行われた場合には、再移動を行うため、Ｓ１０１７に遷移する。また、データステータス更新部３６は、再移動フラグ５１６がｆａｌｓｅの場合には、Ｓ１０１３に遷移する。
Ｓ１０１３では、データステータス更新部３６は、Ｓ１００９で書き込んだデータのステータス５１３を移動済みに変更する。
Ｓ１０１４では、データステータス更新部３６は、データステータス管理テーブル４５を確認し、ステータス５１３が未移動のデータがあるか否かを確認する。データステータス更新部３６は、未移動のデータがない場合には、Ｓ１０１５に遷移し、未移動のデータが存在する場合には、Ｓ１００８に遷移する。
Ｓ１０１５では、接続情報更新部３７は、テナント管理テーブル４４のＤＢＩＤ６１２を、Ｓ１００７で設定された移動先ＤＢＩＤに更新する。
Ｓ１０１６では、接続情報更新部３７は、移動元のデータベースシステムのデータテーブルから移動対象の全データを削除し、図１１の処理を終了する。
Ｓ１０１７では、データステータス更新部３６は、再移動フラグ５１６をｆａｌｓｅに更新する。
【００３１】
以上、バッチサーバー３は、図１１のフローチャートに係る処理を実行することで、書き込み可能期間外のデータを一括で移動させることが可能となる。また、バッチサーバー３は、書き込み可能期間内のデータに関しては、移動中／移動済み／未移動のステータスを管理しながら、予め定められた一定量ずつデータを移動させることが可能となる。
【００３２】
以上、本実施形態におけるデータ管理システム６を実現することで、移動対象のデータの再移動の可能性を下げつつも、一部のデータに対しては一括での移動を可能とすることにより、データの移動パフォーマンスを向上させることが可能となる。
【００３３】
＜実施形態２＞
データの移動には、データベースシステムのＣＰＵやメモリといったリソースが利用されることになる。そのため、データの移動中に、そのデータに対してクライアントからのアクセスがあった場合、クライアントからのリクエストに対するデータ管理システムの処理パフォーマンスが低下するという問題がある。そこで、本実施形態では、データの移動中における処理パフォーマンス低下の影響をユーザーに感じさせないデータ管理システムを実現させるための構成及び処理について説明する。
以下、実施形態１と異なる点についてのみ説明する。
実施形態１と比べて本実施形態のデータ管理システムでは、Ｗｅｂサーバー２、及びバッチサーバー３に新たな機能が設けられていると共に、データベースシステム４に新たなテーブルが設けられている。
【００３４】
上述した図３を用いて、本実施形態で新たに設けた機能、及びテーブルについて説明する。
Ｗｅｂサーバー２には、新たな機能として、アクセス履歴記録部２８が設けられる。
アクセス履歴記録部２８は、リクエスト受信部２１がクライアント１からリクエストを受信した後に、そのリクエストの処理対象データのテナントＩＤと、そのリクエストタイミング（アクセス時間）とを、後述するアクセス履歴管理テーブル４６に記録する。
バッチサーバー３には、新たな機能として、アクセス履歴解析部３８が設けられる。
アクセス履歴解析部３８は、定期的に、後述するアクセス履歴管理テーブル４６に記録されたアクセス履歴を解析し、対象のデータにアクセスされるタイミング、及びアクセスされる頻度をテナント毎に求める。また、アクセス履歴解析部３８は、解析した結果を後述するアクセス履歴解析結果テーブル４７に書き込む。
データベースシステム４には、新たなテーブルとして、アクセス履歴管理テーブル４６、及びアクセス履歴解析結果テーブル４７が設けられる。両テーブルのスキーマ例については、以下で説明する。
【００３５】
図１２は、アクセス履歴管理テーブル４６の一例を示す図である。
アクセス履歴管理テーブル４６は、クライアント１２０１、対象テナントＩＤ１２０２、及びアクセス時間１２０３で構成される。
クライアント１２０１は、リクエストを発行したクライアントを識別するためのＩＤを表す。対象テナントＩＤ１２０２は、そのリクエストで操作される対象のテナントＩＤを表す。アクセス時間１２０３は、そのリクエストをリクエスト受信部２１が受信した時刻を表す。例えば、レコード１２１１は、クライアント１が、テナントＩＤがｔ１のデータに対して、２０１３年１月１日１０時にアクセスしてきたことを意味する。アクセス履歴記録部２８は、リクエスト受信部２１がクライアントからリクエストを受け付ける度に、これらの項目をアクセス履歴管理テーブル４６に書き込む。
【００３６】
図１３は、アクセス履歴解析結果テーブル４７の一例を示す図である。
アクセス履歴解析結果テーブル４７は、対象テナントＩＤ１３０１、アクセス間隔１３０２、及びアクセス開始タイミング１３０３で構成される。
対象テナントＩＤ１３０１は、図１２で説明した対象テナントＩＤ１２０２と同じであるため説明を省略する。アクセス間隔１３０２は、対象テナントＩＤ１３０１のデータに対してアクセスがある間隔を表している。アクセス開始タイミング１３０３は、アクセス間隔１３０２の開始タイミングを表している。例えば、レコード１３１１は、テナントＩＤがｔ１のデータに対して、毎月１日にアクセスがあることを示している。また、レコード１３１２は、テナントＩＤがｔ２のデータに対して、毎週月曜日にアクセスがあることを示している。
【００３７】
次に、図１４を用いて、本実施形態におけるバッチサーバー３によるアクセス履歴解析処理について説明する。
図１４は、本実施形態におけるバッチサーバー３によるアクセス履歴解析処理の一例を示すフローチャートである。
Ｓ１４０１では、アクセス履歴解析部３８は、アクセス履歴管理テーブル４６からデータ（アクセス履歴情報）を取得する。
Ｓ１４０２では、アクセス履歴解析部３８は、Ｓ１４０１で取得したデータを、対象テナント毎にグルーピングする。
Ｓ１４０３では、アクセス履歴解析部３８は、Ｓ１４０２でグルーピングしたあるグループを選択し、そのグループのデータ間のアクセス時間の差（アクセス間隔）を求める。
Ｓ１４０４では、アクセス履歴解析部３８は、Ｓ１４０３で求めた差の中で最も小さい値となったものを、月／週／日／時／分／秒の何れかにマップする。例えば、Ｓ１４０３で求めた差が１ヶ月１時間の場合には、アクセス履歴解析部３８は、月にマップする。また、Ｓ１４０３で求めた差が７日３時間の場合には、アクセス履歴解析部３８は、週にマップする。なお、ここではマップされる選択肢として、月／週／日／時／分／秒の６個としたが、年等、他の選択肢であってもよい。
【００３８】
Ｓ１４０５では、アクセス履歴解析部３８は、Ｓ１４０４で求めたアクセス間隔の開始タイミングを求める。このとき、アクセス履歴解析部３８が求める開始タイミングの粒度は、アクセス間隔が月、又は週であれば日とする。また、アクセス間隔が日であれば時、アクセス間隔が時であれば分、アクセス間隔が分であれば秒とする。例えば、図１２に示したレコード１２１１、１２１２の場合、アクセス間隔は月となるが、アクセス時間は毎月１日であることがわかるので、アクセス開始タイミングは１日となる。
Ｓ１４０６では、アクセス履歴解析部３８は、Ｓ１４０４、Ｓ１４０５で求めたアクセス間隔、及びアクセス開始タイミングをアクセス履歴解析結果テーブル４７に書き込む。
Ｓ１４０７では、アクセス履歴解析部３８は、Ｓ１４０２でグルーピングした全グループに対してＳ１４０３〜Ｓ１４０６の処理を行ったか否かを判断する。アクセス履歴解析部３８は、全てのグループに対して処理を行っていた場合は、図１４の処理を終える。一方、アクセス履歴解析部３８は、全てのグループに対して処理を行っていない場合には、Ｓ１４０３に遷移する。
以上、バッチサーバー３は、図１４のフローチャートに係る処理を実行することで、テナント毎に、アクセスされるタイミングを求めることが可能となる。
【００３９】
次に、図１５を用いて、本実施形態におけるバッチサーバー３によるデータ移動処理について説明する。
図１５は、本実施形態におけるバッチサーバー３によるデータ移動処理の一例を示すフローチャートである。
本フローチャートの処理について、図１１のフローチャートの処理と異なる点についてのみ説明する。
Ｓ１５０１では、分割データ移動部３５は、Ｓ１００３で取得されたテナントＩＤに基づいてアクセス履歴解析結果テーブル４７からデータ（アクセス履歴解析情報）を取得する。
Ｓ１５０２では、分割データ移動部３５は、Ｓ１５０１で取得したデータのアクセス間隔内で移動可能なデータ量を算出する。ここで、データの移動速度、及びデータ１件のデータ量は予め測定しておくものとする。例えば、データの移動速度が１ＧＢｙｔｅ／分、データ１件のデータ量が１ＭＢｙｔｅ、アクセス間隔が１時間であるとした場合、６０００件のデータが移動可能となる。
【００４０】
Ｓ１５０３では、分割データ移動部３５は、Ｓ１５０２で求めたデータ件数のデータを、移動元のデータベースシステムのデータテーブルから取得する。このとき、分割データ移動部３５は、データの取得条件に、データ件数だけではなく、上述したＳ１００８の処理と同様に、Ｓ１００７で書き込まれたデータ期間以降の時刻の時刻情報を持つデータ、という条件も含める。
Ｓ１５０４では、データステータス更新部３６は、データステータス管理テーブル４５の再移動フラグ５１６をチェックする。データステータス更新部３６は、再移動フラグ５１６がｔｒｕｅの場合、即ち、移動中にデータの格納、又は更新が行われた場合には、再移動を行うため、Ｓ１５０６に遷移する。また、データステータス更新部３６は、再移動フラグ５１６がｆａｌｓｅの場合には、Ｓ１０１３に遷移する。
【００４１】
Ｓ１５０５では、データステータス更新部３６は、データステータス管理テーブル４５を確認し、ステータス５１３が未移動のデータがあるか否かを確認する。データステータス更新部３６は、未移動のデータがない場合には、Ｓ１０１５に遷移し、未移動のデータが存在する場合には、Ｓ１５０７に遷移する。
Ｓ１５０６では、データステータス更新部３６は、再移動フラグ５１６をｆａｌｓｅに更新する。
Ｓ１５０７では、分割データ移動部３５は、Ｓ１５０１で求めたアクセス間隔、及びアクセス開始タイミングを基に、次回の移動タイミングまで処理を停止する。例えば、アクセス間隔が１時間、アクセス開始タイミングが０分だとした場合に、分割データ移動部３５は、Ｓ１０１１のデータの移動処理が３０分で終了した場合には、３０分間処理を停止する。
以上、バッチサーバー３は、図１５のフローチャートに係る処理を実行することで、クライアント１からのアクセスが無い時間帯でのデータ移動が可能となる。
【００４２】
以上、本実施形態におけるデータ管理システム６を実現することで、クライアント１からのアクセスが無い時間帯でのデータ移動が可能となり、データの移動中における処理パフォーマンス低下の影響をユーザーに感じさせずに済ませることが可能となる。
【００４３】
＜実施形態３＞
実施形態１、２では、書き込み可能期間は静的に予め定められているものとした。しかし、実際に更新される可能性がある書き込み可能期間は、クライアントや操作対象とするテナントによって異なることが多い。バッチサーバー３は、書き込み可能期間外のデータを一括で移動させることができるので、データ移動に関するパフォーマンスを向上させるため、書き込み可能期間は極力短いほうが好ましい。そこで、本実施形態では、書き込み可能期間をテナント毎に最適化し、書き込み可能期間を短くすることで、データ移動に関するパフォーマンスを向上させることができるデータ管理システムを実現させるための構成及び処理について説明する。なお、ここでいう最適化とは、上述の通り、書き込み可能期間を極力短くすることをいう。以降の説明においても同様とする。
以下、実施形態１、２と異なる点についてのみ説明する。
実施形態１、２と比べて本実施形態のデータ管理システムでは、バッチサーバー３に新たな機能が設けられていると共に、データベースシステム４に新たなテーブルが設けられている。本実施形態では、一部のテーブルのスキーマを変更し、更に、Ｗｅｂサーバー２の一部の機能による処理を変更している。
【００４４】
上述した図３を用いて、本実施形態で新たに設けた機能、テーブル、及び変更点について説明する。
まず、Ｗｅｂサーバー２における、書き込み制御部２２、及びアクセス履歴記録部２８の機能が実行する処理の変更点について説明する。
実施形態１では、書き込み制御部２２には、予め書き込み可能期間が定義されているものとした。しかし、本実施形態の書き込み制御部２２は、この書き込み可能期間を示す書き込み可能期間情報を、後述する書き込み可能期間管理テーブル４８から取得する。書き込み制御部２２は、書き込み可能期間管理テーブル４８から取得した書き込み可能期間情報が示す書き込み可能期間と、リクエスト対象のテナントＩＤと、書き込み／更新対象のデータの時刻とを比較し、書き込み／更新処理の実行可否を判断する。
また、アクセス履歴記録部２８は、実施形態２で述べたアクセス履歴記録の際に、そのリクエストにおいて書き込み／更新されるデータの時刻、及びその時刻とリクエスト時刻との差を、アクセス履歴管理テーブル４６に記録する。
【００４５】
バッチサーバー３には、新たな機能として、書き込み可能期間解析部３９が設けられる。
書き込み可能期間解析部３９は、定期的に動作し、アクセス履歴管理テーブル４６に記録されたリクエスト日時と、書き込み／更新対象のデータの時刻との差から、書き込み／更新される可能性のある期間を求める。また、書き込み可能期間解析部３９は、求めた期間を、書き込み可能期間管理テーブル４８に書き込む。
データベースシステム４には、新たなテーブルとして、書き込み可能期間管理テーブル４８が設けられる。また、アクセス履歴管理テーブル４６のスキーマを変更している。各テーブルの詳細については、図１６、１７等を用いて以下に説明する。
【００４６】
図１６は、本実施形態におけるアクセス履歴管理テーブル４６の一例を示す図である。
本実施形態におけるアクセス履歴管理テーブル４６は、実施形態２で上述した図１２のアクセス履歴管理テーブルに、アクセス時間と書き込み／更新データの時間との差を表すアクセス時間との差１７０１を追加したテーブルとなっている。
レコード１５１１は、クライアント１が、テナントＩＤがｔ１のデータに対して、２０１３／１／１  １０時にアクセスし、最大１５日７時間前のデータを書き込み、又は更新したことを表す。同様に、レコード１５１２は、クライアント１が、テナントＩＤがｔ１のデータに対して、２０１３／２／１  １０時５分にアクセスし、最大６日７時間前のデータを書き込み、又は更新したことを表す。
図１７は、書き込み可能期間管理テーブル４８の一例を示す図である。
書き込み可能期間管理テーブル４８は、テナントＩＤ１８０１、及び書き込み可能期間１８０２から構成される。例えば、レコード１８１１は、テナントＩＤがｔ１のデータの書き込み可能期間が４５日であることを表す。同様に、レコード１８１２は、テナントＩＤがｔ２のデータの書き込み可能期間が１５日であることを表す。このように、書き込み可能期間解析部３９が書き込み可能期間管理テーブル４８を管理することで、テナント毎に書き込み可能期間を分けることが可能となる。
【００４７】
次に、図１８を用いて、本実施形態におけるバッチサーバー３による書き込み可能期間の解析処理について説明する。
図１８は、本実施形態におけるバッチサーバー３による書き込み可能期間の解析処理の一例を示すフローチャートである。
Ｓ１９０１では、書き込み可能期間解析部３９は、アクセス履歴管理テーブル４６からデータ（アクセス履歴情報）を取得する。
Ｓ１９０２では、書き込み可能期間解析部３９は、Ｓ１９０１で取得したデータを、対象テナント毎にグルーピングする。
Ｓ１９０３では、書き込み可能期間解析部３９は、Ｓ１９０２でグルーピングしたグループを選択し、そのグループに所属するデータの中で、最も大きいアクセス時間との差１７０１を求める。例えば図１６の場合、レコード１５１１のアクセス時間との差１７０１と、レコード１５１２のアクセス時間との差１７０１とを比較すると、レコード１５１１のアクセス時間との差１７０１の方が大きい。そのたため、書き込み可能期間解析部３９は、最も大きいアクセス時間との差１７０１の値を、１５日７時間と求める。
【００４８】
Ｓ１９０４では、書き込み可能期間解析部３９は、Ｓ１９０３で求めたアクセス時間との差１７０１の値に係数αをかける。このαは、余裕係数であり、予め、本システム内に静的に定義されているものとする。
Ｓ１９０５では、書き込み可能期間解析部３９は、Ｓ１９０４で求めた値を書き込み可能期間管理テーブル４８に書き込む。また、書き込み可能期間解析部３９は、Ｓ１９０３で選択したグループのテナントＩＤを、書き込み可能期間管理テーブル４８に書き込む。
Ｓ１９０６では、書き込み可能期間解析部３９は、Ｓ１９０２でグルーピングした全てのグループに対して、Ｓ１９０３からＳ１９０５までの処理を実施したか否かを判断する。書き込み可能期間解析部３９は、実施している場合には、処理を終了し、実施していない場合には、Ｓ１９０３に遷移する。
以上、バッチサーバー３は、図１８のフローチャートに係る処理を実行することで、テナント毎に最適化した書き込み可能期間を求めることが可能となる。
【００４９】
次に、図１９を用いて、クライアントから書き込み／更新リクエストが発行されたときのＷｅｂサーバー２による書き込み制御処理について説明する。
図１９は、Ｗｅｂサーバー２による書き込み制御処理の一例を示すフローチャートである。
本フローチャートの処理について、図９のフローチャートの処理と異なる点についてのみ説明する。
Ｓ２００１では、アクセス履歴記録部２８は、リクエストにより書き込み／更新するデータ時刻と、アクセス時刻との差の最大値とを、アクセス履歴管理テーブル４６に書き込む。例えば、２０１３／１０／１５  １０時に、２０１３／１０／１  ０時から２０１３／１０／４  ２３時までのデータが書き込まれたとすると、アクセス時間との差の最大値は、１５日１０時間となる。そして、書き込み可能期間解析部３９は、上述した図１８の処理により、書き込み可能期間管理テーブル４８を更新する。
【００５０】
Ｓ２００２では、書き込み制御部２２は、書き込み可能期間管理テーブル４８から、リクエストの操作対象となるテナントＩＤに基づいて、書き込み可能期間情報を取得する。
Ｓ２００３では、書き込み制御部２２は、Ｓ２００２で取得した書き込み可能期間情報が示す書き込み可能期間と、操作対象のデータの時刻とを比較する。書き込み制御部２２は、比較の結果、操作対象のデータの時刻が書き込み可能期間外の場合は、Ｓ８０２に遷移し、書き込み可能期間内に含まれる場合は、Ｓ８０３に遷移する。
以上、Ｗｅｂサーバー２は、図１９のフローチャートに係る処理を実行することで、テナント毎に最適化された書き込み可能期間を用いて、書き込み／更新リクエストを制御することが可能となる。
【００５１】
以上、本実施形態におけるデータ管理システム６を実現することで、テナント毎に最適な書き込み可能期間を動的に定義することができるようになる。これにより、データ管理システム６は、書き込み可能期間を短縮することが可能になるため、一括移動することができるデータ量が増え、結果として、データの移動パフォーマンスを向上させることができる。
【００５２】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００５３】
以上、上述した各実施形態によれば、データの再移動の可能性を下げつつも、一部のデータに対しては、一括で移動を可能とすることで、移動パフォーマンスを向上させることができる。即ち、データ移動の際のユーザービリティ低下を抑制しつつ、データ移動のパフォーマンスを向上させることができる。
【００５４】
以上、本発明の好ましい形態について詳述したが、本実施形態は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【図１】
2015138334.tif 000003
【図２】
2015138334.tif 000004
【図３】
2015138334.tif 000005
【図４】
2015138334.tif 000006
【図５】
2015138334.tif 000007
【図６】
2015138334.tif 000008
【図７】
2015138334.tif 000009
【図８】
2015138334.tif 000010
【図９】
2015138334.tif 000011
【図１０】
2015138334.tif 000012
【図１１】
2015138334.tif 000013
【図１２】
2015138334.tif 000014
【図１３】
2015138334.tif 000015
【図１４】
2015138334.tif 000016
【図１５】
2015138334.tif 000017
【図１６】
2015138334.tif 000018
【図１７】
2015138334.tif 000019
【図１８】
2015138334.tif 000020
【図１９】
2015138334.tif 000021