JP2013186890A - データベースミドルウェアを用いたデータ管理システム及びその方法 - Google Patents

Abstract

【課題】データベースミドルウェアを用いたデータ管理システム及びその方法を提供する。
【解決手段】データベースミドルウェアを含むデータ管理システムにおいて、前記データベースミドルウェアは、入力されるクエリに基づいてシャードキー識別子を生成し、生成されたシャードキー識別子とデータベースミドルウェアに設定されたシャードメタデータとを用いて決定されたシャード識別子によって複数のデータベースのうち１つのデータベースを選択するシャードプロセシングモジュールを含む。
【選択図】図２

Description

本発明の実施形態は、データベースミドルウェアを用いたデータ管理システム及びその方法に関する。

関係データベース（ｒｅｌａｔｉｏｎａｌ ｄａｔａｂａｓｅ）は、一連の定形化されたテーブルで構成されたデータ項目の集合体であり、そのデータはデータベーステーブルを再構成しなくても、様々な方法によってアクセスしたり、組合わせたりすることができる。関係データベースにおいてユーザと関係データベースとを結びつける標準検索言語をＳＱＬというが、ＳＱＬ文章は関係データベースにあるデータを直接照会したり、または報告書を抽出したりすることに用いることができる。関係データベースは、作成したり利用することが比較的容易であるが、何よりも拡張が容易であるという長所を有する。初めてデータベースを作成した後に関連するアプリケーションを変更しなくても、新しいデータ項目をデータベースに追加することができる。

ここで、１つのデータベースとして扱うことができない程に多くのデータを格納して照会しようとする場合、様々なデータベースにデータを分散して格納及び保持する方式を用いることになる。ここで、従来技術では、テーブルを分離して分割されたテーブルを様々なデータベースに分散させて格納し、アプリケーション側で所望するデータを含むデータベースを探すためのルール（ｒｕｌｅ）を算出した。したがって、このような従来技術では、アプリケーション側の複雑度が増加するという問題点がある。また、テーブルの追加分割またはデータベース増設時のアプリケーション側でも変更が必要となる問題点がある。

図１は、従来技術に係るデータ管理方法を説明するための図である。図１は、複数のユーザが複数の端末（アプリケーション側）１１０を介して複数のデータベース１２０に格納されたデータを照会する際において、データベースミドルウェア１３０がクエリの入力を受けてデータを処理する様子を示している。ここで、従来技術に係るデータ管理方法では、アプリケーション側でキー（Ｋｅｙ）を生成し、含まれるメタデータを用いてデータを格納／照会／生成するためのデータベースを複数のデータベース１２０の中から選択しなければならない。ここで、複数のデータベース１２０の各々は、互いに異なる名前（ｎａｍｅ）を有してもよく、名前によって識別されてもよい。例えば、端末２がデータを追加しようとし、データが追加されなければならないデータベースが「ＤＢ３」である場合、端末２は、予め設定されたルールに従ってデータを追加しなければならないデータベースが「ＤＢ３」であることを直接確認しなければならず、「ＤＢ３」にデータを追加させるクエリを生成しなければならない。すなわち、アプリケーション側で必要なデータベースを直接探してクエリを生成しなければならないため、アプリケーション側の複雑度が増加するという問題点がある。また、テーブルを追加分割したりデータベースを増設する場合、アプリケーション側で所望するデータまたは所望するデータベースを直接探さなければならないため、アプリケーション側にも変更が発生するようになるという問題点がある。

本明細書では、複数のデータベースに分散格納されたデータをより効果的に管理できるシステム及びその方法を提供する。

本発明は、データベースミドルウェアにおいて、シャーディング（ｓｈａｒｄｉｎｇ）処理によってアプリケーション側の要求に適した単一データベースを複数のデータベースの中から探してデータを照会及び提供することにより、アプリケーション側の複雑度を減少させることができるデータ管理システム及びその方法を提供する。

また、本発明は、シャードプロセシングモジュールを含むデータベースミドルウェアを用いて、アプリケーション側の変更なしにテーブルの追加分割またはデータベース増設が可能なデータ管理システム及びその方法を提供する。

また、本発明は、内部ハッシュ法やユーザによって登録されたハッシュ法などのような多様なハッシュ法を使用できるデータ管理システム及びその方法を提供する。

