JP7458610B2 - データベースシステム、及びクエリ実行方法 - Google Patents

データベースシステム、及びクエリ実行方法 Download PDF

Info

Publication number
JP7458610B2
JP7458610B2 JP2020179852A JP2020179852A JP7458610B2 JP 7458610 B2 JP7458610 B2 JP 7458610B2 JP 2020179852 A JP2020179852 A JP 2020179852A JP 2020179852 A JP2020179852 A JP 2020179852A JP 7458610 B2 JP7458610 B2 JP 7458610B2
Authority
JP
Japan
Prior art keywords
dbms
node
data
query
database
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
Application number
JP2020179852A
Other languages
English (en)
Other versions
JP2022070669A (ja
Inventor
英臣 出射
和彦 茂木
記史 西川
晃 清水
和生 合田
悠登 早水
優 喜連川
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.)
Hitachi Ltd
University of Tokyo NUC
Original Assignee
Hitachi Ltd
University of Tokyo NUC
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 Hitachi Ltd, University of Tokyo NUC filed Critical Hitachi Ltd
Priority to JP2020179852A priority Critical patent/JP7458610B2/ja
Priority to US17/471,267 priority patent/US11709839B2/en
Publication of JP2022070669A publication Critical patent/JP2022070669A/ja
Application granted granted Critical
Publication of JP7458610B2 publication Critical patent/JP7458610B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2455Query execution

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、概して、データ処理に関し、例えば、クラウド上に構築したデータベースシステムでの検索クエリの実行に関する。
近年、データベースを基盤とする多くのアプリケーションが存在し、データベースに格納されるデータは年々増加の傾向を辿っている。従来、このようなデータベースを管理するソフトウェアとして、データベース管理システム(以下、DBMS(Database Management System)と呼ぶ)がある。DBMSが管理するデータの規模が拡大すれば、そのデータを記憶するストレージ装置もより大きな記憶容量が必要となり、また大規模のデータベースからデータ検索を迅速に行うためにはより大きなCPUパワーが必要となる。この様な大規模のデータベースシステムを自前で構築及び運用するための作業負担及びコストは膨大になる。
それに対し、サーバやストレージを容易に追加できるクラウド環境では、事業規模、データ規模又はユーザの使用頻度に合わせたデータベースシステムを構築及び運用することが可能となり、自前でハードウェアリソースを用意する必要がなくなるためシステム導入の作業負担及びコストを削減できる。また、AWS(Amazon Web Services(登録商標))の様なパブリッククラウドのサービスを利用することで、ハードウェアの保守に必要な作業負担及びコストも削減できる。
クラウドに論理的な計算機であるインスタンスを作成して、当該インスタンス上にデータベースシステムを構築することが可能である。そのデータベースシステムの構築の際、CPUコア、メモリサイズ及びストレージ容量を追加することで、データ量の増加や負荷増加に対応することが可能である。しかし、1インスタンス内のI/O帯域には制限があり、故に、データベースシステムの規模がある一定の規模を超えるとデータベースシステムのI/O性能を維持することは困難となる。
そこで、複数のインスタンスをクラウド上に作成し、それらのインスタンスが連携して動作することで性能を向上する技術が提案されている。例えば、非特許文献1は、リーダーノードでクライアントアプリケーションからクエリを受け付け、複数のコンピュートノードでクエリの処理を実行し、リーダーノードで実行結果を集計してクライアントアプリケーションに応答する技術を記載している。また、特許文献1は、クラウド上で動作する複数のノードから、クライアントからの要求を実行するノードを選択する技術を記載している。
US2015/0169650
SIGMOD '15: Proceedings of the 2015 ACM SIGMOD International Conferenceon Management of Data, May 2015, Pages 1917-1923
ところが、非特許文献1に記載された技術では、リーダーノードは1つであり、当該リーダーノードがクエリの受付、クエリ実行結果の集計、及びクエリ結果の応答を行うため、処理が一極集中になる可能性がある。また、特許文献1に開示された技術では、データが分散配置されている場合には対応できない。
以上の課題は、データベースシステム以外のデータ処理システムにもあり得る。
かかる課題を解決するため本発明の一例としてのデータベースシステムは、複数の計算リソースを含む計算機システムの一例に設けられた複数のノードにそれぞれ備えられる複数のDBMSを備える。複数のDBMSの各々は、第1のDBMSと第2のDBMSのいずれかである。第1のDBMSは、クエリソースから検索クエリを受け付けた場合に当該検索クエリを転送するがデータ検索を実行しないDBMSである。第2のDBMSは、データ検索を実行するDBMSである。複数のノードは、1つ又は複数のノードグループを構成する。各ノードグループが、第1のノードと1つ以上の第2のノードとを含む。各ノードグループにおいて、第1のノードは、第1の記憶領域を提供し第1のDBMSを実行する論理計算機であり、第2のノードは、第2の記憶領域を提供し第2のDBMSを実行する論理計算機であり、当該ノードグループを構成する2つ以上のノードが有する2つ以上のDBMSが、当該2つ以上のノードが提供する2つ以上の記憶領域に同一のデータベースを格納し、当該ノードグループ内のデータベースからのデータ検索は、当該ノードグループ内の1つ以上の第2のDBMSにより実行される。
本発明によれば、処理の一極集中を回避し、分散配置されたデータからのデータ検索することができる。
本実施の形態におけるデータベースシステムの構成例を示した図である。 マスターノードの構成例を示した図である。 キャッシュノードの構成例を示した図である。 DB管理情報の構成例を示した図である。 DBエリア情報の構成例を示した図である。 スキーマ情報の構成例を示した図である。 テーブル構成情報の構成例を示した図である。 ノード管理情報の構成例を示した図である。 ノード情報の構成例を示した図である。 カレントマスターノード情報の構成例を示した図である。 ノードルール情報の構成例を示した図である。 インスタンス構成情報の構成例を示した図である。 データ管理情報の構成例を示した図である。 キャッシュノード管理情報の構成例を示した図である。 キャッシュノード追加の処理例の一部を示した図である。 キャッシュノード追加の処理例の残りを示した図である。 キャッシュノード削除の処理例の一部を示した図である。 キャッシュノード削除の処理例の残りを示した図である。 新規グループの追加を伴わないデータインポートの処理例を示した図である。 新規グループの追加を伴うデータインポートの処理例の第1の部分を示した図である。 新規グループの追加を伴うデータインポートの処理例の第2の部分を示した図である。 新規グループの追加を伴うデータインポートの処理例の残りの部分を示した図である。 1グループ内に収まる検索クエリ実行の処理例を示した図である。 複数グループ跨る検索クエリ実行の処理例を示した図である。 モニタデータ取得送信処理の一例を示したフロー図である。 モニタデータ受信処理の一例を示したフロー図である。 キャッシュノード追加処理の一例を示したフロー図である。 キャッシュノード削除処理の一例を示したフロー図である。 データインポート処理の一例の一部を示したフロー図である。 データインポート処理の一例の残りを示したフロー図である。 マスターノード追加処理の一例を示したフロー図である。 クエリ実行処理の一例の一部を示したフロー図である。 クエリ実行処理の一例の一部を示したフロー図である。 クエリ実行処理の一例の一部を示したフロー図である。 クエリ実行処理の一例の一部を示したフロー図である。 クエリ実行処理の一例の残りを示したフロー図である。 別の実施形態での検索クエリ実行の処理例を示した図である。 別の実施形態での検索クエリ実行の処理例を示した図である。
以下の説明では、データベースを「DB」と言い、データベース管理システムを「DBMS」と言うことがある。DBMSに対するクエリの発行元は、DBMSの外部のコンピュータプログラム(例えばアプリケーションプログラム)で良い。
以下の説明では、「インターフェース装置」は、1つ以上のインターフェースデバイスで良い。当該1つ以上のインターフェースデバイスは、1つ以上の同種の通信インターフェースデバイス(例えば1つ以上のNIC(Network Interface Card))であっても良いし2つ以上の異種の通信インターフェースデバイス(例えばNICとHBA(Host Bus Adapter))であっても良い。
また、以下の説明では、「メモリ」は、1つ以上のメモリデバイスであり、典型的には主記憶デバイスで良い。メモリにおける少なくとも1つのメモリデバイスは、揮発性メモリデバイスであっても良いし不揮発性メモリデバイスであっても良い。
また、以下の説明では、「永続記憶装置」は、1つ以上の永続記憶デバイスである。永続記憶デバイスは、典型的には、不揮発性の記憶デバイス(例えば補助記憶デバイス)であり、具体的には、例えば、HDD(Hard Disk Drive)又はSSD(Solid State Drive)である。
また、以下の説明では、「記憶装置」は、メモリと永続記憶装置の少なくともメモリで良い。
また、以下の説明では、「プロセッサ」は、1つ以上のプロセッサデバイスである。少なくとも1つのプロセッサデバイスは、典型的には、CPU(Central Processing Unit)のようなマイクロプロセッサデバイスであるが、GPU(Graphics Processing Unit)のような他種のプロセッサデバイスでも良い。少なくとも1つのプロセッサデバイスは、シングルコアでも良いしマルチコアでも良い。少なくとも1つのプロセッサデバイスは、プロセッサコアでも良い。少なくとも1つのプロセッサデバイスは、処理の一部又は全部を行うハードウェア回路(例えばFPGA(Field-Programmable Gate Array)又はASIC(Application Specific Integrated Circuit))といった広義のプロセッサデバイスでも良い。
また、以下の説明では、「yyy部」の表現にて機能を説明することがあるが、機能は、1つ以上のコンピュータプログラムがプロセッサによって実行されることで実現されても良いし、1つ以上のハードウェア回路(例えばFPGA又はASIC)によって実現されても良い。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置及び/又はインターフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされても良い。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としても良い。プログラムは、プログラムソースからインストールされても良い。プログラムソースは、例えば、プログラム配布計算機又は計算機が読み取り可能な記録媒体(例えば非一時的な記録媒体)であっても良い。各機能の説明は一例であり、複数の機能が1つの機能にまとめられたり、1つの機能が複数の機能に分割されたりしても良い。
また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通部分(又は、参照符号)を使用し、同種の要素を区別する場合は、参照符号(又は、要素のID)を使用することがある。
以下、本発明の実施の形態を詳述する。
(1)本実施の形態におけるデータベースシステムの構成
図1は、本実施の形態におけるデータベースシステムの構成例を示した図である。
クラウド100(複数の計算リソースを含む計算機システムに基づく仮想環境の一例)上に作成した複数のインスタンス110がそれぞれ複数のノードとして存在する。複数のノードに、複数のDBMS(データベース管理システム)がそれぞれ備えられる。複数のDBMSでデータベースシステムが構成されている。各インスタンス110は、クラウド100の基になる計算機システムを構成するサーバ、ストレージ及びネットワーク等の物理リソースを基に作成される論理的な計算機である。論理的なネットワーク108に各インスタンス110が接続される。
インスタンス110は、マスターノード120又はキャッシュノード122のいずれかとして動作する。別の言い方をすれば、マスターノードとしての役割が与えられたインスタンス110が、マスターノード120でよく、キャッシュノードとしての役割が与えられたインスタンス110が、キャッシュノード122で良い。
1つのマスターノード120と複数(又は1つ)のキャッシュノード122でノードグループ(以下、グループ)130が構成される。各キャッシュノード122は、同一グループ(自グループ)130のマスターノード120が保持するデータベースのデータと全く同じデータを、例えばマスターノード120が保持するデータベースの全部又は一部(例えば差分)のコピー(レプリケーション)を受信する等の方法によって、保持している。従って、どのキャッシュノード122でもデータ検索を実行することが可能である。但し、データ追加等の更新系の処理に関しては、マスターノード120が実行する。すなわち、本実施形態では、データベースに対するデータのライト(例えばデータ追加)を、マスターノード120が実行しキャッシュノード122が実行せず、一方、データベースからのデータのリード(例えばデータ検索)を、マスターノード120が実行せずキャッシュノード122が実行する。これにより、リード性能の高いデータベースシステムの実現が期待できる。マスターノード120が、第1のノードの一例であり、キャッシュノード122が、第2のノードの一例である。
図1には、2つのグループ130が例示されているが、グループ130は、1つでも良いし、3つ以上でも良い。グループ130の数とマスターノード120の数は同じである。その中で1つのマスターノードがカレントマスターノードとなる。カレントマスターノード120が、クラウド100に接続されているクライアント104上のアプリケーション106(クエリソースの一例)から処理要求(クエリ)を受け付ける。クエリを受け付けたカレントマスターノード120は、同一グループ130内のキャッシュノード122にクエリを転送する(クエリ実行の処理を割り振る)。クエリを受けたキャッシュノード122は、受けたクエリを実行し、その実行結果をクエリ発行元のクライアント104のアプリケーション106に応答する。尚、クエリを受け付けたマスターノード120にキャッシュノード122がクエリの実行結果を送信し、マスターノード120が、当該実行結果を、クエリ発行元のクライアント104のアプリケーション106に応答しても良い。
クラウド100上にインスタンス110を作成する、又は削除する方法としては、クラウドシステム管理者、又はデータベースシステム管理者が、クラウド管理部102に手動でインスタンス110の作成又は削除を指示しても良いし、データベースシステムで動作するDBMS(又は別プログラム)がクラウド管理部102にインスタンス110の作成又は削除の指示を出すことで自動的にインスタンス110がクラウド管理部102により作成又は削除されても良い。尚、本実施の形態では、DBMSがクラウド管理部102に指示を出すことでインスタンス110が自動的に作成又は削除されるものとする。また、インスタンス110を作成する際は、データベース管理者によって予め定められた構成(例えば、CPUコア数、メモリサイズ、ストレージ容量等が予め設定されている構成)のインスタンス110が作成されるものとする。また、インスタンス作成後は、OS(Operating System)のインストール及び環境設定と、DBMSのインストール及び環境設定とを実施する必要があるが、本実施の形態では、新たにインスタンス110が作成された後、例えばスクリプトの実行等によって自動的に当該作成されたインスタンス110が利用可能になるものとする。尚、クラウド管理部102は、クラウド100を管理する機能であり、例えば、上述したように、インスタンス110をクラウド100上に作成したりクラウド100からインスタンス110を削除したりすることができる。
インスタンス110の作成、又は削除の契機は、インスタンス110がマスターノード120であるかキャッシュノード122であるかによって異なる。マスターノード120を作成する契機は、新規にデータベースシステムが構築された時、又は既存のマスターノード120でデータベースのデータを記憶可能な領域がなくなった時である。マスターノード120を削除する契機は無くて良い。但し、データベース管理者が、マスターノード120が記憶しているデータが必要ないと判断した際に当該マスターノード120が削除されても良く、その場合は当該マスターノード120が属するグループ130全体が削除される。キャッシュノード122を作成する契機は、マスターノード120が作成された時(例えば、当該マスターノード120が属するグループ130のキャッシュノード122が作成される)、又は、あるグループ130の少なくとも1つのキャッシュノード122の負荷(例えば、当該グループに属する全キャッシュノード122の平均負荷)が予め設定されている第1の閾値を超えた時(例えば、当該グループ130にキャッシュノード122が新たに作成される)。キャッシュノード122を削除する契機は、あるグループ130の少なくとも1つのキャッシュノード122の負荷が予め設定されている第2の閾値(例えば、第2の閾値は、第1の閾値以下の閾値)を下回った時、又は、マスターノード120が削除された時(この場合は、当該マスターノード120を含んだグループ130削除される)である。
図2は、マスターノード120の構成例を示した図である。
マスターノード120は、マスターノード120が動作するインスタンス110に割り当てられたインターフェース装置260、CPU200、メモリ210、ブロックストレージ242、及び高速ストレージ240で構成される。インターフェース装置260、メモリ210、ブロックストレージ242及び高速ストレージ240にCPU200が接続される。インターフェース装置260を通じてノード間での送受信が可能である。インターフェース装置260、CPU200、メモリ210、ブロックストレージ242及び高速ストレージ240の各々は、クラウド100の基になっている計算機システムが有する物理的な計算リソースに基づく論理的な計算リソースでよいが、本実施形態では、説明を簡単にするために物理的な計算リソースとする。
CPU200は、1又は複数のCPUコア202を内包し、メモリ210に格納されたDBMS212、OS214等の各種プログラムを実行するプロセッサである。メモリ210は例えば半導体メモリであり、CPU200のワークメモリとしても使用される。尚、DBMS212、OS214の実体は、HDD(Hard Disk Drive)等のディスク装置に格納されていても良い。
ブロックストレージ242は、例えばSCSI(Small Computer System Interface)ディスクやSATA(Serial AT Attachment)ディスク等のディスク装置であり、アクセス性能は低いが電源が遮断されても記憶されたデータを保持するデバイスである。ブロックストレージ242が、第1の記憶領域の一例である。
高速ストレージ240は、例えばNVMe(Non-Volatile Memory)で接続された不揮発性メモリであり、ブロックストレージ242と比較してアクセス性能が高いが、電源が遮断されると記憶されているデータは消失するデバイスである。
マスターノード120は、データベースのデータ永続性を保障するため、ブロックストレージ242を有するが、高速ストレージ240を有しないでも良い。高速ストレージ240を有している場合、例えば、次のようにして高速に同一グループ130内で全キャッシュノード122に同一のデータベースをコピーすることが期待される。すなわち、DBMS212が、ブロックストレージ242から高速ストレージ240へデータベース250の全部又は一部(例えば、ブロックストレージ242におけるデータベース250と高速ストレージ240におけるデータベース250との差分)をコピーし(いわゆる内部コピー)、その後、高速ストレージ240から後述の高速ストレージ340へデータベース250の全部又は一部(例えば、高速ストレージ240におけるデータベース250と高速ストレージ340におけるデータベース350との差分)をコピーする(いわゆるリモートコピー)。内部コピーは高速であることが期待され、また、高速ストレージ240及び340間でリモートコピーが行われるため当該リモートコピーも高速であることが期待される。
DBMS212は、第1のDBMSの一例である。DBMS212は、ブロックストレージ242や高速ストレージ240に格納されたデータベース250のデータを管理するプログラムである。DBMS212は、データベース管理やクライアントから受け付けたクエリを実行するために、クエリ受付部220、クエリ実行部222、ノード管理部224、DB管理情報226、ノード管理情報228、データ管理情報230、及びキャッシュノード管理情報232を有する。OS214は、Linux(登録商標)の様な一般的なOSでありここでは説明を省略するが、CPUやI/Oの稼働状態をモニタするsar/mpstat/iostat等のモニタコマンド234を有しているものとする。
図3は、キャッシュノード122の構成例を示した図である。
キャッシュノード122は、前述したマスターノード120と基本的な構成は変わらず、キャッシュノード122が動作するインスタンスに割り当てられたインターフェース装置360、CPU300、メモリ310及び高速ストレージ340で構成される。インターフェース装置360、メモリ310、及び高速ストレージ340にCPU300が接続される。インターフェース装置360を通じてノード間での送受信が可能である。インターフェース装置360、CPU300、メモリ310、及び高速ストレージ340の各々も、クラウド100の基になっている計算機システムが有する物理的な計算リソースに基づく論理的な計算リソースでよいが、本実施形態では、説明を簡単にするために物理的な計算リソースとする。
キャッシュノード122は、高速ストレージ340にデータベース350を保持するがデータベース350を格納するためのブロックストレージを有しない。キャッシュノード122は、高速ストレージ340のデータベース350からデータを読み込む。高速ストレージ340は、例えばNVMe(Non-Volatile Memory)で接続された不揮発性メモリであり、ブロックストレージ242と比較してアクセス性能が高いが、電源が遮断されると記憶されているデータは消失するデバイスである。高速ストレージ340は、第2の記憶領域の一例である。第2の記憶領域は、ブロックストレージ242が一例である第1の記憶領域より高速であれば、電源遮断に伴いデータが消失してもよいしデータの永続性が保証されてもよい。
CPU300は、1又は複数のCPUコア302を内包し、メモリ310に格納されたDBMS312、OS314等の各種プログラムを実行するプロセッサである。メモリ310は例えば半導体メモリであり、CPU300のワークメモリとしても使用される。尚、DBMS312、OS314の実体は、HDD(Hard Disk Drive)等のディスク装置に格納されていても良い。
DBMS312は、第2のDBMSの一例である。DBMS312は、高速ストレージ340に格納されたデータベース350のデータを管理するプログラムである。DBMS312は、データベース管理やクライアントから受け付けたクエリを実行するために、クエリ受付部320、クエリ実行部322、ノード管理部324、DB管理情報226、ノード管理情報228、データ管理情報230を有する。OS314は、Linuxの様な一般的なOSであり、CPUやI/Oの稼働状態をモニタするsar/mpstat/iostat等のモニタコマンド334を有しているものとする。
図4Aは、DB管理情報226の構成例を示した図である。
DB管理情報226は、データベースのデータを格納する領域に関するDBエリア情報400、データベースの表や索引といったスキーマに関するスキーマ情報402、データベースの表(テーブル)の構成に関するテーブル構成情報404で構成される。
図4Bは、DBエリア情報400の構成例を示した図である。
DBエリア情報400は、データベースのデータを格納する論理的な領域であるDBエリアと、実際にデータを格納するブロックストレージ、又は高速ストレージのLU(Logical Unit)に対応するOS上のデバイスファイルとを関係付ける情報であり、DBエリア毎にエントリを有する。各エントリは、DBエリアを一意に識別するIDが登録されるフィールド410、当該DBエリアに対応するデバイスファイルパスが登録されるフィールド412、及び、当該DBエリアの未使用領域のサイズが登録されるフィールド414を有する。尚、ここでは説明を省略しているが、LUはOSが認識しているストレージ上の記憶領域であり、OSがその記憶領域とデバイスファイルと対応付けている。ブロックストレージ及び高速ストレージの各々が1つのLUに相当してよい。この場合、ブロックストレージとしてのLUが、第1の記憶領域の一例であって、高速ストレージとしてのLUが、第2の記憶領域の一例でよい。
図4Cは、スキーマ情報402の構成例を示した図である。
スキーマ情報402は、データベースの表や索引といったスキーマに関する情報であり、データベースのスキーマ毎にエントリを有する。各エントリは、スキーマを一意に識別するIDが登録されるフィールド420、スキーマの種別が登録されるフィールド422、及び、当該スキーマのデータを格納するDBエリアのIDが登録されるフィールド424を有する。
図4Dは、テーブル構成情報404の構成例を示した図である。
テーブル構成情報404は、データベースのテーブル構成に関する情報であり、テーブルを構成する列毎にエントリを有する。各エントリは、テーブルを一意に識別するIDが登録されるフィールド430、テーブルを構成するカラムを一意に識別するIDが登録されるフィールド432、当該カラムの名称が登録されるフィールド434、及び、当該カラムのデータ型が登録されるフィールド436を有する。
図5Aは、ノード管理情報228の構成例を示した図である。
ノード管理情報228は、マルチノードを構成する各ノードに関するノード情報500、カレントとなっているマスターノード120に関するカレントマスターノード情報502、キャッシュノード122の追加及び削除のルールに関するノードルール情報504、及び、新規インスタンス作成時の構成に関するインスタンス構成情報506で構成される。
図5Bは、ノード情報500の構成例を示した図である。
ノード情報500は、当該システムでマルチノードを構成する各ノードに関する情報であり、ノード毎にエントリを有する。各エントリは、ノードを一意に識別するIDが登録されるフィールド510、当該ノードの種別(マスターノード/キャッシュノード)が登録されるフィールド512、当該ノードが属するグループのマスターノードのIDが登録されるフィールド514、当該ノードのIPアドレスが登録されるフィールド516、当該ノードに記憶可能なデータベースのデータ容量が登録されるフィールド518、及び、当該ノードに記憶しているデータベースのデータサイズが登録されるフィールド520を有する。
図5Cは、カレントマスターノード情報502の構成例を示した図である。
カレントマスターノード情報502は、当該システムでカレントになっているマスターノードに関する情報であり、カレントマスターノードのIDが登録されるフィールド530を有する。
図5Dは、ノードルール情報504の構成例を示した図である。
ノードルール情報504は、キャッシュノード122の追加及び削除のルールに関する情報であり、キャッシュノード122の追加ルールが登録されるフィールド540、及び、キャッシュノード122の削除ルールが登録されるフィールド542を有する。キャッシュノード122の追加ルールは、グループ130内の少なくとも一つのキャッシュノード122の負荷が第1の閾値を超えること、例えば、グループ130内のキャッシュノード122の全平均CPU利用率が80%超えたことでよい。キャッシュノード122の削除ルールは、グループ130内の少なくとも一つのキャッシュノード122の負荷が第2の閾値以下であること(第2の閾値は第1の閾値以下)、例えば、グループ130内のキャッシュノード122の全平均CPU利用率が10%を下回ったことでよい。これらのルールは、例えば、データベースシステム管理者等により予め設定される。尚、本実施の形態では、CPU利用率が追加ルール及び削除ルールの両方に用いられているが、例えばIOPS等の他の負荷指標を用いたルールが追加ルール及び削除ルールの少なくとも一つとして採用されて良い。
図5Eは、インスタンス構成情報506の構成例を示した図である。
インスタンス構成情報は、マスターノード構成(マスターノード用インスタンス構成)が登録されるフィールド550、及び、キャッシュノード構成(キャッシュノード用インスタンス構成)が登録されるフィールド552を有する。各フィールドは、インスタンスを構成するCPUコア数、メモリサイズ、ストレージタイプ、ストレージ容量の情報を格納する。当該情報は、データベース管理者等によって予め設定され、新規インスタンス作成時に参照される。尚、図5Eが示す例によれば、キャッシュノードがマスターノードよりもリード性能(本実施形態ではデータ検索性能)が優れているようにするために、キャッシュノードについて、マスターノードのストレージよりも高速のストレージが採用され、例えば更に、マスターノードのCPUコアよりも多くのCPUコアが採用される。
図6Aは、データ管理情報230の構成例を示した図である。
データ管理情報230は、データベースにおけるデータの記憶位置を表す。具体的には、例えば、データ管理情報230は、データベースに登録されたデータに関する情報であり、登録されたデータ毎にエントリを有する。各エントリは、当該データが登録されたマスターノードのIDが登録されるフィールド600、当該データが登録されたテーブルのIDが登録されるフィールド602、当該データが登録されたカラムのIDが登録されるフィールド604、当該データの開始に関する情報(例えば、データが表す期間の開始日、又は、データの格納開始日)が登録されるフィールド606、及び、当該データの終了に関する情報(例えば、データが表す期間の終了日、又は、データの格納終了日)が登録されるフィールド608を有する。
図6Bは、キャッシュノード管理情報232の構成例を示した図である。
キャッシュノード管理情報232は、マスターノード120が同一グループのキャッシュノード122を管理する情報であり、それぞれのマスターノード120が同一グループのキャッシュノード122のノード数だけエントリを有する。図6Bは、あるグループ内のマスターノード120のDBMS212が管理するキャッシュノード管理情報232Aと、別のあるグループ内のマスターノード120のDBMS212が管理するキャッシュノード管理情報232Bとを例示する。各エントリは、キャッシュノード122を識別するIDが登録されるフィールド610、当該キャッシュノード122の状態が登録されるフィールド612、当該キャッシュノード122のCPU利用率が登録されるフィールド614、当該キャッシュノード122のIOPS(I/O Per Second)が登録されるフィールド616、及び、当該キャッシュノード122のスループットが登録されるフィールド618を有する。キャッシュノードの状態、CPU利用率、IOPS及びスループットのうちの少なくとも一つが、キャッシュノードの稼働状況の一例に相当して良い。キャッシュノードのCPU利用率、IOPS及びスループットの少なくとも一つが、キャッシュノードの負荷の一例に相当して良い。
(2)本実施の形態におけるキャッシュノードの追加処理
図7A及び図7Bは、キャッシュノード122の追加処理の流れを示した図である。尚、ここでは、説明簡略化のため、1つのグループ130があり、そのグループ130はマスターノードM1と、キャッシュノードC11とで構成されており、そのグループ130にキャッシュノードC12が追加されるとする。また、以下の説明では、DB管理情報226、ノード管理情報228、及びデータ管理情報230を含んだ情報を、「管理情報75」と呼ぶ。また、以下の説明において、管理情報75の同期を取るとは、更新後(最新)の管理情報75の内容を更新前の管理情報75に反映する(典型的にはコピーする)ことで管理情報75の内容を同一にすることである。同様に、データベースの同期を取るとは、更新後のデータベースの内容を更新前のデータベースに反映する(典型的にはコピーする)ことで、データベースの内容を同一にすることである。
まず、追加前の処理として、図7Aが示すように、キャッシュノードC11のDBMS312は、OS314のモニタコマンド334を定期的に実行することで、CPU利用率やIOPSといったメトリック値を含んだモニタデータ70を取得し、そのモニタデータ70をマスターノードM1に送信する(矢印700)。当該情報を受信したマスターノードM1のDBMS212は、同一グループ130内の全キャッシュノード(ここでは、キャッシュノードC11のみ)の平均CPU利用率を算出する。算出された平均CPU利用率がキャッシュノード追加ルール540に設定されている閾値を超えている場合、マスターノードM1のDBMS212が、クラウド管理部102に、キャッシュノード用の新規インスタンス作成を要求する(矢印702)。
図7Bが示すように、インスタンス作成の要求を受け付けたクラウド管理部102は、要求されたインスタンス110Tを作成し、当該インスタンス110Tに関する情報(例えば、IPアドレス)を、要求元のDBMS212に送信する(矢印704)。インスタンス作成後は、OSのインストールや環境設定、及び、DBMSのインストールや環境設定を実施する必要があるが、本実施の形態では新規インスタンス作成後、例えばスクリプトの実行等によって自動的にインスタンスが利用可能になるものとする。
作成したインスタンス110Tに関する情報を受けたマスターノードM1のDBMS212は、当該情報を元に管理情報75(ノード情報500)を更新し、当該管理情報75と、同一グループ130内のキャッシュノードC11の管理情報75と同期を取る(矢印720)。また、マスターノードM1のDBMS212は、新規作成したインスタンス(キャッシュノードC12)のDBMS312に管理情報75を送信し(矢印722)、ブロックストレージ242(又は高速ストレージ240)に記憶しているデータベース250のデータをキャッシュノードC12の高速ストレージ340に送信する(矢印724)。データ送信の完了によって、新規追加のキャッシュノードC12が利用可能となり、マスターノードM1はキャッシュノード管理情報232に新規追加したキャッシュノードC12のエントリを追加する。
以上のキャッシュノード122の追加処理の例では、説明簡略化のため、1グループ、1マスターノード、1キャッシュノードの構成が採用されたが、実際には複数のグループ130があっても良いし、同一グループ130に複数のキャッシュノード122があっても良い。複数のグループ130がある場合は、グループ130毎に上記の処理が行われ、キャッシュノード追加時に更新された管理情報75は、更新したマスターノード120から別グループ130のマスターノード120に伝搬し、そのマスターノード120から同一グループ内のキャッシュノード122に伝搬して良い。また、同一グループ130に複数のキャッシュノード122がある場合は、全てのキャッシュノード122がモニタデータ70を取得及び送信し、マスターノード120はそれらのモニタデータ70を基にキャッシュノードを追加するか否かの判定を行って良い。
(3)本実施の形態におけるキャッシュノードの削除処理
図8A及び図8Bは、キャッシュノード122の削除処理の流れを示した図である。尚、ここでは、説明簡略化のため、1つのグループ130があり、そのグループ130はマスターノードM1と、キャッシュノードC11及びC12とで構成されており、そのグループからキャッシュノードC12が削除されるとする。
まず、削除前の処理として、図8Aが示すように、キャッシュノードC11及びC12の各々において、DBMS312は、OS314のモニタコマンド334を定期的に実行してCPU利用率やIOPSといったメトリック値を含んだモニタデータ70を取得し、そのモニタデータ70をマスターノードM1に送信する(矢印800)。当該情報を受信したマスターノードM1のDBMS212は、同一グループ130内の全キャッシュノードC11及びC12の平均CPU利用率を算出する。算出された平均CPU利用率がキャッシュノード削除ルールのフィールド542に設定されている閾値を下回っている場合、マスターノードM1のDBMS212が、最もCPU利用率の低いキャッシュノード(ここでは、キャッシュノードC12)のインスタンスを選択し、選択したインスタンスを指定したインスタンス削除要求をクラウド管理部102に送信する(矢印802)。
図8Bが示すように、インスタンス削除の要求を受け付けたクラウド管理部102は、要求されたインスタンス(C12)の削除を実行し、削除結果(削除したインスタンスに関する情報)を要求元のDBMS212に送信する(矢印810)。
削除したインスタンスに関する情報を受けたマスターノードM1のDBMS212は、当該情報を基に管理情報75内のノード情報500を更新し、同一グループ130内のキャッシュノード(ここでは、キャッシュノードC11)と更新した管理情報75の同期を取り(矢印814)、削除したキャッシュノードC12のエントリをキャッシュノード管理情報232から削除する。
以上のキャッシュノード122の削除処理の例では、説明簡略化のため1グループ、1マスターノード、2キャッシュノードの構成が採用されたが、実際には複数のグループ130があっても良く、その場合はグループ130毎に上記の処理が行われて良い。キャッシュノード削除時に更新された管理情報75は、更新したマスターノードM1から別グループ130のマスターノード120に伝搬し、そのマスターノード120から同一グループ130内のキャッシュノード122に伝搬する。また、グループ130内のキャッシュノード122が1ノードとなった場合でも残っているキャッシュノード122が削除されても良いが、データ検索が割り振られた場合に即座に実行できないため、1又は複数のキャッシュノード122が残されておいても良い。
(4)本実施の形態におけるデータインポート処理1
図9は、マスターノードの追加を伴わないデータインポート処理の流れを示した図である。尚、ここでは、説明簡略化のため、1つのグループ130があり、そのグループ130はマスターノードM1と、キャッシュノードC11及びC12とで構成されており、カレントのマスターノードであるマスターノードM1に対してデータがインポートされるとする。
アプリケーション106が、カレントマスターノードM1のDBMS212に対し、インポート対象のデータが格納されているインポートファイル902が関連付けられたインポート要求を送信する(矢印900)。
データのインポート要求を受けたマスターノードM1のDBMS212は、管理情報75内のDBエリア情報400を参照して、インポート対象のデータをブロックストレージ242に格納できるか判定する。「インポート対象のデータをブロックストレージ242に格納できる」とは、ブロックストレージ242の空き領域が十分であることを意味する条件が満たされていること(例えば、空き領域の容量がインポート対象のデータのデータ容量以上であること)でよい。格納できると判定した場合は、DBMS212は、当該インポート要求を実行することで、インポートファイル902からブロックストレージ242のデータベース250にデータをインポートする(矢印904)。データのインポート完了後、DBMS212は、管理情報75(DBエリア情報400及びデータ管理情報230)を、インポートされたデータの内容に合わせて更新し、更新後の管理情報75と同一グループ130内のキャッシュノードC11及びC12内の管理情報75との同期を取る(矢印906)。
また、マスターノードM1のDBMS212は、ブロックストレージ242と高速ストレージ240の同期を取る、つまり、インポートされたデータをブロックストレージ242から高速ストレージ240にコピーする(矢印910)。その後、DBMS212は、マスターノードM1の高速ストレージ240と、同一グループ130のキャッシュノードC11及びC12の各々における高速ストレージ340との同期を取る、つまり、インポートされたデータを高速ストレージ240から高速ストレージ340にコピーする(矢印912)。尚、マスターノードM1のブロックストレージ242とキャッシュノードC11及びC12の各々における高速ストレージ340とで同期が取られても良い。また、同一グループ130内に複数のキャッシュノードがある場合は、各キャッシュノードの負荷(例えば稼働状況)を基に、負荷が低いキャッシュノード順に、同期が取られても良い。
(5)本実施の形態におけるデータインポート処理2
図10、図11及び図12は、マスターノードの追加を伴うデータインポート処理の流れを示した図である。尚、ここでは、説明簡略化のため、1つのグループ130があり、そのグループ130はマスターノードM1と、キャッシュノードC11及びC12とで構成されており、カレントマスターノードM1に対してデータがインポートされようとするが、領域不足のため新たにマスターノードM2とキャッシュノードC21とで構成されたグループ130Tが作成され、新規追加したマスターノードM2にデータがインポートされるとする。
図10が示すように、アプリケーション106が、カレントマスターノードM1のDBMS212に対し、インポート対象のデータが格納されているインポートファイル1002が関連付けられたインポート要求を送信する(矢印1000)。
インポート要求を受けたマスターノードM1のDBMS212は、DBエリア情報400を参照して、インポート対象のデータがデータベースのデータを記憶するブロックストレージ242に格納できるか判定する。「インポート対象のデータをブロックストレージ242に格納できる」とは、ブロックストレージ242の空き領域が不足していることを意味する条件が満たされていること(例えば、空き領域の容量がインポート対象のデータのデータ容量未満であること)でよい。格納できないと判定した場合は、DBMS212は、クラウド管理部102に対して、マスターノード用の新規インスタンスとキャッシュノード用の新規インスタンスの合計2個のインスタンスの作成を要求する(矢印1004)。尚、ここで作成するキャッシュノード用のインスタンスの数は2以上であっても良い。
図11が示すように、インスタンス作成の要求を受けたクラウド管理部102は、要求されたマスターノードM2用のインスタンスと、キャッシュノードC21用のインスタンスを作成し、それらのインスタンスに関する情報(例えばIPアドレス)を要求元のDBMS212に送信する(矢印1100)。
作成したインスタンスに関する情報を受けたマスターノードM1のDBMS212は、当該情報を基に、管理情報75(ノード情報500)を更新し、更新後の管理情報75と同一グループ130内のキャッシュノードC11及びC12の管理情報75との同期を取る(矢印1114)。また、マスターノードM1のDBMS212は、新規作成したインスタンス(マスターノードM2)のDBMS212に管理情報75を送信し(矢印1110)、カレントマスターノード情報502にマスターノードM2のIDを設定する。
マスターノードM1のDBMS212から管理情報75を受信したカレントのマスターノードM2のDBMS212は、自環境に合わせてDBエリア情報400を更新し、キャッシュノード管理情報232を作成する。作成後、DBMS212は、同時に作成されたインスタンス(キャッシュノードC21)のエントリを追加し当該エントリに情報を登録し、キャッシュノードC21のDBMS312に管理情報75(DB管理情報226、ノード管理情報228、及びデータ管理情報230)を送信する(矢印1112)。尚、新規作成されたキャッシュノードが複数の場合は、新規作成された全キャッシュノードに管理情報75が送信される。
図12に示すように、カレントになったマスターノードM2のDBMS212は、データのインポートを要求したクライアント104のアプリケーション106に対して、再度データのインポートを要求するように指示を出す(矢印1200)。当該指示を受けたアプリケーション106は、インポート対象のデータが格納されているインポートファイル1002が関連付けられたインポート要求を、カレントマスターノードM2のDBMS212に送信する(矢印1202)。
データのインポート要求を受けたマスターノードM2のDBMS212は、当該インポート要求を実行して、インポートファイル1002からブロックストレージ242にデータをインポートする(矢印1206)。データのインポート完了後、マスターノードM2のDBMS212は、管理情報75(DBエリア情報400及びデータ管理情報230)を、インポートしたデータの内容に基づき更新し、更新後の管理情報75と同一グループ130内のキャッシュノードC11の管理情報75との同期を取る(矢印1206)。また、カントマスターノードM2のDBMS212は、カレントマスターノードM2以外の各マスターノード(ここでは、マスターノードM1)のDBMS212の管理情報75とも、更新後の管理情報75との同期を取る(矢印1208)。尚、システム内に複数のマスターノードが存在する場合は、全マスターノードの管理情報に対して更新後の管理情報との同期が取られる。管理情報75が更新されたマスターノードM1のDBMS212は、同一グループ130の全キャッシュノード(ここでは、キャッシュノードC11及びC12)の管理情報75と、マスターノードM1における更新後の管理情報75との同期を取る(矢印1210)。
また、カレントマスターノードM2のDBMS212は、ブロックストレージ242におけるデータベース250と高速ストレージ240におけるデータベース250との同期を取る、つまり、ブロックストレージ242にインポートされたデータを高速ストレージ240にコピーする(矢印1220)。その後、当該DBMS212は、マスターノードM2の高速ストレージ240におけるデータベースと、同一グループ130のキャッシュノードC21における高速ストレージ340におけるデータベースと同期を取る、つまり、高速ストレージ240から、インポートされたデータを高速ストレージ340にコピーする(矢印1222)。尚、マスターノードM2のブロックストレージ242におけるデータベースとキャッシュノードC21の高速ストレージ340におけるデータベースとで同期が取られても良い。
以上のように、マスターノードの追加が伴うデータインポート処理では、データは、追加されたマスターノードM2にインポートされ、既存のマスターノードM1にはインポートされない。結果として、グループ130毎に、データベースの内容は異なり、故に、アプリケーション106からカレントマスターノードが受ける検索クエリに従う検索範囲は、下記のうちのいずれかである。
・カレントマスターノードが属する最新のグループ130内のデータベースの全部又は一部で構成された範囲。
・カレントマスターノードが属する最新のグループ130内のデータベースの全部又は一部と、カレントマスターノード以外の1以上のマスターノードがそれぞれ属する1以上のグループ内のデータベースの全部又は一部とで構成された範囲。
・カレントマスターノードが属する最新のグループ130内のデータベースの少なくとも一部を含んでおらず、カレントマスターノード以外の1以上のマスターノードがそれぞれ属する1以上のグループのうちの少なくとも1つのグループにおけるデータベースの全部又は一部で構成された範囲。
(6)本実施の形態におけるクエリ実行処理1
図13は、カレントマスターノードのグループで検索クエリの実行が可能な場合のクエリ実行処理の流れを示した図である。尚、ここでは、2つのグループがあり、1つ目のグループはマスターノードM1とキャッシュノードC11とで構成され、2つ目のグループはマスターノードM2と、キャッシュノードC21及びC22で構成され、マスターノードM2がカレントのマスターノードであるものとする。
カレントマスターノードM2のDBMS212が、アプリケーション106から、検索クエリ1300を受け付ける(矢印1302)。
検索クエリ1300を受けたマスターノードM2のDBMS212は、検索クエリ1300を解析してクエリプラン13を作成する。クエリプラン作成後、DBMS212は、キャッシュノード管理情報232を参照して、同一グループ130内のキャッシュノードのうち一番CPU負荷(CPU利用率)の低いキャッシュノードを特定し(ここでは、キャッシュノードC21)、作成したクエリプラン13と、クエリソース(クライアント104及び/又はアプリケーション106)に関する情報とが関連付けられた検索クエリをキャッシュノードC21のDBMS312に送信する(矢印1304)。この送信される検索クエリは、DBMS212が受けた検索クエリ1300(つまりオリジナルの検索クエリ)に基づく検索クエリであり、具体的には、例えば、検索クエリ1300それ自体でも良いし、検索クエリ1300を用いて生成された検索クエリでも良い。尚、ここではマスターノードM2のDBMS212がクエリプラン13を作成し作成したクエリプラン13をキャッシュノードC21に送信しているが、DBMS212が検索クエリ1300をそのままキャッシュノードC21に送信し、キャッシュノードC21のDBMS312が検索クエリ1300を解析してクエリプランを作成しても良い。また、特定されるキャッシュノードの条件として、一番CPU負荷が低いことに代えて、他種の条件(例えば、CPU負荷に代えて又は代えて他種の負荷が一番低いこと)が採用されてもよい。
検索クエリを受けたキャッシュノードC21のDBMS312は、管理情報75(データ管理情報230)を参照して、受信した検索クエリに関連付けられているクエリプラン13に従いアクセスされるデータが自ノードC21の高速ストレージ340におけるデータベースに全て存在するか判断する。全て存在する場合は、DBMS312は、検索クエリを実行する、すなわち、高速ストレージ340におけるデータベースからのデータ検索を実行する(矢印1306)。キャッシュノードC21のDBMS312は、クエリ実行完了後、実行結果1308を、DBMS212から受けた検索クエリに関連付けられている情報から特定されたクライアント104のアプリケーション106に送信する(矢印1310)。
(7)本実施の形態におけるクエリ実行処理2
図14は、複数のグループに跨って検索クエリを実行する場合のクエリ実行処理の流れを示した図である。尚、ここでは、2つのグループ130があり、1つ目のグループ130はマスターノードM1とキャッシュノードC11とで構成され、2つ目のグループ130はマスターノードM2とキャッシュノードC21及びC22とで構成され、マスターノードM2がカレントのマスターノードであるものとする。
カレントマスターノードM2のDBMS212が、アプリケーション106から、検索クエリ1400を受け付ける(矢印1402)。
検索クエリ1400を受けたマスターノードM2のDBMS212は、検索クエリ1400を解析してクエリプラン13を作成する。クエリプラン作成後、DBMS212は、キャッシュノード管理情報232を参照して、同一グループ130内のキャッシュノードのうち一番CPU負荷の低いキャッシュノードを特定し(ここでは、キャッシュノードC21)、作成したクエリプランと、クエリソース(クライアント104及び/又はアプリケーション106)に関する情報とが関連付けられた検索クエリを、キャッシュノードC21のDBMS312に送信する(矢印1404)。尚、ここではマスターノードM2のDBMS312が作成したクエリプラン13をキャッシュノードC21に送信しているが、DBMS212は、検索クエリ1400をそのままキャッシュノードC21に送信し、キャッシュノードC21のDBMS312が、検索クエリ1400を解析してクエリプランを作成しても良い。
検索クエリを受けたキャッシュノードC21のDBMS312は、管理情報75(データ管理情報230)を参照して、受けた検索クエリに関連付けられているクエリプラン13に従いアクセスされるデータが自ノードC21の高速ストレージ340におけるデータベース350内に全て存在するか判断する。一部のデータでも存在しないデータがあると判断した場合は、DBMS312は、当該データを記憶しているマスターノードを管理情報75(データ管理情報230)から特定し(ここでは、マスターノードM1)、特定されたマスターノードM1のDBMS212に対して、キャッシュノード割当要求(別の言い方をすれば、キャッシュノード問合せ)を発行する(矢印1406)。尚、複数のマスターノードが特定された場合は、特定された全てのマスターノードの各々に対して同じ処理が行われる。また、キャッシュノード割当要求に代えて、特定されたマスターノードが属するグループにおけるデータベースからデータを検索するための検索クエリが、特定されたマスターノードにおけるDBMS212に送信されても良い。当該検索クエリを受けたDBMS212が、同一グループ内のキャッシュノードに、検索クエリを送信しても良い。
キャッシュノード割当要求を受け付けたマスターノードM1のDBMS212は、キャッシュノード管理情報232を参照して、同一グループ内のキャッシュノードのうち一番CPU負荷の低いキャッシュノードを特定し(ここでは、キャッシュノードC11)、特定したキャッシュノードC21のIDを、要求元のキャッシュノードC21のDBMS312に応答する(矢印1406)。
キャッシュノード割当要求に対する応答を受けたキャッシュノードC21のDBMS312は、クエリプラン13が関連付けられた検索クエリを、当該受けた応答が表すキャッシュノードC11のDBMS312に送信する(矢印1408)。この検索クエリに関連付けられるクエリプラン13は、カレントマスターノードM2のDBMS212により作成されたクエリプラン13それ自体であるが、それに代えて、クエリプラン13の一部(少なくとも、キャッシュノードC11に送信される検索クエリに従う検索範囲に対応した部分を含んだクエリプラン)でも良い。キャッシュノードC21のDBMS312は、自ノードC21の高速ストレージ340におけるデータベース350に、カレントマスターノードM2からのクエリプラン13に従いアクセスされるデータが一部でも存在する場合、自ノードC21の高速ストレージ340におけるデータベース350からのデータ検索を実行する(矢印1412)。
検索クエリを受けたキャッシュノードC11のDBMS312は、自ノードC11の高速ストレージ340におけるデータベース350からのデータ検索を実行する、つまり検索クエリを実行する(矢印1414)。DBMS312は、実行結果1416を要求元のキャッシュノードC21のDBMS312に送信する(矢印1418)。
実行結果1416を受信したキャッシュノードC21のDBMS312は、自ノードC21で検索クエリを実行した場合はその実行結果と受信した実行結果1416とをマージし、マージ後の実行結果1420を、カレントマスターノードM2からの検索クエリに関連付けられている情報から特定されたクライアント104のアプリケーション106に送信する(矢印1422)。
(8)本実施の形態における処理フロー
図15は、各キャッシュノード122のDBMS312が実行するモニタデータ取得送信処理1500のフロー図である。一つのキャッシュノード122を例に取る。モニタデータ取得送信処理1500は、例えば、キャッシュノード122のDBMS312におけるノード管理部324により行われて良い。
キャッシュノード122のDBMS312は、一定時間ウェイトし(ステップ1502)、その後CPUやI/Oの稼働状態をモニタするsar/mpstat/iostat等のモニタコマンド334を実行して、CPU利用率やIOPS、スループット等のモニタデータを取得する(ステップ1504)。続いて、モニタデータを取得したキャッシュノード122のDBMS312は、ノード情報500を参照して、当該キャッシュノード122が属するグループのマスターノード120を特定し(ステップ1506)、取得したモニタデータをそのマスターノード120のDBMS212に送信する(ステップ1508)。キャッシュノード122のDBMS312は、ステップ1502~1508の処理を繰り返して実行する。尚、マスターノード120とキャッシュノード122間のモニタデータ送受信は、決められた送受信フォーマットのプロトコルを利用して行われても良いし、ファイル等を介して行われても良い。
図16は、各マスターノード120のDBMS212が実行するモニタデータ受信処理1600のフロー図である。一つのマスターノード120を例に取る。モニタデータ受信処理1600は、例えば、マスターノード120のDBMS212におけるノード管理部224により行われて良い。
マスターノード120のDBMS212は、同じグループに属するキャッシュノード122のDBMS312からモニタデータを受信するのを待ち(ステップ1602)、キャッシュノード122のDBMS312のモニタデータ取得送信処理1500によって送信されたモニタデータを受信する(ステップ1604)。
マスターノード120のDBMS212は、キャッシュノード122のDBMS312からモニタデータ受信した後、受信したモニタデータの内容に合わせてキャッシュノード管理情報232を更新する(ステップ1606)。続いて、DBMS212は、キャッシュノード管理情報232を基に、同じグループに属する全キャッシュノード122のCPU利用率から平均CPU利用率を算出し(ステップ1608)、算出した平均CPU利用率が追加閾値(ノードルール情報504のキャッシュノード追加ルールのフィールド540に設定されている閾値)を超えているか判定する(ステップ1610)。平均CPU利用率が追加閾値を超えている場合は、DBMS212が、キャッシュノード追加処理1700を実行し(ステップ1612)、再度キャッシュノードからのモニタデータ受信待ちとなる。平均CPU利用率が追加閾値を超えていない場合は、DBMS212は、平均CPU利用率が削除閾値(ノードルール情報504のキャッシュノード削除ルール542に設定されている閾値)を下回っているか判定する(ステップ1614)。平均CPU利用率が削除閾値を下回っている場合は、DBMS212が、キャッシュノード削除処理1800を実行し(ステップ1616)、再度キャッシュノードからのモニタデータ受信待ちとなる。平均CPU利用率が削除閾値を下回っていない場合は、DBMS212は、同様に再度キャッシュノードからのモニタデータ受信待ちとなる。
図17は、各マスターノード120のDBMS212が実行するキャッシュノード追加処理1700のフロー図である。一つのマスターノード120を例に取る。キャッシュノード追加処理1700は、例えば、マスターノード120のDBMS212におけるノード管理部224により行われて良い。
マスターノードのDBMS212は、インスタンス構成情報506を参照し、キャッシュノード用インスタンス構成のフィールド552に設定されたキャッシュノード構成を特定し、当該構成の新規インスタンス作成をクラウド管理部102に要求する(ステップ1702)。インスタンス作成の要求を受けたクラウド管理部102は、要求された構成のインスタンスを作成し、IPアドレス等のインスタンスに関する情報を要求元のDBMS212に送信する。インスタンス作成後は、OSのインストールや設定、DBMSのインストールや環境設定を実施する必要があるが、本実施の形態では新規インスタンス作成後、例えばスクリプトの実行等によって自動的にインスタンスが利用可能になるものとする。
新規インスタンス作成要求後のマスターノードのDBMS212は、クラウド管理部102からの応答を待つ(ステップ1704)。応答があった際は、DBMS212は、当該応答に関連付いている情報(作成された新規インスタンス(キャッシュノード)を表す情報)をキャッシュノード管理情報232に登録し、当該キャッシュノードの状態を使用可能の状態として設定する(ステップ1706)。続いて、DBMS212は、新規作成されたキャッシュノードのエントリをノード情報500に作成し、クラウド管理部102からの応答に関連付いている情報(作成された新規インスタンス(キャッシュノード)を表す情報)を基に当該エントリに情報を設定する(ステップ1708)。キャッシュノードの作成後は、DBMS212は、ノード情報500を参照して、自グループに属するキャッシュノードを特定し、特定したキャッシュノードのDBMS312に対して、ノード情報500の同期を取る(ステップ1710)。
続いて、DBMS212は、ノード情報500を参照して、当該DBMS212を有するマスターノードである対象マスターノード以外のマスターノードが存在するか判定する(ステップ1712)。対象マスターノード以外のマスターノードが存在する場合は、DBMS212は、対象マスターノード以外の各マスターノードのDBMS212に対して、ノード情報500の同期を取る(ステップ1714)。ノード情報500の同期が取られたマスターノードにおけるDBMS212は、当該DBMS212が管理するノード情報500を参照して、同一グループに属するキャッシュノードを特定し、特定したキャッシュノードのDBMS312に対して、ノード情報500の同期を取る(ステップ1716)。
対象マスターノード(キャッシュノードを同一グループに新規作成したマスターノード)のDBMS212は、新規作成したキャッシュノードのDBMS312に対して、管理情報75(DB管理情報226、ノード管理情報228、及びデータ管理情報230)の同期を取る(ステップ1718)。DBMS212は、対象マスターノードの高速ストレージ240に記憶しているデータベースのデータを、新規作成したキャッシュノードの高速ストレージ340に送信して同期を取る(ステップ1720)。
図18は、各マスターノード120のDBMS212が実行するキャッシュノード削除処理1800のフロー図である。一つのマスターノード120を例に取る。キャッシュノード削除処理1800は、例えば、マスターノード120のDBMS212におけるノード管理部224により行われて良い。
マスターノード120のDBMS212は、キャッシュノード管理情報232を参照して、CPU利用率が最も低いキャッシュノードを特定し(ステップ1802)、特定したキャッシュノードの状態を削除中に変更し、当該キャッシュノードが処理実行中の場合は実行中の処理が完了するのを待つ(ステップ1804)。
続いて、マスターノード120のDBMS212は、削除対象のキャッシュノードに対応するインスタンスの削除をクラウド管理部102に要求し(ステップ1806)、キャッシュノードの削除が完了するのを待つ(ステップ1808)。クラウド管理部102からの削除完了の応答を受け、DBMS212は、キャッシュノード管理情報232から削除したキャッシュノードのエントリを削除し(ステップ1810)、ノード情報500から削除したキャッシュノードのエントリを削除する(ステップ1812)。削除後は、DBMS212は、ノード情報500を参照して、同一グループに属するキャッシュノードを特定し、特定したキャッシュノードのDBMS312に対して、ノード情報500の同期を取る(ステップ1814)。
続いて、対象マスターノード(キャッシュノードを削除したマスターノード)のDBMS212は、ノード情報500を参照して、対象マスターノード以外のマスターノードが存在するか判定する(ステップ1816)。対象マスターノード以外のマスターノードが存在する場合は、対象マスターノードのDBMS212は、対象マスターノード以外の各マスターノードのDBMS212に対して、ノード情報500の同期を取る(ステップ1820)。ノード情報500の同期が取られたマスターノードのDBMS212は、当該DBMS212が管理するノード情報500を参照して、同一グループに属するキャッシュノードを特定し、特定したキャッシュノードのDBMS312に対して、ノード情報500の同期を取る(ステップ1822)。
図19及び図20は、カレントのマスターノードのDBMS212が実行するデータインポート処理1900のフロー図である。
カレントのマスターノードのDBMS212にあるクエリ受付部220は、アプリケーション106から、データインポートの要求(インポート対象のデータが格納されているインポートファイルが関連付けられている要求)を受信する(ステップ1902)。データインポートの要求を受け付けたDBMS212のクエリ実行部222は、ノード情報500を参照して、当該マスターノードのデータ空き容量(例えば、データ空き容量=データ容量-データ使用量)を算出し(ステップ1904)、算出したデータ空き容量よりインポート対象のデータサイズが大きいか判定する(ステップ1906)。
当該マスターノードのデータ空き容量がインポート対象のデータより大きい(又は同じ)と判定した場合は、DBMS212のクエリ実行部222は、ステップ1914から処理を続行する。当該マスターノードのデータ空き容量がインポート対象のデータより小さいと判定した場合は、DBMS212(例えばノード管理部224)は、マスターノード追加処理2100を実行し(ステップ1908)、キャッシュノード追加処理1700を実行し(ステップ1910)、新規グループを作成する。新規グループ作成後は、作成されたマスターノードがカレントマスターノードとなり、以前にカレントであったマスターノードのDBMS212(例えばクエリ受付部320)が、インポート要求元のクライアント104のアプリケーション106に対して、再度データのインポートを要求するように指示を出し(ステップ1912)、ステップ1902から処理を実行する。
カレントマスターノードのDBMS212のクエリ実行部222が、インポート要求を実行し、受信したインポートファイルのデータをブロックストレージ242上のデータベースにインポートし(ステップ1914)、データのインポート完了後、インポートしたデータに合わせてデータ管理情報230を更新する(ステップ1916)。続いて、DBMS212のクエリ実行部222が、ノード情報500を参照して、同一グループに属するキャッシュノードを特定し、特定したキャッシュノードのDBMS312に対して、データ管理情報230の同期を取る(ステップ1918)。
続いて、DBMS212のクエリ実行部222が、ノード情報500を参照して、対象マスターノード(当該DBMS212を有するマスターノード)以外のマスターノードが存在するか判定する(ステップ2000)。対象マスターノード以外のマスターノードが存在する場合は、DBMS212のクエリ実行部222が、対象マスターノード以外の各マスターノードのDBMS212に対して、データ管理情報230の同期を取る(ステップ2002)。データ管理情報230の同期が取られたマスターノードのDBMS212(例えばクエリ実行部322)は、ノード情報500を参照して、同一グループに属するキャッシュノードを特定し、特定したキャッシュノードのDBMS312に対して、データ管理情報230の同期を取る(ステップ2004)。
対象マスターノード(データのインポートを実行したカレントのマスターノード)のDBMS212のクエリ実行部222は、続いて当該マスターノードのブロックストレージ242のデータベースのデータと、高速ストレージ240のデータベースのデータの同期を取る(ステップ2006)。同期完了後、DBMS212のクエリ実行部222は、ノード情報500を参照して、同一グループに属するキャッシュノードを特定し、特定したキャッシュノードの高速ストレージ340のデータベースのデータと、対象マスターノードの高速ストレージ240のデータベースのデータとの同期を取る(ステップ2008)。
図21は、カレントのマスターノードのDBMS212が実行するマスターノード追加処理2100のフロー図である。マスターノード追加処理2100は、例えば、マスターノード120のDBMS212におけるノード管理部224により行われて良い。
カレントのマスターノードのDBMS212は、インスタンス構成情報506を参照し、マスターノード用インスタンス構成のフィールド550に設定されたマスターノード構成を特定し、当該構成のインスタンス作成をクラウド管理部102に要求する(ステップ2102)。インスタンス作成の要求を受け付けたクラウド管理部102は、要求された構成のインスタンスを作成し、IPアドレス等のインスタンスに関する情報を要求元のDBMS212に送信する。
新規インスタンス作成要求後のマスターノードのDBMS212は、クラウド管理部102からの応答を待つ(ステップ2104)。DBMS212は、応答があった際は、作成された新規インスタンス(マスターノード)を表す情報をノード情報500に登録する(ステップ2106)。続いて、カレントのマスターノードのDBMS212は、カレントマスターノード情報502が表すIDを、新規作成されたマスターノードのIDに変更し(ステップ2108)、新規作成されたマスターノードのDBMS212に対して、管理情報75(DB管理情報226、ノード管理情報228、及びデータ管理情報230)の同期を取る(ステップ2108)。新しくカレントのマスターノードになったマスターノードのDBMS212は、キャッシュノード管理情報232を作成する(ステップ2112)。
図22、図23A、図23B、図24A及び図24Bは、マスターノード及びキャッシュノードが実行するクエリ実行処理の処理フロー図である。この処理で実行されるクエリは、検索クエリである。
カレントのマスターノードのDBMS212にあるクエリ受付部220は、アプリケーション106から、検索クエリを受信する(ステップ2202)。続いて、DBMS212のクエリ受付部220は、受信した検索クエリからクエリプランを作成し(ステップ2204)、作成したクエリプランをDBMS212のクエリ実行部222に渡してクエリ実行を開始する(ステップ2206)。
DBMS212のクエリ実行部222は、キャッシュノード管理情報232を参照して、同一グループに属するキャッシュノードの中で最もCPU利用率の低いキャッシュノードを特定し(ステップ2208)、特定したキャッシュノードに対して、クエリプランとクエリソース情報(クライアント104とアプリケーション106に関する情報)とが関連付けられた検索クエリを送信する(ステップ2210)。
キャッシュノード(ここでは、C21とする)のDBMS312は、クエリプラン及びクエリソース情報が関連付いた検索クエリをDBMS212から受信し(ステップ2220)、データ管理情報230を参照して、当該検索クエリの実行においてアクセスされるデータがノードC31のデータベース350に全て存在するか判定する(ステップ2222)。
ステップ2222の判定結果が真の場合は、キャッシュノードC21のDBMS312のクエリ実行部322が、受信したクエリプランを基に高速ストレージ340上のデータベースからのデータ検索を実行し(ステップ2224)、実行結果を、クエリソース情報が表す要求元のアプリケーション106に応答する(ステップ2226)。
ステップ2222の判定結果が偽の場合は、キャッシュノードC21のDBMS312のクエリ実行部322が、データ管理情報230を参照して、当該検索クエリの実行においてアクセスされるデータを有するマスターノードを特定し(ステップ2300)、特定したマスターノードにキャッシュノード割当要求を送信する(ステップ2302)。尚、ステップ2300で複数のマスターノードが特定された場合は、特定された全てのマスターノードの各々についてステップ2302が行われる。
キャッシュノード割当要求を受けたマスターノードのDBMS212(例えばノード管理部224)は、キャッシュノード管理情報232を参照して、同一グループに属するキャッシュノードの中で最もCPU利用率が低いキャッシュノードを特定し(ステップ2400)、特定したキャッシュノード(ここでは、C11とする)の情報を要求元のキャッシュノードC21のDBMS312に応答する(ステップ2402)。
キャッシュノード割当要求の応答を受けたキャッシュノードC21のDBMS312(例えばクエリ実行部322)は、割り当てられたキャッシュノードC11のDBMS312に対して、クエリプランが関連付けられた検索クエリを送信する(ステップ2304)。続いて、キャッシュノードC21のDBMS312(例えばクエリ実行部322)は、当該DBMS312が管理するデータ管理情報230を参照して、当該検索クエリの実行においてアクセスされるデータが自ノードC21のデータベース350に一部でも存在するか判定する(ステップ2306)。ステップ2306の判定結果が真の場合は、キャッシュノードC21のDBMS312のクエリ実行部322が、受信したクエリプランを基にキャッシュノードC21の高速ストレージ340におけるデータベース350からのデータ検索を実行する(ステップ2308)。当該実行完了後、又はステップ2306の判定結果が偽の場合、キャッシュノードC21のDBMS312(例えばクエリ実行部322)は、他キャッシュノードで実行している検索クエリの応答を待つ(ステップ2310)。
キャッシュノードC11のDBMS312のクエリ受付部320は、クエリプランとクエリ実行の要求をキャッシュノードC21のDBMS312から受信し(ステップ2410)、受信した検索クエリに関連付けられているクエリプランをクエリ実行部322に渡す(ステップ2412)。クエリ実行部322が、受けたクエリプランを基に、キャッシュノードC11の高速ストレージ340におけるデータベース350からのデータ検索を実行する(ステップ2414)。実行完了後は、当該クエリ実行部322が、要求元のキャッシュノードC21のDBMS312に実行結果を送信する(ステップ2416)。
キャッシュノードC21のDBMS312は、ステップ2310で他キャッシュノード(ここでは、C11)からの応答(実行結果)を待ち、応答受信後は、自ノードC21を含む複数のキャッシュノードでクエリを実行した場合は複数の実行結果のマージを行い、マージされた実行結果を要求元のクライアント104のアプリケーション106に送信する(ステップ2312)。
(9)本実施の形態の効果
以上の本実施の形態によるデータベースシステムは、クラウド100(複数の計算リソースを含む計算機システムに基づく仮想環境の一例)に設けられた複数のノードにそれぞれ備えられる複数のDBMS(データベース管理システム)を備える。複数のDBMSの各々は、DBMS212(第1のDBMSの一例)とDBMS312(第2のDBMSの一例)とのいずれかである。DBMS212は、クライアント104(クエリソースの一例)から検索クエリを受け付けた場合に当該検索クエリに基づく1つ以上の検索クエリを送信しデータ検索を実行しないDBMSである。DBMS312は、データ検索を実行するDBMSである。複数のノードは、1つ又は複数のグループ130を構成する。各グループ130が、マスターノード120(第1のノードの一例)と1つ以上のキャッシュノード122(1つ以上の第2のノードの一例)とを含む。各グループ130において、マスターノード120は、ブロックストレージ242の領域(第1の記憶領域の一例)を提供しDBMS212を実行する論理計算機である。キャッシュノード122は、高速ストレージ340の領域(第2の記憶領域の一例)を提供しDBMS312を実行する論理計算機である。各グループ130について、当該グループ130を構成する2つ以上のノードが有する2つ以上のDBMSが、当該2つ以上のノードが提供する2つ以上の記憶領域に同一のデータベースを格納し、当該グループ130内のデータベースからのデータ検索は、当該グループ130内の1つ以上のDBMS312により実行される。グループ130毎にマスターノード120が存在し、また、データ検索はキャッシュノード122により実行されるので、処理の一極集中を回避できる。また、データ検索は、検索対象のデータが存在するグループ130におけるデータベースに対して行われるので、分散配置されたデータからのデータ検索することができる。
各グループ130において、キャッシュノード122は、当該グループ130に属する少なくとも1つのキャッシュノード122の負荷状況に基づいてスケールして良い。一方、グループ130それ自体が、全てのブロックストレージ242に格納されたデータベースの総量に基づいてスケールして良い。これにより、負荷状況の変化にもデータ量の増加にも柔軟に対応することができる。
ブロックストレージ242の領域は、データの永続性を保証するストレージに基づく記憶領域の一例で良い。このため、例えば同一グループ内の全てのキャッシュノード122からデータベース350が消失しても、同一グループ内のマスターノード120が管理するデータベース250を用いて、データベース350を復元できる。そして、高速ストレージ340の領域は、ブロックストレージ242よりも高速なストレージに基づく記憶領域の一例で良い。キャッシュノード122によりデータ検索は高速ストレージ240に対して行われるため、検索性能の向上が期待できる。
各DBMSが、データベースのデータの記憶位置を表すデータ管理情報を管理して良い。所定のDBMS212が、クライアント104から検索クエリを受け付けるようになっていて良い。所定のDBMS212が、検索クエリを受け付けた場合、当該検索クエリに基づく1つ以上の検索クエリを、当該所定のDBMS212と同一グループ130内の1つ以上のDBMS312にそれぞれ送信して良い。所定のDBMS212から検索クエリを受けたDBMS312が、当該DBMS312が管理するデータ管理情報230を基に、当該検索クエリに基づきアクセスされるデータの全てが、当該DBMS312を実行するキャッシュノード122内のデータベース350に存在するか否かのデータ位置判定を行って良い。当該データ位置判定の結果が真の場合、当該DBMS312が、当該データベース350に対してデータ検索を実行して良い。当該データ位置判定の結果が偽の場合、当該DBMS312が、アクセスされるデータからのデータ検索のための1つ以上の検索クエリを、当該アクセスされるデータの少なくとも一部が存在する1つ以上のグループ130へ送信して良い。このようにして、検索対象のデータがいずれのグループ130内のデータベースに存在しても、一つ以上のグループ130における一つ以上のデータベースからデータを検索することができる。DBMS312は、検索クエリを、別グループ130におけるマスターノード120に送信しても良いし、別グループ130におけるキャッシュノード122に送信しても良い(前者の場合、別グループ130において、マスターノード120からキャッシュノード122へ検索クエリが送信されて良い)。
所定のDBMS212は、最新のグループ130内のマスターノード120であるカレントのマスターノード120内のDBMSで良い。カレントのマスターノード120がクエリソースから検索クエリを受けた際は、同一グループ内のキャッシュノード122に検索クエリが送信されて良い。最新のグループ130は、最近データがインポートされたグループであるため、最新のグループ130のデータベースが検索対象である可能性が高い。本実施形態では、最新のグループ130内のマスターノード120がカレントのマスターノード120であるため、高速なデータ検索(例えば、検索クエリを別グループに送信する可能性が低いデータ検索)が期待される。
カレントマスターノード120内のDBMS212が、データベースのデータの追加要求を受け付けるようになっていて良い。カレントのマスターノード120が提供するブロックストレージ242の領域の空き領域が不足していることを意味する条件が満たされているとカレントのDBMS212が判定した場合、グループ130が新たに追加されて良い。新たに追加されたグループ130内のマスターノード120が、上記カレントマスターノード120に代わって新たにカレントのマスターノード120となって良い。このようにして、データベースシステムの全マスターノード120が管理するデータ量の増加に応じて、グループ130が追加され、追加された最新のグループ130内のマスターノード120が、カレントのマスターノードとなる。結果として、データ量に応じてグループ130をスケールし高速なデータ検索を維持することが期待される。尚、所定のDBMS212が受けた追加要求に応答して前記最新のグループ130内のデータベースにデータが追加された場合、当該所定のDBMS212が、当該所定のDBMS212が管理するデータ管理情報230を更新して良い。当該更新と同期的に、当該更新後のデータ管理情報230が、カレントのマスターノード120以外の各ノードにおけるDBMSが管理するデータ管理情報230に反映されて良い。このようにして、どのマスターノード(どのグループ)にどのデータがあるかを表すデータ管理情報230を各ノードにおいて最新の状態に維持することができる。
所定のDBMS212から少なくとも1つのDBMS312への検索クエリには、クエリソースを表す情報であるクエリソース情報が関連付けられて良い。クエリソースから発行された検索クエリについて、2つ以上のDBMS312がそれぞれデータ検索を行った場合、当該2つ以上のDBMS312がそれぞれ行ったデータ検索の結果をいずれかのDBMS312がマージしてクエリソース情報が表すクエリソースに返して良い。これにより、マスターノード120の負荷集中を避けることができる。
クエリソースから検索クエリを受けた所定のDBMS212が、当該検索クエリのクエリプランを作成し、当該作成したクエリプランに基づく1つ以上のクエリプランをそれぞれ関連付けた1つ以上の検索クエリを、当該所定のDBMS212と同一グループ130内の1つ以上のDBMS312にそれぞれ送信してよい。検索クエリを受けたDBMS312が、当該検索クエリに関連付いているクエリプランに従いデータ検索を行ってよい。このように、カレントマスターノード120のDBMS212が作成したクエリプランを、同一グループを含む一つ以上のグループの各々に展開することで、データ検索を実現することができる。
所定のDBMS212から検索クエリを受けたDBMS312が、データ位置判定の結果が偽の場合、当該アクセスされるデータの少なくとも一部が存在する1つ以上のグループ130の各々におけるDBMS212に、当該DBMS212と同一グループ130内のキャッシュノード122を問い合わせて良い。当該1つ以上のグループ130の各々について、問合せに応答して、DBMS312が、問合せ先のDBMS212により選択された1つ以上のキャッシュノード122を表すキャッシュノード情報を受けて良い。当該1つ以上のグループ130の各々について、DBMS312が、受けたキャッシュノード情報から特定される1つ以上のキャッシュノード122の各々に、当該DBMS312が受けた当該検索クエリに基づく1つ以上の検索クエリをそれぞれ送信して良い。これにより、最新グループ以外のグループのマスターノード120が検索クエリを最新グループにおけるキャッシュノード122から受け、当該マスターノード120と同一グループ内のキャッシュノード122に検索クエリを送信する必要が無い。つまり、最新グループ以外のグループにおけるマスターノード120の負荷を低減できる。
各グループ130のマスターノード120のDBMS212は、同一グループ(自グループ)に属するキャッシュノードの稼働状況をモニタして良い。DBMS212が、同一グループから稼働状況の低いキャッシュノード122を選択し、選択したキャッシュノード122に検索クエリを送信して良い。これにより、グループ130内での負荷の均一化を図ることが可能となる。
インスタンスの追加又は削除を行うことが容易であるクラウド100の様な仮想環境の特徴を活かし、稼働状況(負荷)に応じてキャッシュノード122がスケールする。例えば、稼働状況が高くなった際はキャッシュノード122を追加することでデータ検索への影響を小さくすることが可能となる。また、稼働状況が低くなればキャッシュノード122を削除することで、当該キャッシュノード122(インスタンス)の稼働に要する消費電力を削減することが可能となる。
(10)他の実施の形態
上記の実施の形態では、マスターノード120にはブロックストレージ242と高速ストレージ240の両方を記載しているが、高速ストレージ240はマスターノードになくても良い。その場合、ブロックストレージ242と高速ストレージ240のデータベースのデータの同期は必要がなく、またキャッシュノード122の高速ストレージ240にデータベースのデータとの同期はブロックストレージ242と行うことになる。
また、所定のDBMS212が、クエリソースからの検索クエリを基に2つ以上の検索クエリを生成し、当該2つ以上の検索クエリを、当該所定のDBMS212と同一グループ130内の2つ以上のDBMS312にそれぞれ送信してよい。すなわち、図25に例示するように、マスターノード120のDBMS212が、同一グループから複数のキャッシュノード122を選択し、選択した複数のキャッシュノード122に、クエリソースからの検索クエリを分割した複数の検索クエリをそれぞれ送信しても良い(矢印2501)。この場合、複数のキャッシュノード122の中で1つのキャッシュノード122がメインで残りのキャッシュノード122がサブでよい。例えば、サブのキャッシュノードC21が検索クエリを実行してメインのキャッシュノードC21に実行結果2511を送信して良い。メインのキャッシュノードC21が、実行結果2511と、当該ノードC21での実行結果とをマージした実行結果2512を、クエリソースの一例であるアプリケーション106に応答して良い。このように、複数のキャッシュノード122で分割してデータ検索を実行することで、クエリソースから検索クエリを受けてからクエリソースに応答するまでの時間を短縮することが可能となる。
また、カレントのマスターノード120のDBMS212が、クライアント104のアプリケーション106から検索クエリを受けた際、当該DBMS212がクエリプランを作成するが、それに代えて、例えば図14において、検索クエリを受けたDBMS312が、当該検索クエリのクエリプランを作成し、当該作成したクエリプランに従いデータ検索を行って良い。これにより、クエリプランの作成に処理に要する負荷がマスターノードから削減されるので、マスターノードの一極集中を避けることが可能となる。
また、図26が例示するように、検索クエリを受けたキャッシュノード122のDBMS312が、データ管理情報230を用いて、当該検索クエリに従いアクセスされるデータが自ノード122が有するデータベースに全く存在しないと判定した場合は、アクセスされるデータを有するキャッシュノードに対して、当該キャッシュノードを含むグループ内のマスターノード経由又は非経由に、検索クエリを送信し、当該検索クエリを受けたキャッシュノードが、検索クエリを実行し、実行結果を含む応答を、要求元のクエリソースに送信しても良い。これにより、クエリ実行に関係のないキャッシュノードの処理負荷を低減することが可能となる。
以上、幾つかの実施形態を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施形態にのみ限定する趣旨ではない。
例えば、本発明は、データベースシステムを含むデータ処理システム全般に適用可能である。例えば、本発明の一実施形態に係るデータ処理システムを、以下のように表現することができる。
すなわち、データ処理システムは、複数の計算リソースを含む計算機システムに基づく仮想環境に設けられた複数のノードにそれぞれ備えられる複数のデータ処理部を備える。複数のデータ処理部の各々は、第1のデータ処理部と第2のデータ処理部のいずれかである。第1のデータ処理部は、要求ソースからリード要求を受け付けた場合に当該リード要求に基づく1つ以上のリード要求を送信するがリード対象のデータを記憶領域からリードするリード処理を実行しないデータ処理部である。第2のデータ処理部は、リード処理を実行するデータ処理部である。複数のノードは、1つ又は複数のノードグループを構成する。各ノードグループが、第1のノードと1つ以上の第2のノードとを含む。各ノードグループにおいて、第1のノードは、第1の記憶領域を提供し第1のデータ処理部を有する論理計算機である。第2のノードは、第2の記憶領域を提供し第2のデータ処理部を有する論理計算機である。各ノードグループについて、当該ノードグループを構成する2つ以上のノードが有する2つ以上のデータ処理部が、当該2つ以上のノードが提供する2つ以上の記憶領域に同一のデータを格納する。各ノードグループについて、当該ノードグループ内のデータからのリード処理は、当該ノードグループ内の1つ以上の第2のデータ処理部により実行される。データ処理部は、要求を受けた場合、当該要求に従う処理を実行する、及び/又は、当該要求に基づく1つ以上の要求を送信する。データ処理部の一例が、DBMSである。リード要求の一例が、検索クエリである。
100…クラウド、 102…クラウド管理部、 110…インスタンス、 120…マスターノード、 122…キャッシュノード、 130…グループ、 200、300…CPU、 210、310…メモリ、 212、312…データベース管理システム(DBMS)、 214、314…OS、 220、320…クエリ受付部、 222、322…クエリ実行部、 224、324…ノード管理部、 226…DB管理情報、 228…ノード管理情報、 230…データ管理情報、 232…キャッシュノード管理情報、 234、334…モニタコマンド、 240、340…高速ストレージ、 242…ブロックストレージ、 250、350…データベース

