JP2007317138A - データ記憶システム、ファイル検索装置およびプログラム - Google Patents

Abstract

【課題】複数のノードが格子状に接続され、各ノードに配置された記憶装置をひとつのデータ記憶システムとして利用する。
【解決手段】それぞれが記憶装置を有する複数のノードに保持されたファイルを共通の索引を用いて管理して単一のデータベースとして機能させるデータ記憶システムを提供する。格子状配列１０を構成するノード２０を、ファイルを実際に格納するためのファイル格納ノードと、ファイル格納ノードの索引情報を格納するための索引ノードとに分割する。索引データはツリー構造を使用して管理されている。ファイル格納ノードがツリー構造の葉に対応し、索引ノードがツリー構造の根または節点に対応する。そして、ファイル格納ノードに保持されているファイルを特定するためのファイル特定情報に基づいて一意に決定される索引ノードに、ファイル格納ノードのアドレス情報が格納される。
【選択図】図８

Description

本発明は、複数のノードを格子状に接続してなるデータ記憶システムと、このシステムで用いるファイル検索装置およびプログラムに関する。

ネットワーク上でやり取りされるファイル数や個別ファイルのサイズの増大により、データベースの構築に必要となる記憶容量は年々拡大している。しかしながら、ストレージエリアネットワーク（ＳＡＮ）等を構築して十分な記憶容量を確保するには、多大な費用が必要となる。

そこで、比較的安価な複数のサーバまたはパーソナルコンピュータを利用して大容量の記憶システムを構築したいという要望がある。このようなシステムでは、システムを構成する個々のノードの備える記憶容量は十分でなくとも、それらを論理的に統合してひとつの記憶領域に見立ててデータを格納し、またデータを検索できることが要求される。
特開平７−１２９４５０号公報

上述のような複数のノードを用いるシステムでは、複数のノードとそれらのノード間の接続に何らかの規則性がある場合、ファイルの格納位置を示すポインタを含む索引データを準備しておくことが行われる。データを検索する際に、この索引データが利用される。索引データの保存領域と実データの保存領域との対応関係を不適切に設計すると、拡張性に乏しかったり、ファイル検索に長時間を要したり、または索引データのデータ量と実データのデータ量とのバランスが取れないといった問題が生じうる。

本発明はこうした状況に鑑みてなされたものであり、その目的は、それぞれが記憶装置を有する複数のノードに保持されたファイルを共通の索引を用いて管理して単一のデータベースとして機能させるデータ記憶システムを構築するための技術を提供することにある。

本発明のある態様は、それぞれが記憶装置を有する複数のノードに保持されたファイルを共通の索引を用いて管理して単一のデータベースとして機能させるデータ記憶システムである。複数のノードは格子状に配列され、各ノードが前後左右のノードと通信可能に接続される。ファイルを実際に格納するファイル格納ノードと、ファイル格納ノードの索引データを格納する索引ノードとがそれぞれ正方形の部分格子を構成するように分割されている。ファイル格納ノードをツリー構造の葉に対応させ、索引ノードをツリー構造の根または節点に対応させて、ファイルおよび索引データを管理するツリー構造の情報が索引ノードに保持されている。そして、ファイル格納ノードに保持されているファイルを特定するためのファイル特定情報に基づいて一意に決定される索引ノードに、ファイル格納ノードのアドレス情報が格納される。

この態様によると、複数のノードがそれぞれ備えている記憶領域を論理的にひとつの記憶領域として統合して使用することができる。したがって、大容量の記憶装置の代わりに安価なコンピュータやサーバを結合させて、大容量の記憶装置の代替とすることができる。また、ファイル特定情報に基づいて決まる索引ノードに、ファイル格納ノードのアドレス情報が保持されているので、ファイルが実際に格納されているファイル格納ノードのアドレスが不明であっても、ファイル特定情報さえあれば容易に所望のファイルの格納場所を特定することができる。なお、「ファイル特定情報」はファイル固有の情報であればよく、例えばファイル名、ファイルの作成時刻、更新時刻、ファイルの作成者、ファイルを作成したコンピュータ名やこれらの組合せを含む。

格子状の配列において縦方向に並ぶノード数と横方向に並ぶノード数とが互いに素の関係にあり、格子状の配列をユークリッドの互除法を使用して複数の正方形の部分格子に分割してもよい。これによると、互いに素である任意のｍ×ｎ個のノードを複数の正方形の部分格子に容易に分割することができる。また、ユークリッドの互除法から自然に導かれる正方形分割を用いると、ツリー構造において親子関係または兄弟関係にあるノードが近接して位置することになり、ファイル検索時またはファイル格納時の親子方向または兄弟方向へのアクセス時間を削減することができる。さらに、ファイル格納ノードが正方形の部分格子であると、ファイルの転送時に宛先のノードに至るまでの経路が複数化されるため、ノード間の接続の一部が切断されたときでもファイルの転送を実現することができる。

ファイル特定情報を所定の規則にしたがってコード化し、得られたコードにしたがってファイル特定情報に対応するファイルを格納すべきノードを決定してもよい。この場合、コードにハッシュ関数を適用してハッシュ値を求め、ハッシュ値にしたがってファイル格納ノードのアドレス情報を保持すべき索引ノードを決定してもよい。

本発明の別の態様は、上述のデータ記憶システムにおけるファイル検索プログラムである。ファイル検索プログラムは、索引ノード上で動作し、ファイルの検索要求を受け取る機能と、ファイルのファイル特定情報を所定の規則にしたがってコード化し、得られたコードにしたがってファイル特定情報に対応するファイルが格納されているファイル格納ノードを決定する機能と、コードにハッシュ関数を適用してハッシュ値を求め、ハッシュ値にしたがってファイル格納ノードのアドレス情報が保持されている索引ノードを決定する機能と、を含む。