本発明の一実施形態によれば、データベースミドルウェアを含むデータ管理システムにおいて、データベースミドルウェアは、入力されるクエリに基づいてシャードキー識別子（Ｓｈａｒｄ Ｋｅｙ ＩＤ）を生成し、生成されたシャードキー識別子とシャードメタデータ（Ｓｈａｒｄ ｍｅｔａｄａｔａ）とを用いて決定されたシャード識別子（ｓｈａｒｄ ＩＤ）によって複数のデータベースのうち１つのデータベースを選択するシャードプロセシングモジュールを含むことを特徴とするデータ管理システムを提供する。

また、複数のデータベースは、異種のデータベースを含み、データベースミドルウェアは、異種のデータベースの各々のために、クエリを実行する複数のクライアントライブラリーモジュール（ｃｌｉｅｎｔ ｌｉｂｒａｒｙ ｍｏｄｕｌｅ）をさらに含んでもよい。

また、データベースミドルウェアは、アプリケーション側の接続要求を容認したプロセスに分配するためのジョブキューモジュール（ｊｏｂ ｑｕｅｕｅ ｍｏｄｕｌｅ）、同時に複数のユーザ及びデータベースとの接続を保持して、必要時に接続を再使用するためのコネクションプーリングモジュール（ｃｏｎｎｅｃｔｉｏｎ ｐｏｏｌｉｎｇ ｍｏｄｕｌｅ）、リアルタイムモニタリングによって状態及び統計情報を収集するモニタリングモジュール、ユーザからのデータベース命令を処理するためのデータベースインターフェースモジュール、エラーまたは実行したクエリに対するイベントログを生成するロギングモジュール（ｌｏｇｇｉｎｇ ｍｏｄｕｌｅ）のうち少なくとも１つのモジュールをさらに含んでもよい。

また、シャードプロセシングモジュールは、入力されるクエリに含まれる予め設定されたヒントをさらに用いてシャード識別子を選択してもよい。

また、予め設定されたヒントは、１つのデータベースが１つのシャードキーを有する場合、入力されるクエリを処理するシャード識別子を選択するためにバインド変数またはリテラル値の前に位置するヒントを含んでもよい。

また、予め設定されたヒントは、１つのデータベースが１つのシャードキーを有する場合、シャードキーを有さないテーブルの処理のためのヒントを含んでもよい。

また、予め設定されたヒントは、１つのデータベースが１つのシャードキーを有する場合、すべてのシャードにあるデータを選択するためのヒントを含んでもよい。

また、予め設定されたヒントは、１つのデータベースがいくつかのシャードキーを有する場合、特定シャードキーを選択してデータを選択するためのヒントを含んでもよい。

また、本発明の一実施形態によれば、データベースミドルウェアを含むデータ管理システムでデータを管理する方法であって、データベースミドルウェアが含むシャードプロセシングモジュールにおいて、シャードキー値（ｓｈａｒｄ ｋｅｙ ｖａｌｕｅ）を得るための関数とシャードキー識別子を得るための関数とを実行し、関数のリターン値と、データベースミドルウェアに設定されたシャードメタデータとを用いて複数のデータベースの各々を識別するシャード識別子のうち１つのシャード識別子を選択することを含むデータ管理方法を提供する。

また、本発明の一実施形態によれば、コンピュータシステムがウェブページを提供するように制御する命令（ｉｎｓｔｒｕｃｔｉｏｎ）を含むコンピュータで読み出し可能な記録媒体であって、命令は、シャードキー値を得るための関数とシャードキー識別子を得るための関数とを実行し、関数のリターン値と、データベースミドルウェアに設定されたシャードメタデータとを用いて複数のデータベースの各々を識別するシャード識別子のうち１つのシャード識別子を選択することを含む方法によってコンピュータシステムを制御する、コンピュータで読み出し可能な記録媒体を提供する。

本発明によれば、データベースミドルウェアでシャーディング処理によってアプリケーション側の要求に適した単一データベースを複数のデータベースの中から探してデータを照会及び提供することにより、アプリケーション側の複雑度を減少させることができる。

また、シャードプロセシングモジュールを含むデータベースミドルウェアを用いてアプリケーション側の変更なしにテーブルを追加分割したり、またはデータベースを増設することができる。

また、内部ハッシュ法やユーザによって登録されたハッシュ法などのような多様なハッシュ法を用いることができる。

