JP5146440B2

JP5146440B2 - 無共有型データベース管理システム

Info

Publication number: JP5146440B2
Application number: JP2009254559A
Authority: JP
Inventors: 大輔伊藤; 一智牛嶋; マシエル・フレデリコ; 真二藤原
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2009-11-06
Filing date: 2009-11-06
Publication date: 2013-02-20
Anticipated expiration: 2024-01-09
Also published as: JP2010033599A

Description

本発明はデータベース管理システムを構成する各データベースサーバ間で処理対象データの共有を行わない無共有型データベース管理システムに関する。

＜背景の説明、用語の定義＞
「無共有型データベース管理システム」
無共有型データベース管理システムは、複数データベースサーバからなる大規模データベースシステムの構成法の一つである。無共有型データベース管理システムでは、計算機の主要要素であるプロセッサ、メモリおよびストレージが、各データベースサーバごとに割り当てられ、ネットワーク以外の構成要素を共有しない。データベースを構成するデータも各データベースサーバごとに分配され、その割り当てストレージに格納される。よって各データベースサーバは、データベースの互いに素な部分集合を処理対象データとして担当し、部分集合ごとに処理を行うことになる。

このような構成の特徴から、無共有型データベース管理システムは共有資源に対する排他制御処理を必要とせず、データベースサーバ数の増加に対するスケーラビリティが高いという長所を持つ。しかし、システムの構成変更などの原因により、各データベースサーバ間で扱うデータ量の不均衡が生じると、データ量の多いデータベースサーバの実行時間が相対的に長くなり、クエリ全体の処理が効率的に行われなくなる。そのため、無共有型データベースシステムでは、データベースサーバ数を変更する際に、あわせてデータベースサーバ間の扱うデータの均衡を取るために、データのサーバへの割り当ての変更を行う必要が生じるという短所を持つ。

「データベースサーバのリソース」
無共有データベース管理システムに新たなデータベースサーバを追加する際には、一般的に新規サーバマシンを追加し、新規サーバマシン上でデータベースサーバを実行する。新規サーバマシンを追加したことで、データベースサーバを実行するための資源が増加し、性能向上に繋がる。本発明では、前記資源のうち、演算能力向上にかかわるものを「ＣＰＵリソース」と呼ぶ事とする。また、ストレージ入出力性能向上にかかわるものを「ストレージＩ／Ｏリソース」と呼ぶ事とする。

「データ再配置」
前記のとおり、無共有型データベース管理システムにデータベースサーバを新規に追加する際や、無共有型データベース管理システムからデータベースサーバを取り外す際には、データベースサーバ間でのデータの均衡を取る必要がある。本発明では、この操作を以下「データの再配置」と呼ぶこととする。

「ストレージ仮想化」
ストレージ仮想化は、ネットワーク上のストレージの使いやすさを向上させる手段の一つである。ネットワーク上に複数台のストレージが存在し、それらを単一のサーバから使用する際に、あたかも単一のストレージを使用しているように見せることで、運用管理も一つに統合でき、管理コストの低減に繋がる。本発明では、ストレージ仮想化を行う場所を「（ストレージ）仮想化層」と呼ぶ。ストレージ仮想化層は一般にストレージ上、ストレージ管理ミドルウエア、ファイルシステム上に存在する。オペレーティングシステムはストレージをボリューム単位で管理する。そこで、本発明では、仮想化されたストレージを「論理ボリューム」と呼ぶ。また、論理ボリュームを構成する個々のストレージを「単位ボリューム」と呼ぶ。

＜従来手法の説明＞
従来の手法としては、ＤＢ２バージョン７．２添付のオンラインマニュアル「管理者の手引き第３０章」に記載のＡＬＴＥＲＮＯＤＥＧＲＯＵＰステートメントを使用する手法がある。この手法では、図２(a)に示すように新規データベースサーバの追加を行う際には、新規データベースサーバの割り当てストレージにデータ領域を追加し（２１）、複数データベースサーバからなる無共有型データベース管理システムに新規データベースサーバを追加（２２）した後に、データ量の均衡を取るためにデータベースサーバ間でデータの再配置を行う（２３）となっていた。また、図２(b)に示すデータベースサーバの取り外しを行う際には、データの再配置を行い取り外し対象データベースサーバのデータ領域を空にし（２４）、その後データベースサーバの取り外しを行う（２５）となっていた。