Claims (14)

  1. 複数の計算リソースを含む計算機システムに基づく仮想環境に設けられた複数のノードにそれぞれ備えられる複数のDBMS(データベース管理システム)を備え、
    前記複数のDBMSの各々は、第1のDBMSと第2のDBMSのいずれかであり、
    第1のDBMSは、検索クエリを受け付けた場合には当該検索クエリに基づく1つ以上の検索クエリを送信しデータ検索を実行しないDBMSであり、
    第2のDBMSは、データ検索を実行するDBMSであり、
    前記複数のノードは、1つ又は複数のノードグループを構成し、
    各ノードグループが、第1のノードと1つ以上の第2のノードとを含み、
    各ノードグループにおいて、
    第1のノードは、第1の記憶領域を提供し第1のDBMSを実行する論理計算機であり、
    第2のノードは、第2の記憶領域を提供し第2のDBMSを実行する論理計算機であり、
    当該ノードグループを構成する2つ以上のノードが有する2つ以上のDBMSが、当該2つ以上のノードが提供する2つ以上の記憶領域に同一のデータベースを格納し、
    当該ノードグループ内のデータベースからのデータ検索は、当該ノードグループ内の1つ以上の第2のDBMSにより実行される、
    データベースシステム。
  2. 各ノードグループにおいて、第2のノードは、当該ノードグループに属する少なくとも1つの第2のノードの負荷状況に基づいてスケールし、
    ノードグループは、全ての第1の記憶領域に格納されたデータベースの総量に基づいてスケールする、
    請求項1に記載のデータベースシステム。
  3. 第1の記憶領域は、データの永続性を保証する記憶装置に基づく記憶領域であり、
    第2の記憶領域は、前記第1の記憶領域の基になっている記憶装置よりも高速な記憶装置に基づく記憶領域である、
    請求項1に記載のデータベースシステム。
  4. 各DBMSが、データベースにおけるデータの記憶位置を表すデータ管理情報を管理し、
    所定の第1のDBMSが、クエリソースから検索クエリを受け付けるようになっており、
    前記所定の第1のDBMSが、検索クエリを受け付けた場合、当該検索クエリに基づく1つ以上の検索クエリを、当該所定の第1のDBMSと同一ノードグループ内の1つ以上の第2のDBMSにそれぞれ送信し、
    前記所定の第1のDBMSから検索クエリを受けた第2のDBMSが、
    当該第2のDBMSが管理するデータ管理情報を基に、当該検索クエリに基づきアクセスされるデータの全てが、当該第2のDBMSを実行する第2のノードが提供する第2の記憶領域内のデータベースに存在するか否かのデータ位置判定を行い、
    当該データ位置判定の結果が真の場合、当該第2のDBMSを実行する第2のノードが提供する第2の記憶領域内のデータベースに対してデータ検索を実行し、
    当該データ位置判定の結果が偽の場合、アクセスされるデータからのデータ検索のための1つ以上の検索クエリを、当該アクセスされるデータの少なくとも一部が存在する1つ以上のノードグループへ送信する、
    請求項1に記載のデータベースシステム。
  5. 前記所定の第1のDBMSは、最新のノードグループ内の第1のノードであるカレントの第1のノード内のDBMSである、
    請求項4に記載のデータベースシステム。
  6. 前記所定の第1のDBMSが、データベースのデータの追加要求を受け付けるようになっており、
    前記カレントの第1のノードが提供する第1の記憶領域の空き領域が不足していることを意味する条件が満たされていると前記所定の第1のDBMSが判定した場合、ノードグループが新たに追加され、新たに追加されたノードグループ内の第1のノードが、前記カレントの第1のノードに代わって新たにカレントの第1のノードとなる、
    請求項5に記載のデータベースシステム。
  7. 前記所定の第1のDBMSが受けた追加要求に応答して最新のノードグループ内のデータベースにデータが追加された場合、当該所定の第1のDBMSが、当該所定の第1のDBMSが管理するデータ管理情報を更新し、当該更新と同期的に、当該更新後のデータ管理情報が、前記カレントの第1のノード以外の各ノードにおけるDBMSが管理するデータ管理情報に反映される、
    請求項6に記載のデータベースシステム。
  8. 前記所定の第1のDBMSから少なくとも1つの第2のDBMSへの検索クエリには、前記クエリソースを表す情報であるクエリソース情報が関連付けられており、
    前記クエリソースから発行された検索クエリについて、2つ以上の第2のDBMSがそれぞれデータ検索を行った場合、当該2つ以上の第2のDBMSがそれぞれ行ったデータ検索の結果をいずれかの第2のDBMSがマージして前記クエリソース情報が表すクエリソースに返す、
    請求項4に記載のデータベースシステム。
  9. 前記クエリソースから検索クエリを受けた前記所定の第1のDBMSが、当該検索クエリのクエリプランを作成し、当該作成したクエリプランに基づく1つ以上のクエリプランをそれぞれ関連付けた1つ以上の検索クエリを、当該所定の第1のDBMSと同一ノードグループ内の1つ以上の第2のDBMSにそれぞれ送信し、
    検索クエリを受けた第2のDBMSが、当該検索クエリに関連付いているクエリプランに従いデータ検索を行う、
    請求項4に記載のデータベースシステム。
  10. 検索クエリを受けた第2のDBMSが、当該検索クエリのクエリプランを作成し、当該作成したクエリプランに従いデータ検索を行う、
    請求項4に記載のデータベースシステム。
  11. 前記所定の第1のDBMSが、前記クエリソースからの検索クエリを基に2つ以上の検索クエリを生成し、当該2つ以上の検索クエリを、当該所定の第1のDBMSと同一ノードグループ内の2つ以上の第2のDBMSにそれぞれ送信する、
    請求項4に記載のデータベースシステム。
  12. 前記所定の第1のDBMSから同一ノードグループ内の第2のDBMSが受けた検索クエリに従いアクセスされるデータの全てが、当該第2のDBMSを実行する第2のノードが提供する第2の記憶領域内のデータベースに無い場合、当該第2のDBMSから検索クエリを受けた別ノードグループ内の第2のDBMSが、当該検索クエリの実行結果を前記クエリソースに応答する、
    請求項4に記載のデータベースシステム。
  13. 前記所定の第1のDBMSから検索クエリを受けた第2のDBMSが、前記データ位置判定の結果が偽の場合、
    当該アクセスされるデータの少なくとも一部が存在する1つ以上のノードグループの各々における第1のDBMSに、当該第1のDBMSと同一ノードグループ内の第2のノードを問い合わせ、
    当該1つ以上のノードグループの各々について、問合せに応答して、問合せ先の第1のDBMSにより選択された1つ以上の第2のノードを表す第2ノード情報を受け、
    当該1つ以上のノードグループの各々について、受けた第2ノード情報から特定される1つ以上の第2のノードの各々に、当該第2のDBMSが受けた当該検索クエリに基づく1つ以上の検索クエリをそれぞれ送信する、
    請求項4に記載のデータベースシステム。
  14. 複数の計算リソースを含む計算機システムに基づく仮想環境に1つ又は複数のノードグループを構築し、
    各ノードグループが、第1のノードと1つ以上の第2のノードとを含み、
    第1のノードは、第1の記憶領域を提供し第1のDBMSを実行する論理計算機であり、
    第2のノードは、第2の記憶領域を提供し第2のDBMSを実行する論理計算機であり、
    構築されたノードグループにおいて、2つ以上のノードが提供する2つ以上の記憶領域に同一のデータベースを格納し、
    クエリソースから第1のDBMSにより検索クエリを受け付け、
    当該第1のDBMSにより、当該検索クエリに基づく1つ以上の検索クエリを1つ以上の第2のDBMSに送信し、
    各ノードグループについて、当該ノードグループ内のデータベースが検索対象の場合、当該データベースからのデータ検索を、当該ノードグループ内の1つ以上の第2のDBMSにより実行する、
    クエリ実行方法。