従来技術に係るデータ管理方法を説明するための図である。 本発明の一実施形態において、データ管理方法を説明するための図である。 本発明の一実施形態において、１つのデータベースが１つのシャードキー（ｓｈａｒｄ ｋｅｙ）を有する場合、データを選択する方法を説明するための図である。 本発明の一実施形態において、１つのデータベースが１つのシャードキーを有する場合、シャードキーを有さないテーブルを処理する方法を示す図である。 本発明の一実施形態において、１つのデータベースが１つのシャードキーを有する場合、すべてのシャードにあるデータを選択する方法を示す図である。 本発明の一実施形態において、１つのデータベースがいくつかのシャードキーを有する場合、データを選択する方法を示す図である。 本発明の一実施形態において、シャードキー識別子の生成及びシャードを選択する方法の一例を示す図である。 本発明の一実施形態において、データ管理システムの内部構成の一例を説明するためのブロック図である。 本発明の一実施形態において、データ管理方法を示すフローチャートである。

以下、本発明の実施形態について図面を参照しながら詳細に説明する。

図２は、本発明の一実施形態において、データ管理方法を説明するための図である。図１及び図２を共に参照すると、図２でも複数のユーザが複数の端末（アプリケーション側）２１０を介して複数のデータベース２２０に格納されたデータを照会する際において、データベースミドルウェア２３０がクエリの入力を受けてデータを処理する様子を示している。ここで、図２でデータベースミドルウェア２３０は、シャードプロセシング（ｓｈａｒｄ ｐｒｏｃｅｓｓｉｎｇ）モジュール２３１を含んでいる。ここで、複数のデータベース２２０は、全て単一データベースの名前（ｎａｍｅ）を有してもよく、複数のシャードに分類されてもよい。

データベースミドルウェア２３０は、シャードプロセシングモジュール２３１を用いてシャードキー識別子を生成し、生成されたシャードキー識別子とシャードメタデータとを用いてシャード（データベース）を選択してもよい。一例として、データベースミドルウェア２３０は、シャードキーをハッシュ関数を用いてハッシュし、ハッシュ値をシャードキー識別子として生成してもよい。ここで、ハッシュ関数は、シャードキー値の入力を受けてハッシュ値を出力してもよく、出力されたハッシュ値をシャードキー識別子として用いてもよい。ここで、シャードメタデータは、一実施形態において、データベースミドルウェア２３０の設定ファイルに含まれてもよい。

また、他の実施形態において、シャードメタデータは、各データベースに含まれてもよい。この場合、データベースミドルウェア２３０は、シャードプロセシングモジュール２３１を用いて少なくとも１つのデータベースに含まれるシャードメタデータを参考にしてシャード識別子を決定してもよい。ここで、データベースミドルウェア２３０は、決定されたシャード識別子を用いてシャード（データベース）を選択してもよい。

このような、データベースミドルウェア２３０は、シャードプロセシングモジュール２３１を用いて適切なデータベースを選択するため、アプリケーション側では複数のデータベース２２０のうち適切なデータベースを直接選択する必要がなくなり、したがって、アプリケーション側の複雑度が減少することになる。また、このようなデータベース選択のために従来技術においてアプリケーション側が含んでいたメタデータをアプリケーション側で含んでいる必要がないため、アプリケーション側の変更なしにテーブルを追加分割したり、またはデータベースを増設することができる。それだけでなく、内部ハッシュ法やユーザによって登録されたハッシュ法などのような多様なハッシュ法を使用できるようになる。

ここで、アプリケーション側でデータベースミドルウェア２３０に伝えられるクエリは、多様な種類のヒント（ｈｉｎｔ）を含んでもよい。以後では、多様な種類のヒントの例を図３〜図５によって詳しく説明する。

図３は、本発明の一実施形態において、１つのデータベースが１つのシャードキーを有する場合、データを選択する方法を説明するための図である。図３は、１つのデータベース３００を示している。ここで、データベース３００には、ユーザテーブル３１０が含まれている。ここで、ユーザテーブル３１０は、各々「ｅｍｐ＿ｎｏ」という名前のカラムを含む３つのテーブル「ｅｍｐ」、「ｅｍｐ＿評価」及び「ｅｍｐ＿経歴」を含んでいる。ここで、図２で説明したデータベースミドルウェア２３０は、一例として、設定ファイルにシャードメタデータを含んでもよく、シャードメタデータは、一例として、「ｅｍｐ＿ｎｏ」と共にテーブルを識別するための情報を含んでもよい。すでに説明したように、シャードメタデータは、他の実施形態で各データベースに含まれてもよい。