本発明のさらに別の態様は、それぞれが記憶装置を有する複数のノードが格子状に配列され、各ノードが前後左右のノードと通信可能に接続されているとき、各ノードに保持されたファイルをＢツリー構造で管理するデータ記憶システムである。Ｂツリー構造の根、節点、葉と、格子状に配列された複数のノードのいずれかとを一対一に対応させる。そして、葉に対応させたノードにはファイルを実際に格納し、節点に対応させたノードには、部分木に含まれる葉に対応するノードを指し示すアドレス情報を格納し、根に対応させたノードには、節点に対応するノードを指し示すアドレス情報を格納する。

この態様によると、格子状に配列された複数のノードと既知のＢツリーとを組み合わせて、複数のノードに分散して配置されたファイルをＢツリーで効率よく管理することができる。

なお、以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。

本発明によれば、それぞれが記憶装置を有する複数のノードに保持されたファイルをまとめて管理して単一のデータベースとして機能させることができる。

本発明の一実施形態は、それぞれがプロセッサを備える複数のノードが格子状に配列されたシステムにおいて、各ノードに配置された記憶装置の集合を管理するデータ記憶システムである、本実施形態は、特にファイルの格納場所を探索するための索引付け技術に特徴がある。以下、図面を参照してこの実施形態について詳細に説明する。

図１は、本発明の一実施形態に係るデータ記憶システム１００と、これに接続されるクライアント端末１２の全体構成図である。本実施形態が対象とする「データ記憶システム」とは、サーバまたはパーソナルコンピュータ等のそれぞれプロセッサを備える複数のノードを格子状に接続させ、複数のノードにデータを分散配置させたシステムのことをいう。

図１に示すように、データ記憶システム１００は、クライアント端末１２から発行される検索要求に対してシステム内に格納されたファイルを検索して提供する格子状配列１０を備える。格子状配列１０は、複数列複数行（図１では５行７列）の格子を形成するようにノード２０が配置される。図１の各ノードは、一台のサーバまたはパーソナルコンピュータに対応しており、各ノードを白抜きの正方形で表している。これら格子状に配列されたノードは、上下左右に位置するノードと通信可能なように構成される。図１では格子状配列１０を５行７列としているが、より多数またはより少数のノードで構成されていてもよいことはいうまでもない。これについては後述する。

格子状配列１０内の各ノード２０は、ルータ１６を介してインターネット、ＬＡＮ、ＷＡＮ等のネットワーク１４に接続される。データ記憶システム１００は、企業のデータセンタ等に配置され、多数の検索要求に同時に応答することが可能である。

格子状配列１０は、全体としてひとつのデータベースとして機能する。この機能を発揮するために必要となる各種プログラムやＩＰアドレスなどの情報は、システム管理者によって予め各ノードに与えられる。別の実施例では、後述する各ノードの役割が決定された時点で、特定のノードに格納されているプログラムや各種データを各ノードに送信するようにしてもよい。

クライアント端末１２は、キーボードやマウスなどの入力装置とディスプレイなどの出力装置を備えるパーソナルコンピュータ、または、それに準ずる入出力装置を備える携帯電話であってもよい。ただし、携帯電話の場合には、無線で通信することを想定する。ユーザは、クライアント端末１２上でウェブブラウザ等を使用して、データ記憶システム１００に対して検索要求を発行する。

図２は、格子状配列１０を構成する各ノードのハードウェア構成図である。ノードは、プログラムにしたがって各種処理を実行するプロセッサ９２と、一時的にデータやプログラムを記憶するメモリ９４と、ノードの再起動があっても記録内容が失われない記憶装置９６と、隣接する別のノードに接続し各種の入出力処理を実行するネットワークインタフェース９８と、これらを相互接続するバス９０とを少なくとも含む。ノードは、図１のように上下左右に位置する別のノードと接続するために、最大４つのネットワークインタフェース９８を備える。記憶装置９６としては、ハードディスク装置、光ディスク装置、磁気ディスク装置、不揮発性メモリのほか、任意のものを使用できる。各ノードは、必要に応じて、キーボードやマウスなどの入力装置、ディスプレイなどの出力装置を有していてもよい。

各ノードは、データ記憶システム１００を構成するのに適したコンパクトな形状、すなわちプロセッサ、メモリ、ハードディスク、バスなどが搭載されたブレードサーバであってもよい。格子状配列１０は、このブレードサーバがラックに多数並ぶ配置となることがサーバ同士をリンクするうえで好ましいが、他の態様であってもよい。

図３は、各ノード２０が上下左右のノードとリンクした様子を示す図である。図示するように、ノード２０は上下左右のノードとピアツーピア接続になるよう結線し、それぞれのリンクについて予めＩＰアドレスを与えておく。したがって、各ノードは隣接するノードと同数のネットワークインタフェースを備える必要がある。

各ノード２０は、ハイパースレッディングやＶＭｗａｒｅなどの既知の仮想化技術を使用して、複数のＯＳを同時に起動できるように構成する。仮想化技術を用いれば、複数のＯＳを同時起動するために２つ以上のＣＰＵを備えている必要はない。そして、一方のＯＳではアプリケーションの実行を管理し（以下、このＯＳを「アプリケーションＯＳ」と呼ぶ）、他方のＯＳではルーティングを管理する（以下、このＯＳを「自律ディスクＯＳ」と呼ぶ）。各ノード２０を、アプリケーションＯＳを実行するアプリケーションノード２２と、自律ディスクＯＳを実行する自律ディスクノード２４とに仮想的に分けて考えると、アプリケーションノード２２は自律ディスクノード２４に他のノード２０との通信経路の決定を任せることで、格子状配列内の任意のノード２０間で通信が可能になる。ルーティング機能を自律ディスクノード２４とネットワークインタフェースによって実現するので、各ノード間にスイッチやルータの配置は不要である。しかしながら、複数のノードを行や列の単位でひとくくりにして、それぞれにルータを配置する従来通りのネットワーク構成であっても、本実施形態を実現することができる。

以下の説明では、すべてのノードでアプリケーションＯＳと自律ディスクＯＳが稼働し、ルーティングとアプリケーションの実行ができるものとする。記憶装置へのデータファイルの格納や検索、後述するハッシュ計算などはアプリケーションノード２２が実行し、ファイルの転送処理やルーティングは自律ディスクノード２４が実行することを前提とし、特にそれらの役割を区別しないで説明する。

