JP2013077205A - データベース要求処理装置及びプログラム - Google Patents
データベース要求処理装置及びプログラム Download PDFInfo
- Publication number
- JP2013077205A JP2013077205A JP2011217287A JP2011217287A JP2013077205A JP 2013077205 A JP2013077205 A JP 2013077205A JP 2011217287 A JP2011217287 A JP 2011217287A JP 2011217287 A JP2011217287 A JP 2011217287A JP 2013077205 A JP2013077205 A JP 2013077205A
- Authority
- JP
- Japan
- Prior art keywords
- request
- key
- value
- sql
- column
- 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
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
【課題】 RDBの使用を前提とした既存システムを改変せずにキー/バリュー型DB3の環境へ移行可能とする。
【解決手段】 実施形態の変換モジュール判定部は、既存システムから送出された要求SQLに基づいて、変換モジュールセット内の要求SQL解析モジュールを順次実行し、解析に成功した要求SQL解析モジュールを備えた変換モジュールセットを使用する旨を判定する。実施形態のDB呼び出し実行部は、判定された変換モジュールセットを用い、要求SQLをキー/バリュー型DBに対する要求に変換して当該変換後の要求を実行処理した処理結果を示す戻り値を得る。実施形態のDB呼び出し結果変換部は、判定された変換モジュールセットを用い、得られた戻り値を要求SQLの処理結果を示す戻り値に変換する。実施形態のDB要求処理部は、変換された戻り値を既存システムに送出する。
【選択図】図1
【解決手段】 実施形態の変換モジュール判定部は、既存システムから送出された要求SQLに基づいて、変換モジュールセット内の要求SQL解析モジュールを順次実行し、解析に成功した要求SQL解析モジュールを備えた変換モジュールセットを使用する旨を判定する。実施形態のDB呼び出し実行部は、判定された変換モジュールセットを用い、要求SQLをキー/バリュー型DBに対する要求に変換して当該変換後の要求を実行処理した処理結果を示す戻り値を得る。実施形態のDB呼び出し結果変換部は、判定された変換モジュールセットを用い、得られた戻り値を要求SQLの処理結果を示す戻り値に変換する。実施形態のDB要求処理部は、変換された戻り値を既存システムに送出する。
【選択図】図1
Description
本発明の実施形態は、データベース要求処理装置及びプログラムに関する。
クラウドコンピューティング環境では、従来から広く用いられているRDB(Relational Database)ではなく、キー/バリュー(Key/Value)型のDBが用いられるようになってきている。このため、RDBを使用した既存システムをキー/バリュー型DBを用いる環境に移行させる必要が出てきている。
しかしながら、RDBを使用した既存システムをキー/バリュー型DBを用いる環境に移行させる場合、既存システムにおけるRDBにアクセスする部分のアプリケーションを改変する必要がある。この改変は、RDBにアクセスする全てのアプリケーションについて行う必要があるので、多くの労力と時間を要する不都合がある。
本明細書に開示した実施形態は、RDBの使用を前提とした既存システムを改変せずにキー/バリュー型DBの環境へ移行させることが可能なデータベース要求処理装置及びプログラムを提供することを目的とする。
実施形態のデータベース要求処理装置は、複数のカラム名と、各カラム名に対応するデータとを有してテーブル名により識別される複数のテーブルを備えたRDBに対してテーブル名、カラム名及びデータを含む要求SQLを送出して要求SQLに応じた戻り値を受ける既存システムに対し、要求SQLをキー/バリュー型DBに対する要求に変換して実行処理する。
ここで、実施形態のデータベース要求処理装置は、RDBスキーマ情報管理部、RDBデータ変換登録部、変換モジュールセット管理部、変換モジュール判定部、DB呼び出し実行部、DB呼び出し結果変換部及びDB要求処理部を備えている。
実施形態のRDBスキーマ情報管理部は、テーブル名及びテーブルIDを関連付けてなるテーブル一覧を記憶する。また、実施形態のRDBスキーマ情報管理部は、テーブルID、カラムID、カラム名及びデータ型を関連付けてなるカラム情報を記憶する。
実施形態のRDBデータ変換登録部は、テーブルID、カラムID及び同一行識別子を含む座標キーと、データキーを示す値とを関連付けてなる第1のキー/バリュー型データをキー/バリュー型DBに書き込む。また、実施形態のRDBデータ変換登録部は、データキーと、座標キーにより特定される前記データを示す値とを関連付けてなる第2のキー/バリュー型データをキー/バリュー型DBに書き込む。
実施形態の変換モジュールセット管理部は、要求SQLの種別毎に、変換モジュールセットを記憶している。変換モジュールセットとしては、要求SQLを解析して種別に合う場合には解析が成功し、種別に合わない場合には解析が失敗する手段としてデータベース要求処理装置本体を機能させるための要求SQL解析モジュールと、解析が成功した要求SQL解析モジュールに起動され、要求SQLをキー/バリュー型DBに対する要求に変換して当該キー/バリュー型DBに対する要求を実行処理する手段としてデータベース要求処理装置本体を機能させるための要求実行モジュールと、キー/バリュー型DBに対する要求の処理結果を示す戻り値を要求SQLの処理結果を示す戻り値に変換する手段としてデータベース要求処理装置本体を機能させるための戻り値変換モジュールとを備えている。
実施形態の変換モジュール判定部は、既存システムから送出された要求SQLに基づいて、変換モジュールセット内の要求SQL解析モジュールを順次実行し、解析に成功した要求SQL解析モジュールを備えた変換モジュールセットを使用する旨を判定する。
実施形態のDB呼び出し実行部は、判定された変換モジュールセットを用い、要求SQLをキー/バリュー型DBに対する要求に変換して当該キー/バリュー型DBに対する要求を実行処理した処理結果を示す戻り値を得る。
実施形態のDB呼び出し結果変換部は、判定された変換モジュールセットを用い、得られた戻り値を要求SQLの処理結果を示す戻り値に変換する。
実施形態のDB要求処理部は、変換された戻り値を既存システムに送出する。
以下、実施形態について図面を用いて説明する。なお、以下のデータベース要求処理装置は、ハードウェア構成、又はハードウェア資源とソフトウェアとの組合せ構成のいずれでも実施可能となっている。組合せ構成のソフトウェアとしては、予めネットワーク又は記憶媒体からデータベース要求処理装置となるコンピュータにインストールされ、データベース要求処理装置の機能を実現させるためのプログラムが用いられる。
図1は実施形態に係るデータベース要求処理装置及びその周辺構成を示すブロック図であり、図2乃至図10は同実施形態における各情報を示す模式図である。このデータベース要求処理装置は、既存システム1と、既存のRDB2及びキー/バリュー型DB3との間に介在して設けられている。具体的には、データベース要求処理装置は、RDBスキーマ情報管理部11、RDBスキーマ情報取得部12、RDBデータ変換登録部13、キー生成部14、変換モジュールセット管理部15、DB要求処理部16、要求管理部17、変換モジュール判定部18、DB呼び出し実行部19及びDB呼び出し結果変換部20を備えている。
既存システム1は、以前からRDB2に接続して処理を行なっていたシステムである。具体的には、既存システム1は、RDB2に対してテーブル名、カラム名及びデータを含む要求SQLを送出して当該要求SQLに応じた戻り値を受けることにより、処理を実行している。
RDB2は、複数のカラム名と、各カラム名に対応するデータとを有してテーブル名により識別される複数のテーブルを備えており、既存システム1から受けた要求SQLを受けると、この要求SQLに応じた戻り値を既存システム1に送出する機能をもっている。但し、この例では、この機能はデータベース要求処理装置が実行するので、RDB2はこの機能を実行しない。RDB2は、図2及び図3に一例を示すように、従業員テーブル2aとテーマ管理テーブル2bの2つのテーブルを記憶している。
RDBスキーマ情報管理部11は、RDB2のスキーマとして、テーブル一覧11a、カラム情報11b、カラム対応関係情報11cを格納する。
ここで、テーブル一覧11aは、図4に示すように、RDB2に格納されているテーブルのテーブル名を一覧して示すように、テーブル名及びテーブルIDが関連付けられており、ここでは更に結合情報が関連付けられている。テーブルIDは、テーブルごとに付けられたユニークなIDである。
カラム情報11bは、図5に示すように、各テーブルのテーブルID、カラムID、カラム名及びデータ型を関連付けてなる情報であり、ここでは更に補足情報、主キーであることを示す情報及び外部キーを示す情報が関連付けられている。カラムIDは、各テーブルのカラムに付けられたユニークなIDである。
カラム対応関係情報11cは、図6に一例を示すように、各テーブル(Table100,Table200)を結合した結合テーブル(Table300)がある場合に、結合テーブルの各カラムが元のテーブルのどのカラムに対応しているかを示す情報であり、図6に示すように、結合テーブルのテーブルID、結合テーブルのカラムID、結合テーブルのカラム名、結合元のテーブルのテーブルIDを示す対応テーブルID、結合元のテーブルのカラムIDを示す対応カラムID、及び重複するデータに関する結合元の他のテーブルのテーブルIDとカラムIDとを示す結合条件、を関連付けてなる情報である。
キー/バリュー型DB3は、通常のキー/バリュー型DB3であるが、本実施形態では主に、図7に示すように、座標キーをキーとしてデータキーを値(バリュー)とした第1のキー/バリュー型データ3aと、データキーをキーとしてデータを値(バリュー)とした第2のキー/バリュー型データ3bとを記憶する。なお、図7中、両データ3a,3b間の矢印は、同じデータキーを結んで対応関係を見易く表したものである。実際に両データ3a,3b間に矢印のデータがあることを示したものではない。
ここで、座標キーは、テーブルID、カラムID及び同一行識別子という3つの値から構成されている。同一行識別子は、RDB2の各テーブル内において、当該データが同一行にあることを示すIDであり、ユニークなIDである必要がある。このため、UUID(Universally Unique Identifier)などを用い、キー/バリュー型DB3にデータを挿入する際にキー生成部14により発行される。
RDBスキーマ情報取得部12は、既存システム1が本来アクセスしていたRDB2が存在し、アクセスできる場合、RDB2のスキーマ情報を収集し、テーブル一覧11a、カラム情報11b及びカラム対応関係情報11cをRDBスキーマ情報管理部11に書き込む機能をもっている。
また、RDBスキーマ情報取得部12は、図8に示す如き、各テーブル2a,2bを結合した結合テーブル2cに関し、テーブル一覧11a内のテーブルIDの値として当該結合テーブル2cのテーブルIDの値を書き込むと共に、当該書き込まれたテーブルIDの値に関連付けて結合元の各テーブルの各テーブルIDを示す結合情報を書き込む機能をもっている。なお、図8に示した例は、社員番号により結合している。結合関係のイメージを図9に示し、結合情報の例を図10に示す。
RDBデータ変換登録部13は、既存システム1が本来アクセスしていたRDB2が存在し、アクセスできる場合、RDB2に格納されているデータを取得し、キー/バリュー型DB3へ格納する。
具体的には、RDBデータ変換登録部13は、RDB2内のデータに関し、テーブルID、カラムID及びデータをキー生成部14に送出し、キー生成部14から座標キーとデータキーとを受ける機能と、テーブルID、カラムID及び同一行識別子を含む座標キーと、データキーを示す値とを関連付けてなる第1のキー/バリュー型データ3aをキー/バリュー型DB3に書き込む機能と、データキーと、座標キーにより特定されるデータを示す値とを関連付けてなる第2のキー/バリュー型データ3bをキー/バリュー型DB3に書き込む機能とをもっている。
また、RDBデータ変換登録部13は、結合テーブル2cのテーブルID(Table300)、結合テーブル2cのカラムID及び同一行識別子を含む座標キーと、データキーを示す値とを関連付けてなる第3のキー/バリュー型データをキー/バリュー型DB3に書き込む機能とをもっている。
キー生成部14は、RDBデータ変換登録部13から受けるテーブルID、カラムID及びデータに基づいて、キー/バリュー型DB3へ当該データを登録する際のデータキーと座標キーを生成する機能をもっている。
変換モジュールセット管理部15は、変換モジュールセットを管理する。変換モジュールセットMSiの追加、削除、変更などの管理を行う。また、変換モジュール判定部18、DB呼び出し実行部19、DB呼び出し結果変換部20からの要求により変換モジュールセットMSiを実行する。
変換モジュールセットMSiは、要求SQL解析モジュールMia、要求実行モジュールMib、戻り値変換モジュールMicからなり(但し、i=1,2,…)、要求SQLの種別ごとに用意される。
要求SQL解析モジュールMiaは、要求SQLを解析し、当該変換モジュールセットで処理できるか否かを判断する。また、要求実行モジュールMibからの要求に対し、対象となるテーブルやカラムなどのデータを要求SQLから抽出する。
戻り値変換モジュールMicは、キー/バリュー型DB3からの戻り値をあたかもRDB2からの戻り値のように変換するモジュールである。
換言すると、変換モジュールセット管理部15は、要求SQLの種別毎に、変換モジュールセットMS1,MS2,…を記憶している。変換モジュールセットMS1,MS2,…としては、要求SQLを解析して種別に合う場合には解析が成功し、種別に合わない場合には解析が失敗する手段としてデータベース要求処理装置本体を機能させるための要求SQL解析モジュールM1a,M2a,…と、解析が成功した要求SQL解析モジュールMiaに起動され、要求SQLをキー/バリュー型DBに対する要求に変換して当該キー/バリュー型DBに対する要求を実行処理する手段としてデータベース要求処理装置本体を機能させるための要求実行モジュールMibと、キー/バリュー型DB3に対する要求の処理結果を示す戻り値を要求SQLの処理結果を示す戻り値に変換する手段としてデータベース要求処理装置本体を機能させるための戻り値変換モジュールMicとを備えている。
DB要求処理部16は、既存システム1からRDB2向けの要求SQLを受け取り、DB呼び出し結果変換部20により変換された戻り値を(あたかもRDB2からの戻り値であるように)既存システム1に送出する機能をもっている。
要求管理部17は、既存システム1からの要求に対し、要求IDを発行し、この要求ID、要求のSQL(Structured Query Language)、当該要求を処理する変換モジュールセットMS1,MS2,…の名称、キー/バリュー型DB3からの戻り値、及び要求SQLに対する戻り値、を関連付けて要求管理テーブル17aに格納する。
変換モジュール判定部18は、既存システム1からの要求SQLをどの変換モジュールセットMS1,MS2,…で処理するかを判定する。判定方法としては、各変換モジュールセットMS1,MS2,…が持つ要求SQL解析モジュールを用いて要求SQLを解析して解析に成功する変換モジュールセットMSiを使用する。
換言すると、変換モジュール判定部18は、既存システム1から送出された要求SQLに基づいて、変換モジュールセット内の要求SQL解析モジュールM1a,M2a,…を順次実行し、解析に成功した要求SQL解析モジュールMiaを備えた変換モジュールセットMSiを使用する旨を判定する機能をもっている。
DB呼び出し実行部19は、判定された変換モジュールセットMSiを用い、要求SQLをキー/バリュー型DB3に対する要求に変換して当該キー/バリュー型DB3に対する要求を実行処理した処理結果を示す戻り値を得る機能をもっている。
DB呼び出し結果変換部20は、判定された変換モジュールセットMSiを用い、DB呼び出し実行部19により得られた戻り値を要求SQLの処理結果を示す戻り値に変換する機能をもっている。
次に、以上のように構成されたデータベース要求処理装置の動作について説明する。
始めに、キー/バリュー型DB3をRDB2のように見せかけるには、元のRDB2のスキーマ情報をRDBスキーマ情報管理部11に格納しておく必要がある。
このとき、図11に事前準備の動作を示すように、既存のRDB2にアクセスできる場合(ST10:YES)には、RDBスキーマ情報取得部12が既存のRDB2から情報を収集し、RDBスキーマ情報管理部11にテーブル一覧11a及びカラム情報11bを格納する(ST20)。
このとき、図11に事前準備の動作を示すように、既存のRDB2にアクセスできる場合(ST10:YES)には、RDBスキーマ情報取得部12が既存のRDB2から情報を収集し、RDBスキーマ情報管理部11にテーブル一覧11a及びカラム情報11bを格納する(ST20)。
既存のRDB2にアクセスできない場合には、RDBスキーマ情報取得部12は、ユーザの操作に応じて、RDBスキーマ情報管理部11にテーブル一覧11a及びカラム情報11bを格納する(ST30)。
また、RDBスキーマ情報取得部12は、テーブルを結合してアクセスする必要がある場合(ST40:YES)、テーブルの結合に対応するため結合されたテーブルのスキーマも合わせて登録しておく(ST50)。例えば、先に挙げた従業員テーブル2aとテーマ管理テーブル2bを結合し、図8に示したように、結合したテーブルとしてアクセスする場合が該当する。結合の関係のイメージは図9に示した通りである。
ステップST50では、結合したテーブルのスキーマとして、図10に示したように、元のテーブルとの対応関係を合わせて格納する。この例の対応関係は、Table300というテーブルがTable100とTable200を結合させたものである旨を示している。また、カラム対応関係情報11cも登録される。
このようにしてRDBスキーマ情報管理部11にテーブル一覧11a及びカラム情報11b等の情報が格納された場合、キー/バリュー型DB3にデータが移行可能となる。
RDBデータ変換登録部13は、RDB2のデータを抽出し、キー/バリュー型DB3に格納する(ST70)。データ格納イメージは図7に示した通りである。
ステップST70は、図12に詳細に示すように、ステップST71〜ST77までの処理により実行される。すなわち、RDBデータ変換登録部13は、RDB2の全ての行についてステップST72〜ST77の処理を実行する(ST71)と共に、現在実行中の当該行の全てのカラムについてステップST73〜ST77の処理を実行する(ST72)。
RDBデータ変換登録部13は、図7に示したように、データの値そのものにデータキーを付けた第2のキー/バリュー型データ3bをキー/バリュー型DB3に格納する(ST73)。
また、RDBデータ変換登録部13は、個々のデータが元のRDB2に格納された場合、どのテーブルのどのカラムに格納されるのかが分かるようにキー生成部14に座標キーを生成させ、キー生成部14から受けた座標キーをキーとし、データキーを値とした第1のキー/バリュー型データ3aをキー/バリュー型DB3に格納する(ST74)。
座標キーは、例えば、テーブルIDが「Table100」、カラムIDが「Column1」、同一行識別子が「abcd0001」である場合、例えば、これらを組み合わせて「Table100-Column1-abcd0001」のように生成される。
次に、RDBデータ変換登録部13は、当該テーブルが結合されている場合(ST75:結合されている)には、当該カラムのデータが結合条件となって既に登録されていなければ(ST76:登録されていない)、キー生成部14によって結合テーブル2cの座標キーを生成し、この座標キーに対してもデータキーを値とした第1のキー/バリュー型データ3aをキー/バリュー型DB3に格納する(ST77)
なお、キー生成部14は、結合されているテーブルの座標キーを生成する場合、カラム対応関係情報11cにある結合条件から同じ行になるデータを判別し、既に同一行識別子が発行されている場合は同じ同一行識別子を使う。例えば、Table300は、Table100とTable200を結合したものとする。Table100のデータを格納する際、Table100用の座標キーとTable300用の座標キーを生成する。このとき、同一行識別子は、それぞれ別個に発行する。Table200用のデータを格納する場合、Table200用には新規に同一行識別子を発行するが、Table300用には既に同一行となるデータが格納されていればそのデータの同一行識別子を使用する。同一行となるデータが格納されていなければ新規に同一行識別子を発行する。
なお、キー生成部14は、結合されているテーブルの座標キーを生成する場合、カラム対応関係情報11cにある結合条件から同じ行になるデータを判別し、既に同一行識別子が発行されている場合は同じ同一行識別子を使う。例えば、Table300は、Table100とTable200を結合したものとする。Table100のデータを格納する際、Table100用の座標キーとTable300用の座標キーを生成する。このとき、同一行識別子は、それぞれ別個に発行する。Table200用のデータを格納する場合、Table200用には新規に同一行識別子を発行するが、Table300用には既に同一行となるデータが格納されていればそのデータの同一行識別子を使用する。同一行となるデータが格納されていなければ新規に同一行識別子を発行する。
例えば、Table200に先に登録して、その後でTable100に登録を行なった場合について述べる。Table200のデータを登録する場合、図13に示すように、Table200とTable300について登録することになる。このとき、同一行識別子として、「ccccc」と「eeeee」の2つが発番されている。次に、Table100のデータを登録する。このときもTable100とTable300について登録される。この登録は図14に示すように行われる。このとき、新たに同一行識別子として「aaaaa」を発番している。Table300の部分に関しては、「Table300-Column3-eeeee」の行L1は、結合キーとして既に登録されているので新たな登録を行なわない。これに対し、「Table300-Column7-eeeee」と「Table300-Column8-eeeee」の行L2は新規に登録するが、既に同じ行となるデータが登録されているので同一行識別子「eeeee」をそのまま使用し、新たな同一行識別子を発行しない。
以上により、RDBデータ変換登録部13は、図7に示したように、キー/バリュー型データ3a,3bをキー/バリュー型DB3に書き込む。
以上により、ステップST70が終了して事前準備が完了する。続いて、データベース要求処理の動作について述べる。
DB要求処理部16は、図15に示すように、RDB2向けの要求を既存システム1から受け付ける(ST80)。
具体的には、DB要求処理部16では、図16に示すように、データ挿入用の要求SQLを受け付けると(ST81)、要求IDを発行し、図17に示すように、要求IDを要求SQLに付加して要求管理部17内の要求管理テーブル17aに格納する。
しかる後、DB要求処理部16は、要求ID及び要求SQLを変換モジュール判定部18に送出する(ST83)。これにより、ステップST80に関連した処理が終了する。
次に、変換モジュール判定部18は、当該要求を処理すべき変換モジュールセットを判定する(ST90)。
ステップST90において、変換モジュール判定部18は、受け取ったSQLがどのようなものかを解析するため、変換モジュールセット管理部15に登録されている要求SQL解析モジュールM1a,M2a,…を使って解析を行なう。このとき、複数登録されている要求SQL解析モジュールM1a,M2a,…で順次解析を行い、当該SQLを処理可能な変換モジュールセットMSiの判定を行う。例えば、まず第1の変換モジュールセットMS1内の第1の要求SQL解析モジュールM1aで要求SQLの解析を行なう。このとき、第1の要求SQL解析モジュールM1aで解析できれば以後の処理で第1の変換モジュールセットMS1を使用する。解析できなければ次の第2の要求SQL解析モジュールM2aを使って要求SQLの解析を行なう。第2の要求SQL解析モジュールM2aで解析できれば以後の処理で第2の変換モジュールセットMS2を使用する。どの変換モジュールセットMSiを使用するのかを示す変換モジュールセット名を図18に示すように要求管理部17内の要求管理テーブル17aに登録しておく。ステップST90は、このように実行される。
次に、DB呼び出し実行部19では、選択された変換モジュールセットを利用してRDB2向けの要求であるSQLを解析し、キー/バリュー型DB3への要求に変換し、変換後の要求を実行し、キー/バリュー型DB3からの戻り値を得る(ST100)。
ステップST100において、DB呼び出し実行部19は、要求に対応する変換モジュールセットMSiを使用する。まず、要求SQL解析モジュールMiaにより要求SQLを解析し、その結果を用いて要求実行モジュールMibでキー/バリュー型DB3に要求を行なう。
この例では、第2の要求SQL解析モジュールMS2がデータ挿入のSQLに対応しているものとする。第2の要求SQL解析モジュールM2aでは、SQLの文法を持っており、挿入対象となるテーブル及びカラムを特定する。この処理は、ルールをBNF(Backus Naur Form)記法などで記述することにより、既存の構文解析の技術で行うことで実現できる。例えば図19に示すような呼び出し解析ルールを用いる。この例では、SQLでのデータ挿入の構文がBNFをベースにした記法で記載されている。@テーブル名、@カラム名、@値が取得したいデータとなる。挿入対象となるテーブル及びカラムと値の取得例を図20に示す。
次に、DB呼び出し実行部19は、第2の要求実行モジュールM2bを使ってキー/バリュー型DB3への要求を行なう。第2の要求実行モジュールM2bの例の場合、データ挿入の要求を生成する。ここで、データ挿入の要求を生成する処理は、図21に示すように、ステップST101〜ST107までの処理により実行される。すなわち、DB呼び出し実行部19は、挿入対象のデータの全ての行についてステップST102〜ST107の処理を実行する(ST101)と共に、現在実行中の当該行の全てのカラムについてステップST103〜ST107の処理を実行する(ST102)。
DB呼び出し実行部19は、データの値そのものにデータキーを付けてキー/バリュー型DB3に挿入する要求を生成する(ST103)。また、DB呼び出し実行部19は、カラム毎に座標キーを生成し、座標キーに対し、データキーを値としてキー/バリュー型DB3に挿入する要求を生成する(ST104)。
次に、DB呼び出し実行部19は、当該テーブルが結合されている場合(ST105:結合されている)には、当該カラムのデータが結合条件となって既に登録されていなければ(ST106:登録されていない)、結合テーブル2cの座標キーを生成し、この座標キーに対しても、データキーを値としてキー/バリュー型DB3に挿入する要求を生成する(ST107)。
これらステップST101〜ST107の処理により生成されたキー/バリュー型DB3への要求の例を図22に示す。
DB呼び出し実行部19は、生成されたキー/バリュー型DB3への要求を実行する。
DB呼び出し実行部19は、キー/バリュー型DB3に要求を行なった結果である戻り値をキー/バリュー型DB3から受ける。DB呼び出し実行部19は、この戻り値をDB呼び出し結果変換部20に送出する。DB呼び出し結果変換部20は、図23に一例を示すように、この戻り値を対応する要求IDに関連付けて要求管理テーブル17aに格納する。ステップST100は、このように実行される。
また、DB呼び出し結果変換部20は、この戻り値をRDB2からの戻り値に変換する(ST110)。
ステップST110において、DB呼び出し結果変換部20では、図24に一例を示すように、第2の戻り値変換モジュールM2cによりRDB2の戻り値を生成する。この例では、キー/バリュー型DB3への要求が9個になっており、戻り値が9個あったが、もともとのRDBデータが1行に格納されるため一つの戻り値としている。DB呼び出し結果変換部20では、図25に示すように、RDB2の戻り値を要求IDに関連付けて要求管理テーブル17aに格納する。
しかる後、DB要求処理部16では、既存システム1に対し、要求SQLに対応した戻り値をRDB2からの戻り値として返す(ST120)。
以上により、要求SQLがデータ挿入の場合の要求SQLに対する処理が終了する。
なお、本実施形態のデータベース要求処理装置は、要求SQLの種類が変わっても基本的に同様な処理を行なう。例えば図26に示すような検索要求があった場合について説明する。
ステップST80で受け付けた要求SQLの種類(検索要求)が、前述した要求SQLの種類(データ挿入の要求)とは異なるため、ステップST90において、先ほどとは異なる変換モジュールセットMSiが選択される。
例えば第1の変換モジュールセットMS1が選択されたとする。第1の要求実行モジュールM1bでは、まず値として「042-340-abcd」を格納しているデータのデータキーを取得する。ここでは、「Data-3」を得る。
次に、当該データキーを値として持つ座標キーを取得する。ここでは、「Table100-Column3-aaaaa」と「Table300-Column8-eeeee」を得る。
「従業員テーブル」のテーブルIDは「Table100」、「電話番号」のカラムIDは「Column3」であるため、座標キーの中に「Table100」と「Column3」を含むものを選択する。ここでは、「Table100-Column3-aaaa」が選ばれる。当該座標キーの同一行識別子を取得する。ここでは「aaaaa」となる。
ここで、改めて検索対象である社員番号の座標キーを生成する。従業員テーブルのテーブルIDは「Table100」、「社員番号」のカラムIDは「Column1」、同一行識別子は「aaaaa」となる。これから座標キーを生成すると「Table100-Column1-aaaaa」となる。
この座標キーを持つ値を検索すると「Data-1」が得られる。「Data-1」をデータキーとして持つ値を検索すると「012345678」が得られる。これが検索結果の社員番号となる。
このように要求SQLの種類ごとに要求SQL解析モジュールMia、要求実行モジュールMib、戻り値変換モジュールMicが用意されている。
上述したように本実施形態によれば、RDB2の使用を前提とした既存システム1を改変せずにキー/バリュー型DB3の環境へ移行させることができる。
補足すると、既存システム1からキー/バリュー型DB3をRDB2に見せかけることにより、RDB2を用いた既存システム1をキー/バリュー型DB3を用いた環境に容易に移行させることができる。また、複数のスキーマ間の関連を定義することにより、一つのデータを複数のスキーマから参照できるようになる。
なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク(フロッピー(登録商標)ディスク、ハードディスクなど)、光ディスク(CD−ROM、DVDなど)、光磁気ディスク(MO)、半導体メモリなどの記憶媒体に格納して頒布することもできる。
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているOS(オペレーティングシステム)や、データベース管理ソフト、ネットワークソフト等のMW(ミドルウェア)等が上記実施形態を実現するための各処理の一部を実行しても良い。
さらに、実施形態における記憶媒体は、コンピュータと独立した媒体に限らず、LANやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
また、記憶媒体は1つに限らず、複数の媒体から上記実施形態における処理が実行される場合も実施形態における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。
尚、実施形態におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の1つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。
また、実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって実施形態の機能を実現することが可能な機器、装置を総称している。
なお、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の変形例を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。
1…既存システム、2…RDB、3…キー/バリュー型DB、11…RDBスキーマ情報管理部、12…RDBスキーマ情報取得部、13…RDBデータ変換登録部、14…キー生成部、15…変換モジュールセット管理部、16…DB要求処理部、17…要求管理部、18…変換モジュール判定部、19…DB呼び出し実行部、20…DB呼び出し結果変換部。
Claims (3)
- 複数のカラム名と、前記各カラム名に対応するデータとを有してテーブル名により識別される複数のテーブルを備えたRDBに対して前記テーブル名、前記カラム名及びデータを含む要求SQLを送出して前記要求SQLに応じた戻り値を受ける既存システムに対し、前記要求SQLをキー/バリュー型DBに対する要求に変換して実行処理するデータベース要求処理装置であって、
前記テーブル名及びテーブルIDを関連付けてなるテーブル一覧を記憶するテーブル一覧記憶手段と、
前記テーブルID、カラムID、前記カラム名及びデータ型を関連付けてなるカラム情報を記憶するカラム情報記憶手段と、
前記テーブルID、前記カラムID及び同一行識別子を含む座標キーと、データキーを示す値とを関連付けてなる第1のキー/バリュー型データを前記キー/バリュー型DBに書き込む手段と、
前記データキーと、前記座標キーにより特定される前記データを示す値とを関連付けてなる第2のキー/バリュー型データを前記キー/バリュー型DBに書き込む手段と、
要求SQLの種別毎に、変換モジュールセットを記憶しており、前記変換モジュールセットとしては、要求SQLを解析して前記種別に合う場合には解析が成功し、前記種別に合わない場合には解析が失敗する手段として前記データベース要求処理装置本体を機能させるための要求SQL解析モジュールと、前記解析が成功した要求SQL解析モジュールに起動され、前記要求SQLをキー/バリュー型DBに対する要求に変換して当該キー/バリュー型DBに対する要求を実行処理する手段として前記データベース要求処理装置本体を機能させるための要求実行モジュールと、前記キー/バリュー型DBに対する要求の処理結果を示す戻り値を要求SQLの処理結果を示す戻り値に変換する手段として前記データベース要求処理装置本体を機能させるための戻り値変換モジュールとを備えている変換モジュールセット記憶手段と、
前記既存システムから送出された要求SQLに基づいて、前記変換モジュールセット内の要求SQL解析モジュールを順次実行し、解析に成功した要求SQL解析モジュールを備えた変換モジュールセットを使用する旨を判定する手段と、
前記判定された変換モジュールセットを用い、前記要求SQLをキー/バリュー型DBに対する要求に変換して当該キー/バリュー型DBに対する要求を実行処理した処理結果を示す戻り値を得る手段と、
前記判定された変換モジュールセットを用い、前記得られた戻り値を要求SQLの処理結果を示す戻り値に変換する手段と、
前記変換された戻り値を前記既存システムに送出する手段と、
を備えたことを特徴とするデータベース要求処理装置。 - 請求項1に記載のデータベース要求処理装置において、
前記各テーブルを結合した結合テーブルに関し、前記テーブル一覧内のテーブルIDの値として当該結合テーブルのテーブルIDの値を書き込むと共に、当該書き込まれたテーブルIDの値に関連付けて結合元の各テーブルの各テーブルIDを示す結合情報を書き込む手段と、
前記結合テーブルのテーブルID、前記結合テーブルのカラムID、前記結合テーブルのカラム名、結合元のテーブルのテーブルIDを示す対応テーブルID、結合元のテーブルのカラムIDを示す対応カラムID、及び重複するデータに関する結合元の他のテーブルのテーブルIDとカラムIDとを示す結合条件、を関連付けてなるカラム対応関係情報を記憶するカラム関係情報記憶手段と、
前記結合テーブルのテーブルID、前記結合テーブルのカラムID及び同一行識別子を含む座標キーと、データキーを示す値とを関連付けてなる第3のキー/バリュー型データを前記キー/バリュー型DBに書き込む手段と、
を更に備えたことを特徴とするデータベース要求処理装置。 - 複数のカラム名と、前記各カラム名に対応するデータとを有してテーブル名により識別される複数のテーブルを備えたRDBに対して前記テーブル名、前記カラム名及びデータを含む要求SQLを送出して前記要求SQLに応じた戻り値を受ける既存システムに対し、テーブル一覧記憶手段、カラム情報記憶手段及び変換モジュールセット記憶手段を備え、前記要求SQLをキー/バリュー型DBに対する要求に変換して実行処理するデータベース要求処理装置に用いられるプログラムであって、
前記データベース要求処理装置を、
前記テーブル名及びテーブルIDを関連付けてなるテーブル一覧を前記テーブル一覧記憶手段に書き込む手段、
前記テーブルID、カラムID、前記カラム名及びデータ型を関連付けてなるカラム情報を前記カラム情報記憶手段に書き込む手段、
前記テーブルID、前記カラムID及び同一行識別子を含む座標キーと、データキーを示す値とを関連付けてなる第1のキー/バリュー型データを前記キー/バリュー型DBに書き込む手段、
前記データキーと、前記座標キーにより特定される前記データを示す値とを関連付けてなる第2のキー/バリュー型データを前記キー/バリュー型DBに書き込む手段、
要求SQLの種別毎に、要求SQLを解析して前記種別に合う場合には解析が成功し、前記種別に合わない場合には解析が失敗する手段として前記データベース要求処理装置を機能させるための要求SQL解析モジュールと、前記解析が成功した要求SQL解析モジュールに起動され、前記要求SQLをキー/バリュー型DBに対する要求に変換して当該キー/バリュー型DBに対する要求を実行処理する手段として前記データベース要求処理装置を機能させるための要求実行モジュールと、前記キー/バリュー型DBに対する要求の処理結果を示す戻り値を要求SQLの処理結果を示す戻り値に変換する手段として前記データベース要求処理装置を機能させるための戻り値変換モジュールとを備えた複数の変換モジュールセットを前記変換モジュールセット記憶手段に書き込む手段、
前記既存システムから送出された要求SQLに基づいて、前記変換モジュールセット内の要求SQL解析モジュールを順次実行し、解析に成功した要求SQL解析モジュールを備えた変換モジュールセットを使用する旨を判定する手段、
前記判定された変換モジュールセットを用い、前記要求SQLをキー/バリュー型DBに対する要求に変換して当該キー/バリュー型DBに対する要求を実行処理した処理結果を示す戻り値を得る手段、
前記判定された変換モジュールセットを用い、前記得られた戻り値を要求SQLの処理結果を示す戻り値に変換する手段、
前記変換された戻り値を前記既存システムに送出する手段、
として機能させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011217287A JP5444302B2 (ja) | 2011-09-30 | 2011-09-30 | データベース要求処理装置及びプログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011217287A JP5444302B2 (ja) | 2011-09-30 | 2011-09-30 | データベース要求処理装置及びプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2013077205A true JP2013077205A (ja) | 2013-04-25 |
JP5444302B2 JP5444302B2 (ja) | 2014-03-19 |
Family
ID=48480611
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011217287A Expired - Fee Related JP5444302B2 (ja) | 2011-09-30 | 2011-09-30 | データベース要求処理装置及びプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5444302B2 (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2015062109A (ja) * | 2013-07-18 | 2015-04-02 | アイエムエス ヘルス インコーポレイテッドIMS Health Incorporated | データをモデリングするためのシステム及び方法 |
JP2022547956A (ja) * | 2020-05-18 | 2022-11-16 | 杭州趣鏈科技有限公司 | ブロックチェーンデータをインデックスする方法およびブロックチェーンデータを格納する方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011008451A (ja) * | 2009-06-25 | 2011-01-13 | Shuhei Nishiyama | キー・バリュー・ストアによるデータベース・キャッシュ装置 |
JP2011113103A (ja) * | 2009-11-24 | 2011-06-09 | Hitachi Ltd | マルチテナント型コンピュータシステム |
JP2011165148A (ja) * | 2010-02-15 | 2011-08-25 | Fujitsu Ltd | データストア切替装置、データストア切替方法およびデータストア切替プログラム |
-
2011
- 2011-09-30 JP JP2011217287A patent/JP5444302B2/ja not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011008451A (ja) * | 2009-06-25 | 2011-01-13 | Shuhei Nishiyama | キー・バリュー・ストアによるデータベース・キャッシュ装置 |
JP2011113103A (ja) * | 2009-11-24 | 2011-06-09 | Hitachi Ltd | マルチテナント型コンピュータシステム |
JP2011165148A (ja) * | 2010-02-15 | 2011-08-25 | Fujitsu Ltd | データストア切替装置、データストア切替方法およびデータストア切替プログラム |
Non-Patent Citations (2)
Title |
---|
CSNG201100175012; 黒田貴之ほか2名: 'シングルテナント型システムからの移行に適したマルチテナント型データベースシステムの構成法' 情報処理学会論文誌 論文誌ジャーナル Vol.52 No.3 [CD-ROM] 第52巻 第3号, 20110315, pp.1126〜1135, 一般社団法人情報処理学会 * |
JPN6013057480; 黒田貴之ほか2名: 'シングルテナント型システムからの移行に適したマルチテナント型データベースシステムの構成法' 情報処理学会論文誌 論文誌ジャーナル Vol.52 No.3 [CD-ROM] 第52巻 第3号, 20110315, pp.1126〜1135, 一般社団法人情報処理学会 * |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2015062109A (ja) * | 2013-07-18 | 2015-04-02 | アイエムエス ヘルス インコーポレイテッドIMS Health Incorporated | データをモデリングするためのシステム及び方法 |
JP2022547956A (ja) * | 2020-05-18 | 2022-11-16 | 杭州趣鏈科技有限公司 | ブロックチェーンデータをインデックスする方法およびブロックチェーンデータを格納する方法 |
JP7407912B2 (ja) | 2020-05-18 | 2024-01-04 | 杭州趣鏈科技有限公司 | ブロックチェーンデータをインデックスする方法およびブロックチェーンデータを格納する方法 |
Also Published As
Publication number | Publication date |
---|---|
JP5444302B2 (ja) | 2014-03-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107247808B (zh) | 一种分布式NewSQL数据库系统及图片数据查询方法 | |
Saha et al. | Apache tez: A unifying framework for modeling and building data processing applications | |
US11269839B2 (en) | Authenticated key-value stores supporting partial state | |
US7769789B2 (en) | High performant row-level data manipulation using a data layer interface | |
JP4436036B2 (ja) | 情報処理装置、トレース処理方法、プログラム及び記録媒体 | |
US7634512B2 (en) | Migrating temporary data of a session | |
CN102681836B (zh) | 针对大量并发用户进行扩展的系统和方法 | |
JPWO2011108695A1 (ja) | 並列データ処理システム、並列データ処理方法及びプログラム | |
CN115934855B (zh) | 一种全链路字段级血缘解析方法、系统、设备及存储介质 | |
JP2016021232A (ja) | データ統合システム(dis)のデータの鮮度のチェック | |
JP2008165447A (ja) | データアクセス装置、データアクセス方法、及び、コンピュータプログラム | |
CN108268468B (zh) | 一种大数据的分析方法及系统 | |
JP2018531439A6 (ja) | トランザクション処理環境において分散型キャッシングを提供するためのシステムおよび方法 | |
JP2018531439A (ja) | トランザクション処理環境において分散型キャッシングを提供するためのシステムおよび方法 | |
US7752399B2 (en) | Exclusion control method and information processing apparatus | |
US7752225B2 (en) | Replication and mapping mechanism for recreating memory durations | |
JP5444302B2 (ja) | データベース要求処理装置及びプログラム | |
US8290922B2 (en) | Data framework to enable rich processing of data from any arbitrary data source | |
CA3089289C (en) | System and methods for loading objects from hash chains | |
US8996521B2 (en) | Data caveats for database tables | |
CN112347794A (zh) | 数据翻译方法、装置、设备及计算机存储介质 | |
JP6902579B2 (ja) | トランザクション処理環境において分散型キャッシングを提供するためのシステムおよび方法 | |
Hsieh et al. | A method for web application data migration based on RESTful API: A case study of ezScrum | |
US20150019672A1 (en) | Method and System for Record Access in a Distributed System | |
Krogh et al. | Monitoring Locks and Mutexes |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
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: 20131126 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131220 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
LAPS | Cancellation because of no payment of annual fees |