ここで、アプリケーション側から伝えられるクエリは、『／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／』のようなヒントを含んでもよい。ヒント『／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／』は、１つのデータベースが１つのシャードキーを有する場合に用いられてもよく、シャードキーカラム（ｃｏｌｕｍｎ）に該当するリテラル値の前に位置してもよく、バインド変数のための『？』の前に位置してもよい。下の一例として、提供されたクエリで最初と３番目目の「ＳＥＬＥＣＴ」文では、バインド変数を示す『？』の前にヒント『／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／』が位置する様子を示しており、２番目の「ＳＥＬＥＣＴ」の文では、シャードキーカラムの値である「１」の前にヒント『／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／』が位置する様子を示している。

ＳＥＬＥＣＴ＊ＦＲＯＭ ｅｍｐ
ＷＨＥＲＥ ｅｍｐ＿ｎｏ＝／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／？
ＳＥＬＥＣＴ＊ＦＲＯＭ ｅｍｐ＿評価
ＷＨＥＲＥ ｅｍｐ＿ｎｏ＝／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／１
ＳＥＬＥＣＴ＊ＦＲＯＭ ｅｍｐ＿経歴
ＷＨＥＲＥ ｅｍｐ＿ｎｏ ＩＮ｛／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／？、／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／？｝

図４は、本発明の一実施形態において、１つのデータベースが１つのシャードキーを有する場合、シャードキーを有さないテーブルを処理する方法を示す図である。図４は、１つのデータベース４００を示している。ここで、データベース４００は、ユーザテーブル４１０を含んでいる。ここで、ユーザテーブル４１０は各々「ｅｍｐ＿ｎｏ」という名前のカラムを含む２つのテーブル「ｅｍｐ」及び「ｅｍｐ＿評価」と、シャードキーを有さないテーブル「ｗｉｔｈｏｕｔ＿ｓｈａｒｄ＿ｔａｂｌｅ」とを含んでいる。

ここで、図２で説明したデータベースミドルウェア２３０には、シャードメタデータが含まれてもよく、シャードメタデータは、一例として、「ｅｍｐ＿ｎｏ」と共に必要なテーブルを識別するための情報を含んでもよい。すでに説明したように、シャードメタデータは、他の実施形態で各データベースに含まれてもよい。

この場合、クエリは、ヒントとして『／＊＋ＳＨＡＲＤ＿ＶＡＬ（ｖａｌｕｅ）＊／』を含んでもよい。ヒント『／＊＋ＳＨＡＲＤ＿ＶＡＬ（ｖａｌｕｅ）＊／』は、１つのデータベース４００が１つのシャードキーを有する場合、シャードキーを有さないテーブル「ｗｉｔｈｏｕｔ＿ｓｈａｒｄ＿ｔａｂｌｅ」の処理のために用いられてもよい。例えば、下のクエリと共にクエリにヒントを含んでもよい。

ＳＥＬＥＣＴ＊ＦＲＯＭ ｅｍｐ
ＷＨＥＲＥ ｅｍｐ＿ｎｏ＝／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／？
…
ＳＥＬＥＣＴ＊ＦＲＯＭ ｗｉｔｈｏｕｔ＿ｓｈａｒｄ＿ｔａｂｌｅ
ＷＨＥＲＥ／＊＋ＳＨＡＲＤ＿ＶＡＬ１＊／ｎｏ＝「ａ」

２番目の「ＳＥＬＥＣＴ」文では、臨時シャードキー値の「１」を用いてシャードキーがないテーブル「ｗｉｔｈｏｕｔ＿ｓｈａｒｄ＿ｔａｂｌｅ」でｎｏカラムの値が「ａ」であるデータを照会する様子を示している。

図５は、本発明の一実施形態において、１つのデータベースが１つのシャードキーを有する場合、すべてのシャードにあるデータを選択する方法を示す図である。図５は、「ｓｈａｒｄ １」で識別されるデータベース５１０と「ｓｈａｒｄ ２」で識別されるデータベース５２０とを示している。ここで、データベース５１０及びデータベース５２０は、全て同一のデータベースの名前を有してもよい。各データベース（５１０及び５２０）は、「ｅｍｐ＿ｎｏ」という名前のカラムを含むテーブル「ｅｍｐ」を含む。ここで、ヒント『／＊＋ＳＨＡＲＤ＿ＡＬＬ＊／』を用いてもよい。

ＳＥＬＥＣＴ＊ＦＲＯＭ ｅｍｐ
ＷＨＥＲＥ ｅｍｐ＿ｎｏ＝／＊＋ＳＨＡＲＤ＿ＫＥＹ＊／？
…
ＳＥＬＥＣＴ＊ＦＲＯＭ ｅｍｐ／＊＋ＳＨＡＲＤ＿ＡＬＬ＊／

