JP2018041322A - 異種データベース管理装置、方法及びプログラム - Google Patents

Abstract

【課題】システム運用者とクライアントとが異なる場合適切な格納先ＤＢ種別の指定ができる。
【解決手段】異種データベース管理装置は、データ特性分析部と、ルール生成部と、を備えている。データ特性分析部は、クライアントから受け付けた１以上のリクエストに関するデータをテーブルＩＤごとに含んだリクエスト履歴テーブルと、データ実体をデータＩＤごとに含んだデータテーブルを取得し、これからテーブルＩＤごとに１以上の特性情報項目に対する値を含んだ特性情報テーブルを生成する。ルール生成部は、特性情報テーブルから１以上の特性情報を抽出しこれらの特性情報を、１以上の情報からテーブルＩＤごとに格納先として最適なデータベースを選択する判定ロジックに適用して、テーブルＩＤごとに振り分ける際に最適なデータベースを対応付けるルールテーブルを生成する。
【選択図】図１

Description

この発明は、異種データベース管理装置、方法及びプログラムに関する。

異なる複数のテーブルを複数の種別の異なるデータベース（ＤＢとも略す）に管理する技術としてマルチＤＢ技術がある。従来では、テーブル生成時にユーザが明示的に格納先のＤＢの種別を指定することで、複数のＤＢと管理サーバ（システムと呼ぶこともある）との間でデータの読み書きを可能とする（例えば、非特許文献１参照）。

IBM(2002) Garlic: A New Flavor of Federated Query Processing for DB2

しかし、システム運用者とクライアントが異なる場合、システム運用者はテーブルに含まれるそれぞれのデータの非単体特性（データ単体からは判明しない特性）を把握できず、またクライアントはシステム構成及びＤＢ構成を把握できないため、データの非単体特性に応じてデータの格納先のＤＢ種別を指定することが困難であるという課題がある。

この発明は上記事情に着目してなされたもので、その目的とするところは、システム運用者とクライアントとが異なる場合でも異なる複数のテーブルを格納先の適切なＤＢ種別の指定ができる異種データベース管理装置、方法及びプログラムを提供することにある。

上記目的を達成するためにこの発明の観点は、以下のような構成要素を備えている。すなわち、異種データベース管理装置は、データ特性分析部と、ルール生成部と、を備えている。データ特性分析部は、クライアントから受け付けた１以上のリクエストに関するデータをテーブルＩＤごとに含んだリクエスト履歴テーブルと、データ実体をデータＩＤごとに含んだデータテーブルを取得し、それらからテーブルＩＤごとに１以上の特性情報項目に対する値を含んだ特性情報テーブルを生成する。ルール生成部は、特性情報テーブルから１以上の特性情報を抽出しこれらの特性情報を、１以上の情報からテーブルＩＤごとに格納先として最適なデータベースを選択する判定ロジックに適用して、テーブルＩＤごとに振り分ける際に最適なデータベースを対応付けるルールテーブルを生成する。

この発明によれば、システム運用者とクライアントとが異なる場合でも要件の異なる複数のデータを適切な格納先ＤＢ種別の指定ができる異種データベース管理装置、方法及びプログラムを提供することができる。

実施形態に係る異種データベース管理装置を示すブロック図。 図１の振り分け情報ＤＢが事前処理として各テーブルの定義を行うことを示すシーケンス図。 振り分けルールを示すルールテーブルを更新することを示すシーケンス図。 ルールテーブルを定期的に更新することを示すシーケンス図。 データテーブルを永続化することを示すシーケンス図。 図１のＳｅｃｏｎｄａｒｙ−ＤＢの更新を示すシーケンス図。 リクエストの振り分けを示すシーケンス図。 特性情報テーブルの一例を示す図。 判定ロジックの一例を示す図。 ルールテーブルの一例を示す図。 リクエスト履歴テーブルの一例を示す図。

以下、図面を参照してこの発明に係わる実施形態の異種データベース管理装置、方法及びプログラムを説明する。なお、以下の実施形態では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。
本実施形態の異種データベース管理装置（以下、異種ＤＢ管理装置と称す）について図１を参照して説明する。
本実施形態の異種ＤＢ管理装置１００は、振り分けエンジン部１０１、振り分け情報ＤＢ１０２、メモリ１０３、データ特性分析部１０４、ルール生成部１０５、永続化部１０６、アダプタＡ１０７、アダプタＺ１０８、ＤＢ−Ａ１０９、ＤＢ−Ｚ１１０を備えている。本実施形態の異種ＤＢ管理装置は、複数種別のデータベースを対象とする。異種データベース管理装置は、上述したシステムに対応している。