ところで、例えば図４に示すような格子状に並んだ複数のノードからなるデータ記憶システムを想定すると、従来では、システム管理者が必要と見込まれる記憶容量に応じて、いくつのノードを割り当てれば良いかを決定する。例えば、図４（ａ）のように、初期では２×２＝４個のノードを割り当てたとする。その後の運用によって、初期の見込み以上の記憶容量が必要になると、システム管理者は割り当てるノードを増加する必要がある。この際、追加ノードを例えば図４（ｂ）のように割り当てたとする。すると、各ノードに格納しているデータファイルの配置規則と、ノード追加後に格納されるデータファイルの配置規則との間で一貫性を維持できなくなり、索引データに異同が生じる。したがって、格子状に配列された多数のノードをデータベースとして用いるには、データを配置するノードを一定の規則にしたがって定め、索引データの一貫性を維持する必要がある。

また、図５に示すように、２行１列の索引ノードと、２行２列の実データ格納ノードが割り当てられた状態から記憶容量を増やす場合を想定すると、実データが増えるにしたがって索引データも増加する。このため、索引データも複数のノードに分散する必要に迫られ、索引データの分割ルールが必要になる。例えば、図５（ａ）、（ｂ）のように、索引データを格納するノードをブロックの左一列というような決め方をしていると、実データの許容量は縦横の積である二次式の比率で増えていくにもかかわらず、索引データの許容量が縦一列の一次式の比率でしか増えないため、索引データの格納領域が制約となって実データへのアクセスが制約される。その結果、索引データの再配置が必然的に求められる。もし、この再配置を怠れば、実データを探索するために索引を有するすべてのノードに問い合わせを行わざるを得なくなる。

そこで、ある格子状配列が与えられたときに、実データと索引データの配置を適切に決定できる方法が必要になる。本実施形態では、格子状配列の縦横のノード数を互いに素の整数の組で構成することによって、上述の問題を解決するようにした。より具体的には、格子状配列におけるノードの物理的な配置と、索引データを階層化する周知のＢツリーによる索引データの管理とを組み合わせて使用する。

本実施形態による索引データの管理を実施する前提として、格子状配列を構成するノードを、ファイルを実際に格納する「ファイル格納ノード」と、ファイル格納ノードのアドレス情報を含む索引データを格納する「索引ノード」とに分割する必要がある。ここで、「索引データ」とは、ファイル格納ノードを特定するために必要なデータであり、後述する実施例では、ファイル格納ノードのノード番号とアドレス情報の組である。

図６のフローチャートを参照して、格子状配列１０の分割の手順を説明する。まず、システム管理者は、格子状配列の縦方向のノード数をｍ、横方向のノード数をｎ（ｍ、ｎは自然数）としたとき、ｍとｎが互いに素である格子状配列を構築し、それぞれのノードのＩＰアドレスを設定する（Ｓ１０）。縦横のノード数を互いに素とする理由は、後述するユークリッドの互除法により正方形分割することで索引ノードを階層的に構成できることが保証されるからである。

次に、システム管理者は、格子状配列を大きさを異にする複数の正方形の部分格子に分割する（Ｓ１２）。縦と横のノード数が互いに素である格子状配列１０を複数の正方形の部分格子へと分割するには、周知のユークリッドの互除法を使用する。以下、本実施形態における格子状に配列されたノードに対しユークリッドの互除法を適用して、縦横のノード数が等しい正方形の部分領域に分割する方法を説明する。

１．ｍ＞ｎであるような自然数ｍ、ｎのノード数を持つ格子状配列をＫ(ｍ、ｎ)と表記する。
２．Ｋ(ｍ、ｎ)の左側から正方形の部分格子Ｋ(ｎ、ｎ)を詰めていく。正方形の個数をｑ_０とすると、ｍをｎで割った商がｑ_０であり、余りは（ｍ−ｑ_０・ｎ）と表せる。
３．余り（ｍ−ｑ_０・ｎ）＝ｒ_１と表記すると、正方形の部分格子Ｋ(ｎ，ｎ)を詰めた残りの部分はＫ(ｒ_１，ｎ)と表せる。
４．長方形Ｋ(ｒ_１，ｎ)の下側から今度は正方形の部分格子Ｋ(ｒ_１，ｒ_１)を詰めていく。正方形の部分格子の個数をｑ_１とすると、ｎをｒ_１で割ったときの商がｑ_１であり、余りは（ｎ−ｑ_１・ｒ_１）と表せる。
５．上記の操作を繰り返すと、有限回で格子状配列Ｋ(ｍ、ｎ)は複数の正方形の部分格子に分割される。

ユークリッドの互除法を用いて任意の領域を正方形の部分格子に分割する方法は、例えば「分割の幾何学 デーンによる２つの定理」、日本評論社、砂田利一著、p.34-p.38に記載されているように周知であるから、これ以上詳細な説明は省略する。

図７を参照して、上記手順１〜５の具体例を示す。
１．格子状配列１０は、Ｋ(７，５)と表せる。
２．Ｋ(７，５)の左側から正方形の部分格子Ｋ(５，５)を詰めると、正方形はひとつしか入らないのでｑ_０＝１であり、余りは（７−５・１）＝２となる。
３．したがって、長方形のＫ（２，５）が残る。
４．Ｋ(２，５)の下側から正方形の部分格子Ｋ(２，２)を詰めていくと、正方形は２つ配置できるのでｑ_１＝２となり、あとにＫ(２，１)が余る。
５．最後に、Ｋ(１，１)であるひとつのノードが２つ残る。
これによって、格子状配列１０は、図７で太線の四角形で囲んだ５つの正方形の部分格子に分割される。

図６に戻り、システム管理者は、分割された正方形の部分格子を、ファイル格納ノードかまたは索引ノードのいずれかに指定する（Ｓ１４）。図７において、左側の最大の部分格子に含まれるノードを「ファイル格納ノード」と定め、残りの部分格子に含まれるノードは「索引ノード」と定められる。システム管理者は、各ノードを識別するための番号を割り振る（Ｓ１６）。その結果を図８に示す。図示するように、ファイル格納ノードはｃ０〜ｃ２４の２５個あり、二次索引ノードはｂ０〜ｂ３の４個あり、一次索引ノードはａ０の一個が存在する。図中のａ０’およびｂ０’〜ｂ３’のノードの活用方法については後述する。