ここで、最初の「ＳＥＬＥＣＴ」文において、「？」の値によって「ｓｈａｒｄ １」または「ｓｈａｒｄ ２」がダイナミックにバインディングされて、バインディングされたデータベースからデータがリターンされてもよい。

また、ヒント『／＊＋ＳＨＡＲＤ＿ＡＬＬ＊／』は、「ｓｈａｒｄ １」のデータと「ｓｈａｒｄ ２」のデータとが全てリターンされることを意味してもよい。ここで、アプリケーション側は、「ｇｅｔＭｏｒｅＲｅｓｕｌｔ ＡＰＩ」を介して「ｓｈａｒｄ １」のデータを全て受けた後、「ｓｈａｒｄ ２」のデータを受けてもよい。

図６は、本発明の一実施形態において、１つのデータベースがいくつかのシャードキーを有する場合、データを選択する方法を示す図である。データベース６００は、ユーザテーブル６１０を含んでいる。

ここで、ユーザテーブル６１０は、各々「ｅｍｐ＿ｎｏ」という名前のカラムを含む２つのテーブル「ｅｍｐ」及び「ｅｍｐ＿評価」を有しており、「ｌｅｖｅｌ」という名前のカラムを含む「力量レベル」テーブルをさらに有している。ここで、図２で説明したデータベースミドルウェア２３０は、シャードメタデータを含んでもよく、シャードメタデータは、一例として、「ｅｍｐ＿ｎｏ」及び「ｌｅｖｅｌ」のような必要なテーブル及びレベルを識別するための情報を含んでもよい。すでに説明したように、シャードメタデータは、他の実施形態で各データベースに含まれてもよい。

この場合、ヒント『／＊＋ＳＨＡＲＤ＿ＫＥＹ（ｎａｍｅ）／』を用いてもよい。ここで、「ｎａｍｅ」は、必要な「ｌｅｖｅｌ」に対応してもよい。すなわち、下の３番目の「ＳＥＬＥＣＴ」文では、１つのデータベース６００が含む複数のシャードキーのうちで必要なシャードキーを「ｌｅｖｅｌ」を介して選択するために、ヒント『／＋ＳＨＡＲＤ＿ＫＥＹ（ｎａｍｅ）＊／』を用いる様子を示している。

ＳＥＬＥＣＴ＊ＦＲＯＭ ｅｍｐ
ＷＨＥＲＥ ｅｍｐ＿ｎｏ＝／＊＋ＳＨＡＲＤ＿ＫＥＹ（ｅｍｐ＿ｎｏ）＊／？
ＳＥＬＥＣＴ＊ＦＲＯＭ ｅｍｐ＿評価
ＷＨＥＲＥ ｅｍｐ＿ｎｏ＝／＊＋ＳＨＡＲＤ＿ＫＥＹ（ｅｍｐ＿ｎｏ）＊／１
…
ＳＥＬＥＣＴ＊ＦＲＯＭ力量レベル
ＷＨＥＲＥ ｌｅｖｅｌ＝／＊＋ＳＨＡＲＤ＿ＫＥＹ （ｌｅｖｅｌ）＊／？

図７は、本発明の一実施形態において、キー識別子の生成及びシャードを選択する方法の一例を示す図である。図７は、データベースミドルウェア７１０、「ｓｈａｒｄ １」で識別されるデータベース７２０、及び「ｓｈａｒｄ ２」で識別されるデータベース７３０を示している。ここで、データベース７２０は、ユーザテーブル７２１を含んでおり、データベース７３０は、ユーザテーブル７３１を含んでいる。

ここで、クエリ７４０がデータベースミドルウェア７１０に入力されると、データベースミドルウェア７１０は、データベースミドルウェア７１０が提供する算出方式またはユーザ定義関数を使用してシャードキーに対するハッシュ値を算出してもよく、得られたハッシュ値を用いてデータベースミドルウェア７１０が含むシャードメタデータの内容によってルールを適用してシャード識別子を選択してクエリを実行してもよい。ここで、シャードメタデータは、他の実施形態として各データベースに含まれてもよい。

すでに何度か説明したように、複数のデータベースは、複数のシャードに分類されてもよい。一例として、Ｎ個のデータベースがＭ個のシャードに分類されてもよい。この場合、ＮとＭとは全て整数で、ＮはＭよりもさらに大きいか同じであってもよい。もし、１つのシャードに分類されるデータベースが複数である場合、１つのシャードに分類されるデータベースは、互いに同一機種のデータベースであってもよい。