振り分けエンジン部１０１は、データ特性分析部１０４が生成した振り分けルールに従って、リクエスト先となるＤＢまたはメモリを決定する。振り分けエンジン部１０１は、クライアントのリクエストに含まれるデータのＵＲＩ（Uniform Resource Identifiers）情報からテーブル名を特定し、振り分けルールにテーブル名ごとに登録された格納先ＤＢ情報を取得する。
また、振り分けエンジン部１０１がデータテーブルの新規定義リクエストを受けた場合及び振り分けルールの更新依頼を受けた場合には、振り分けエンジン部１０１は以下のように動作する。（１）ルールテーブル及びリクエスト履歴テーブルに該当するテーブルのＩＤを持つデータを追加する。その際、ルールテーブル上の当該データテーブルＩＤのＰｒｉｍａｒｙ−ＤＢ（プライマリーデータベース）をメモリに設定する。（２）クライアントからリクエストを受けると、データをメモリ１０３上のデータテーブルに読み書きする。さらにリクエスト履歴テーブルを更新する。（３）一定量のデータがメモリ１０３上に蓄積されると、データ特性分析部１０４にデータ特性分析を依頼する。なお、データテーブルは、クライアントのデータテーブルを定義する度に生成され通常複数ある。また、テーブルＩＤは、複数あるデータテーブルを識別するためのものである。各データテーブルには、複数のデータ実体を記録するため、データ実体を特定するデータＩＤを、各データ実体に対応付けている。
この他の場合には、振り分けエンジン部１０１は、取得した格納先ＤＢにデータのリクエスト先を送信する。ここでは、データの新規作成リクエストの場合、Ｐｒｉｍａｒｙ−ＤＢを参照先とする。データの新規作成リクエスト以外の場合、Ｐｒｉｍａｒｙ−ＤＢとＳｅｃｏｎｄａｒｙ−ＤＢ（セカンダリーデータベース）を参照先とする。複数のテーブルを対象としたリクエストの場合、格納先ＤＢごとにリクエストを分解し、各リクエストを実行する。

メモリ１０３は、クライアントからのデータテーブル及びリクエストを一時的に格納する。なお、これらのデータテーブル及びリクエストはデータ特性分析部１０４の指示に従い永続化部１０６によって各データベースへ振り分けられる。なお便宜上、ここではメモリ１０３を設けたが、異種ＤＢ管理装置１００内の各部がそれぞれ情報格納部（バッファ、メモリ等）を持ちそこで、種々のデータを格納していてもよい。データの格納に関しては様々な変形版が考えられ、本実施形態の異種ＤＢ管理装置が機能すればその変形版を採用してもよい。

データ特性分析部１０４は、テーブル単位でデータの単体特性及び非単体特性を分析する。単体特性とは、データ単体の特性であり、例えばサイズや属性数がある。非単体特性とは、データ単体からは知り得ない特性であり、例えばリクエスト頻度や検索時の条件数がある。データ特性分析部１０４は、振り分けエンジン部１０１からの依頼時またはスケジュールによって指定されたタイミングで以下を実行する。なお、スケジュールは、外部ファイルから取得してもよい。（１）振り分け情報ＤＢ１０２から該当するデータテーブルのリクエスト履歴を取得及び分析し、このデータテーブルの特性情報を生成する。（２）生成した特性情報を引数に、ルール生成部１０５に振り分けルールの生成を依頼する。振り分けルールが生成されると、振り分け情報ＤＢ１０２からこのデータテーブルに関するリクエスト履歴を削除し、振り分けルールの更新を行う。（３）最後に、メモリ１０３上に保持されたデータテーブルの永続化を永続化部１０６に依頼する。

ＤＢ−Ａ１０９からＤＢ−Ｚ１１０は、それぞれが互いに異種のデータベースであり、それぞれアダプタＡ１０７からアダプタＺ１０８によって振り分けエンジン部１０１に接続されている。図１ではデータベースは２つしか記載していないが、通常データベースは２以上で多数ある。