本実施形態では、ファイルはファイル格納ノードに分散して配置しておき、それらの格納場所を知るための索引データとして格納場所へのポインタを周知のＢツリーによって管理する。本実施形態では、ポインタとして図３で示したＩＰアドレスやＭＡＣアドレスを使用する。ファイル格納ノードのそれぞれがＢツリーにおける「葉」と一対一に対応し、索引ノードのそれぞれがＢツリーにおける「節点」と一対一に対応する。最後の正方形分割で得られる１×１のノードは、Ｂツリー構造における「根」と対応させる。この結果、Ｂツリーの構成は図９のようになる。図示するように、一次索引ノードａ０は、自分自身と二次索引ノードｂ０〜ｂ３とを結ぶ４つの枝を有している。二次索引ノードｂ０〜ｂ３は、ファイル格納ノードのうちのいくつかを葉として有している。ファイル格納ノードと二次索引ノードの関連については後述する。

システム管理者は、一次索引ノード、二次索引ノード、およびファイル格納ノードに対して、後述する検索プロセスを実行するためのプログラムをインストールさせる。

図１０は、検索プログラムを実行した状態での一次索引ノードの機能ブロック図である。ファイル受取部１０２は、ファイルの格納場所の問い合わせのためにファイル名を受け取ったり、または転送されたファイルを受け取る。検索部１０４は、コード化部１０６とハッシュ計算部１０８とを含む。コード化部１０６は、後述する方法によってファイル名をコード化（数値化）して、ファイルを保持すべきファイル格納ノードを表す「格納場所コード」に変換する。ここで、「コード化」とは、後に具体例を挙げて説明するように、任意のファイル名をファイル格納ノード数以下の整数に変換することをいう。ハッシュ計算部１０８は、格納場所コードに対してハッシュ関数を適用し、ハッシュ値を算出する。ファイル転送部１１０は、アドレス情報にしたがってファイルを別のノードに転送する。テーブル保持部１１２は、格納場所コードまたはハッシュ値と対応するノードのアドレス情報をテーブル形式で保持する。情報取得部１１４は、システム管理者から与えられるノード番号やＩＰアドレスの情報などを取得する。

二次索引ノードおよびファイル格納ノードの構成も一次索引ノードと同様であるが、後述するように、検索部１０４の機能とテーブル保持部１１２に格納される索引データが異なる。

次に、図１１のフローチャートを参照して、ファイル名に基づいて当ファイルを格納すべきファイル格納ノードを決定し、さらに各ファイル格納ノードの索引データを格納すべき索引ノードを決定するプロセスを説明する。このプロセスを経て、図９で示したようなＢツリーを用いてデータ記憶システム内のファイルを検索できるようになる。

図６の手順にしたがってＢツリーを構成した後に、外部からデータ記憶システムにファイルを送信して適当なノードに記憶させる場合を考える。一次索引ノードには、予めシステム管理者によって、二次索引ノードｂ０〜ｂ３およびファイル格納ノードｃ０〜ｃ２４のアドレス情報が記録されており、一次索引ノードはアドレス情報をノード番号と対応付けてテーブル保持部１１２に記録する（Ｓ２０）。外部からのファイルはルータによって一次索引ノードに送信される。一次索引ノードのファイル受取部１０２がファイルを受け取り、コード化部１０６に渡す。コード化部１０６は、受け取ったファイルのファイル名を所定の規則にしたがってコード化し、格納場所コードｘを算出する（Ｓ２２）。ファイル転送部１１０は、格納場所コードｘで指定されるファイル格納ノードに対してそのファイルを転送する（Ｓ２４）。続いて、ハッシュ計算部１０８は、格納場所コードｘに対してハッシュ関数を適用してハッシュ値を算出する（Ｓ２６）。このハッシュ関数をｈ（ｘ）、二次索引ノードの数をｒ_１ ^２と表記すると、ｈ（ｘ）＝０、．．．、（ｒ_１ ^２−１）となるようにハッシュ関数を選択する。ファイル転送部１１０は、ハッシュ値で指定される二次索引ノードに対して、ファイル格納ノードのアドレス情報を送信する（Ｓ２８）。二次索引ノードは、ファイル格納ノードのノード番号とアドレス情報とを対応付けて、自身のテーブル保持部１１２に記録する（Ｓ３０）。

以下、具体例を挙げて図１１の各ステップを説明する。この例では、簡単のためにファイル名はすべて平仮名で与えられているものとし、平仮名の各文字の母音に基づいてコード化を実行する。

各ノードのコード化部１０６は、図１２に示すような母音コード表を予め保持している。そして、コード化部１０６は、母音コード表にしたがって、ファイル名中の各文字の母音が「あ」であれば「１」を、母音が「い」であれば「２」を、母音が「う」であれば「３」を、母音が「え」であれば「４」を、母音が「お」であれば「５」を、それぞれ与えるとする。促音、拗音、長音や「ん」については「０」を与える。

図１３は、ファイル名の具体例と、ファイル名に基づいた格納場所コードの算出方法を示す。ファイル名が「せみなさんか」である場合、コード化部１０６は、「せ」の母音「え」のコード「４」、「み」の母音「い」のコード「２」、．．．といったように、ファイル名の平仮名のコードを母音コード表にしたがって変換していく。すべての文字を変換したら、それらを足し合わせる。この例では、「せ」「み」「な」「さ」「ん」「か」にそれぞれ対応するコード「４」「２」「１」「１」「０」「１」を加算して、格納場所コード「９」が求められる。この数字が、当該ファイルを格納すべきファイル格納ノードの番号（つまりｃ９）を示している。他のファイル名「けいひ」「よさん」「かし」「たいさく」についても同様の手順で計算をし、それぞれのファイル格納ノードはｃ８、ｃ６、ｃ３、ｃ７となる。コードの加算の結果、格納場所コードがファイル格納ノードの総数である「２５」以上になった場合は、格納場所コードを２５で除したときの余りをそのファイルの格納場所コードとする。