また、これ以外の従来の手法としては、特開平11-282734号公報に記載した並列データベース管理方法があげられる。この手法では、オンライン業務を中断することなくデータベースとデータベース処理装置との対応付けを変更する事で、複数のデータベース処理装置で管理しているデータベースを特定のデータベース処理装置から直接アクセスすることができる。また、この手法はデータベースの分割数は不変である事を特徴とする。

特開平11-282734号公報

前記従来技術は無共有型データベース管理システムにおいて頻繁にデータベースサーバの追加や取り外しが起こる場合への配慮がされておらず、長時間を要するデータ再配置を行わないとデータベースサーバの追加や取り外しが行えないという問題があった。さらにデータ再配置は負荷の高い処理であるため、単純に実行した場合、ユーザやアプリケーションからの表へのアクセス処理性能が低下する。よって負荷に応じてサーバ数を変更可能なシステムに応用した際に、サーバの追加が遅延を生じることなく処理性能の向上に反映されず、むしろ処理性能の低下を招く要因となりうるという問題があった。また、サーバの取り外しを決定してからデータ再配置を行うため、実際にサーバが取り外せるまでに遅延があるという問題があった。

また、特願平10-81097号公報に記載された方法では、データベースとデータベース処理装置の対応付けを変換することで負荷分散の是正を行う場合、データベースの分割数が不変であるため、データベース処理装置間の負荷を均衡化するのが難しい。この手法でも予めデータベースを細かく分割することで、負荷を均衡化することは可能であるが、その場合にはデータベースが大量に作成され、バキュームやバックアップといった運用管理面のコストが増大してしまう。本発明の目的は、ユーザやアプリケーションからの表へのアクセス処理性能に与える影響の少ないデータベースサーバの追加方法、および取り外し方法を提供することにある。

本発明の無共有型データベース管理システムは、データの探索、演算を行う複数のバックエンドモジュールと、それぞれがデータベースを構成するデータの細分化された一部を格納する複数の単位ボリュームを含み、複数のバックエンドモジュールから共有される共有ストレージと、各々が複数のバックエンドモジュールのいずれか一つからアクセス可能な複数の仮想ボリュームに単位ボリュームの少なくとも一つを重複しないように対応付け、複数の単位ボリュームの各々が複数のバックエンドモジュールのいずれか一つからアクセスされるように単位ボリュームと仮想ボリュームとを関連付けるストレージ仮想化手段と、単位ボリュームに保持されたデータとバックエンドモジュールとの対応関係を保持した対応表を管理するマッピングモジュールと、データベースへの問い合わせを受け付け、マッピングモジュールマッピング情報を参照してバックエンドモジュールに向けた問い合わせのプランを作成するフロントエンドモジュールとを有し、単位ボリュームと仮想ボリュームとの関連づけを変更することによりバックエンドモジュールへの割り当てデータ領域を変更するようにしたことを特徴とする。

本発明によれば、無共有型データベース管理システムのデータベースサーバリソースの追加および取り外し処理に伴うデータ再配置をストレージ仮想化層と組み合わせる事で、データの移動を仮想ボリュームの更新に置き換え、物理的なデータ移動を伴わないデータ再配置が可能であり、サーバの稼働率を高めることが可能な無共有型データベース管理システムを実現できる。

また、データエリアを共有ディスク上で予め細分化しておく手法を取ることで、ＣＰＵリソースとストレージＩ／Ｏを遅延を生じることなく追加および取り外し可能であり、さらにデータ再配置と要った余計な負荷を生じないことから、先の場合と同様にデータベースサーバの負荷に応じて新規サーバの追加および取り外しを決定する際の負荷の閾値を高く設定でき、サーバの稼働率の向上やプールサーバの台数を減らすといった効果がある。