JP2020179852A 2020-10-27 2020-10-27 データベースシステム、及びクエリ実行方法 Active JP7458610B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2020179852A JP7458610B2 (ja) 2020-10-27 2020-10-27 データベースシステム、及びクエリ実行方法
US17/471,267 US11709839B2 (en) 2020-10-27 2021-09-10 Database system and query execution method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020179852A JP7458610B2 (ja) 2020-10-27 2020-10-27 データベースシステム、及びクエリ実行方法

Publications (2)

Publication Number Publication Date
JP2022070669A JP2022070669A (ja) 2022-05-13
JP7458610B2 true JP7458610B2 (ja) 2024-04-01

Family

ID=81257060

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020179852A Active JP7458610B2 (ja) 2020-10-27 2020-10-27 データベースシステム、及びクエリ実行方法

Country Status (2)

Country Link
US (1) US11709839B2 (ja)
JP (1) JP7458610B2 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014501416A (ja) 2010-12-30 2014-01-20 フェイスブック,インク. グラフ・データの分散キャッシュ

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7177917B2 (en) * 2000-12-27 2007-02-13 Softwired Ag Scaleable message system
WO2007148300A2 (en) * 2006-06-20 2007-12-27 Gal Zuckerman Methods and systems for push-to-storage
US8554951B2 (en) * 2011-03-08 2013-10-08 Rackspace Us, Inc. Synchronization and ordering of multiple accessess in a distributed system
US8965921B2 (en) * 2012-06-06 2015-02-24 Rackspace Us, Inc. Data management and indexing across a distributed database
US9501501B2 (en) * 2013-03-15 2016-11-22 Amazon Technologies, Inc. Log record management
US20160048633A1 (en) * 2013-03-15 2016-02-18 Cypher Genomics, Inc. Systems and methods for genomic variant annotation
US20150286748A1 (en) * 2014-04-08 2015-10-08 RedPoint Global Inc. Data Transformation System and Method
US11443390B1 (en) * 2015-11-06 2022-09-13 Addepar, Inc. Systems and user interfaces for dynamic and interactive table generation and editing based on automatic traversal of complex data structures and incorporation of metadata mapped to the complex data structures
US11593377B2 (en) * 2016-09-26 2023-02-28 Splunk Inc. Assigning processing tasks in a data intake and query system
US11442935B2 (en) * 2016-09-26 2022-09-13 Splunk Inc. Determining a record generation estimate of a processing task
US10353965B2 (en) * 2016-09-26 2019-07-16 Splunk Inc. Data fabric service system architecture
US11604795B2 (en) * 2016-09-26 2023-03-14 Splunk Inc. Distributing partial results from an external data system between worker nodes
US11580107B2 (en) * 2016-09-26 2023-02-14 Splunk Inc. Bucket data distribution for exporting data to worker nodes
US20180260190A1 (en) * 2017-03-10 2018-09-13 Microsoft Technology Licensing, Llc Split and merge graphs
US10698897B2 (en) * 2017-09-25 2020-06-30 Splunk Inc. Executing a distributed execution model with untrusted commands

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014501416A (ja) 2010-12-30 2014-01-20 フェイスブック,インク. グラフ・データの分散キャッシュ