さらに図１３を参照して、ファイル格納ノードの索引データを格納すべきノードを決定する手順について説明する。ハッシュ計算部１０８は、格納場所コードに対して二次索引ノード数を法とした剰余をハッシュ値として計算する。そして、ハッシュ値を索引データを保持すべき二次索引ノードの番号と決定する。例えば、格納場所コードが「９」であれば、９＝４・２＋１であるから二次索引ノードはｂ１となる。したがって、ファイル格納ノードｃ０、ｃ４、ｃ８、．．．、ｃ２４の索引データは二次索引ノードｂ０に、ファイル格納ノードｃ１、ｃ５、ｃ９、．．．、ｃ２１の索引データは二次索引ノードｂ１に、ファイル格納ノードｃ２、ｃ６、ｃ１０、．．．、ｃ２２の索引データは二次索引ノードｂ２に、ファイル格納ノードｃ３、ｃ７、ｃ１１、．．．、ｃ２３の索引データは二次索引ノードｂ３に、それぞれ格納される。
なお、ハッシュ関数は、連続する格納場所コードに対して異なるハッシュ値を出力するものであれば他の関数でもよい。

図１４は、上記具体例にしたがって構築されるＢツリー構造として、各ノードとそれらに格納されるデータを表している。一次索引ノードには、すべての二次索引ノードおよびファイル格納ノードの索引データ（つまり、ノード番号とアドレス情報の組）が配置される。他方、二次索引ノードには、Ｂツリーの葉に相当するファイル格納ノードの索引データが配置される。二次索引ノードは、すべてのファイル格納ノードの索引データを保持するのではなく、上述のハッシュ計算の結果が自身のノード番号と一致するファイルを格納したファイル格納ノードの索引データのみを保持する。本明細書では、これを「部分木の索引データを保持する」という。

図１４に示すように、本実施形態では、実際のファイルはファイル格納ノードに保持され、そのファイルを検索するために必要な索引データを二次索引ノードと一次索引ノードに格納する。このように、ファイルの保存場所と索引データの保存場所とを異なるノードにしている。

また、全体のファイル格納ノードの数がいくつであってもＢツリー構造でファイルを管理することができるため、ノードの縦横の配列数に拡張性がある。

上述した正方形の部分格子への分割により、ｒ_０とｒ_１とは互いに素であるから、ファイル格納ノードと二次索引ノードのノード数の比ｒ_０ ^２とｒ_１ ^２も必ず互いに素となる。このため、索引をたどる階層にハッシュ関数を適用すると、二次索引ノードの数とファイル格納ノードの数に公約数がある場合と比べて、索引並びに実データを分散する効果が高くなると期待される。

外部からデータ格納システムに対してファイルの要求が来ると、その要求は一次索引ノードに渡される。一次索引ノードは、ファイル名をコード化して、格納場所コードと同じ番号を持つファイル格納ノードのアドレスをテーブルから検索し、ファイル要求を検索したファイル格納ノードに渡す。ファイル要求を受け取ったファイル格納ノードは、ファイルを記憶装置から取り出して、要求元のアドレスに対して検索したファイルを送信する。

Ｂツリー構造を構築した後であれば、各ノードに元から格納されていたファイルを、Ｂツリーに合わせて再配置することもできる。このプロセスを図１５のフローチャートを参照して説明する。

まず、各ノードにおいて、現在格納されているデータファイルのファイル名を取得し、それぞれの格納場所コードを計算する（Ｓ４０）。計算された格納場所コードが、各ノードに割り振られたノード番号と一致しているか否かを判定する（Ｓ４２）。一致していれば（Ｓ４２のＹ）、そのファイル名を持つデータファイルは、当該ノードに格納すべきものであるから、このフローを終了する。一致していなければ（Ｓ４２のＮ）、そのファイル名のデータファイルは別のノードに格納すべきものである。したがって、ファイル格納ノードは、上位の索引ノードに対し、そのファイルを格納すべきファイル格納ノードのアドレスを問い合わせる（Ｓ４４）。

二次索引ノードは、ファイル名を受け取ると、格納場所コードを計算したうえで、さらにハッシュ値を計算する（Ｓ４６）。計算したハッシュ値が、二次索引ノードに割り振られたノード番号と一致していれば（Ｓ４８のＹ）、テーブルに格納場所コードと一致するファイル格納ノードのアドレスが存在するので、問い合わせをしてきたファイル格納ノードにアドレス情報を送信する（Ｓ５０）。計算したハッシュ値が、二次索引ノードに割り振られたノード番号と一致していないときは（Ｓ４８のＮ）、二次索引ノードは、一次索引ノードに対してさらにファイル名を問い合わせる（Ｓ５２）。
一次索引ノードには、すべてのノードのアドレス情報が記録されているので、格納場所コードに対応するファイル格納ノードのアドレスを検索して、問い合わせをしてきたファイル格納ノードにアドレス情報を送信する（Ｓ５４）。

問い合わせ元のファイル格納ノードは、送信されてきたアドレス情報にしたがって、直接そのファイル格納ノードに対して、ファイルを送信して格納を依頼する（Ｓ５６）。ファイルを受け取ったファイル格納ノードは、ファイル名をコード化して自らに格納すべきファイルであることを確認した後、そのファイルを記憶装置に格納する（Ｓ５８）。

以上の手順は、ファイル格納ノードにおけるものであるが、索引ノードでは若干異なる。二次索引ノードでは、コード化、ハッシュ値計算によって、自分の管理する部分木内のファイル格納ノードであることが分かれば、そのアドレスを検索してファイルの格納を依頼する。自分の管理する部分木内のデータでないことが分かると、一次索引ノードに対してファイル格納ノードのアドレスを問い合わせた後、ファイルの格納を依頼する。

一次索引ノードはすべてのノードのアドレスを保持しているので、格納場所コードと同一番号を持つファイル格納ノードのアドレスを検索して、ファイルの格納を依頼する。こうすることで、Ｂツリーの作成前に各ノードの記憶装置に保持されていたファイルを再配置することが可能になる。