本発明の実施例の無共有型データベース管理システムの概略を示すブロック図である。従来手法によるデータベースサーバの追加および取り外しのフローチャートである。上記実施例のバックエンドモジュール当た当たり１つのデータ領域を割り当てた際の構成図である。上記実施例当たサーバの追加の手順を示すフローチャートである。上記実施例当たサーバの取り外しの手順うを示すフローチャートである。共有ストレージ上に細分化されたデータ領域を用いた本発明の別の実施例のバックエンドモジュールの構成図である。上記実施例におけるハッシュ−モジュールＩＤ対応表のデータ構造図である。上記実施例のサーバの追加の手順を示すフローチャートである。上記実施例のサーバの取り外しの手順を示すフローチャートである。共有ストレージ上の仮想化層を用いた本発明の更に別の実施例の構成図である。ストレージ管理ミドルウエア上の仮想化層を用いた本発明の更に別の実施例の構成図である。共有ファイルシステム上の仮想化層を用いた本発明の更に別の実施例の構成図である。データベース管理システム上の仮想化層を用いた本発明の更に別の実施例の構成図である。

以下、本発明の実施例を図１により説明する。

本実施例における無共有型データベース管理システム（１）は、主にユーザインターフェースとなるフロントエンドモジュール（２）、データの探索や演算を行うバックエンドモジュール（３）、データベースサーバの追加および取り外し操作のスケジュールを作成するスケジューラモジュール（４）、データベースサーバの負荷を監視するサーバ監視モジュール（５）、複数のバックエンドモジュール間で共有される共有ストレージ（６）、およびバックエンドモジュールと共有ストレージの間のマッピングを管理するマッピングモジュール（７）を有する。

また、バックエンドモジュールを論理的に現用サーバ群（８）およびプールサーバ群（９）に分割して管理する。フロントエンドモジュール（２）はユーザ又はプログラムからの問合せを受け付け、複数のデータベースサーバに向けた問合せのプランを作成し、結果を返すモジュールである。本実施例においては現用サーバ群の構成が動的に変更されるため、フロントエンドモジュールもそれに対応して、現用サーバ群の構成に沿った問合せを発行する機能を持つ。

バックエンドモジュール（３）はデータベースサーバ上で動作し、ストレージ上のデータの探索を行い、その結果の演算を行うモジュールである。本実施例ではサーバ１台当たりバックエンドモジュールが１つ起動する。詳細構造は後述する。スケジューラモジュール（４）はデータベースサーバの追加および取り外し操作のスケジュールを作成するモジュールである。スケジューラモジュールの作成したスケジュールに従い、サーバ監視モジュールがバックエンドモジュールに指示を出す。サーバ監視モジュール（５）は各データベースサーバのＣＰＵ負荷を監視し、さらにデータベースサーバの追加および取り外し処理のコーディネータとなる。データベースサーバへのストレージ資源の割り当てはマッピングモジュールに委譲する。

共有ストレージ（６）はストレージ専用ネットワーク上に論理的に構成される。各バックエンドモジュールに対しては、専用のデータ領域が共有ストレージ上に確保されるため、各バックエンドモジュール間でのリソース競合は起こらない。マッピングモジュール（７）は、サーバ監視モジュールから依頼を受けて、バックエンドモジュールと共有ストレージ上のストレージ領域を結びつける。

これら２〜５および７の各モジュール間の通信は非同期に行われる。本実施例ではキューを用いた非同期通信を行う。キューは通信に優先度をつけるために二本用意し、通常用いるキューと、優先度の高い特別なキューとする。

現用サーバ群（８）は複数台のデータベースサーバのうち、現在データ処理にかかわっているサーバの集合をあらわし、プールサーバ群（９）は現在データ処理にかかわっておらず、システム全体が高負荷状態となった時の予備サーバの集合をあらわす。なお、プールサーバ群は複数の無共有型データベース管理システム間で共有することができる。この手法はサーバの稼働率を高める上で有効である。