ルール生成部１０５は、最適な蓄積ＤＢ（ＤＢ−Ａ１０９からＤＢ−Ｚ１１０のいずれか）を判定する判定ロジックを用い、テーブルごとに格納先ＤＢを振り分ける振り分けルールを生成する。なお、判定ロジックは、ルール生成部１０５に格納されていてもよいし、外部ファイルから取得してもよい。またルール生成部１０５は、クライアントからのリクエストを受け付ける前に、ルールテーブルを振り分け情報ＤＢ上に定義する。

ルール生成部１０５は、データ特性分析部１０４が分析したテーブルの特性情報をデータ特性分析部１０４から取得し、取得した特性情報と判定ロジックから、当該テーブルのデータを格納するＤＢを振り分ける振り分けルール（図１０のルールテーブルがそれに対応する）を生成する。振り分けルールは、テーブルごとにＰｒｉｍａｒｙ−ＤＢとＳｅｃｏｎｄａｒｙ−ＤＢを設定する。Ｐｒｉｍａｒｙ−ＤＢは、テーブルに含まれるデータを格納する。そして、データの生成時にはＰｒｉｍａｒｙ−ＤＢを参照先とし、データの取得／更新／削除／検索時には、Ｐｒｉｍａｒｙ−ＤＢとＳｅｃｏｎｄａｒｙ−ＤＢの両方を参照先とする。Ｓｅｃｏｎｄａｒｙ−ＤＢは定期的にデータの有無を確認する等して、データが無くなった場合にはＳｅｃｏｎｄａｒｙ−ＤＢを振り分けルールから削除する。

永続化部１０６は、ルール生成部１０５による振り分けルールの生成が完了したタイミング、または振り分け情報ＤＢ１０２による振り分けルールの更新が完了したタイミングで、メモリ１０３上のデータの実体を振り分けルールに従って異種ＤＢに移動またはコピーし永続化する。永続化部１０６は、メモリ１０３上のデータの書き込み処理を振り分けエンジン部１０１に依頼する。

振り分け情報ＤＢ１０２は、リクエストの種類（データの生成、更新、取得、削除、及び検索）のうちの属性（例えば、回数、時刻、合計値、条件数）を１以上含むリクエスト履歴テーブル、特性情報を含むテーブルである特性情報テーブル、及び振り分けルールを含むルールテーブルを定義し、さらに定義されたそれらのテーブルにデータを格納し蓄積する。なお、振り分けルールテーブルは、テーブル名（テーブルＩＤで示してもよい）に格納先ＤＢであるＰｒｉｍａｒｙ−ＤＢとＳｅｃｏｎｄａｒｙ−ＤＢとを紐付けた情報を含む。

次に、振り分け情報ＤＢ１０２が事前処理として各テーブルの定義を行うことについて図２を参照して説明する。
データ特性分析部１０４がリクエスト履歴テーブルの作成を振り分け情報ＤＢ１０２に依頼する（ステップＳ２０１）。振り分け情報ＤＢ１０２がリクエスト履歴テーブルの定義を行い（ステップＳ２０２）、その定義を行った旨をデータ特性分析部１０４に知らせる。リクエスト履歴テーブルは、テーブル名の項目と、リクエスト内容を示す１以上の項目と、が設定されている。リクエスト履歴テーブルについては後に図１１を参照して説明する。
同様に、データ特性分析部１０４が特性情報テーブルの作成を振り分け情報ＤＢ１０２に依頼する（ステップＳ２０３）。振り分け情報ＤＢ１０２が特性情報テーブルの定義を行い（ステップＳ２０４）、その行った旨をデータ特性分析部１０４に知らせる。特性情報テーブルは、テーブル名の項目と、データに関する特性情報を示す１以上の項目とが設定されている。特性情報テーブルについては後に図８を参照して説明する。

さらに同様に、データ特性分析部１０４がルールテーブルの定義を振り分け情報ＤＢ１０２に依頼する（ステップＳ２０５）。振り分け情報ＤＢ１０２がルールテーブルの定義を行い（ステップＳ２０６）、その行った旨をデータ特性分析部１０４に知らせる。ルールテーブルは、テーブル名の項目と、Ｐｒｉｍａｒｙ−ＤＢとＳｅｃｏｎｄａｒｙ−ＤＢとの項目が設定されている。ルールテーブルについては後に図１０を参照して説明する。