なお、図１５の手順は、データ記憶システム内の各ノードにおいてアプリケーションが実行されており、システム内に格納されているファイルが必要になったときに、そのファイルを検索する場合にも適用できる。ファイル名の問い合わせをするまでは図１５と同様であり、所望のファイルを格納しているノードのアドレスが判明すると、そのアドレスに対してファイルの要求を出す。ファイル要求を受け取ったファイル格納ノードは、ファイル名をコード化して自らに格納されているファイルであることを確認すると、そのファイルを要求元のファイル格納ノードに対して送信する。

格子状配列内の全ノードのアドレスは、一次索引ノードにある。したがって、各ファイル格納ノードに対して一次索引ノードのアドレスだけを予め通知しておけば、各ファイル格納ノードは、必要なファイルの格納場所の問い合わせを一次索引ノードに対して発することで、ファイル格納ノードのアドレスを知ることができる。しかしながら、この構成では、すべての問い合わせが一次索引ノードに集中してしまう。これに対し本実施形態では、ファイル格納ノードからの問い合わせの一部については、二次索引ノードが管理する部分木内にあるファイルであれば二次索引ノードでアドレスを知ることができるため、一次索引ノードにおける検索の負荷を軽減できる。

各ファイル格納ノードには、部分木内の二次索引ノードのアドレスのみならず、すべての二次索引ノードのアドレス情報を予め送信しておいてもよい。こうすれば、ファイル格納ノードからファイルを検索する際、コード化、ハッシュ値計算を行って、自らのノードの記憶装置にファイルが存在しない場合は、そのファイルが格納されたノードが含まれる部分木を管理する二次索引ノードに対し、ファイルの格納場所の問い合わせを直接行うことができる。したがって、図１５のように二次索引ノードから一次索引ノードに対する問い合わせが発生しないため、一次索引ノードの処理負荷を引き下げることができる。

一次索引ノードに全ノードのアドレスを格納する代わりに、二次索引ノードのアドレスのみを格納しておいてもよい。この場合、外部からのファイル要求があったとき、一次索引ノードは、コード化とハッシュ値を計算して、そのファイルを格納しているファイル格納ノードを部分木として管理している二次索引ノードのアドレスを知ることができる。一次索引ノードは、二次索引ノードにファイル要求を転送する。二次索引ノードは、そのファイル要求からファイル名を取り出して格納場所コードを求めることで、ファイル格納ノードのアドレスをテーブルから検索する。そして、ファイル要求を該当するファイル格納ノードに渡す。こうすることで、最終的なファイル格納ノードのアドレスを検索する処理を二次索引ノードに回すことで、一次索引ノードの検索負荷をさらに低下させることができる。

図８に示したように、格子状配列されたノードを正方形分割して、それぞれにファイル格納ノード、索引ノードの役割を与えると、Ｂツリーを構成しないノードが発生することが避けられない。図８では、ノードａ０’、ｂ０’〜ｂ３’は、Ｂツリーを構成していない。そこで、これらの未使用ノードを、検索データのバックアップ領域として使用してもよい。

図１６は、索引ノードのレプリケーションを示す。上述のユークリッドの互除法によって未使用ノードが発生する場合、それらのサイズは、必ず索引ノードを構成する正方形の部分格子と同じ大きさになる。したがって、同じサイズの索引ノードに格納されている索引データのレプリケーションを実行して、バックアップノードを作成する。図１６では、ノードａ０’は、一次索引ノードａ０をレプリケートし、ノードｂ０’〜ｂ３’は、二次索引ノードｂ０〜ｂ３をそれぞれレプリケートする（以下、元からＢツリーである方を「プライマリ」、レプリケートした方を「バックアップ」と呼ぶ）。こうして索引データを二重化することで、索引の信頼性を向上させることができる。これは、Ｂツリーの一部の階層を複製したことに相当する。

上記ユークリッドの互除法を用いた手順だと、最後には１×１のノードが二個以上できることになる。したがって、格子状配列の縦横が互いに素である限り、一次索引ノードのレプリケーションを実行できる。バックアップノードを確保したうえで、外部からのファイル要求を、ルータによりラウンドロビンやハッシュ等の既知のアルゴリズムで複数の一次索引ノード（プライマリとバックアップ）に分散して送ることで、ルートである一次索引ノードへのアクセスの集中を緩和し、アクセス数増加時の一次索引ノードの処理負荷を低下させることも可能である。ファイル格納ノードから二次索引ノードへのファイル要求についても、プライマリとバックアップの二次索引ノードに分散させることで同様の効果が得られる。

また、ユークリッドの互除法で正方形の部分格子に分割したとき、プライマリとバックアップが並ぶ方向は、階層間で互い違いになる。すなわち、図１７に示すように、一次索引ノードのプライマリとバックアップとが横方向の並びであれば、二次索引ノードのプライマリとバックアップとの並びは縦方向になる。したがって、プライマリとバックアップとの間で、索引データを同期させるときのデータフロー（図１７中の斜線を付した矢印の方向）と、ファイル検索時のファイル要求やアドレス情報をやり取りするときのデータフロー（図１７中の白抜き矢印の方向）とは、通常直交する。したがって、これらのフローがひとつのリンクで競合することがなく、一部のリンクがボトルネックとなりシステム全体の処理性能が低下するような事態が発生しにくい。

以上説明したように、本実施形態では、格子状に配列されたノードとＢツリー構造を適用し、Ｂツリーの「葉」「節点」「根」に相当するものに対して、格子型システム内のノードを一対一で割り当てるようにした。そして、葉に当たるノードにはＢツリーと同じく実際のデータを格納し、節点、根に当たるノードには、葉ノードにルーティングするための索引データを配置するようにした。従来から知られているＢツリーは、索引データも実際のデータも、ひとつのコンピュータの中で閉じているが、それを複数ノードに広げた点に特徴がある。また、Ｂツリーを作るためのノードの領域分割と、索引データの付け方が、ハッシュを介して対になっている点にも特徴がある。