「バックエンドモジュール当たり１つのデータ領域を割り当てた際のバックエンドモジュールの構成」
図３はバックエンドモジュール当たり１つのデータ領域を割り当てた際のバックエンドモジュールの構成を示す。バックエンドモジュール（３１）は共有ストレージ（３２）上の一つのデータ領域（３３）と結び付けられる。また、この構成の元ではデータ領域に割り当てられていないバックエンドモジュール（３４）を考える。バックエンドモジュール（３１）は、マッピングモジュールによって、共有ストレージ上の共有データ領域を割り当てられる。各バックエンドモジュールは割り当てられたデータ領域上に処理対象データを格納し、探索を行う。また、ソートやマージといったデータ演算も行う。これは複数のバックエンドモジュールでデータをやり取りしながら行うこともある。

データ領域（３３）には主にデータベースの互いに疎な部分集合が格納される。また、データ演算の中間結果やデータ操作の履歴なども格納される。データ領域を持たないバックエンドモジュール（３４）はデータの探索は行わず、ＣＰＵ負荷の高いソートやマージといった操作専用に設定される。操作対象のデータはネットワーク経由で他のバックエンドモジュールから転送される。データ領域を持たないバックエンドモジュールは、現用サーバ群に対してＣＰＵリソースのみを提供する。一方、３１に示される通常のバックエンドモジュールはＣＰＵリソースとストレージＩ／Ｏを共に提供する。

＜バックエンドモジュール当たり１つのデータ領域を割り当てた際の動作の説明＞
「サーバの追加」
前記サーバ監視モジュールが高負荷を検出することで、サーバの追加処理が開始され、スケジューラモジュール（４）によって図４に示す処理フローが作成される。処理フローにおいて、まず新規追加サーバが準備される（４１）。ここではプールサーバ群の中から適当なサーバを選び、現用サーバ群の構成情報が伝えられる。

次に準備されたサーバがプールサーバ群から現用サーバ群に追加される（４２）。ここではデータ領域を持たないバックエンドモジュール（３４）としてサーバを追加するため、データの移動を伴わない。そのため、従来手法を用いた場合と比較して極めて迅速に行われる。４２おいてデータ領域を持たないバックエンドモジュールを追加したことによって、現用サーバ群の負荷が低下する。負荷の低下速度および過去の統計情報から、今回検出された高負荷が一過性のものか、それとも長期に及ぶ現用サーバ群のリソース不足を意味するものか判断する（４３）。

現用サーバ群のリソース不足を意味するのならば、４２において追加されたデータ領域を持たないバックエンドモジュールにもデータ領域を割り当てることで、ストレージＩ／Ｏもあわせて追加する事が望ましい。しかし前述したようにデータ再配置は負荷の高い操作である。そこで現用サーバ群の負荷が十分に下がるまで待機する（４４）。そして負荷の低下後にデータ再配置を行う（４５）。

一方、４３において現用サーバ群の高負荷が一過性のものと判断された場合は、今回追加したデータ領域を持たないバックエンドモジュールが動作するサーバをプールサーバ群に戻す。この場合は負荷が十分に下がるまで待機（４６）した後に、４２で追加したデータ領域を持たないバックエンドモジュールの取り外しを行い、該当サーバをプールサーバ群に戻す（４７）。これは、プールサーバ群を複数のデータベース管理システム間で共有する際に、総プールサーバの台数を減少させ、サーバの実稼働率を高める。なお、現用サーバ群の構成変更（４２）を行う際にはトランザクションのＡＣＩＤ特性を保証する必要がある。本実施例のデータベース管理システムでは新規トランザクションを開始することなく現在実行中のトランザクションの終了を待ち、その後全てのバックエンドモジュール間で同期を取って構成変更を行う事でＡＣＩＤ特性を保証する。

「サーバの取り外し」
前記サーバ監視モジュールが低負荷を検出することで、サーバの取り外し処理が開始され、スケジューラモジュール（４）によって図５に示す処理フローが作成される。

