JP2015146205A - データベース処理方法、及びデータベース処理装置 - Google Patents

データベース処理方法、及びデータベース処理装置 Download PDF

Info

Publication number
JP2015146205A
JP2015146205A JP2015052530A JP2015052530A JP2015146205A JP 2015146205 A JP2015146205 A JP 2015146205A JP 2015052530 A JP2015052530 A JP 2015052530A JP 2015052530 A JP2015052530 A JP 2015052530A JP 2015146205 A JP2015146205 A JP 2015146205A
Authority
JP
Japan
Prior art keywords
data
storage unit
storage
storage units
data table
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.)
Pending
Application number
JP2015052530A
Other languages
English (en)
Inventor
貴宏 栗田
Takahiro Kurita
貴宏 栗田
孝生 丸亀
Takao Marugame
孝生 丸亀
敦寛 木下
Atsuhiro Kinoshita
敦寛 木下
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.)
Toshiba Corp
Original Assignee
Toshiba Corp
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 Toshiba Corp filed Critical Toshiba Corp
Priority to JP2015052530A priority Critical patent/JP2015146205A/ja
Publication of JP2015146205A publication Critical patent/JP2015146205A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】より検索効率を高めることができるデータベース処理方法を提供する。【解決手段】実施形態のデータベース処理方法は、サーバが複数の記憶部における処理対象のデータの位置を決定する第1ステップと、前記処理対象のデータを、複数のデータテーブルに分割し、前記複数の記憶部における決定された位置の前記記憶部を指定して、前記複数のデータテーブルを保存する指示を前記複数の記憶部に行う第2ステップと、前記複数の記憶部のうち前記決定された位置の前記記憶部において、前記データテーブルを受信して、前記データテーブルを保存する第3ステップと、前記データテーブルを保存した前記記憶部の位置を前記サーバに通知する第4ステップと、前記サーバが、通知された前記記憶部の位置を保存する第5ステップと、を含み、前記第1ステップは、保存されている一または複数の位置に関する情報に基づいて、前記処理対象のデータの位置を決定する。【選択図】図1

Description