またユークリッドの互除法を用いることにより、格子状配列の縦横のノード数が互いに素であれば、原理的にノード数がいくつであってもデータを管理できる。したがって、システムの拡張性が高い。

本実施形態によれば、格子状配列されたノードをデータ記憶システムとして用いるときに、公知のＢツリー構造を利用して、ファイルと索引ノードとを階層化して分散配置するようにした。索引ノードは、ファイルが実際に格納されているノードのアドレスを示すポインタの役割を果たす。また、索引ノード数と実ファイル格納ノード数とが、互いに素の関係となることを利用して、索引データを複数の索引ノードに分散させることができる。また、実ファイル格納ノード数と二次索引データ格納ノード数も互いに素となるので、実ファイル格納ノードに配置されるデータの偏りも分散させることができる。階層間のノード数比率が、互いに素である数字の二乗であるため、ノード数の比率が各階層で互いに素となるため、データの分配の偏りを小さくすることができる。また、各葉ノードでのファイル検索の負荷が比較的分散されるので、特定のノードの処理負荷が突出して高くなることを防止できる。

なお、実施形態では、簡単のためコード化を「日本語ファイル名の母音」で計算しているため、ファイル名の長さが実際には限られることから分散の効果は少ない。しかしながら、例えばアスキーコードなどを用いてコード化すれば、格納場所コードの値はよりばらついた値になることが予測されるので、この分散の効果はより大きくなることが期待される。これ以外にも、単にファイル名の文字数をカウントしたり、ファイル名の英数字に予め数を割り当てておいたり、暗号化の手法を適用するなど、ファイル名などの文字列をコード化するために任意の技術を使用することができる。

本実施形態では、格子状に配列されたノードを正方形の部分領域に分割することで、次のような効果も生じる。すなわち、親子関係、兄弟関係にある枝ノードが、格子型システム内で近接して位置することになる。親子ノードは索引データの依存関係があり、兄弟ノードは索引データの補完関係にある。よって、互いに隣接していることで、親子方向、兄弟方向へのアクセス時間を短縮できる。
また、ファイル格納ノードが正方形の領域として確保されるため、ファイルを転送するときに、そのノードに至るまでの経路が複数化され、ノード間のリンクの一部が切断されたときでもファイルの転送を実現することができる。

以上、本発明をいくつかの実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例がありうること、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

実施形態では、ファイル格納ノードの番号から求めたハッシュ値を使用して、ファイル格納ノードのアドレスを検索するための索引データを格納する索引ノードを決定することを述べた。しかしながら、上述のＢツリーでは、範囲を指定した検索に対応できない。そこで、ｎ分探索木を使って索引データの管理をしてもよい。ハッシュ値を計算する際に現れた格納場所コードを用いて節点や葉を形成すればｎ分探索木を構築できる。索引データはこの格納場所コードをそのまま用いる一方で、実データはハッシュ値により格納すべき葉を決定する。範囲探索では、このｎ分探索木をたどって葉に格納された実データを得る。

格納場所コードを算出するためにファイル名を使用したが、それ以外のファイル固有の情報、例えばファイルの作成時刻、更新時刻、ファイルサイズ、ファイルの作成者、ファイルを作成したコンピュータ名やこれらの組合せから格納場所コードを算出してもよい。また、二種類以上の索引、つまり格納場所コードを併用してもよい。

格納すべきデータが増加した場合に、システム管理者がファイル格納ノードまたは索引ノードの増強を必要とするときには、事後的に格子状配列の縦、横のノード数を増加させることも可能である。この場合、一次索引ノードは、新たな格子状配列のノード数と各ノードのアドレス情報に基づいて、上述の手順にしたがってＢツリーを再構築するようにしてもよい。再構築の結果、ファイル格納ノード数と二次索引ノード数との比率が変わるため、索引データを格納すべき二次索引ノードやファイル格納ノード数が増加して、データファイルを格納すべきファイル格納ノードが変わったとき、各ノードは上述した再配置の手順にしたがって、データの再配置を実行するようにしてもよい。

実施形態で述べたように、システムの管理者が仕様に応じた望ましい正方形の部分格子に切り出しができるように、格子状配列の縦、横のノード数を決定し、その通りに格子状配列を構成する方が、使用されないノードがなく、かつレプリケーション用のノードを確保した好ましい論理構成を持つ記憶システムを構築できる。しかしながら、システム管理者によらずに、正方形分割をプログラムで実行させることもできる。この場合、対象となる格子状配列１０の縦横のノード数は任意であってよく、いずれかのノードで実行されるプログラムが、図７で述べたステップを順次実行することで、正方形の部分格子への切り出しを行うようにしてもよい。

格子の形状によっては、三次索引以上の階層をＢツリーに設けてもよいが、本発明の方法は二次索引ノードの検索まででファイル格納ノードを決定できるので、それ以上の次数の階層は不要である。

一台のルータに複数のサーバまたはパーソナルコンピュータが接続することによって、図１のひとつのノード２０の下に複数のサーバやパーソナルコンピュータを配置してもよい。

本発明の一実施形態に係るデータ記憶システムと、これに接続されるクライアント端末の全体構成図である。 格子状配列を構成する各ノードのハードウェア構成図である。 各ノードを上下左右のノードとリンクさせる様子を示した図である。 （ａ）、（ｂ）は、格子状配列を有するデータ記憶システムにおける従来技術を説明する図である。 （ａ）、（ｂ）は、格子状配列を有するデータ記憶システムにおける従来技術を説明する図である。 格子状配列を複数の正方形の部分格子に分割する手順を示すフローチャートである。 格子状配列の分割の具体例を示す図である。 格子状配列の正方形の部分格子への分割結果と、各ノードに割り振られたノード番号を示す図である。 Ｂツリーの構成を示す図である。 検索プログラムを実行する一次索引ノードの機能ブロック図である。 ファイル格納ノードと索引ノードを決定するプロセスを示すフローチャートである。 母音コード表を示す図である。 ファイル名の具体例とファイル名に基づいたコードの算出方法を示す図である。 Ｂツリーと、各ノードに格納されるデータを示す図である。 ファイルをＢツリーに合わせて再構成するプロセスを示すフローチャートである。 索引ノードのレプリケーションを示す図である。 索引データを同期させるときのデータフローと、ファイル検索時のデータフローとを示す図である。