処理フローにおいて、まず現用サーバ群の構成変更が行われる（５１）。ここでは現用サーバ群から任意のデータベースサーバと共にそのサーバ上で実行していたバックエンドモジュールが取り外され、該当データ領域が他のバックエンドモジュール（５１−Ａ）に割り当てられる。この操作はデータの不均衡を招く。また、取り外されたデータベースサーバは、サーバの実稼働率を高めるためにプールサーバ群に戻される。次にデータ再配置が行われる（５２）。ここでのデータ再配置は、５１で他のバックエンドモジュール（５１−Ａ）に割り当てられたデータ領域を空にすることが目的である。この操作によって、現用サーバ群の割り当てデータ量は実質的に均衡化される。なお、図５に示される処理フローは現用サーバ群が低負荷の状態で行われるため、データ再配置に伴う負荷上昇の影響は問題とならない。データ再配置完了後、５２で空になったデータ領域が完全に削除される（５３）。

「共有ストレージ上に細分化されたデータ領域を用いたバックエンドモジュールの構成」
図６は本発明の別の実施例の構成を示す。図６にはバックエンドモジュールと共有ストレージ内の各領域との関係のみ示すが、データベース管理システム全体の構成要素は図１に示す先の実施例と同様であるので図中で省略している。本実施例では、共有ストレージ６２のデータ領域６３は、そのデータの探索処理、演算処理を担当するバックエンドモジュール６１に対応してではなく、より小さな単位に細分化されている。細分化は、例えば領域識別子のハッシュ値を用いたハッシュ分割法による。ただし、各バックエンドモジュールへのデータ領域の割り当てがハッシュ値によって直接定まるのではなく、ハッシュ値と担当するバックエンドモジュールとの対応関係を記録・管理するハッシュ値・モジュールＩＤ対応表によって定める。この構成により、バックエンドモジュールの追加投入もしくは削減の時に必要となるデータ領域の割り当て変更は、上記のハッシュ値・モジュールＩＤ対応表を更新するのみで可能となる。この割り当ての変更は、データの実移動を伴わないため、瞬時に行うことが可能である。したがって、バックエンドモジュールの追加もしくは削除に際し、データベース管理システム本来のアクセス処理の性能低下が先の実施例に増して回避可能である。

また、データ領域が属するバックエンドモジュールが変更した際にフロントエンドモジュールがクエリを適切なバックエンドモジュールに転送できるように、図７に上記のハッシュ−モジュールＩＤ対応表の例を示す。データ領域の識別子のハッシュ値７１のそれぞれに対応してバックエンドモジュールＩＤ７３が設定される。その設定は、バックエンドモジュール間で担当するデータ領域の合計データ量もしくはデータアクセスの頻度ができるだけ均等になるように分散すれば良い。このハッシュ−モジュールＩＤ対応表はマッピングモジュール（図１を参照）で管理する。フロントエンドモジュールはスケジュールを立てる際に、マッピングモジュールに問合せを行い、適切なバックエンドモジュールを選択する。

＜共有ストレージ上に細分化されたデータ領域を用いた際の動作の説明＞
「サーバの追加」
前記サーバ監視モジュールが高負荷を検出することで、サーバの追加処理が開始され、スケジューラモジュール（４）によって図８に示す処理フローが作成される。

処理フローにおいて、まず新規追加サーバが準備される（８１）。ここでも４１と同様に、プールサーバ群の中から適当なサーバを選び、現用サーバ群の構成情報が伝えられる。次に現用サーバ群の構成が変更される（８２）。ここでは８１で準備したサーバが追加され、バックエンドモジュールが追加される。さらに全バックエンドモジュール間の割り当てデータ量を均衡化するために、割り当てデータ領域が変更される。前記のように、割り当てデータ領域の変更は瞬時に行われる。

「サーバの取り外し」
前記サーバ監視モジュールが低負荷を検出することで、サーバの追加処理が開始され、スケジューラモジュール（４）によって図９に示す処理フローが作成される。

処理フローにおいて、現用サーバ群の構成が変更される（９１）。ここでは適当なバックエンドモジュールが取り外され、該当サーバがプールサーバ群に戻される。さらに全バックエンドモジュール間の割り当てデータ量を均衡化するために、割り当てデータ領域が変更される。前記のように、割り当てデータ領域の変更は瞬時に行われる。