次に、データテーブルを新規生成する場合、またはリクエストを異種ＤＢ管理装置１００へ送信する場合の異種ＤＢ管理装置１００での動作について図３を参照して説明する。
振り分けエンジン部１０１がクライアントからデータテーブルの新規定義の依頼を受け、振り分けエンジン部１０１は上述した動作を行う（ステップＳ３０１）。これはデータテーブルの新規定義及び当該データテーブルのテーブルＩＤを定義することである。ルールテーブル及びリクエスト履歴テーブルのそれぞれに依頼されたデータテーブルのデータテーブルＩＤを追加し、情報ＤＢ１０２に蓄積する（ステップＳ３０２、ステップＳ３０３）。その旨を振り分けエンジン部１０１及びクライアントに知らせる（ステップＳ３０５）。これでクライアントからのリクエスト受け付ける準備ができたことになる。

クライアントがリクエストを異種ＤＢ管理装置１００に送信すると（ステップＳ３０５）、リクエストに応じた処理を実行する。振り分けエンジン部１０１が、実行した結果のデータを含んだデータテーブルをメモリ１０３にキャッシュするように指示し（ステップＳ３０６）、メモリ１０３がそのデータテーブルを格納する（ステップＳ３０７）。

その後振り分けエンジン部１０１がメモリ１０３に格納されたデータテーブルに基づいて振り分け情報ＤＢ１０２がリクエスト履歴テーブルを更新するように指示し（ステップＳ３０８）、振り分け情報ＤＢ１０２がリクエスト履歴テーブルを更新する（ステップＳ３０９）。この更新は、該当するテーブルＩＤに対応する項目の更新である。その旨をクライアントに送信する（ステップＳ３１０）。振り分けエンジン部１０１は、データ特性分析部１０４へデータ特性分析の実施を依頼する（ステップＳ３１１）。この依頼は、例えばメモリ１０３に蓄積したメモリ量が一定値を超えた場合に行う。

データ特性分析部１０４が振り分け情報ＤＢ１０２から更新されたリクエスト履歴テーブルを取得し、該当するテーブルＩＤ（これは複数でもよい）に対してデータ分析し、特性情報テーブルを生成する（ステップＳ３１３）。このように、データの非単体特性を分析し特性情報テーブルを得て、非単体特性を持つデータに対しても格納先ＤＢの種別を指定することができる。この生成された特性情報テーブルをルール生成部１０５が取得し、特性情報テーブルから情報を抽出し（図９で説明する）判定ロジックを適用して、該当するテーブルＩＤに対応するＰｒｉｍａｒｙ−ＤＢにするデータベース名、及びＳｅｃｏｎｄａｒｙ−ＤＢにするデータベース名を算出し、ルールテーブルの該当テーブルＩＤに対応する項目内容を生成する。換言すれば、判定ロジックの結果、テーブル名と格納先ＤＢ（Ｐｒｉｍａｒｙ−ＤＢまたはＳｅｃｏｎｄａｒｙ−ＤＢ）の組み合わせを振り分けルールとして保持する。したがって、このルールテーブルによって種別の異なるＤＢの特性を考慮した振り分けルールを生成することができるようになる。

ルール生成部１０５はルールテーブルが作成されたことをデータ特性分析部１０４及び振り分け情報ＤＢ１０２に伝える（ステップＳ３１５）。注目している該当テーブルＩＤの振り分けルールが生成できたので、振り分け情報ＤＢ１０２はステップＳ３０９で更新したリクエスト履歴テーブルは不要なので削除する（ステップＳ３１６）。振り分け情報ＤＢ１０２は、ステップＳ３１４で生成されたルールテーブルの該当テーブルＩＤに対応する項目内容をルールテーブルに追加し（図１０では行を追加することに対応する）に追加してルールテーブルを更新する（ステップＳ３１７）。振り分けルールであるルールテーブルを自動的に異種ＤＢ管理装置が生成することによって、クライアントが非単体特性を持つデータに対して格納先ＤＢを把握または指定することができたとして、この把握または指定のための設計作業を行う必要がなくなる。