本発明の実施形態は、データベース処理方法、及びデータベース処理装置に関する。
テーブル単位でデータを管理したり、XMLによって記述されたデータを管理したりするリレーショナルデータベースを用いた分散システムにおけるデータベースマネージメントシステム(DBMS)では、検索の効率化を図るためデータベースを構成するデータテーブルを分割して管理する方法が採用されている。例えば、特定のカラムの値ごとにレコードを分割し、それぞれのレコードを異なるサーバに記録したり、他のカラムから独立性の高いカラムを別のサーバに記録したりする技術が知られている。また、複数のカラムに対してキーレンジを設け、そのキーレンジに対応して異なるデータの記憶領域を割り付けることで、検索の際にアクセスするデータ量を少なくすることができ、より高速にデータベースを検索することが可能となる。
特開2007−48318号公報
ところで、あらかじめデータテーブルの分割の仕方を決定する際には、実際に検索される頻度が高い検索文を想定し、その検索に検索効率が高くなる分割方法が採用される。この場合、想定と異なる検索がなされた場合においては、所望の検索効率が得られない。
本発明は、上記に鑑みてなされたものであって、より検索効率を高めることができるデータベース処理方法及びデータベース処理装置を提供することにある。
実施形態のデータベース処理方法は、サーバと複数の記憶部とを備えたシステムで実行されるデータベース処理方法であって、前記サーバが前記複数の記憶部における処理対象のデータの位置を決定する第1ステップと、前記処理対象のデータを、複数のデータテーブルに分割し、前記複数の記憶部における決定された位置の前記記憶部を指定して、前記複数のデータテーブルを保存する指示を前記複数の記憶部に行う第2ステップと、前記複数の記憶部のうち前記決定された位置の前記記憶部において、前記データテーブルを受信して、前記データテーブルを保存する第3ステップと、前記データテーブルを保存した前記記憶部の位置を前記サーバに通知する第4ステップと、前記サーバが、通知された前記記憶部の位置を保存する第5ステップと、を含み、前記第1ステップは、保存されている一または複数の位置に関する情報に基づいて、前記処理対象のデータの位置を決定する。
図1は、実施形態のデータベース処理装置の構成を示す図である。 図2は、実施形態のデータテーブルの分割の手順を示す図である。 図3は、実施形態のレコードマスターテーブルのテーブル構成図である。 図4は、実施形態の分割情報テーブルのテーブル構成図である。 図5は、実施形態のレコード挿入処理の流れを示すフロー図である。 図6は、実施形態のレコード検索処理の流れを示すフロー図である。 図7は、実施形態のレコード更新処理の流れを示すフロー図である。 図8は、実施形態のレコード削除処理の流れを示すフロー図である。 図9は、実施形態のレコード検索処理の流れを示すフロー図である。
以下に、本発明のデータベース処理装置の実施形態を図面に基づいて詳細に説明する。本実施形態においては、データテーブルをリレーショナルデータベースの形式で管理するデータベース処理装置に適用した例を示すが、例えばXMLにより記述されたデータをリレーショナルデータベースにより管理する構成などにも適用することは可能である。
図1は、実施形態のデータベース処理装置1のハードウェア構成例を示す図である。データベース処理装置1は、フロントエンドサーバ10と、ストレージサーバ20とを含む。フロントエンドサーバ10は、クライアント30からの要求を受け取り、受け取った要求をストレージサーバ20へと転送する。また、フロントエンドサーバ10は、クライアント30からのデータベースへの挿入要求、検索要求、更新要求、及び削除要求を受け付け、その要求内容を参照して、カラム、及びデータの範囲にしたがって分割する処理を行う。詳細については、後述する。
ストレージサーバ20は、データの記憶部40へとアクセスする。記憶部40は、ストレージメモリ41と、コントローラ42と、インターフェイス43とを備えている。ストレージメモリ41は、ハードディスクドライブ(HDD)、ソリッドステートドライブ(SSD)、フラッシュメモリ、及びMRAMなどの不揮発メモリなどにより構成されるデータが物理的に記憶される部位である。本実施形態においては、記憶部40は、互いに物理的に独立した記憶領域となっている。また、コントローラ42は、隣接する記憶部40との間で、データを送受信したり、ストレージメモリ41へのデータの読み書きを他の記憶部40とは独立して行ったりする。本実施形態においては、記憶部40が正方格子状に並べてあるが、物理的な配置の態様は適宜変更することができる。
また、フロントエンドサーバ10と、ストレージサーバ20との間には、I/Fユニット部50が設けられている。I/F部ユニット50は、CPU51と、フロントエンドサーバ10との間でデータを入出力するインターフェイス52、記憶部40との間でデータを入出力するインターフェイス53、及び分割部54を備えている。分割部54は論理回路と、データテーブルの分割の情報を記録する記憶領域とからなり、フロントエンドサーバ10から受理したレコードの挿入や更新、及び削除の要求に対して、記憶部40に対し処理を行う際にデータを後述の方法で分割する。この分割作業はI/Fユニット部50やフロントエンドサーバ10で行っても良い。本実施形態においては、フロントエンドサーバ10とストレージサーバ20とを別のハードウェアとして設ける構成を示したが、これらは同じハードウェア上に存在していてもよい。
次に、本実施形態におけるデータベースの分割手順について図2を用いて説明する。図2は、あるデータテーブルから、任意のレコード、及びカラムの両方のデータによって分割する手順を示した図である。実際には、データは最終的には図2(c)にして示した状態で記憶部40のストレージメモリ41に記憶されるが、図2(a)、(b)は、説明のため便宜的に分割前のテーブルの状態を示している。
図2(a)に示されるように、本実施形態における第1データテーブル100は、カラムとして、「ID(識別情報)」、「No.」、「名称」、「所在地」、「商品」、及び「個数」を有している。レコードしては、例示的にID=11、12、105、106の4つが示されている。
まず、第1データテーブル100を、任意のカラムを組み合わせたカラム分割基準に従い、第2データテーブル200を作成する。図2(b)は、各第2データテーブル200を示している。図2(b)に示されるように、IDとNo、IDと名称と所在地、IDと商品、及びIDと個数の組み合わせが本実施形態においては、カラム分割基準に該当し、このカラム分割基準により4つの第2データテーブル200に第1データテーブル100は分割される。なお、このカラム分割基準は、プログラム内に記載されていてもよいし、設定用のテーブルとして記憶部40に記憶されていてもよい。さらに、4つの第2データテーブル200をレコードのデータの値に応じて分割し、第3データテーブル300が作成される。図2(c)は、作成された第3データテーブル300の状態を示している。なお、図ではIDと個数の組み合わせによるテーブルのみを示しているが、他の3つの組み合わせについても同様にテーブルは作成される。
図2(c)に示されるように、第3データテーブル300は、「個数」のカラムのデータが、「1〜10」、「11〜20」、及び「21以上」の3つの値の範囲で分割されている。値の範囲に基づく分割は、他の方法においては、カラムのデータやデータから生成されるハッシュ値の大小で行ってもよいし、その他の条件で行ってもよい。図2(c)においては、第3データテーブル300は3つ作成されているが、それぞれ、物理的に異なる記憶部40に記憶される。
また、本実施形態においては、フロントエンドサーバ10に、レコードマスターテーブルと、分割情報テーブルとが記憶されている。図3はレコードマスターテーブルを、図4は分割情報テーブルをそれぞれ示している。図3に示されるように、レコードマスターテーブル400(位置情報テーブル)は、IDと対応付けて、それぞれのカラムのデータが物理的に記憶されている記憶部40の位置情報を記憶している。記憶部40の位置情報は、Si(iは1以上の整数)で示されている。例えば、ID=11のレコードには、カラム「No」のデータとして「S1」が、カラム「名称」のデータとして「S10」が、カラム「所在地」のデータとして「S16」が、カラム「商品」のデータとして「S24」が、カラム「個数」のデータとして「S27」がそれぞれ記憶されている。したがって、IDをキーにレコードマスターテーブル400を検索することで、各カラムのデータの記憶位置を即座に把握することができるようになる。なお、記憶部40の位置情報としては、物理的なハードウェア単位だけでなく、ディスク内の論理アドレスなどを指定してもよい。また、このレコードマスターテーブル400のデータ構造は図に示されたような形でなくてもよい。
また、図4に示されるように、分割情報テーブル500は、カラムと、カラムのデータの値の範囲との組み合わせと対応付けて、物理的に記憶されている記憶部40の位置情報を記憶している。例えば、「個数」のカラムは1から10、11から20、及び21以上の3つの範囲に分割されており、それぞれS26、S27、及びS28にて示される記憶部40に割り当てられていることが示されている。また、図4に示されるように、分割情報テーブル500には、所在地の値の範囲として、数値でなく「関東」や「中部」などのように、概念的な文字情報が記憶されている。
続いて、本実施形態における、データベースの処理手順を説明する。図5は、クライアント30からレコードを新たに挿入する要求が出されたときの処理の流れを示すフロー図である。図5に示されるように、まずフロントエンドサーバ10が、クライアント30からのレコード挿入の命令を受け取る(ステップS100)。次いで、フロントエンドサーバ10は、受け取ったレコードに含まれる各カラムのデータと、分割情報テーブル500とを参照し、それぞれのデータをどの記憶部40に記録するかを決定する(ステップS101)。フロントエンドサーバ10は、ストレージサーバ20に対して書き込み要求を行う(ステップS102)。書き込み要求を受理したストレージサーバ20は、分割情報テーブル500を参照して決定した各記憶部40に対して該当するデータの書き込み要求を行う(ステップS103)。ストレージサーバ20においては、上述した分割部54が、各データがそれぞれ決定された記憶部40に記憶されるよう、レコードを分割する処理を行う。
次いで、ストレージサーバ20は、フロントエンドサーバ10に対して、レコードの書き込みが完了した通知を出力する(ステップS104)。フロントエンドサーバ10は、書き込み完了通知を受信後、レコードマスターテーブル400に新たに挿入したレコードの各カラムのデータの記憶位置の情報を記憶する(ステップS105)。そして、最後にフロントエンドサーバ10は、クライアント30に対し、レコード挿入の完了通知を出力する(ステップS106)。
続いて、クライアント30から検索要求が出された際の処理の流れについて図6を参照して説明する。検索要求としては、単にあるデータを含むレコードが存在するか否かを調べるものや、あるカラムにおけるデータの総和や平均値を求めるようなものなどがある。図6においては、単一のカラムのデータのみを参照して行う検索の場合の処理を示している。図6においては、特定のカラムについてのみ、まず、フロントエンドサーバ10は、クライアント30から検索命令を受理する(ステップS200)。次いで、フロントエンドサーバ10は、検索命令において指定された検索条件と、分割情報テーブルの情報とから、検索に必要なカラムと、データがどのデータのレンジに属するかを判定して、データの読み出しを行う記憶部40の物理的な位置を決定する(ステップS201)。
フロントエンドサーバ10は、ストレージサーバ20に対し決定した記憶部40を指定してデータの読み出し要求を出力する(ステップS202)。ストレージサーバ20は、指定された各記憶部40に対し、データの読み出し要求を行う(ステップS203)。次いで、ストレージサーバ20は、読みだしたデータをフロントエンドサーバ10へと送信する(ステップS204)。最後に、フロントエンドサーバ10は、受理したデータを検索条件に基づいて集計、及び加工し、結果をクライアント30に対して出力する(ステップS205)。
次に、レコードの更新時の処理の流れについて図7を参照して説明する。図7の処理はクライアント30からフロントエンドサーバ10に対して、レコードの更新要求が出力されたときに処理が開始される。まず、フロントエンドサーバ10が、レコード更新の要求命令をクライアント30から受理する(ステップS300)。フロントエンドサーバ10は、更新後のレコードに含まれる各カラムのデータに基づいて分割情報テーブル500を参照し、更新後のデータをどこの記憶部40に書き込むかを決定する(ステップS301)。
次いで、フロントエンドサーバ10は、決定した記憶部40における書き込み位置を指定して、ストレージサーバ20へと書き込み要求を出力する(ステップS302)。次いで、ストレージサーバ20は、指定された記憶部40に対し、データの書き込み要求を行う(ステップS303)。
また、レコードの更新の際には、元のレコードのデータを第3データテーブル300から削除する処理を行う。まず、フロントエンドサーバ10は、更新の際に指定されたレコードのID(識別情報)に基づきレコードマスターテーブル400を参照して、更新前のデータが記憶されている記憶部40の位置を取得する(ステップS304)。フロントエンドサーバ10は、ストレージサーバ20に対して取得した更新前のデータの記憶部40の位置を指定して、データの削除要求を行う(ステップS305)。ストレージサーバ20は、指定された記憶部40に記憶された第3データテーブル300上のデータを削除する削除要求を出力する(ステップS306)。ストレージサーバ20は、データの削除が完了すると、削除の完了通知をフロントエンドサーバ10へと出力する(ステップS307)。フロントエンドサーバ10は、完了通知を受け取ると、レコードマスターテーブル400の該当するデータの記憶位置の値を、更新後のデータの位置に更新する(ステップS308)。最後に、フロントエンドサーバ10は、クライアント30に対して更新要求の完了通知を出力する(ステップS309)。なお、ステップS301〜S304のデータの書き込みの処理と、ステップS305〜ステップS308のデータの削除処理とは並列して実施することも可能である。
次に、レコード削除時の処理の流れについて図8を参照して説明する。図8の処理はクライアント30からデータの削除要求が出力された際にスタートする。図8に示されるように、まずフロントエンドサーバ10は、クライアント30からレコード削除要求を受理する(ステップS400)。次いで、フロントエンドサーバ10は、削除の際に指定されたレコードのID(識別情報)に基づきレコードマスターテーブル400を参照して、データが記憶されている記憶部40の位置を決定する(ステップS401)。フロントエンドサーバ10は、ストレージサーバ20に対して取得したデータの記憶部40の位置を指定して、データの削除要求を行う(ステップS402)。ストレージサーバ20は、指定された記憶部40に記憶された第3データテーブル300上のデータを削除する削除要求を出力する(ステップS403)。ストレージサーバ20は、データの削除が完了すると、削除の完了通知をフロントエンドサーバ10へと出力する(S404)。フロントエンドサーバ10は、完了通知を受け取ると、クライアント30に対して削除要求の完了通知を出力する(ステップS405)。
次に、複数のカラムに対して、検索が行われた際の処理の流れについて図9を参照して説明する。単一のデータに対する検索の処理を示した図6とは異なり、それぞれのカラムにおいて検索条件と一致したレコードからIDを取得し、レコードマスターテーブル400を参照して、最終的な検索結果を加工する必要がある。例えば、複数のカラムのデータで検索を行う場合や、検索に用いたカラムとは異なるカラムを検索結果として表示することを要求された場合などが該当する。
図9に示されるように、フロントエンドサーバ10は、クライアント30からの検索命令を受理する(ステップS500)。次いで、フロントエンドサーバ10は、検索命令において指定された検索条件と、分割情報テーブルの分割情報とから、検索に必要なカラムと、データがどのレンジに属するかを判定して、データの読み出しを行う記憶部40の物理的な位置を決定する(ステップS501)。
フロントエンドサーバ10は、ストレージサーバ20に対し決定した記憶部40を指定してデータの読み出し要求を出力する(ステップS502)。ストレージサーバ20は、指定された各記憶部40に対し、データの読み出し要求を行う(ステップS503)。次いで、ストレージサーバ20は、読みだしたデータから検索式に含まれるカラムのデータと一致するレコードのIDを取得し、フロントエンドサーバ10へと出力する(ステップS504)。複数のカラムに対して、検索を行っていることから、このステップは通常であれば、複数のレコードのIDが出力されることとなる。
次いで、フロントエンドサーバ10は、検索結果として表示する項目として指定されたカラムのデータが記憶されている記憶部40の位置を、取得したレコードIDをキーにレコードマスターテーブル400から取得する(ステップS505)。次いで、フロントエンドサーバ10は、取得した位置に存在する記憶部40を指定してストレージサーバ20へと読み出し要求を行う(ステップS506)。ストレージサーバ20は、指定された各記憶部40に対し、データの読み出し要求を行う(ステップS507)。次いで、ストレージサーバ20は、読みだしたデータをフロントエンドサーバ10へと送信する(ステップS508)。最後に、フロントエンドサーバ10は、検索式にて指定された表示形式に読み出されたデータを加工し、クライアント30へと出力する(ステップS509)。
以上に示した、本実施形態のデータベース処理装置1においては、データテーブルを細かく分散し、かつ物理的に異なる記憶部40に格納することで、検索要求に対して読み出しを行う物理的なデータ量を抑制することができるようになる。また、データを並列に読み出すことが可能となるため、検索効率が向上する。そして、全てのカラムが分散された記憶部40に記憶されているため、どのような検索式に対しても検索効率の低下を抑えることができるようになる。
また、第3のデータテーブル300の各レコードに対してIDを付加することで、検索結果に対する応答をIDのみで行うことができるようになるため、サーバ間での転送時間が短くなり、複数のサーバをまたがって検索を行った際の検索効率を向上させることができる。
以上に示した実施形態においては、第3のデータテーブル300に、それぞれIDを付与することとしたが、IDがなく単一のカラムのみを記憶するようにしてもよい。
また、フロントエンドサーバ10において行った処理を、ストレージサーバ20において実施してもよい。例えば、検索時において、分割情報テーブル500やレコードマスターテーブル400を参照する処理をフロントエンドサーバ10側において行う例を示したが、フロントエンドサーバ10は単に要求を転送するのみにし、データベースにかかる処理をストレージサーバ20側で行ってもよい。この場合、分割情報テーブル500やレコードマスターテーブル400はストレージサーバ20に記憶されるが、これらの各レコードを管理するテーブルの一部または全部を、ストレージサーバ20側に記憶することで、検索結果として得られたIDから必要なカラムのデータを取得するまでの時間が早くなり、検索効率を向上させることができるようになる。
本発明の実施形態を説明したが、実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
1 データベース処理装置
10 フロントエンドサーバ
20 ストレージサーバ
30 クライアント
40 記憶部
41 ストレージメモリ
42 コントローラ
43 インターフェイス
50 I/Fユニット部
51 CPU
52 インターフェイス
53 インターフェイス
54 分割部
100 第1データテーブル
200 第2データテーブル
300 第3データテーブル
400 レコードマスターテーブル
500 分割情報テーブル