「共有ストレージ上の仮想化層を用いた際の動作の説明」
図１０は共有ストレージ上のストレージ仮想化層（１０３）によって仮想化された仮想ボリュームを用いる実施例の構成を示す。複数のバックエンドモジュール１０１は各々データ探索及び、データ演算を行う。そのデータ探索の対象は各々の仮想ボリューム１０５である。共有ストレージ１０２に設けられたストレージ仮想化層１０３によって、共有ストレージ上の複数の単位ボリューム１０６が仮想ボリューム１０５に関連付けられる。関連付けにはマップ１０Ａを用いる。ここでもバックエンドモジュール間のデータ配分にはハッシュ分割法を用いる。即ち、バックエンドモジュールが扱うデータ識別子のハッシュ値が等しいデータは同一データグループ１０７に属するデータと見なされる。また、それらのデータグループはそれぞれ単位ボリューム１０６に重複なく配置される。バックエンドモジュールを新たに追加したとき、もしくは削除したときに生じるデータ移動の最小単位は上記のデータグループである。

本実施例の場合、データグループ単位のデータの移動（１０８）はデータベース内で対応する単位ボリューム（１０６）の移動に置換可能である。置換後、ストレージ上のストレージ仮想化層（１０３）に渡され、ストレージ仮想化層ではデータの移動（１０８）に対応する（１０９）ように、マップ（１０Ａ）の書き換えを行う。このように、ストレージ仮想化層（１０３）を用いることで物理的な移動を伴わないデータの移動が実現される。

「ストレージ管理ミドルウエア上の仮想化層を用いた際の動作の説明」
図１１において、１１１はストレージ管理ミドルウエア上のストレージ仮想化層（１１３）によって仮想化されたストレージ（１１５）を用いた際のバックエンドモジュールである。ストレージ管理ミドルウエアは、バックエンドモジュール（１１１）と共有ストレージ（１１２）の間に入り、バックエンドモジュール毎のデータ領域割り当てを管理し仮想ボリューム（１１５）を割り当てる。データ領域割り当ては共有ストレージ（１１２）上の単位ボリューム（１１６）と仮想ボリューム（１１５）の関連付けとして実現する。関連付けにはマップ（１１Ａ）を用いる。ここでもバックエンドモジュール間のデータ配分にはハッシュ分割法を用いる。さらに、ハッシュ値が等しい物を同一データグループ（１１７）内に配置する事とし、データ移動の最小単位とする。また、データグループはそれぞれ単位ボリューム（１１６）に重複なく配置される。

本実施例の場合も、データグループ単位のデータの移動（１１８）はデータベース内で対応する単位ボリューム（１１６）の移動に置換可能である。置換後、ストレージ管理ミドルウエア上のストレージ仮想化層（１１３）に渡され、ストレージ仮想化層ではデータの移動（１１８）に対応する（１１９）ように、マップ（１１Ａ）の書き換えを行う。このように、ストレージ管理ミドルウエア上のストレージ仮想化層（１１３）を用いることで物理的な移動を伴わないデータの移動が実現される。

「共有ファイルシステム上の仮想化層を用いた際の動作の説明」
図１２において、１２１は共有ファイルシステム上のストレージ仮想化層（１２３）によって仮想化されたストレージ（１２５）を用いた際のバックエンドモジュールである。ここではファイルシステムとして、ＮＦＳのようなサーバ−クライアント型のファイルシステムを想定している。ファイルシステムは、バックエンドモジュール（１２１）と共有ストレージ（１２２）の間に入り、バックエンドモジュール毎のデータ領域割り当てを管理し仮想ボリューム（１２５）を割り当てる。データ領域割り当ては共有ストレージ（１２５）上の単位ボリューム（１２６）と仮想ボリューム（１２５）の関連付けとして実現する。関連付けにはファイルサーバ上のマップ（１２Ａ）を用いる。ここでもバックエンドモジュール間のデータ配分にはハッシュ分割法を用いる。さらに、ハッシュ値が等しい物を同一データグループ（１２７）内に配置する事とし、データ移動の最小単位とする。また、データグループはそれぞれ単位ボリューム（１２６）に重複なく配置される。