ステップＳ３０９での該当ルールＩＤに対してルールテーブルの更新が完了した旨をデータ特性分析部１０４及び振り分けエンジン部１０１に知らせる。

次に、判定ロジックを適用してルールテーブルを更新することについて図４を参照して説明する。判定ロジックは例えば、データテーブルが生成された後１度のみ実行する設定と、定期的に複数回実行する設定とがある。判定ロジックを定期的に複数回実行する設定の場合を説明する。
データ特性分析部１０４が、振り分け情報ＤＢ１０２へ定期的な分析を依頼する（ステップＳ４０１）。この依頼は特定の複数のテーブルＩＤに対する分析でもよいし、１つのテーブルＩＤについての分析でもよい。すなわち、１以上のテーブルＩＤについて分析することができる。振り分け情報ＤＢ１０２はルールテーブルの更新を受け付け（ステップＳ４０２）、データ特性分析部１０４へその旨を伝える。

分析対象のテーブルＩＤの振り分け先を一時的にメモリ１０３とする。対象となるテーブルＩＤについて図３のステップＳ３０５から処理を開始する。最終的にステップＳ３１７でルールテーブルの該当テーブルＩＤに対応する格納先ＤＢを示した項目内容（判定結果）を得ることができる。この判定結果が前回の判定結果と格納先ＤＢが異なる場合、前回の判定結果の格納先ＤＢをＳｅｃｏｎｄａｒｙ−ＤＢとし、最新の判定結果をＰｒｉｍａｒｙ−ＤＢとする。なお、判定ロジックを１度のみ実行する設定の場合及び、複数回実行するが判定結果が合致する場合には、Ｓｅｃｏｎｄａｒｙ−ＤＢの値は存在しない。

次に、メモリ１０３に格納されているデータテーブルごとに対応するデータベースに永続化することについて図５を参照して説明する。
図３のルールテーブルの更新がなされた後に、振り分け情報ＤＢ１０２からデータ特性分析部１０４にその旨の知らせが送信され、これを受けてデータ特性分析部１０４はデータの永続化の処理に入り永続化部１０６へメモリ１０３が格納しているデータを永続化する処理を開始する（ステップＳ５０１）。永続化部１０６がメモリ１０３内にあるデータを取得する（ステップＳ５０２）。図３の処理で得ているルールテーブルに基づいて、メモリ１０３にあるデータテーブルごとに対応するデータ実体をＤＢ−Ａ１０９からＤＢ−Ｚ１１０のいずれかのデータベースへデータテーブルを移動させ（ステップＳ５０４、５０６）そこに格納し（永続化：ステップＳ５０５、Ｓ５０７）永続化した旨を永続化部１０６へ返す。ＤＢ−Ａ１０９からＤＢ−Ｚ１１０は複数であれば任意の個数あり、それぞれの仕様も任意あるが、特性情報テーブルの項目に対応する仕様はそれぞれのデータベースで異なっていることが想定される。換言すれば、図９の判定ロジックで選択が多様になるようなデータベースの仕様であればよい。

次に、Ｓｅｃｏｎｄａｒｙ−ＤＢの更新について図６を参照して説明する。
ルール生成部１０５は、振り分けルールを振り分け情報ＤＢ１０２から取得する（ステップＳ６０１）。ルール生成部１０５は、取得した振り分けルールに基づいて、Ｓｅｃｏｎｄａｒｙ−ＤＢであるデータベースを特定しそのデータベース名を抽出する（ステップＳ６０２）。ルール生成部１０５が、抽出されたＳｅｃｏｎｄａｒｙ−ＤＢであるデータベースのそれぞれにデータ実体が格納されているかどうかを検索する（ステップＳ６０３）。その後、ルール生成部１０５が、抽出された全てのＳｅｃｏｎｄａｒｙ−ＤＢそれぞれにデータが格納されているかどうかを判定して更新するかどうかを判定する（ステップＳ６０４）。この更新判定では、データが格納されていないＤＢはルールテーブル（振り分けルール）から記載を削除し、一方、１つでもデータが格納されているＤＢはそのままルールテーブルに記載を残しておく。その後、ルール生成部１０５がこの更新判定の結果を振り分け情報ＤＢ１０２に送信し、振り分け情報ＤＢ１０２がルールテーブルを更新する（ステップＳ６０６）。