符号の説明

１０ 格子状配列、 １２ クライアント端末、 １４ ネットワーク、 １６ ルータ、 ２０ ノード、 ９６ 記憶装置、 ９８ ネットワークインタフェース、 １００ データ記憶システム、 １０２ ファイル受取部、 １０４ 検索部、 １０６ コード化部、 １０８ ハッシュ計算部、 １１０ ファイル転送部、 １１２ テーブル保持部、 １１４ 情報取得部。

Claims (9)

1. それぞれが記憶装置を有する複数のノードに保持されたファイルを共通の索引を用いて管理して単一のデータベースとして機能させるデータ記憶システムであって、
   前記複数のノードは格子状に配列され、各ノードが前後左右のノードと通信可能に接続され、ファイルを実際に格納するファイル格納ノードと、該ファイル格納ノードの索引データを格納する索引ノードとがそれぞれ正方形の部分格子を構成するように分割されており、
   前記ファイル格納ノードをツリー構造の葉に対応させ、前記索引ノードをツリー構造の根または節点に対応させて、前記ファイルおよび前記索引データを管理するツリー構造の情報が前記索引ノードに保持され、
   前記ファイル格納ノードに保持されているファイルを特定するためのファイル特定情報に基づいて一意に決定される索引ノードに、該ファイル格納ノードのアドレス情報が格納されることを特徴とするデータ記憶システム。
2. 前記格子状に配列されたノードを分割して得られる部分格子のうち、最大の部分格子に含まれるノードを前記ファイル格納ノードとし、他の部分格子に含まれるノードを前記索引ノードとすることを特徴とする請求項１に記載のデータ記憶システム。
3. 前記格子状の配列において縦方向に並ぶノード数と横方向に並ぶノード数とが互いに素の関係にあり、該格子状の配列をユークリッドの互除法を使用して複数の正方形の部分格子に分割することを特徴とする請求項１または２に記載のデータ記憶システム。
4. 前記ファイル特定情報を所定の規則にしたがってコード化し、得られたコードにしたがって該ファイル特定情報に対応するファイルを格納すべきファイル格納ノードが決定され、
   前記コードにハッシュ関数を適用してハッシュ値を求め、該ハッシュ値にしたがって前記ファイル格納ノードのアドレス情報を保持すべき索引ノードが決定されることを特徴とする請求項１ないし３のいずれかに記載のデータ記憶システム。
5. 前記ファイル特定情報としてファイルに付与された名前を使用することを特徴とする請求項４に記載のデータ記憶システム。
6. 前記分割により複数の同サイズの部分格子ができた場合、前記索引データを複数の部分格子に複製して前記索引ノードのバックアップを作成することを特徴とする請求項３に記載のデータ記憶システム。
7. それぞれが記憶装置を有する複数のノードに保持されたファイルを共通の索引を用いて管理して単一のデータベースとして機能させるデータ記憶システムにおいて、
   前記複数のノードは格子状に配列され、各ノードが前後左右のノードと通信可能に接続され、ファイルを実際に格納するファイル格納ノードと、該ファイル格納ノードの索引データを格納する索引ノードとがそれぞれ正方形の部分格子を構成するように分割されており、
   前記ファイル格納ノードをツリー構造の葉に対応させ、前記索引ノードをツリー構造の根または節点に対応させて、前記ファイルおよび前記索引データを管理するツリー構造の情報が前記索引ノードに保持されているとき、
   前記索引ノードにおいて実行されるプログラムが、
   ファイルの検索要求を受け取る機能と、
   前記ファイルのファイル特定情報を所定の規則にしたがってコード化し、得られたコードにしたがって該ファイル特定情報に対応するファイルが格納されているファイル格納ノードを決定する機能と、
   前記コードにハッシュ関数を適用してハッシュ値を求め、該ハッシュ値にしたがって前記ファイル格納ノードのアドレス情報が保持されている索引ノードを決定する機能と、
   を含むことを特徴とするデータ記憶システムにおけるファイル検索プログラム。
8. それぞれが記憶装置を有する複数のノードに保持されたファイルを共通の索引を用いて管理して単一のデータベースとして機能させるデータ記憶システムにおいて、
   前記複数のノードは格子状に配列され、各ノードが前後左右のノードと通信可能に接続され、ファイルを実際に格納するファイル格納ノードと、該ファイル格納ノードの索引データを格納する索引ノードとがそれぞれ正方形の部分格子を構成するように分割されており、
   前記ファイル格納ノードをツリー構造の葉に対応させ、前記索引ノードをツリー構造の根または節点に対応させて、前記ファイルおよび前記索引データを管理するツリー構造の情報が前記索引ノードに保持されているとき、
   前記索引ノードがファイルの検索装置として機能し、
   ファイルの検索要求を受け取るファイル受取部と、
   前記ファイルのファイル特定情報を所定の規則にしたがってコード化し、得られたコードにしたがって該ファイル特定情報に対応するファイルが格納されているファイル格納ノードを決定するコード化部と、
   前記コードにハッシュ関数を適用してハッシュ値を求め、該ハッシュ値にしたがって前記ファイル格納ノードのアドレス情報が保持されている索引ノードを決定するハッシュ計算部と、
   を備えることを特徴とするデータ記憶システムにおけるファイル検索装置。
9. それぞれが記憶装置を有する複数のノードが格子状に配列され、各ノードが前後左右のノードと通信可能に接続されているとき、各ノードに保持されたファイルをＢツリー構造で管理するデータ記憶システムであって、
   Ｂツリー構造の根、節点、葉と、格子状に配列された複数のノードのいずれかとを一対一に対応させ、
   葉に対応させたノードにはファイルを実際に格納し、節点に対応させたノードには、部分木に含まれる前記葉に対応するノードを指し示すアドレス情報を格納し、根に対応させたノードには、前記節点に対応するノードを指し示すアドレス情報を格納したことを特徴とするデータ記憶システム。

Images