Also Published As

Publication number Publication date
US20220129453A1 (en) 2022-04-28
US11709839B2 (en) 2023-07-25
JP2022070669A (ja) 2022-05-13

Similar Documents

Publication Publication Date Title
US11153380B2 (en) Continuous backup of data in a distributed data store
US10579610B2 (en) Replicated database startup for common database storage
US10929428B1 (en) Adaptive database replication for database copies
US9946735B2 (en) Index structure navigation using page versions for read-only nodes
US10853242B2 (en) Deduplication and garbage collection across logical databases
US9251003B1 (en) Database cache survivability across database failures
US11080253B1 (en) Dynamic splitting of contentious index data pages
US20220114064A1 (en) Online restore for database engines
US10642837B2 (en) Relocating derived cache during data rebalance to maintain application performance
US10885023B1 (en) Asynchronous processing for synchronous requests in a database
JP2004070403A (ja) ファイル格納先ボリューム制御方法
US10909143B1 (en) Shared pages for database copies
US11347647B2 (en) Adaptive cache commit delay for write aggregation
US11755557B2 (en) Flat object storage namespace in an object storage system
US11741144B2 (en) Direct storage loading for adding data to a database
Cao et al. Is-hbase: An in-storage computing optimized hbase with i/o offloading and self-adaptive caching in compute-storage disaggregated infrastructure
US20170206027A1 (en) Management system and management method of computer system
WO2019026222A1 (ja) ストレージシステム及びデータ転送制御方法
EP4016312B1 (en) Data operations using a cache table in a file system
JP7458610B2 (ja) データベースシステム、及びクエリ実行方法
US9870152B2 (en) Management system and management method for managing data units constituting schemas of a database
CN113051244A (zh) 数据访问方法和装置、数据获取方法和装置
US20230262127A1 (en) Volume Placement Based on Resource Usage
US20220413940A1 (en) Cluster computing system and operating method thereof
US11914571B1 (en) Optimistic concurrency for a multi-writer database

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230224

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20240124

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: 20240227

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240311

R150 Certificate of patent or registration of utility model

Ref document number: 7458610

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150