図７の例では、「４５」というシャードキー識別子を用いてデータベースミドルウェア７１０のシャードメタデータを照会し、必要なシャード識別子が「１」であることを確認して「ｓｈａｒｄ １」で識別されるデータベース７２０を選択してクエリを実行する様子を示している。

クエリには、１つのシャードキー値当たり１つのシャードキーヒント（ＳＨＡＲＤ＿ＫＥＹ Ｈｉｎｔ）が含まれてもよく、１つ以上のシャードキーヒントが用いられる場合、各ヒントは同一のシャード識別子に対して適用してもよい。また、シャード（Ｓｈａｒｄ）を越える結合クエリ（ＪＯＩＮ ｑｕｅｒｙ）は、サポートしなくてもよい。

本実施形態に係るデータ管理システムは、データベースミドルウェアを含んでもよく、データベースミドルウェアは、シャードプロセシングモジュールを含んでもよい。ここで、シャードプロセシングモジュールは、入力されるクエリに基づいてシャードキー識別子を生成し、生成されたシャードキーとデータベースミドルウェアに設定されたシャードメタデータとを用いてシャード識別子を選択してもよい。ここで、データベースミドルウェアは、選択されたシャード識別子によって複数のデータベースのうち１つのデータベースを選択してもよい。一例として、データベースミドルウェア２３０は、シャードキーをハッシュ関数を用いてハッシュし、ハッシュ値をシャードキー識別子として生成してもよい。

ここで、複数のデータベースは、異種のデータベースを含んでもよい。ただし、１つのシャードに分類されるデータベースは、同一機種のデータベースで構成してもよい。ここで、データベースミドルウェアは、異種のデータベースの各々のために、クエリを実行する複数のクライアントライブラリー（Ｃｌｉｅｎｔ Ｌｉｂｒａｒｙ）モジュールを必要に応じてさらに含んでもよい。また、データベースミドルウェアは、必要に応じてアプリケーション側の接続要求を容認したプロセスに分配するためのジョブキュー（Ｊｏｂ Ｑｕｅｕｉｎｇ）モジュール、同時に複数のユーザ及びデータベースとの接続を保持し、必要時に接続を再使用するためのコネクションプーリング（Ｃｏｎｎｅｃｔｉｏｎ Ｐｏｏｌｉｎｇ）モジュール、リアルタイムモニタリングによって状態及び統計情報を収集するモニタリング（Ｍｏｎｉｔｏｒｉｎｇ）モジュール、ユーザからのデータベース命令を処理するためのデータベースインターフェース（ＤＢ Ｉｎｔｅｒｆａｃｅ）モジュール、エラーまたは行ったクエリに対するイベントログを生成するロギング（Ｌｏｇｇｉｎｇ）モジュールのうち少なくとも１つのモジュールをさらに含んでもよい。

ここで、シャードプロセシングモジュールは、入力されるクエリに含まれる予め設定されたヒントをさらに用いてシャード識別子を選択してもよい。予め設定されたヒントは、１つのデータベースが１つのシャードキーを有する場合、入力されるクエリを処理するシャード識別子を選択するためにシャードキー値（バインド変数またはリテラル値）の前に位置するヒント、１つのデータベースが１つのシャードキーを有する場合、シャードキーを有さないテーブルの処理のためのヒント、１つのデータベースが１つのシャードキーを有する場合、すべてのシャードにあるデータを選択するためのヒント、及び１つのデータベースがいくつかのシャードキーを有する場合、特定のシャードキーを選択してデータを選択するためのヒントのうち少なくとも１つのヒントを含んでもよい。それぞれのヒントについては、図３〜図６によってすでに詳しく説明した。

図８は、本発明の一実施形態において、データ管理システムの内部構成の一例を説明するためのブロック図である。図８では、アプリケーション側として「ＤＢ Ｍｉｄｄｌｅｗａｒｅ Ｉｎｔｅｒｆａｃｅ（データベースミドルウェアインターフェース）」８１０と、データベースミドルウェアとして「ＤＢ Ｍｉｄｄｌｅｗａｒｅ」８２０と、そして異種のデータベースとして互いに異なる種類の３つのデータベース（「ＣＵＢＲＩＤ」、「Ｏｒａｃｌｅ」及び「ＭｙＳＱＬ」）８３０とを各々示している。

ここで、「ＤＢ Ｍｉｄｄｌｅｗａｒｅ」８２０は、上述したモジュールをすべて含む一例を示している。また、「ＤＢ Ｍｉｄｄｌｅｗａｒｅ Ｉｎｔｅｒｆａｃｅ」８１０は、ジャバプログラムのうちでＳＱＬを実行するためにデータベースを接続するアプリケーションインターフェースの「ＪＤＢＣ（Ｊａｖａ（登録商標） ｄａｔａ ｂａｓｅ ｃｏｎｎｅｃｔｉｖｉｔｙ）」を含む一例を示している。

