JP5276639B2 - 分散データベース管理装置および分散データベース管理プログラム - Google Patents
分散データベース管理装置および分散データベース管理プログラム Download PDFInfo
- Publication number
- JP5276639B2 JP5276639B2 JP2010223449A JP2010223449A JP5276639B2 JP 5276639 B2 JP5276639 B2 JP 5276639B2 JP 2010223449 A JP2010223449 A JP 2010223449A JP 2010223449 A JP2010223449 A JP 2010223449A JP 5276639 B2 JP5276639 B2 JP 5276639B2
- Authority
- JP
- Japan
- Prior art keywords
- key
- unit
- search request
- data
- primary key
- 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.)
- Active
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
本発明は、分散データベース管理装置および分散データベース管理プログラムに関するものである。
従来、分散データベース管理システムにより、各データベース（ＤＢ：DataBase）サーバに分散されて記憶されたテーブルを結合する場合には、ＤＢＭＳ（Database Management System）において、例えば、入れ子ループ法、ソートマージ法、セミジョイン法等が用いられていた。
入れ子ループ法は、一方のテーブルから１行を取り出して他方のテーブルを格納するサイトに送信する。そして、送信されたサイトでは受信した１行に対し、自身のテーブルのすべての行との結合の可能性を試した上で、結合処理を行う。
ソートマージ法は、各サイトで結合対象となる列でソート（並べ替え）して、一方から他方（結合処理を行うサイト）へソート済みのテーブル全体を送信し、受け取ったサイトでマージ（合併）しながら結合処理を行う。
セミジョイン法は、一方のサイトから結合対象の列のみを他方のサイトに送信し、受信したサイトで結合処理を行い、結合結果を送信元に送り返す。送信元では、受信した結果に対し再度、結合処理を行う。
ソートマージ法は、各サイトで結合対象となる列でソート（並べ替え）して、一方から他方（結合処理を行うサイト）へソート済みのテーブル全体を送信し、受け取ったサイトでマージ（合併）しながら結合処理を行う。
セミジョイン法は、一方のサイトから結合対象の列のみを他方のサイトに送信し、受信したサイトで結合処理を行い、結合結果を送信元に送り返す。送信元では、受信した結果に対し再度、結合処理を行う。
これらのテーブル結合方法は、いずれも、テーブル結合の際に、結合対象のテーブルの片方を他方のテーブルが格納されたサイトに送信する処理を必要とする。
また、他の方法であるＧＲＡＣＥハッシュ結合法（Grace hash join 法）は、結合対象とする２つのテーブルの結合属性に同一のハッシュ関数を施していくつかのバケットに分割し、その後に同じハッシュ値を有するバケット同士でつき合わせることより結合処理を行う（非特許文献１参照）。
一方、グーグル（Google：登録商標）が開発したデータ分散処理システムとして、MapReduceが知られている（非特許文献２参照）。このMapReduceにおいて、分割されたテーブル間の結合処理を行う方法として、Map-side join 法が知られている（非特許文献３参照）。Map-side join 法は、結合条件のキーを用いて、結合対象のテーブルを事前にソートキーで複数のＤＢサーバに分割しておき、検索時には、ＤＢサーバごとにソートキーで分割済みの２つのテーブルを同時にスキャンして結合処理を行う。ここで、結合条件のキーでソートされていない場合は、MapReduceのReduce処理において、結合するテーブルの全レコードをシャッフル（shuffle）するテーブル結合方法である、Reduce-side join 法が用いられる（非特許文献３参照）。
喜連川優、他２名、「共有メモリ型マルチプロセッサによる並列ハッシュ結合演算処理とその評価」、情報処理学会論文誌、1993年5月、第34巻、第５号、p.1019-1030
Jeffrey Dean and Sanjay Ghemawat，"MapReduce: Simplified Data Processing on Large Clusters"，OSDI'04: Sixth Symposium on Operating System Design and Implementation，San Francisco, CA, December, 2004
Jimmy Lin and Gchris Dyer，"Data-Intensive Text Processing with MapReduce"，3.5 Relational Joins，Morgan & Claypool ，2010/8/15, ISBN-10: 1608453421 , ISBN-13: 978-1608453429
しかしながら、入れ子ループ法や、ソートマージ法、セミジョイン法等のテーブル結合方法を用いた場合、いずれも結合対象のテーブルの片方を、残りの片方のテーブルが格納されているＤＢサーバに送信しなければならないため、通信コストが発生する。特に、各ＤＢサーバに格納されるデータのデータ件数やデータサイズが大ききなものになるほど、通信により発生するコストが増大することが課題となる。
非特許文献１に記載された技術であるＧＲＡＣＥハッシュジョイン法は、事前に結合対象のテーブルを、結合条件をキーに分割することで、テーブル結合時に通信コストを生じさせないものである。しかし、１テーブルに対して異なる結合条件が指定されるケースについては、結合対象のテーブルを送信しなければならないため、通信コストの発生を避けることはできない。
また、非特許文献２に記載された技術であるMapReduceでの、テーブル結合を行う方法であるMap-side join 法（非特許文献３参照）においても、ＧＲＡＣＥハッシュジョイン法と同様に、事前に結合対象のテーブルを結合条件のキーでソートするため、テーブル結合時に通信コストは生じない。しかし、ソートされた結合キー以外の条件によりテーブル結合する場合には、結合するテーブルのレコードすべてをシャッフル（shuffle）するReduce-side join法を用いなければならないため、処理コストが増大するという課題がある。
このような背景に鑑みて本発明がなされたのであり、本発明は、ＤＢサーバ間でテーブルのデータの送信処理を行わずに、複数のテーブルの結合処理を実行することができる、分散データベース管理装置および分散データベース管理プログラムを提供することを目的とする。
前記した課題を解決するため、請求項１に記載の発明は、ネットワーク上の複数のサーバに、複数のテーブルで構成されるデータベースのデータを分散して格納し、前記格納されたデータに対する検索要求を処理する分散データベース管理装置であって、前記複数のサーバに分散して格納されたデータを受信するデータ送受信部と、前記受信したデータの集合であるテーブルごとに、当該テーブルの主キーで当該テーブルのレコードをソートし、当該ソートしたレコードを、当該レコードの値ごとに前記データを格納する前記複数のサーバの数の応じた所定の範囲で分割した主キー分割テーブルを生成して記憶部に記憶し、前記記憶した主キー分割テーブルそれぞれを、前記複数のサーバに前記データ送受信部を介して送信する主キー分割テーブル生成部と、前記テーブルごとの主キーおよび外部キーのスキーマを抽出し、前記抽出したスキーマのレコードを前記外部キーでソートし、当該ソートしたレコードを、前記外部キーが参照する主キーと同じ前記所定の範囲で分割した結合用テーブルを生成して前記記憶部に記憶し、前記記憶した結合用テーブルそれぞれを、前記複数のサーバに前記データ送受信部を介して送信する結合用テーブル生成部と、前記データベースに対する前記検索要求を受け付ける検索要求受付部と、前記受け付けた検索要求の実行プランを生成し、前記生成した実行プランに含まれるテーブル結合条件に示される前記外部キーの結合対象となるテーブルを、当該テーブルについて作成された当該外部キーの前記結合用テーブルに書き換える検索要求書換部と、前記書き換えた検索要求の実行プランに基づき、前記主キー分割テーブルおよび前記結合用テーブルを用いて、検索処理を実行する検索実行部と、を備えることを特徴とする分散データベース管理装置とした。
このようにすることで、複数のサーバに、主キー分割テーブルおよび結合用テーブルを分散して格納することができる。そして、分散データベース管理装置は、検索要求を受け付けると、受け付けた検索要求の実行プランを生成し、生成した実行プランに含まれるテーブル結合条件の外部キーの結合対象となるテーブルを、そのテーブルについて作成された外部キーの結合用テーブルに書き換える。したがって、自己のサーバ以外のサーバにデータを送信する必要がないため、テーブル結合による通信コストの発生を防ぐことができる。
請求項２に記載の発明は、前記複数のサーバに分散して格納されたデータをサンプリングして得られるサンプリングデータベースを生成し、前記サンプリングしたデータに対して、前記検索要求を複数の実行プランで実行し、最も早く処理が完了した前記実行プランを、最適実行プランとして選択する最適実行プラン選択部をさらに備え、前記検索実行部は、前記最適実行プラン選択部が選択した実行プランを用いて、前記書き換えた検索要求の検索処理を実行することを特徴とする請求項１に記載の分散データベース管理装置とした。
このようにすることで、サンプリングして得られたデータに対して、複数の実行プランで検索要求の検索処理を実行した上で、最も早く処理が完了した実行プランを、検索実行部が処理する最適実行プランとして選択することができる。
請求項３に記載の発明は、前記検索実行部による前記書き換えた検索要求の検索処理の実行において、MapReduceを用いる場合に、前記主キー分割テーブル生成部は、前記受信したデータの集合であるテーブルごとに、当該テーブルの主キーを、map関数のキーとして設定し、当該設定したキーを用いてハッシュ分割することにより前記主キー分割テーブルを生成し、前記結合用テーブル生成部は、前記テーブルごとの主キーおよび外部キーのスキーマを抽出し、前記抽出した外部キーをmap関数のキーとして設定し、当該設定したキーを用いてハッシュ分割することにより前記結合用テーブルを生成することを特徴とする請求項１に記載の分散データベース管理装置とした。
このようにすることで、MapReduceを用いて、検索要求の検索処理が実行される場合においても、主キー分割テーブルおよび結合用テーブルを生成しておくことにより、自己のサーバ以外のサーバにデータを送信する必要がないため、テーブル結合による通信コストの発生を防ぐことができる。
請求項４に記載の発明は、請求項１乃至請求項３のいずれか一項に記載の分散データベース管理装置を構成する各手段としてコンピュータを機能させるための分散データベース管理プログラムとした。
本発明に係る分散データベース管理プログラムは、請求項１乃至請求項３のいずれか一項に記載の分散データベース管理装置を構成する各手段としてコンピュータを機能させるためのプログラムである。このように構成されることにより、このプログラムをインストールされたコンピュータは、このプログラムに基づいた各機能を実現することができる。
本発明によれば、ＤＢサーバ間でテーブルのデータの送信処理を行わずに、複数のテーブルの結合処理を実行することができる、分散データベース管理装置および分散データベース管理プログラムを提供するができる。
次に、本発明を実施するための形態（以下、「実施形態」という）について、適宜図面を参照しながら詳細に説明する。
図１は、本実施形態に係る分散データベースシステム１の構成を示す機能ブロック図である。図１に示すように、本実施形態に係る分散データベースシステム１は、ネットワーク３０に接続された複数のＤＢ（DataBase）サーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）と、分散データベース管理装置１０とを含んで構成される。
ＤＢサーバ２０は、クライアント４０と接続され、また不図示のデータベース管理サーバにネットワーク３０を介して接続される。このＤＢサーバ２０は、データベース管理サーバ等から受信したデータベースのデータを、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）が備えるＤＢＭＳ（Database Management System）により、各データベース２００（２００Ａ，２００Ｂ，２００Ｃ，２００Ｄ，…）に分割したデータとして格納する。また、この各データベース２００には、分散データベース管理装置１０が生成した、後記する主キー分割テーブルおよび結合用テーブルが分散して記憶される（詳細は、図４参照）。
分散データベース管理装置１０は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に格納され、自ＤＢサーバ２０内でテーブル結合を実行するための、主キー分割テーブルおよび結合用テーブルを生成し、クライアント４０等から受信した検索要求の書換処理を行った上で検索実行する装置である。
分散データベース管理装置１０は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）のＤＢＭＳの処理により、分散して格納されているデータベースのデータを取得して、データベースの加工処理(データベース加工処理)を行う。このデータベース加工処理は、後の処理である検索処理の際に、自ＤＢサーバ２０内でテーブル結合が行えるように、データベースのデータを事前に加工しておくものである。具体的には、分散データベース管理装置１０は、取得したデータベースのテーブルごとに、そのテーブルの主キーでレコードをソートして分割した主キー分割テーブルと、主キーおよび外部キーのスキーマのレコードを、外部キーでソートし分割した結合用テーブルを生成し、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）それぞれに格納しておく。そして、クライアント４０等から、検索要求を受け付けると、分散データベース管理装置１０は、その検索要求の実行プランについて、テーブル結合条件の外部キーの結合対象となるテーブルを、結合用テーブルに書き換えて、検索処理を実行する。このようにすることにより、本実施形態に係る分散データベース管理装置１０は、通信コストを発生させずにテーブル結合処理を実現させることができる。
分散データベース管理装置１０は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）のＤＢＭＳの処理により、分散して格納されているデータベースのデータを取得して、データベースの加工処理(データベース加工処理)を行う。このデータベース加工処理は、後の処理である検索処理の際に、自ＤＢサーバ２０内でテーブル結合が行えるように、データベースのデータを事前に加工しておくものである。具体的には、分散データベース管理装置１０は、取得したデータベースのテーブルごとに、そのテーブルの主キーでレコードをソートして分割した主キー分割テーブルと、主キーおよび外部キーのスキーマのレコードを、外部キーでソートし分割した結合用テーブルを生成し、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）それぞれに格納しておく。そして、クライアント４０等から、検索要求を受け付けると、分散データベース管理装置１０は、その検索要求の実行プランについて、テーブル結合条件の外部キーの結合対象となるテーブルを、結合用テーブルに書き換えて、検索処理を実行する。このようにすることにより、本実施形態に係る分散データベース管理装置１０は、通信コストを発生させずにテーブル結合処理を実現させることができる。
また、本実施形態に係る分散データベース管理装置１０によれば、テーブル結合を複数回実行する実行プランを用いた検索処理において、最適な実行プランを選択することが可能となる。
従来のＤＢＭＳにおいて、複数のテーブル結合を含む検索処理を行う場合は、各テーブルにおける各カラム値の分布をヒストグラム等の形式で統計的に記憶しておき、テーブル結合の結果のデータ量が最小になるように結合処理を見積もることで最適プランを決定する。しかし、ＷＨＥＲＥ条件が付与されたり、テーブル結合が多段になるにしたがって、正確に最適プランを選択することが困難になっていた。本実施形態に係る分散データベース管理装置１０によれば、対象となるデータベースから、例えば、ランダムサンプリングによる方法によりサンプリングデータを取得し、検索要求についての複数の実行プランを、取得したサンプリングデータに対して実行し、最も早く処理が完了した実行プランを選択する。このようにすることで、本実施形態に係る分散データベース管理装置１０は、処理が最も早い最適な実行プランを用いて、検索要求の実行処理を行うことができる。
従来のＤＢＭＳにおいて、複数のテーブル結合を含む検索処理を行う場合は、各テーブルにおける各カラム値の分布をヒストグラム等の形式で統計的に記憶しておき、テーブル結合の結果のデータ量が最小になるように結合処理を見積もることで最適プランを決定する。しかし、ＷＨＥＲＥ条件が付与されたり、テーブル結合が多段になるにしたがって、正確に最適プランを選択することが困難になっていた。本実施形態に係る分散データベース管理装置１０によれば、対象となるデータベースから、例えば、ランダムサンプリングによる方法によりサンプリングデータを取得し、検索要求についての複数の実行プランを、取得したサンプリングデータに対して実行し、最も早く処理が完了した実行プランを選択する。このようにすることで、本実施形態に係る分散データベース管理装置１０は、処理が最も早い最適な実行プランを用いて、検索要求の実行処理を行うことができる。
＜分散データベース管理装置＞
図２は、本実施形態に係る分散データベース管理装置１０の構成を示す機能ブロック図である。図２に示すように、分散データベース管理装置１０は、入出力部１１と、制御部１２と、記憶部１３とを含んで構成される。
図２は、本実施形態に係る分散データベース管理装置１０の構成を示す機能ブロック図である。図２に示すように、分散データベース管理装置１０は、入出力部１１と、制御部１２と、記憶部１３とを含んで構成される。
入出力部１１は、ＤＢサーバ２０との間の情報の入出力を行う。例えば、入出力部１１は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散して格納されたデータを取得する。また、入出力部１１は、制御部１２により生成された主キー分割テーブルおよび結合用テーブルを各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）それぞれに送信する。また、この入出力部１１は、不図示のキーボート等の入力装置やモニタ等の表示装置等との間で入出力を行う入出力インタフェースと、ネットワークを介して情報の送受信を行うネットワークインタフェースとから構成される。
記憶部１３は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等で構成され、制御部１２による処理を実行するためのプログラム等を記憶する。
制御部１２は、分散データベース管理装置１０全体の制御を司り、データ送受信部１２１と、主キー分割テーブル生成部１２２と、結合用テーブル生成部１２３と、検索要求受付部１２４と、検索要求書換部１２５と、最適実行プラン選択部１２６と、検索実行部１２７とを備える。なお、この制御部１２および入出力部１１は、例えば、分散データベース管理装置１０の記憶部１３に格納されたプログラムを、ＣＰＵ（Central Processing Unit）がＲＡＭに展開し実行することで実現される。
データ送受信部１２１は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散して格納されたデータベースのデータを、入出力部１１を介して取得する。また、主キー分割テーブル生成部１２２が生成する主キー分割テーブルと、結合用テーブル生成部１２３が生成する結合用テーブルとを、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）それぞれに入出力部１１を介して送信する。
主キー分割テーブル生成部１２２は、データベースのテーブルごとに、そのテーブルの主キーでレコードをソートし分割した主キー分割テーブルを生成する。
具体的には、主キー分割テーブル生成部１２２は、データ送受信部１２１が受信するデータの集合であるデータベースのテーブルごとに、そのテーブルの主キーで当該テーブルのレコードをソートする。そして、主キー分割テーブル生成部１２２は、そのソートしたレコードを、当該レコードの値ごとにデータを格納するＤＢサーバ２０の数に応じた所定の範囲で分割し、主キー分割テーブルを生成する。また、主キー分割テーブル生成部１２２は、生成した主キー分割テーブルを記憶部１３に記憶し、その記憶した主キー分割テーブルそれぞれを、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散させて送信する。各ＤＢサーバ２０では、送信されたデータを各ＤＢ２００（２００Ａ，２００Ｂ，２００Ｃ，２００Ｄ，…）に記憶する。
具体的には、主キー分割テーブル生成部１２２は、データ送受信部１２１が受信するデータの集合であるデータベースのテーブルごとに、そのテーブルの主キーで当該テーブルのレコードをソートする。そして、主キー分割テーブル生成部１２２は、そのソートしたレコードを、当該レコードの値ごとにデータを格納するＤＢサーバ２０の数に応じた所定の範囲で分割し、主キー分割テーブルを生成する。また、主キー分割テーブル生成部１２２は、生成した主キー分割テーブルを記憶部１３に記憶し、その記憶した主キー分割テーブルそれぞれを、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散させて送信する。各ＤＢサーバ２０では、送信されたデータを各ＤＢ２００（２００Ａ，２００Ｂ，２００Ｃ，２００Ｄ，…）に記憶する。
結合用テーブル生成部１２３は、テーブルごとの主キーおよび外部キーのスキーマを抽出し、その抽出したスキーマのレコードを、外部キーでソートする。そして、結合用テーブル生成部１２３は、そのソートしたレコードを、外部キーが参照する主キーと同じ所定の範囲で分割し、結合用テーブルを生成する。結合用テーブル生成部１２３は、生成した結合用テーブルを記憶部１３に記憶し、その記憶した結合用テーブルそれぞれを、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散させて送信する。各ＤＢサーバ２０では、送信されたデータを各ＤＢ２００（２００Ａ，２００Ｂ，２００Ｃ，２００Ｄ，…）に記憶する。
この主キー分割テーブル生成部１２２および結合用テーブル生成部１２３によるテーブルの分割は、結合条件となる主キーと外部キーとにおいて、同じ範囲で分割する。そして、同じ範囲で分割された主キー分割テーブルと結合用テーブルは、同じ１つのＤＢサーバ２０に格納する。このようにすることで、結合対象の両テーブルにおける同じ範囲のレコード群は、同一のＤＢサーバ２０内に格納されることとなる。
検索要求受付部１２４は、クライアント４０や不図示のデータベース管理サーバ等から入出力部１１を介して、検索要求（クエリ）を受け付ける。そして、検索要求受付部１２４は、受け付けた検索要求を、検索要求書換部１２５に出力する。
検索要求書換部１２５は、検索要求受付部１２４から受信した検索要求の実行プランを生成する。そして、その生成した実行プランに含まれるテーブル結合条件の外部キーに示される結合対象となるテーブルを、そのテーブルについて作成された外部キーの結合用テーブルに書き換える。
また、検索要求書換部１２５は、テーブル結合処理が複数のステップから構成される場合に、次のステップで結合対象となるキーに基づき、当該処理結果を分割する（詳細は、後記する図１３および図１４参照）。
なお、この実行プランは、例えば、従来技術であるbushy tree プランや、left-deep プラン等のテーブル結合の最適化法（非特許文献４：Left-deep vs. bushy trees: an analysis of strategy spaces and its implications for query optimization, ACM SIGMOD Record Volume 20, Issue 2, p.168-177, June 1991）を用いて作成される。
また、検索要求書換部１２５は、テーブル結合処理が複数のステップから構成される場合に、次のステップで結合対象となるキーに基づき、当該処理結果を分割する（詳細は、後記する図１３および図１４参照）。
なお、この実行プランは、例えば、従来技術であるbushy tree プランや、left-deep プラン等のテーブル結合の最適化法（非特許文献４：Left-deep vs. bushy trees: an analysis of strategy spaces and its implications for query optimization, ACM SIGMOD Record Volume 20, Issue 2, p.168-177, June 1991）を用いて作成される。
最適実行プラン選択部１２６は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に格納されたデータから、例えば、ランダムサンプリングによる方法によりサンプリングデータを取得し、記憶部１３内にサンプリングデータベースを生成する。そして、そのサンプリングしたデータに対して、検索要求書換部１２５が書き換えた検索要求のbushy tree プランやleft-deep プラン等を用いた複数の実行プランを実行し、最も早く処理が完了した実行プランを、最適実行プランとして選択する。
検索実行部１２７は、最適実行プラン選択部１２６が選択した検索要求の実行プランに基づき、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に格納されたデータの検索処理を実行する。本検索処理においては、各ＤＢサーバ２０内の検索実行部を呼び出すことによって、各ＤＢサーバ２０が格納するデータに対して検索処理を実行する。
（分散データ管理装置の処理手順）
次に、本実施形態に係る分散データベース管理装置１０の処理手順について、図２を参照しつつ、図３〜図１５を用いて詳細に説明する。
次に、本実施形態に係る分散データベース管理装置１０の処理手順について、図２を参照しつつ、図３〜図１５を用いて詳細に説明する。
図３は、本実施形態に係る分散データベース管理装置１０の処理概要を示すフローチャートである。図３に示すように、分散データベース管理装置１０が実行する処理は、大きく分けて、データベース加工処理（ステップＳ１）とデータ検索処理（ステップＳ２）とを行う。
ステップＳ１のデータベース加工処理は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散されて格納されているデータを取り込み、主キー分割テーブル生成部１２２が主キー分割テーブルを生成し、結合用テーブル生成部１２３が結合用テーブルを生成して、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散して格納させる。
ステップＳ２のデータ検索処理は、検索要求受付部１２４が、クライアント４０等から検索要求（クエリ）を受け付け、検索要求書換部１２５が、その検索要求の実行プランに含まれる結合対象となるテーブルを結合用テーブルに書き換えた上で、検索実行部１２７が検索処理を実行する。
次に、データベース加工処理（ステップＳ１）、データ検索処理（Ｓ２）のそれぞれについて、詳細に説明する。
〔データベース加工処理〕
図４は、本実施形態に係る分散データベース管理装置１０のデータベース加工処理（図３のステップＳ１）の流れを示すフローチャートである。このデータベース加工処理では、図４に示すように、主キー分割テーブルの生成処理（ステップＳ１１）と結合用テーブルの生成処理（ステップＳ１２）とを行う。
図４は、本実施形態に係る分散データベース管理装置１０のデータベース加工処理（図３のステップＳ１）の流れを示すフローチャートである。このデータベース加工処理では、図４に示すように、主キー分割テーブルの生成処理（ステップＳ１１）と結合用テーブルの生成処理（ステップＳ１２）とを行う。
（主キー分割テーブル生成処理）
まず、データ送受信部１２１は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散して格納された各テーブルのデータを、入出力部１１を介して取得する（ステップＳ１１１）。
まず、データ送受信部１２１は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散して格納された各テーブルのデータを、入出力部１１を介して取得する（ステップＳ１１１）。
次に、主キー分割テーブル生成部１２２は、データ送受信部１２１が取得したテーブルごとのデータについて、そのテーブルの主キーでレコードをソートする。そして、主キー分割テーブル生成部１２２は、そのソートしたレコードを、当該レコードの値ごとにデータを格納するＤＢサーバ２０の数に応じた所定の範囲で分割し、主キー分割テーブルを生成する（ステップＳ１１２）。なお、データを記憶するためのＤＢサーバ２０が、例えば１０台あれば、ソートしたレコードを１０分割し、１００台あれば、ソートしたレコードを１００分割する。
続いて、主キー分割テーブル生成部１２２は、生成した主キー分割テーブルを自身の記憶部１３に記憶し、その記憶した各主キー分割テーブルを、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）それぞれに送信する（ステップＳ１１３）。
（結合用テーブル生成処理）
次に、結合用テーブル生成部１２３は、テーブルごとの主キーおよび外部キーのスキーマを抽出し、その抽出したスキーマのレコードを、外部キーでソートする。そして、結合用テーブル生成部１２３は、ソートしたレコードを、外部キーが参照する主キーと同じ範囲で分割し、結合用テーブルを生成する（ステップＳ１２１）。
次に、結合用テーブル生成部１２３は、テーブルごとの主キーおよび外部キーのスキーマを抽出し、その抽出したスキーマのレコードを、外部キーでソートする。そして、結合用テーブル生成部１２３は、ソートしたレコードを、外部キーが参照する主キーと同じ範囲で分割し、結合用テーブルを生成する（ステップＳ１２１）。
続いて、結合用テーブル生成部１２３は、生成した結合用テーブルを自身の記憶部１３に記憶し、その記憶した各結合用テーブルを、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）それぞれに送信する（ステップＳ１２２）。
なお、この主キー分割テーブルのレコードと、結合用テーブルのレコードとは同じ範囲で分割し、分割された同じ範囲の主キー分割テーブルおよび結合用テーブルのレコード群は、同一のＤＢサーバ２０内に格納する。
この主キー分割テーブルおよび結合用テーブルを、図５および図６に示す具体例を用いて説明する。図５は、ＴＰＣ（Transaction Processing Performance Council）−Ｈのベンチマークで規定されるスキーマ構造を示す。また、図６は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）の各ＤＢ２００に格納される主キー分割テーブルおよび結合用テーブルを概念的に示す図である。
図５に示すスキーマ例において、例えば、「ＰＡＲＴ」，「ＰＡＲＴＳＵＰＰ」，「ＬＩＮＥＩＴＥＭ」等はテーブル名を表し、（Ｐ＿），（ＰＳ＿），（Ｌ＿）等は、テーブル名の略称を表し、「SF*200,000」，「SF*800,000」，「SF*6,000,000」等はそのテーブルのレコード数を表す。また、例えば、「ＰＡＲＴＳＵＰＰ」テーブルにおいて、「ＰＡＴＲＴＫＥＹ」，「ＳＵＰＰＫＥＹ」，「ＡＶＡＩＬＱＴＹ」等はそのテーブルの属性名を表し、属性名のうち、ドッドで示した「ＰＡＴＲＫＥＹ」「ＳＵＰＰＫＥＹ」はそのテーブルの主キーであることを示す。そして、他のテーブルの主キーから矢印（→）で接続された属性名は、そのテーブルの外部キー（下線で示す）であることを示している。よって、例えば、「ＰＡＲＴＳＵＰＰ」テーブルにおいて、「ＰＡＴＲＫＥＹ」および「ＳＵＰＰＫＥＹ」は、主キーでもあり、外部キーでもあることを示している。
そして、図６は、この図５に示すスキーマで示されるデータについて、図４に示すデータベース加工処理を行った結果、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）のＤＢ２００（２００Ａ，２００Ｂ，２００Ｃ，２００Ｄ，…）に分散され格納された主キー分割テーブルと結合用テーブルとを示している。
図６に示すように、主キー分割テーブルのうち、例えば、「part(partkey,name,…)」(図において、partkeyの下線は主キーを示す)は、「ＰＡＲＴ」テーブルを、主キーである「ＰＡＲＴＫＥＹ」でソートした上で、そのレコードの値ごとにデータを格納するＤＢサーバ２０の数に応じた所定の範囲で分割して生成した主キー分割テーブルである。また、「partsupp(partkey,suppkey,availqty,…)」（図において、partkeyおよびsuppkeyの下線は主キーを示す）は、「ＰＡＲＴＳＵＰＰ」テーブルを、主キーである「ＰＡＲＴＫＥＹ」および「ＳＵＰＰＫＥＹ」でソートした上で、そのレコードの値ごとにデータを格納するＤＢサーバ２０の数に応じた所定の範囲で分割して生成した主キー分割テーブルである。
また、結合用テーブルのうち、例えば、「partsupp_v1(partkey,suppkey)」（図において、partkeyの下線は外部キーを示す）は、「ＰＡＲＴＳＵＰＰ」テーブルの主キー（「ＰＡＲＴＫＥＹ」および「ＳＵＰＰＫＥＹ」）および外部キー（「ＰＡＲＴＫＥＹ」）のスキーマを抽出し、抽出した「ＰＡＲＴＫＥＹ」および「ＳＵＰＰＫＥＹ」のレコードを、外部キーである「ＰＡＲＴＫＥＹ」でソートした上で、外部キーが参照する主キーと同じ範囲（「ＰＡＲＴ」テーブルの主キー分割テーブルの分割と同じ範囲）で分割して生成した結合用テーブルである。また、「partsupp_v2(suppkey,partkey)」（図において、suppkeyの下線は外部キーを示す）は、「ＰＡＲＴＳＵＰＰ」テーブルの主キー（「ＰＡＲＴＫＥＹ」および「ＳＵＰＰＫＥＹ」）および外部キー（「ＳＵＰＰＫＥＹ」）のスキーマを抽出し、抽出した「ＰＡＲＴＫＥＹ」および「ＳＵＰＰＫＥＹ」のレコードを、外部キーである「ＳＵＰＰＫＥＹ」でソートした上で、外部キーが参照する主キーと同じ範囲（「ＳＵＰＰＬＩＥＲ」テーブルの主キー分割テーブルの分割と同じ範囲）で分割して生成した結合用テーブルである。
なお、図６の破線で囲った「nation(nationkey,name,…)」，「region(regionkey,name,…)」は、図５に示すように、レコード数がそれぞれ「25」，「5」という小規模テーブルであるため、オンメモリ化して結合処理を行う。つまり、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）において分割して格納せずに、ＤＢ２００（２００Ａ，２００Ｂ，２００Ｃ，２００Ｄ，…）それぞれにデータを記憶しておく。
〔データ検索処理〕
図７は、本実施形態に係る分散データベース管理装置１０のデータ検索処理（図３のステップＳ２）の流れを示すフローチャートである。
図７は、本実施形態に係る分散データベース管理装置１０のデータ検索処理（図３のステップＳ２）の流れを示すフローチャートである。
まず、分散データベース管理装置１０の検索要求受付部１２４は、クライアント４０等から、入出力部１１を介して検索要求（クエリ）を受け付ける（ステップＳ２１）。
次に、検索要求書換部１２５は、例えば、bushy tree プランや、left-deep プラン等のテーブル結合の最適化法を用いて、複数の検索要求の実行プランを作成する。そして、検索要求書換部１２５は、作成した各実行プランごとに、その実行プランに含まれるテーブル結合条件の外部キーに示される結合対象となるテーブルを、そのテーブルについて作成された外部キーの結合用テーブルに書き換える（ステップＳ２２）。
なお、この検索要求書換部１２５の結合用テーブルを用いた書換処理については、後記する図８〜図１５を用いて詳細に説明する。
なお、この検索要求書換部１２５の結合用テーブルを用いた書換処理については、後記する図８〜図１５を用いて詳細に説明する。
続いて、最適実行プラン選択部１２６は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に格納されたデータをサンプリングして記憶部１３内にサンプリングデータベースを生成する。そして、最適実行プラン選択部１２６は、そのサンプリングしたデータに対して、検索要求書換部１２５が書き換えた検索要求の各実行プランを実行し、最も早く処理が完了した実行プランを、最適実行プランとして選択する（ステップＳ２３）。
そして、検索実行部１２７は、最適実行プラン選択部１２６が選択した検索要求の実行プランに基づき、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に格納されたデータの検索処理を実行する（ステップＳ２４）。
（結合用テーブルを用いた書換処理）
次に、図７のステップＳ２２における、検索要求書換部１２５による結合用テーブルを用いた検索要求の実行プランの書換処理について説明する。ここでは、図７のステップＳ２１において、検索要求受付部１２４が、図８に示す検索要求（クエリ）を受け付けた例として説明する。また、図８に示す検索要求は、図５のスキーマ例で示したデータベースにおいて、「ＰＡＲＴ」，「ＳＵＰＰＬＩＥＲ」，「ＬＩＮＥＩＴＥＭ」，「ＰＡＲＴＳＵＰＰ」，「ＯＲＤＥＲＳ」，「ＮＡＴＩＯＮ」の６つのテーブル（from句を参照）を結合する処理であるため、多数の実行プランが想定されるが、その１つの実行プランとして、図９に示す実行プランの書換処理を行うものとする。
次に、図７のステップＳ２２における、検索要求書換部１２５による結合用テーブルを用いた検索要求の実行プランの書換処理について説明する。ここでは、図７のステップＳ２１において、検索要求受付部１２４が、図８に示す検索要求（クエリ）を受け付けた例として説明する。また、図８に示す検索要求は、図５のスキーマ例で示したデータベースにおいて、「ＰＡＲＴ」，「ＳＵＰＰＬＩＥＲ」，「ＬＩＮＥＩＴＥＭ」，「ＰＡＲＴＳＵＰＰ」，「ＯＲＤＥＲＳ」，「ＮＡＴＩＯＮ」の６つのテーブル（from句を参照）を結合する処理であるため、多数の実行プランが想定されるが、その１つの実行プランとして、図９に示す実行プランの書換処理を行うものとする。
図９に示す実行プランは、
・「Ｑ０」を実行
・「Ｑ０」の結果を入力して「Ｑ１」を実行
・「Ｑ３」を実行
・「Ｑ１」，「Ｑ３」の結果を入力して「Ｑ２」を実行
・「Ｑ２」の結果を入力して「Ｑ５」を実行
・「Ｑ４」を実行
・「Ｑ５」，「Ｑ４」の結果を入力して「Ｑ６」を実行
・「Ｑ６」の結果を入力して「Ｑ７」を実行
という順序で各部分クエリ「Ｑ０」〜「Ｑ７」を実行するプランである。各部分クエリ「Ｑ０」〜「Ｑ７」の詳細は、図１０および図１１に示すとおりである。
・「Ｑ０」を実行
・「Ｑ０」の結果を入力して「Ｑ１」を実行
・「Ｑ３」を実行
・「Ｑ１」，「Ｑ３」の結果を入力して「Ｑ２」を実行
・「Ｑ２」の結果を入力して「Ｑ５」を実行
・「Ｑ４」を実行
・「Ｑ５」，「Ｑ４」の結果を入力して「Ｑ６」を実行
・「Ｑ６」の結果を入力して「Ｑ７」を実行
という順序で各部分クエリ「Ｑ０」〜「Ｑ７」を実行するプランである。各部分クエリ「Ｑ０」〜「Ｑ７」の詳細は、図１０および図１１に示すとおりである。
そして、図７のステップＳ２２において、検索要求書換部１２５が、結合用テーブルを用いて検索要求の実行プランの書き換えた結果が、図１２に示す部分クエリの実行プランと、図１３〜図１５に示す各部分クエリの詳細である。
例えば、検索要求書換部１２５は、部分クエリ「Ｑ１」（図１０参照）を、「Ｑ１'」（図１３参照）に書き換える。
ここで、部分クエリ「Ｑ１」におけるテーブル結合条件（where句）は、
s_suppkey = ps_suppkey
である。「s_」は「ＳＵＰＰＬＩＥＲ」テーブルを意味し、「ps_」は、「ＰＡＲＴＳＵＰＰ」テーブルを意味する。
検索要求書換部１２５は、この外部キー「suppkey」の結合条件側のテーブルである「ＰＡＲＴＳＵＰＰ」テーブルを、結合用テーブル「partsupp_v2」に書き換える。具体的には、検索要求書換部１２５は、from句のテーブルを、「partsupp」（図１０参照）から「partsupp_v2」（図１３参照）に書き換える。ここで、図１３の「Ｑ１'」のfrom句に示す「Ｑ０」の結果テーブルである「＄Ｑ０」はs_suppkeyをキーに分割されており、結合用テーブル「partsupp_v2」も同様にs_suppkeyをキーに分割されている。そのため、自己のＤＢサーバ２０内だけで結合処理を行うことができる。なお、部分クエリにおける「＄Ｑ」の表記は、部分クエリ「Ｑ」の結果テーブルを表す。
ここで、部分クエリ「Ｑ１」におけるテーブル結合条件（where句）は、
s_suppkey = ps_suppkey
である。「s_」は「ＳＵＰＰＬＩＥＲ」テーブルを意味し、「ps_」は、「ＰＡＲＴＳＵＰＰ」テーブルを意味する。
検索要求書換部１２５は、この外部キー「suppkey」の結合条件側のテーブルである「ＰＡＲＴＳＵＰＰ」テーブルを、結合用テーブル「partsupp_v2」に書き換える。具体的には、検索要求書換部１２５は、from句のテーブルを、「partsupp」（図１０参照）から「partsupp_v2」（図１３参照）に書き換える。ここで、図１３の「Ｑ１'」のfrom句に示す「Ｑ０」の結果テーブルである「＄Ｑ０」はs_suppkeyをキーに分割されており、結合用テーブル「partsupp_v2」も同様にs_suppkeyをキーに分割されている。そのため、自己のＤＢサーバ２０内だけで結合処理を行うことができる。なお、部分クエリにおける「＄Ｑ」の表記は、部分クエリ「Ｑ」の結果テーブルを表す。
また、検索要求書換部１２５は、「Ｑ１'」の後続の処理である「Ｑ２'」のテーブル結合処理を、分散する各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）内で実行できるように、処理結果をＱ２の結合条件（ps_partkey，ps_suppkey）をキーとして分割する。具体的には、検索要求書換部１２５は、各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散して格納させるため、「Ｑ１'」において、「GROUP BY ps_partkey,ps_suppkey」の処理を加える。ここで「GROUP BY」は、データを分割する命令である。「Ｑ３」および「Ｑ４」については、「Ｑ１」と同様に、「Ｑ３'」，「Ｑ４'」として書換えを行う。
「Ｑ２」についての書換えは、入力となる「Ｑ１」，「Ｑ３」の検索結果である結果テーブル「＄Ｑ１」，「＄Ｑ３」を、結果テーブル「＄Ｑ１'」，「＄Ｑ３'」とすることで「Ｑ２'」を得る。ここで、「Ｑ２'」についても、「Ｑ１'」と同様に、後続の処理である「Ｑ５」の結合条件をキーとしてデータを分割して各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に分散して格納する必要があるが、「Ｑ５」の結合条件がpartkey,supkeyであり、「Ｑ２'」の入力データが既にこの条件で分割済みであるため、「GROUP BY」の処理を加える必要はない。「Ｑ６'」についても、同様に「GROUP BY」を加える必要はない。
なお、「Ｑ６'」については、from句で指定された「lineitem」を、「lineitem_v1」もしくは「lineitem_v2」に書き換える必要はない。各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に格納された「lineitem」の主キー分割テーブルにおいて、「Ｑ６'」に入力される「Ｑ５'」および「Ｑ４'」と同じ、orderkey,partkey,suppkeyをキーに分割済みであるからである。
以上のように、本実施形態に係る分散データベース管理装置１０および分散データベース管理プログラムによれば、検索要求書換部１２５が、検索要求の実行プランを書き換えることで、テーブル結合処理を、個々のＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）内で完了することが可能となる。したがって、テーブル結合処理において、各ＤＢサーバ２０間で、データを送受信する必要がなく、通信コストの発生を防ぐことができる。
さらに、本実施形態に係る分散データベース管理装置１０および分散データベース管理プログラムによれば、テーブル結合を複数回実行する実行プランを用いた検索処理において、サンプリングデータに対して複数の検索要求の実行プランを実行することで、最も早く処理が完了した実行プランを、最適実行プランとして選択することが可能となる。
さらに、本実施形態に係る分散データベース管理装置１０および分散データベース管理プログラムによれば、テーブル結合を複数回実行する実行プランを用いた検索処理において、サンプリングデータに対して複数の検索要求の実行プランを実行することで、最も早く処理が完了した実行プランを、最適実行プランとして選択することが可能となる。
＜本実施形態の変形例＞
次に、本実施形態の変形例について説明する。図１において示した本実施形態に係る分散データベースシステム１においては、各ＤＢサーバ２０は、ＤＢＭＳにより分散処理を行うものとして説明した。本実施形態に係る変形例は、図２に示した分散データベース管理装置１０と同じ構成を備えるものであるが、分散処理システムとしてＤＢＭＳの代わりにMapReduceを用いる。以下、本実施形態において説明した分散データベース管理装置１０と異なる処理について説明する。
次に、本実施形態の変形例について説明する。図１において示した本実施形態に係る分散データベースシステム１においては、各ＤＢサーバ２０は、ＤＢＭＳにより分散処理を行うものとして説明した。本実施形態に係る変形例は、図２に示した分散データベース管理装置１０と同じ構成を備えるものであるが、分散処理システムとしてＤＢＭＳの代わりにMapReduceを用いる。以下、本実施形態において説明した分散データベース管理装置１０と異なる処理について説明する。
図４に示した主キー分割テーブルの生成処理（Ｓ１１）において、MapReduceを用いた場合には、主キー分割テーブル生成部１２２は、データ送受信部１２１が受信したテーブルについて、その主キーをmap関数のキーとして設定することで、その設定したキーを用いてハッシュ分割することにより主キー分割テーブルを生成する。そして、生成した主キー分割テーブルを各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）それぞれにシャッフル（shuffle） 操作により送信され、reduce 操作により結果が分散して格納される。
また、図７に示すデータ検索処理においては、分散データベース管理装置１０に相当する機能をHive (非特許文献５：Ashish Thusoo, Joydeep Sen Sarma, Namit Jain, Zheng Shao, Prasad Chakka, Ning Zhang, Suresh Antony, Hao Liu and Raghotham Murthy ，"Hive - A Petabyte Scale Data Warehouse Using Hadoop"，Facebook Data Infrastruct. Team, CA, USA，IEEE 26th International Conference on Data Engineering (ICDE)， p.996-1005，2010)等のMapReduce 上でSQLを実行する仕組みを用いることで、検索要求を受け付けて実行プランを生成することができる。しかし、Hive では通常の分散ＤＢＭＳと同様に結合用テーブルを用いた検索命令に書き換える機能を有しないため、検索要求書換部１２５を組み込む必要がある。検索要求書換部１２５は、Hiveにおける検索要求受付部１２４が受け付けた検索要求の実行プランについて、テーブル結合条件の外部キーの結合対象となるテーブルを結合用テーブルに書き換えることができることから、非特許文献３に示したMap-side join法において、テーブル結合処理が個々のＤＢサーバ２０内で完了するように実装することができる。
さらに、図１２〜図１５に示したように、テーブル結合を多段階で処理する場合には、Map-side join法を用いた処理の後に、後続のテーブル結合を含む部分クエリをMap-side join法を用いて処理できるようにするため、後続のテーブル結合における結合条件をキーとしてMapタスクの結果を出力し、シャッフル（shuffle）して当該キーごとに結果を分割して各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）に送信する。一方、後続の処理がグループ化処理の場合は、シャッフルによりグループ化を行い、後続の処理がソート処理の場合は、シャッフルにより１つのＤＢサーバ２０に集約して（つまりグループ数を１とする）結果をソートする。
具体的には、図１２〜図１５に示した「Ｑ１'」〜「Ｑ６'」については、結合用テーブルを用いて結合処理を行うため、その処理をMap-side joinを用いて実行することができる。また、「Ｑ１'」〜「Ｑ５'」については、後続の部分クエリでテーブル結合を行うため「GROUP BY」が指定されており、この「GROUP BY」の指定に基づき、「GROUP BY」キーでシャッフルし、当該キーごとに結果を分割して各ＤＢサーバ２０（２０Ａ，２０Ｂ，２０Ｃ，２０Ｄ，…）それぞれに送信する。なお、「Ｑ２'」については、前記したように、入力データが既にデータ分割されているため、「GROUP BY」指定はされていないものである。「Ｑ６'」では、書き換え前の「Ｑ６」（図１１参照）において「BROUP BY」が記述されており、この指示でMapReduceにおけるシャッフルによりグループ化を行う。また、「Ｑ７'」では、書き換え前の「Ｑ７」（図１１参照）において、ソート処理が「ORDER BY」として記述されており、この指示でMapReduceにおけるシャッフルにより１つのＤＢサーバ２０に集約して結果をソートする。
このように、本実施形態の変形例に係る分散データベース管理装置１０において、MapReduceを用いた場合でも、検索要求書換部１２５が、検索要求の実行プランを結合用テーブルを用いて書き換えることができることから、Map-side join法を用いて、テーブル結合を実現することができる。したがって、各ＤＢサーバ２０間で、データを送受信する必要がなく、通信コストの発生させずに、テーブル結合処理を実現することができる。
１ 分散データベースシステム
１０ 分散データベース管理装置
１１ 入出力部
１２ 制御部
１３ 記憶部
２０ ＤＢサーバ
３０ ネットワーク
４０ クライアント
１２１ データ送受信部
１２２ 主キー分割テーブル生成部
１２３ 結合用テーブル生成部
１２４ 検索要求受付部
１２５ 検索要求書換部
１２６ 最適実行プラン選択部
１２７ 検索実行部
２００ ＤＢ（データベース）
１０ 分散データベース管理装置
１１ 入出力部
１２ 制御部
１３ 記憶部
２０ ＤＢサーバ
３０ ネットワーク
４０ クライアント
１２１ データ送受信部
１２２ 主キー分割テーブル生成部
１２３ 結合用テーブル生成部
１２４ 検索要求受付部
１２５ 検索要求書換部
１２６ 最適実行プラン選択部
１２７ 検索実行部
２００ ＤＢ（データベース）
Claims (4)
- ネットワーク上の複数のサーバに、複数のテーブルで構成されるデータベースのデータを分散して格納し、前記格納されたデータに対する検索要求を処理する分散データベース管理装置であって、
前記複数のサーバに分散して格納されたデータを受信するデータ送受信部と、
前記受信したデータの集合であるテーブルごとに、当該テーブルの主キーで当該テーブルのレコードをソートし、当該ソートしたレコードを、当該レコードの値ごとに前記データを格納する前記複数のサーバの数の応じた所定の範囲で分割した主キー分割テーブルを生成して記憶部に記憶し、前記記憶した主キー分割テーブルそれぞれを、前記複数のサーバに前記データ送受信部を介して送信する主キー分割テーブル生成部と、
前記テーブルごとの主キーおよび外部キーのスキーマを抽出し、前記抽出したスキーマのレコードを前記外部キーでソートし、当該ソートしたレコードを、前記外部キーが参照する主キーと同じ前記所定の範囲で分割した結合用テーブルを生成して前記記憶部に記憶し、前記記憶した結合用テーブルそれぞれを、前記複数のサーバに前記データ送受信部を介して送信する結合用テーブル生成部と、
前記データベースに対する前記検索要求を受け付ける検索要求受付部と、
前記受け付けた検索要求の実行プランを生成し、前記生成した実行プランに含まれるテーブル結合条件に示される前記外部キーの結合対象となるテーブルを、当該テーブルについて作成された当該外部キーの前記結合用テーブルに書き換える検索要求書換部と、
前記書き換えた検索要求の実行プランに基づき、前記主キー分割テーブルおよび前記結合用テーブルを用いて、検索処理を実行する検索実行部と、
を備えることを特徴とする分散データベース管理装置。 - 前記複数のサーバに分散して格納されたデータをサンプリングして得られるサンプリングデータベースを生成し、前記サンプリングしたデータに対して、前記検索要求を複数の実行プランで実行し、最も早く処理が完了した前記実行プランを、最適実行プランとして選択する最適実行プラン選択部をさらに備え、
前記検索実行部は、前記最適実行プラン選択部が選択した実行プランを用いて、前記書き換えた検索要求の検索処理を実行すること
を特徴とする請求項１に記載の分散データベース管理装置。 - 前記検索実行部による前記書き換えた検索要求の検索処理の実行において、MapReduceを用いる場合に、
前記主キー分割テーブル生成部は、前記受信したデータの集合であるテーブルごとに、当該テーブルの主キーを、map関数のキーとして設定し、当該設定したキーを用いてハッシュ分割することにより前記主キー分割テーブルを生成し、
前記結合用テーブル生成部は、前記テーブルごとの主キーおよび外部キーのスキーマを抽出し、前記抽出した外部キーをmap関数のキーとして設定し、当該設定したキーを用いてハッシュ分割することにより前記結合用テーブルを生成すること
を特徴とする請求項１に記載の分散データベース管理装置。 - 請求項１乃至請求項３のいずれか一項に記載の分散データベース管理装置を構成する各手段としてコンピュータを機能させるための分散データベース管理プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010223449A JP5276639B2 (ja) | 2010-10-01 | 2010-10-01 | 分散データベース管理装置および分散データベース管理プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010223449A JP5276639B2 (ja) | 2010-10-01 | 2010-10-01 | 分散データベース管理装置および分散データベース管理プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2012079078A JP2012079078A (ja) | 2012-04-19 |
| JP5276639B2 true JP5276639B2 (ja) | 2013-08-28 |
Family
ID=46239251
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2010223449A Active JP5276639B2 (ja) | 2010-10-01 | 2010-10-01 | 分散データベース管理装置および分散データベース管理プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5276639B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101542299B1 (ko) | 2013-02-18 | 2015-08-07 | 단국대학교 산학협력단 | 하둡 기반의 질의 처리 방법 및 장치 |
| US9779137B2 (en) | 2013-07-09 | 2017-10-03 | Logicblox Inc. | Salient sampling for query size estimation |
| US10453071B2 (en) | 2013-09-09 | 2019-10-22 | UnitedLex Corp. | Interactive case management system |
| WO2015123809A1 (zh) * | 2014-02-18 | 2015-08-27 | 华为技术有限公司 | 一种数据表的导入方法、数据管理器以及服务器 |
| WO2016117007A1 (ja) * | 2015-01-19 | 2016-07-28 | 株式会社日立製作所 | データベースシステム及びデータベース管理方法 |
| JP6405062B2 (ja) * | 2016-02-08 | 2018-10-17 | 株式会社日立製作所 | 分散データベースシステム、及び、分散データベースシステムの管理方法 |
| US20190065559A1 (en) * | 2016-06-28 | 2019-02-28 | Hitachi, Ltd. | Computer system and database management method |
| JP6865003B2 (ja) * | 2016-09-05 | 2021-04-28 | ヤフー株式会社 | 情報処理装置、情報処理システム、情報処理プログラムおよび情報処理方法 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1196055A (ja) * | 1997-09-19 | 1999-04-09 | Hitachi Ltd | データベースの結合処理最適化方法及び装置 |
| CA2556979A1 (en) * | 2004-02-21 | 2005-10-20 | Datallegro, Inc. | Ultra-shared-nothing parallel database |
| JP2006146514A (ja) * | 2004-11-18 | 2006-06-08 | Nippon Telegr & Teleph Corp <Ntt> | データベース検索システムおよび方法、プログラムおよび記録媒体 |
-
2010
- 2010-10-01 JP JP2010223449A patent/JP5276639B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2012079078A (ja) | 2012-04-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP5276639B2 (ja) | 分散データベース管理装置および分散データベース管理プログラム | |
| US10169409B2 (en) | System and method for transferring data between RDBMS and big data platform | |
| US10521427B2 (en) | Managing data queries | |
| US11593369B2 (en) | Managing data queries | |
| US10713255B2 (en) | Spool file for optimizing hash join operations in a relational database system | |
| US6801903B2 (en) | Collecting statistics in a database system | |
| US10769147B2 (en) | Batch data query method and apparatus | |
| Lee et al. | SQL-to-NoSQL schema denormalization and migration: a study on content management systems | |
| Chen et al. | Optimization of sub-query processing in distributed data integration systems | |
| CN103353901B (zh) | 基于Hadoop分布式文件系统的表数据的有序管理方法以及系统 | |
| US20090043750A1 (en) | Query Optimization in a Parallel Computer System with Multiple Networks | |
| CN112015741A (zh) | 一种海量数据的分库分表存储方法与装置 | |
| US20160342646A1 (en) | Database query cursor management | |
| US11354313B2 (en) | Transforming a user-defined table function to a derived table in a database management system | |
| US9870399B1 (en) | Processing column-partitioned data for row-based operations in a database system | |
| US10997175B2 (en) | Method for predicate evaluation in relational database systems | |
| Tapdiya et al. | A comparative analysis of state-of-the-art sql-on-hadoop systems for interactive analytics | |
| Guzun et al. | A two-phase mapreduce algorithm for scalable preference queries over high-dimensional data | |
| Gu et al. | Cost-based join algorithm selection in hadoop | |
| Kodabagi et al. | A text information retrieval technique for big data using Map Reduce | |
| Taelman et al. | Demonstration of Link Traversal SPARQL Query Processing over the Decentralized Solid Environment. | |
| Nerić et al. | Big Data Optimization Using Hive | |
| Wang et al. | Research on the Application of Bank Transaction Data Stream Storage based on HBase | |
| Ma | Data Communication Algorithm of HPDB Parallel Database System Based on Computer Network | |
| Gupta et al. | Pragamana: performance comparison and programming-miner algorithm in relational database query language and NoSQL column-oriented using apache phoenix |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20130201 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130314 |
|
| 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: 20130514 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130517 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 Ref document number: 5276639 Country of ref document: JP 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 |