Claims (6)

  1. サーバと複数の記憶部とを備えたシステムで実行されるデータベース処理方法であって、
    前記サーバが前記複数の記憶部における処理対象のデータの位置を決定する第1ステップと、
    前記処理対象のデータを、複数のデータテーブルに分割し、前記複数の記憶部における決定された位置の前記記憶部を指定して、前記複数のデータテーブルを保存する指示を前記複数の記憶部に行う第2ステップと、
    前記複数の記憶部のうち前記決定された位置の前記記憶部において、前記データテーブルを受信して、前記データテーブルを保存する第3ステップと、
    前記データテーブルを保存した前記記憶部の位置を前記サーバに通知する第4ステップと、
    前記サーバが、通知された前記記憶部の位置を保存する第5ステップと、を含み、
    前記第1ステップは、保存されている一または複数の位置に関する情報に基づいて、前記処理対象のデータの位置を決定する、
    データベース処理方法。
  2. 前記第1ステップは、新たなデータの挿入要求を受信した場合に、前記新たなデータを挿入する前記データテーブルの前記複数の記憶部における位置を決定し、
    前記第2ステップは、決定した位置の前記記憶部に対し、前記新たなデータを挿入する指示を行い、
    前記第3ステップは、前記複数の記憶部のうち、前記決定された位置の前記記憶部が、前記新たなデータを受信して、記憶されている前記データテーブルに前記新たなデータを挿入して保存する、
    請求項1に記載のデータベース処理方法。
  3. 前記第1ステップは、データの更新要求を受信した場合、前記更新要求に含まれる前記データと対応する前記データテーブルが記憶される前記記憶部の位置を決定し、
    前記第2ステップは、決定した位置の前記記憶部に対し、前記第データテーブルを更新する指示を行い、
    前記第3ステップは、前記複数の記憶部のうち、前記決定された位置の前記記憶部が、前記データを受信して、記憶されている前記データテーブルを前記データで更新する、
    請求項1または2に記載のデータベース処理方法。
  4. 前記第1ステップは、前記データの削除要求を受信した場合、前記削除要求の対象の前記データが記憶されている前記データテーブルが記憶される前記記憶部の位置を決定し、
    前記第2ステップは、決定した位置の前記記憶部に対し、前記データテーブルの前記データを削除する指示を行い、
    前記第3ステップは、前記複数の記憶部のうち、前記決定された位置の前記記憶部が、前記指示を受信して、記憶されている前記データテーブルから前記データを削除する、
    請求項1〜3のいずれか一つに記載のデータベース処理方法。
  5. 前記第2ステップは、前記処理対象のデータとしての複数のカラムのデータを含むレコードを有する第1のデータテーブルを、少なくとも1以上の任意のカラムのデータを含む複数の第2のデータテーブルに分割し、前記第2のデータテーブルを1以上のレコードを有する複数の第3のデータテーブルに分割し、前記複数の記憶部における決定された位置の前記記憶部を指定して、前記第3のデータテーブルを保存する指示を前記複数の記憶部に行い、
    前記第3ステップは、前記複数の記憶部のうち、前記決定された位置の前記記憶部のそれぞれが、前記第3のデータテーブルを受信して、それぞれ独立して、前記第3のデータテーブルを保存する、
    請求項1〜4のいずれか一つに記載のデータベース処理方法。
  6. 複数の記憶部と、
    前記複数の記憶部における処理対象のデータの位置を決定する第1処理部と、
    前記処理対象のデータを、複数のデータテーブルに分割し、前記複数の記憶部における決定された位置の前記記憶部を指定して、前記複数のデータテーブルを保存する指示を前記複数の記憶部に行う第2処理部と、とを備え、
    前記複数の記憶部のうち前記決定された位置の前記記憶部は、前記データテーブルを受信して、前記データテーブルを保存し、前記データテーブルを保存した前記記憶部の位置を前記第1処理部に通知し、
    前記第1処理部は、通知された前記記憶部の位置に関する情報を保存し、保存されている一または複数の位置に関する情報に基づいて、前記処理対象のデータの位置を決定する、
    データベース処理装置。