図９は、本発明の一実施形態において、データ管理方法を示すフローチャートである。

ステップＳ９１０において、データ管理システムは、シャードキー値を得るための関数とシャードキー識別子を得るための関数とを実行する。ここで、シャードキー識別子は、シャードキー値をハッシュしたハッシュ値として生成されてもよい。すなわち、シャードキー識別子を得るための関数は、シャードキー値をハッシュするためのハッシュ関数であってもよい。

ステップＳ９２０において、データ管理システムは、関数のリターン値と、データベースミドルウェアに設定されたシャードメタデータとを用いて複数のデータベースの各々を識別するシャード識別子のうち１つのシャード識別子を選択する。

このようなステップＳ９１０及びステップＳ９２０は、データ管理システムが含むデータベースミドルウェアを介して、特にデータベースミドルウェアが含むシャードプロセシングモジュールによって実行してもよい。

ここで、複数のデータベースは、異種のデータベースを含んでもよい。ただし、１つのシャードに分類されるデータベースは、互いに同一の機種のデータベースで構成してもよい。ここで、データベースミドルウェアは、異種のデータベースの各々のために、クエリを実行する複数のクライアントライブラリーモジュールをさらに含んでもよい。また、データベースミドルウェアは、アプリケーション側の接続要求を容認したプロセスに分配するためのジョブキューモジュール、同時に複数のユーザ及びデータベースとの接続を保持して、必要時に接続を再使用するためのコネクションプーリングモジュール、リアルタイムモニタリングによって状態及び統計情報を収集するモニタリングモジュール、ユーザからのデータベース命令を処理するためのデータベースインターフェースモジュール、エラーまたは実行したクエリに対するイベントログを生成するロギングモジュールのうち少なくとも１つのモジュールをさらに含んでもよい。

また、ステップＳ９２０において、データ管理システムは、入力されるクエリに含まれる予め設定されたヒントをさらに用いてシャード識別子を選択してもよい。１つのデータベースが１つのシャードキーを有する場合、入力されるクエリを処理するシャード識別子を選択するためにシャードキー値（バインド変数またはリテラル値）の前に位置するヒント、１つのデータベースが１つのシャードキーを有する場合、シャードキーを有さないテーブルの処理のためのヒント、１つのデータベースが１つのシャードキーを有する場合、すべてのシャードにあるデータを選択するためのヒント、及び１つのデータベースがいくつかのシャードキーを有する場合、特定のシャードキーを選択してデータを選択するためのヒントのうち少なくとも１つのヒントを含んでもよい。それぞれのヒントについては、図３〜図６によってすでに詳しく説明した。

このように、本発明の実施形態によれば、データベースミドルウェアでシャーディング処理によってアプリケーション側の要求に適した単一データベースを複数のデータベースの中から探してデータを照会及び提供することにより、アプリケーション側の複雑度を減少させることができる。また、シャードプロセシングモジュールを含むデータベースミドルウェアを用いてアプリケーション側の変更なしにテーブルを追加分割したり、またはデータベースを増設してもよく、内部ハッシュ法やユーザによって登録されたハッシュ法などのような多様なハッシュ法を用いてもよい。

本発明の実施形態に係る方法は、多様なコンピュータ手段によって行うことができるプログラム命令形態で実現され、コンピュータ読み出し可能媒体に記録してもよい。前記記録媒体は、プログラム命令、データファイル、データ構造などを単独または組み合わせたものを含んでもよい。前記記録媒体及びプログラム命令は、本発明の目的のために特別に設計して構成されたものでもよく、コンピュータソフトウェア分野の技術を有する当業者にとって公知のものであり使用可能なものであってもよい。

上述したように本発明を限定された実施形態と図面によって説明したが、本発明は、上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態から多様な修正及び変形が可能である。

したがって、本発明の範囲は、開示された実施形態に限定されて定められるものではなく、特許請求の範囲及び特許請求の範囲と均等なものなどによって定められるものである。

２３０：データベースミドルウェア
２３１：シャードプロセシングモジュール

Claims (11)

1. データベースミドルウェアを含むデータ管理システムにおいて、
   前記データベースミドルウェアは、
   入力されるクエリに基づいてシャードキー識別子を生成し、前記生成されたシャードキー識別子とシャードメタデータとを用いて決定されたシャード識別子によって複数のデータベースのうち１つのデータベースを選択するシャードプロセシングモジュールを含むことを特徴とするデータ管理システム。