ここで、リクエストの送信からリクエストを実行する前にリクエストがどのように振り分けられるかについて図７を参照して説明する。ここでは、既にルールテーブル（すなわち、振り分けルール）が決定している場合である。
クライアントがリクエストを送信し振り分けエンジン部１０１が受け付けると、振り分けエンジン部１０１がリクエストに含まれるデータのＵＲＩ情報からテーブル名を特定し、振り分け情報ＤＢ１０２に格納されているルールテーブル（振り分けルールが記載）にテーブル名ごとに登録された格納先ＤＢ情報を取得する（ステップＳ７０２）。その後、振り分け先がＤＢ−Ａ１０９であった場合にはＤＢ−Ａ１０９へ送信し（ステップＳ７０３）、ＤＢ−Ａ１０９でリクエストが実行される（ステップＳ７０４）。一方、振り分け先がＤＢ−Ｚ１１０であった場合にはＤＢ−Ｚ１１０へ送信し（ステップＳ７０５）、ＤＢ−Ｚ１１０でリクエストが実行される（ステップＳ７０６）。

ここで、特性情報テーブルについて一具体例である図８を参照して説明する。
特性情報テーブルは、データ特性分析部１０４が、メモリ１０３に格納されているデータテーブルと、振り分けエンジン部１０１に格納されて更新されているリクエスト履歴テーブルから作成する。リクエスト履歴テーブルは、後に図１１を参照して詳細に説明するが、リクエストの統計情報である次のものをテーブルＩＤごとに格納している。このリクエストの統計情報は、例えば、データの生成回数、最新及び最古のデータ生成リクエストの受信時刻、データの更新回数、最新及び最古のデータ更新リクエストの受信時刻、データの取得回数、最新及び最古のデータ取得リクエストの受信時刻、削除されたデータの生成時刻、削除されたデータの削除時刻、データの検索回数、及び検索クエリの条件数（リスト形式）を含んでいる。

特性情報テーブルは、テーブルに格納したデータの単体特性、非単体特性を表現する項目で構成される。例えば以下の（１）から（６）のうちの１以上を含む。（１）テーブルにおけるデータの合計生成頻度（例えば、１０（回／時））：リクエスト履歴テーブルからデータの生成回数及び最新／最古の生成時刻を取得し、生成頻度を算出する。（２）テーブルにおけるデータの合計更新頻度（例えば、１（回／時））：リクエスト履歴テーブルからデータの更新回数及び最新／最古の更新時刻を取得し、更新頻度を算出する。（３）テーブルにおけるデータの合計取得頻度（例えば、１０（回／時））：リクエスト履歴テーブルからデータの取得回数及び最新／最古の取得時刻を取得し、生成頻度を算出する。（４）テーブルにおけるデータの平均生存時間（例えば、１４８（時間））：リクエスト履歴テーブルから総生存時間及び削除回数を取得し、生存時間の平均値を算出する。（５）テーブルにおけるデータの平均サイズ（例えば、１０００（ＫＢ））：データテーブルから各データのデータサイズを取得する。平均値を算出する。（６）テーブルにおける検索クエリの平均条件数：リクエスト履歴テーブルから総検索条件数及び検索回数を取得し、検索条件の平均値を算出する。（７）テーブルにおけるデータの平均属性数：データテーブルから各データの属性数を取得する。平均値を算出する（例えば、１０（属性））。

次に、ルール生成部１０５が振り分けルール（ルールテーブル）を生成するための判定ロジックについて図９を参照して説明する。
判定ロジックは、ステップＳ３１２でデータ特性分析部１０４が分析して生成し特性情報テーブルから、特性情報項目の1つ以上を用いてルールテーブルを得るためのロジックである。そのロジックの一例が図９に示されている。図９の例では、まず、平均データサイズの大きさで分け、平均データサイズが第１閾値（ここでは１０００［ＫＢ］）よりも小さいかどうか判定する（ステップＳ９０１）。ステップＳ９０１で平均データサイズが第１閾値よりも小さいと判定された場合には、データの合計生成頻度が合計更新頻度よりも大きいかどうか判定し（ステップＳ９０２）、ステップＳ９０１で平均データサイズが第１閾値よりも小さくないと判定された場合には、平均データサイズが第２閾値（８０００［ＫＢ］）よりも小さいかどうか判定する（ステップＳ９０３）。