JP2015052530A 2015-03-16 2015-03-16 データベース処理方法、及びデータベース処理装置 Pending JP2015146205A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2015052530A JP2015146205A (ja) 2015-03-16 2015-03-16 データベース処理方法、及びデータベース処理装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2015052530A JP2015146205A (ja) 2015-03-16 2015-03-16 データベース処理方法、及びデータベース処理装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2012065045A Division JP2013196565A (ja) 2012-03-22 2012-03-22 データベース処理方法、及びデータベース処理装置

Publications (1)

Publication Number Publication Date
JP2015146205A true JP2015146205A (ja) 2015-08-13

Family

ID=53890373

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015052530A Pending JP2015146205A (ja) 2015-03-16 2015-03-16 データベース処理方法、及びデータベース処理装置

Country Status (1)

Country Link
JP (1) JP2015146205A (ja)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06314299A (ja) * 1993-04-28 1994-11-08 Hitachi Ltd データベース管理方法
US5878409A (en) * 1995-06-01 1999-03-02 International Business Machines Corporation Method and apparatus for implementing partial declustering in a parallel database system
US5940289A (en) * 1996-08-28 1999-08-17 Hitachi, Ltd. Parallel database system retrieval method of a relational database management system using initial data retrieval query and subsequent sub-data utilization query processing for minimizing query time
JP2007048318A (ja) * 2006-10-30 2007-02-22 Hitachi Ltd リレーショナルデータベースの処理方法およびリレーショナルデータベース処理装置
WO2010098034A1 (ja) * 2009-02-24 2010-09-02 日本電気株式会社 分散データベース管理システムおよび分散データベース管理方法
JP2011048427A (ja) * 2009-08-25 2011-03-10 Nec Corp データ管理システム、その分散記憶装置とユーザ計算端末、そのコンピュータプログラムとデータ処理方法
JP2013196565A (ja) * 2012-03-22 2013-09-30 Toshiba Corp データベース処理方法、及びデータベース処理装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06314299A (ja) * 1993-04-28 1994-11-08 Hitachi Ltd データベース管理方法
US5878409A (en) * 1995-06-01 1999-03-02 International Business Machines Corporation Method and apparatus for implementing partial declustering in a parallel database system
US5940289A (en) * 1996-08-28 1999-08-17 Hitachi, Ltd. Parallel database system retrieval method of a relational database management system using initial data retrieval query and subsequent sub-data utilization query processing for minimizing query time
JP2007048318A (ja) * 2006-10-30 2007-02-22 Hitachi Ltd リレーショナルデータベースの処理方法およびリレーショナルデータベース処理装置
WO2010098034A1 (ja) * 2009-02-24 2010-09-02 日本電気株式会社 分散データベース管理システムおよび分散データベース管理方法
JP2011048427A (ja) * 2009-08-25 2011-03-10 Nec Corp データ管理システム、その分散記憶装置とユーザ計算端末、そのコンピュータプログラムとデータ処理方法
JP2013196565A (ja) * 2012-03-22 2013-09-30 Toshiba Corp データベース処理方法、及びデータベース処理装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
手嶋 透: ""シンプル"が成功の秘訣 ITアーキテクチャの作り方 Part2 アーキテクトの取り組み プロジェク", 日経SYSTEMS, vol. 第188号, JPN6014021018, 26 November 2008 (2008-11-26), JP, pages 18 - 21, ISSN: 0003254355 *