2. 前記複数のデータベースは、異種のデータベースを含み、
   前記データベースミドルウェアは、
   前記異種のデータベースの各々のために、クエリを実行する複数のクライアントライブラリーモジュールをさらに含むことを特徴とする請求項１に記載のデータ管理システム。
3. 前記データベースミドルウェアは、
   アプリケーション側の接続要求を容認したプロセスに分配するためのジョブキューモジュール、同時に複数のユーザ及びデータベースとの接続を保持して、必要時に接続を再使用するためのコネクションプーリングモジュール、リアルタイムモニタリングによって状態及び統計情報を収集するモニタリングモジュール、ユーザからのデータベース命令を処理するためのデータベースインターフェースモジュール、エラーまたは実行したクエリに対するイベントログを生成するロギングモジュールのうち少なくとも１つのモジュールをさらに含むことを特徴とする請求項１または請求項２項に記載のデータ管理システム。
4. 前記シャードプロセシングモジュールは、
   前記入力されるクエリに含まれる予め設定されたヒントをさらに用いて前記シャード識別子を選択することを特徴とする請求項１から請求項３のいずれか一項に記載のデータ管理システム。
5. 前記予め設定されたヒントは、
   （１）１つのデータベースが１つのシャードキーを有する場合、前記入力されるクエリを処理するシャード識別子を選択するためにバインド変数またはリテラル値の前に位置するヒントを含み、
   （２）１つのデータベースが１つのシャードキーを有する場合、シャードキーを有さないテーブルの処理のためのヒントを含み、
   （３）１つのデータベースが１つのシャードキーを有する場合、すべてのシャードにあるデータを選択するためのヒントを含み、
   （４）１つのデータベースがいくつかのシャードキーを有する場合、特定のシャードキーを選択してデータを選択するためのヒントを含む、ことを特徴とする請求項４に記載のデータ管理システム。
6. データベースミドルウェアを含むデータ管理システムでデータを管理する方法であって、
   前記データベースミドルウェアが含むシャードプロセシングモジュールにおいて、
   シャードキー値を得るための関数とシャードキー識別子を得るための関数とを実行し、
   前記関数のリターン値と、前記データベースミドルウェアに設定されたシャードメタデータとを用いて前記複数のデータベースの各々を識別するシャード識別子のうち１つのシャード識別子を選択すること、
   を含むデータ管理方法。
7. 前記複数のデータベースは、異種のデータベースを含み、
   前記データベースミドルウェアは、
   前記異種のデータベースの各々のために、クエリを実行する複数のクライアントライブラリーモジュールをさらに含むことを特徴とする請求項６に記載のデータ管理方法。
8. 前記データベースミドルウェアは、
   アプリケーション側の接続要求を容認したプロセスに分配するためのジョブキューモジュール、同時に複数のユーザ及びデータベースとの接続を保持して、必要時に接続を再使用するためのコネクションプーリングモジュール、リアルタイムモニタリングによって状態及び統計情報を収集するモニタリングモジュール、ユーザからのデータベース命令を処理するためのデータベースインターフェースモジュール、エラーまたは実行したクエリに対するイベントログを生成するロギングモジュールのうち少なくとも１つのモジュールをさらに含むことを特徴とする請求項６または請求項７項に記載のデータ管理方法。
9. 前記シャード識別子を選択することは、
   前記入力されるクエリに含まれる予め設定されたヒントをさらに用いて前記シャード識別子を選択することを特徴とする請求項６から請求項８のいずれか一項に記載のデータ管理方法。
10. 前記予め設定されたヒントは、
    （１）１つのデータベースが１つのシャードキーを有する場合、前記入力されるクエリを処理するシャード識別子を選択するためにバインド変数またはリテラル値の前に位置するヒントを含み、
    （２）１つのデータベースが１つのシャードキーを有する場合、シャードキーを有さないテーブルの処理のためのヒントを含み、
    （３）１つのデータベースが１つのシャードキーを有する場合、すべてのシャードにあるデータを選択するためのヒントを含み、
    （４）１つのデータベースがいくつかのシャードキーを有する場合、特定のシャードキーを選択してデータを選択するためのヒントを含む、ことを特徴とする請求項９に記載のデータ管理方法。
11. 請求項６から請求項１０のいずれか一項に係る方法を実行するプログラムを記録したコンピュータ読み出し可能記録媒体。

Images