ステップＳ９０２でデータの合計生成頻度が合計更新頻度よりも大きい場合には、データの合計生成頻度が第３閾値よりも大きいかどうかを判定し（ステップＳ９０４）、ステップＳ９０２でデータの合計生成頻度が合計更新頻度よりも大きくない場合には、データのサービス頻度が所定値（Ｘ）であるかどうかを判定する（ステップＳ９０５）。

ステップＳ９０４でデータの合計生成頻度が第３閾値よりも大きい場合にはデータベースＡを採用し、ステップＳ９０４でデータの合計生成頻度が第３閾値よりも大きくない場合にはデータベースＢを採用する。また、ステップＳ９０５でデータのサービス頻度が所定値である場合にはデータベースＢを採用し、ステップＳ９０５でデータのサービス頻度が所定値でない場合にはデータベースＣを採用する。さらに、ステップＳ９０３で平均データサイズが第２閾値よりも小さい場合にはデータベースＤを採用し、ステップＳ９０３で平均データサイズが第２閾値よりも小さくない場合にはデータベースＥを採用する。

この判定ロジックに対応するテーブルＩＤの特性情報テーブルを適用することによって、ルール生成部１０５がこのテーブルＩＤに対応するＰｒｉｍａｒｙ−ＤＢを決定することができ、テーブルＩＤごとにこの判定ロジックを適用すれば、図１０に示すルールテーブルを作成することができる。図１０は、ルール生成部１０５によって得られる振り分けルールを示すルールテーブルである。図１０の例では、テーブル名（テーブルＩＤ）が「userTable001」「userTable002」「userTable003」及び「userTable004」では、それぞれＰｒｉｍａｒｙ−ＤＢが「Ａ」「Ｂ」「Ｃ」及び「Ｄ」となり、Ｓｅｃｏｎｄａｒｙ−ＤＢが「なし」「なし」「なし」及び「Ａ、Ｂ」となることを示している。

次に、リクエスト履歴テーブルについて図１１を参照して説明する。
リクエスト履歴テーブルは、（１）データの生成リクエスト、（２）データの更新リクエスト、（３）データの取得リクエスト、（４）データの削除リクエスト、及び（５）データの検索リクエストの情報のうち少なくとも１つ以上を保持する。

（１）データの生成リクエストを受信した場合に、以下の項目を更新する。１．データの生成回数（回）。ルールテーブルに格納された生成回数を＋１加算する。２．最新／最古の生成時刻（時刻）。データ生成回数が０である場合に、最新／最古の生成時刻を更新する。データ生成回数が０ではない場合に、最新生成時刻を更新する。３．データの生成時刻（｛ＩＤ：時刻｝）。データＩＤとデータ生成時刻の組を追加する。なお、データテーブル上に生成時刻を記録してもよい。

（２）データの更新リクエストを受信した場合に、以下の項目を更新する。１．データの更新回数（回）。ルールテーブルに格納された更新回数を＋１加算する。２．最新／最古の更新時刻（時刻）。データ更新回数が０である場合に、最新／最古の更新時刻を更新する。データ更新回数が０ではない場合に、最新の更新時刻を更新する。

（３）データの取得リクエストを受信した場合に、以下の項目を更新する。１．データの取得回数（回）。ルールテーブルに格納された取得回数を＋１加算する。２．最新／最古の取得時刻（時刻）。データ取得回数が０である場合に、最新／最古の取得時刻を更新する。データ取得回数が０ではない場合に、最新の取得時刻を更新する。

（４）データの削除リクエストを受信した場合に、以下の項目を更新する。１．削除回数（回）。ルールテーブルに格納された削除回数を＋１加算する。２．生存時間の合計値（時間）。ルールテーブルに格納された生存時間に、削除対象の生存時間を加算する。生存時間は、データの生成時刻と削除リクエストの受信時刻の減算から算出する。３．データ生成時刻（時刻）。ルールテーブルに格納されたデータ生成時刻から削除されたデータのＩＤと合致するデータＩＤ／生成時刻情報を削除する。