Similar Documents

Publication Publication Date Title
JP2013196565A (ja) データベース処理方法、及びデータベース処理装置
US9953051B2 (en) Multi-version concurrency control method in database and database system
US11099771B2 (en) System and method for early removal of tombstone records in database
US9171027B2 (en) Managing a multi-version database
US20140297603A1 (en) Method and apparatus for deduplication of replicated file
US20070162506A1 (en) Method and system for performing a redistribute transparently in a multi-node system
JP2020529673A5 (ja)
JP6479186B2 (ja) 計算機システム及びデータベース管理方法
US20130013648A1 (en) Method for database storage of a table with plural schemas
CN103714090A (zh) 多索引数据库事务处理方法及数据库
CN102609492B (zh) 一种支持表模式可变的元数据管理方法
US20170161050A1 (en) Methods for Downloading and Installing Computer Software Applications on Demand
CN104598652B (zh) 一种数据库查询方法及装置
CN106383826A (zh) 数据库查询方法和装置
JP2014199573A (ja) ストレージ制御装置、ストレージ制御装置の制御方法およびストレージ制御装置の制御プログラム
KR20150097973A (ko) 지도 서비스를 위한 타일 이미지 갱신 시스템 및 그 방법
JP5287071B2 (ja) データベース管理システムおよびプログラム
JP2017167654A (ja) データ管理装置及びデータベースの管理方法
US10430287B2 (en) Computer
JP2015146205A (ja) データベース処理方法、及びデータベース処理装置
CN111061759A (zh) 数据查询方法及装置
JP6477169B2 (ja) データベースの処理制御方法、処理制御プロラム及びデータベースサーバ
US20170161056A1 (en) Methods for Managing the Writing of Datasets by Computer-Implemented Processes
JP2015162042A (ja) インデックス管理装置
US20200379967A1 (en) Data management apparatus, method and non-transitory tangible machine-readable medium thereof

Legal Events

Date Code Title Description
RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20151102

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160129

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160216

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20160809