本実施例の場合も、データグループ単位のデータの移動（１２８）はデータベース内で対応する単位ボリューム（１２６）の移動に置換可能である。置換後、ファイルシステム上のストレージ仮想化層（１２３）に渡され、ストレージ仮想化層ではデータの移動（１２８）に対応する（１２９）ように、マップ（１２Ａ）の書き換えを行う。このように、ファイルシステム上のストレージ仮想化層（１２３）を用いることで物理的な移動を伴わないデータの移動が実現される。

「データベース管理システム上の仮想化層を用いた際の動作の説明」
図１３において、１３１はデータベース管理システムに内蔵されたストレージ仮想化層（１３３）によって仮想化されたストレージ（１３４）上の仮想ボリューム（１３５）を用いた際のバックエンドモジュールである。ストレージ仮想化層によって、共有ストレージ上の共有ストレージ（１３２）上の複数の単位ボリューム（１３６）が仮想ボリュームに関連付けられる。関連付けにはマップ管理モジュール（１３Ｂ）上のマップ（１３Ａ）を用いる。ここでもバックエンドモジュール間のデータ配分にはハッシュ分割法を用いる。さらに、ハッシュ値が等しい物を同一データグループ（１３７）内に配置する事とし、データ移動の最小単位とする。また、データグループはそれぞれ単位ボリューム（１３６）に重複なく配置される。

本実施例の場合も、データグループ単位のデータの移動（１３８）はデータベース内で対応する単位ボリューム（１３６）の移動に置換可能である。置換後、ストレージ仮想化層（１３３）に渡され、ストレージ仮想化層ではデータの移動（１３８）に対応する（１３９）ように、マップ（１３Ａ）の書き換えを行う。このように、ストレージ管理ミドルウエア上のストレージ仮想化層（１３３）を用いることで物理的な移動を伴わないデータの移動が実現される。

本発明によれば、無共有型データベース管理システムのデータベースサーバリソースの追加および取り外し処理に伴うデータ再配置を低負荷時にずらして行う事で処理に伴う負荷の上昇を避けることができるので、データベースサーバの負荷に応じてサーバの追加および取り外しを決定する際の負荷の閾値を高く設定でき、サーバの稼働率の向上やプールサーバの台数を減らすといった効果がある。

さらに、ストレージ仮想化層と組み合わせる事で、データの移動を仮想ボリュームの更新に置き換え、物理的なデータ移動を伴わないデータ再配置も可能であり、サーバの稼働率をさらに高めることが可能である。

１．無共有型データベース管理システム
２．フロントエンドモジュール
３．バックエンドモジュール
４．スケジューラモジュール
５．サーバ監視モジュール
６．共有ストレージ
７．マッピングモジュール
８．現用サーバ群
９．プールサーバ群。

Claims

データベース管理システムであって、
データの探索、演算を行う複数のバックエンドモジュールと、
それぞれがデータベースを構成するデータのハッシュ分割法によって細分化された一部を格納し前記バックエンドモジュールの数よりも多い数の複数の単位ボリュームを含み、前記複数のバックエンドモジュールから共有される共有ストレージと、
各々が前記複数のバックエンドモジュールのいずれか一つからアクセス可能な複数の仮想ボリュームに前記単位ボリュームの少なくとも一つを重複しないように対応付け、前記複数の単位ボリュームの各々が前記複数のバックエンドモジュールのいずれか一つからアクセスされるように前記複数の単位ボリュームと前記複数の仮想ボリュームとを関連付けるストレージ仮想化手段と、
前記複数の単位ボリュームに保持されたデータの識別子であるハッシュ値と前記複数のバックエンドモジュールとの対応関係を保持した対応表を管理するマッピングモジュールと、
前記データベースへの問い合わせを受け付け、前記マッピングモジュールにおける前記対応表を参照して前記複数のバックエンドモジュールに向けた問い合わせのプランを作成するフロントエンドモジュールと、を有し、
前記データベース管理システムに前記バックエンドモジュールの追加又は取り外しを行う場合、前記マッピングモジュールが前記対応表における前記ハッシュ値と前記バックエンドモジュールとの関連づけを変更することにより前記複数のバックエンドモジュールへの割り当てデータを前記単位ボリューム単位で変更することを特徴とするデータベース管理システム。