（５）データの検索リクエストを受信した場合に、以下の項目を更新する。１．検索回数(回)。ルールテーブルに格納された生成回数を+1加算する。２．検索条件数の総和(数)。ルールテーブルに格納された属性数に、生成リクエストに含まれるデータの属性数を加算する。

以上の情報を含んだ具体的な一例が図１１である。

以上の実施形態に係る異種データベース管理装置によれば、サイズや属性数などのデータ単体の「単体特性」とは別に、クエリ頻度や検索方法などのデータ単体からはわらない「非単体特性」を持つデータであっても、ルールテーブルがデータＩＤごとに種別の異なる格納先となるデータベースを決定するので、クライアントとデータベースの構成を熟知しているシステム運用者とが異なる場合でもデータごとに適切な格納先データベースを指定することができる。したがって、クライアントはデータベースの構成を知らなくても、クライアントからの非単体特性を持つリクエストでも、適切なデータベースを格納先に指定することができる。

なお、この発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

１００…異種ＤＢ管理装置、１０１…振り分けエンジン部、１０２…振り分け情報ＤＢ、１０３…メモリ、１０４…データ特性分析部、１０５…ルール生成部、１０６…永続化部、１０７…アダプタＡ、１０８…アダプタＺ、１０９…データベースＡ、１１０…データベースＢ。

Claims (8)

1. クライアントから受け付けた１以上のリクエストに関するデータをテーブルＩＤごとに含んだリクエスト履歴テーブルと、データ実体をデータＩＤごとに含んだデータテーブルとを取得し、このデータテーブルからテーブルＩＤごとに１以上の特性情報項目に対する値を含んだ特性情報テーブルを生成するデータ特性分析部と、
   前記特性情報テーブルから１以上の特性情報を抽出しこれらの特性情報を、１以上の情報からテーブルＩＤごとに格納先として最適なデータベースを選択する判定ロジックに適用して、テーブルＩＤごとに振り分ける際に最適なデータベースを対応付けるルールテーブルを生成するルール生成部と、を備える異種データベース管理装置。
2. 前記ルールテーブルは、テーブルＩＤごとにプライマリーデータベースとセカンダリーデータベースとを設定する請求項１に記載の異種データベース管理装置。
3. 前記ルールテーブルに従って、一時的に格納しているデータの実体を、対応するデータベースに書き込む永続化部をさらに備える請求項１または２に記載の異種データベース管理装置。
4. 前記ルールテーブルを取得し前記リクエストに含まれるデータのＵＲＩ情報からテーブルＩＤを特定し、ルールテーブルに従って当該テーブルＩＤの格納先データベースにリクエストを送信し、新規作成リクエストの場合にプライマリーデータベースを格納先とし、新規作成以外のリクエストの場合にプライマリーデータベースとセカンダリーデータベースを格納先とする請求項１から３のいずれか１項に記載の異種データベース管理装置。
5. クライアントから受け付けた１以上のリクエストに関するデータをテーブルＩＤごとに含んだリクエスト履歴テーブルと、データ実体をデータＩＤごとに含んだデータテーブルとを取得し、このデータテーブルからテーブルＩＤごとに１以上の特性情報項目に対する値を含んだ特性情報テーブルを生成するステップと、
   前記特性情報テーブルから１以上の特性情報を抽出しこれらの特性情報を、１以上の情報からテーブルＩＤごとに格納先として最適なデータベースを選択する判定ロジックに適用して、テーブルＩＤごとに振り分ける際に最適なデータベースを対応付けるルールテーブルを生成するステップと、を備える異種データベース管理方法。
6. 前記ルールテーブルに従って、一時的に格納しているデータの実体を、対応するデータベースに書き込むステップをさらに備える請求項５に記載の異種データベース管理方法。
7. 前記ルールテーブルを取得し前記リクエストに含まれるデータのＵＲＩ情報からテーブルＩＤを特定し、ルールテーブルに従って当該テーブルＩＤの格納先データベースにリクエストを送信し、新規作成リクエストの場合にプライマリーデータベースを格納先とし、新規作成以外のリクエストの場合にプライマリーデータベースとセカンダリーデータベースを格納先とする請求項５または６に記載の異種データベース管理方法。
8. コンピュータに、請求項５から７のいずれか１項に記載の異種データベース管理方法の各ステップを実行させるためのプログラム。