特許 6180710 データ格納方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6180710

(24)【登録日】2017年7月28日

(45)【発行日】2017年8月16日

(54)【発明の名称】データ格納方法及び装置

(51)【国際特許分類】

   G06F 12/00 20060101AFI20170807BHJP

【ＦＩ】

   G06F12/00 545A

   G06F12/00 520A

【請求項の数】8

【全頁数】26

(21)【出願番号】特願2012-149299(P2012-149299)

(22)【出願日】2012年7月3日

(65)【公開番号】特開2013-30165(P2013-30165A)

(43)【公開日】2013年2月7日

【審査請求日】2015年6月30日

(31)【優先権主張番号】10-2011-0075026

(32)【優先日】2011年7月28日

(33)【優先権主張国】KR

(31)【優先権主張番号】10-2011-0080533

(32)【優先日】2011年8月12日

(33)【優先権主張国】KR

【前置審査】

(73)【特許権者】

【識別番号】505205812

【氏名又は名称】ネイバー コーポレーション

【氏名又は名称原語表記】ＮＡＶＥＲ Ｃｏｒｐｏｒａｔｉｏｎ

(74)【代理人】

【識別番号】110000408

【氏名又は名称】特許業務法人高橋・林アンドパートナーズ

(72)【発明者】

【氏名】宋 基 銑

(72)【発明者】

【氏名】文 鍾 皓

(72)【発明者】

【氏名】金 水 亨

(72)【発明者】

【氏名】李 鉉 傑

【審査官】 大桃 由紀雄

(56)【参考文献】

【文献】 特開２００６−０９９１６４（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

クライアントからのデータアクセス要請に応じてマルチマスター方式によって動作する複数のノードのうち一つを選択し、前記選択されたノードが前記データアクセス要請を受信し、
前記選択されたノードが前記データアクセス要請を処理する前に、前記データアクセス要請のマルチキャスト要請をメッセージングチャネルに送信し、
前記メッセージングチャネルが前記マルチキャスト要請を受信して前記データアクセス要請を前記複数のノードにマルチキャストし、
前記複数のノードそれぞれが前記マルチキャストを受信したときに前記データアクセス要請を処理すること、
を含み、
前記複数のノードは、前記データアクセス要請のデータに対する複製を含み、
前記複数のノードの各々は他のノードと直接的に通信せず、互いに前記データアクセス要請を送信しない
ことを特徴とするデータ管理方法。

【請求項2】

前記メッセージングチャネルがクライアントから前記データアクセス要請を受信し、
前記メッセージングチャネルが前記複数のノードのうち前記選択されたノードを決定し、
前記メッセージングチャネルが前記データアクセス要請を前記選択されたノードに送信すること、
をさらに含むことを特徴とする請求項１に記載のデータ管理方法。

【請求項3】

データアクセス要請をメッセージングチャネルによって受信し、
前記メッセージングチャネルから前記データアクセス要請を、マルチマスター方式によって動作する複数のノードから選択されたノードに送信し、
前記選択されたノードが前記データアクセス要請を処理する前に、前記データアクセス要請のマルチキャスト要請をメッセージングチャネルに送信し、
前記複数のノードに前記メッセージングチャネルによって前記データアクセス要請を送信し、
前記複数のノードのそれぞれが前記データアクセス要請を受信したときに前記データアクセス要請を処理すること
を含み、
前記複数のノードは、前記データアクセス要請が要請するデータに対する複製を含むノードであり、
前記複数のノードの各々は他のノードと直接的に通信せず、互いに前記データアクセス要請を送信しない
ことを特徴とするデータ管理方法。

【請求項4】

前記ノードを決定するステップは、ラウンドロビン方式またはロードバランシングに基づいて前記複数のノードのうち前記選択されるノードを決定することを特徴とする請求項２に記載のデータ管理方法。

【請求項5】

クライアントからのデータアクセス要請に応じてマルチマスター方式によって動作する複数のノードのうち選択されたノードに前記データアクセス要請をメッセージングチャネルによって送信し、
前記選択されたノードが前記データアクセス要請を処理する前に、前記データアクセス要請のマルチキャスト要請を前記選択されたノードによってメッセージングチャネルに送信し、
前記メッセージングチャネルからマルチキャストを介して前記データアクセス要請を前記複数のノードによって受信し、
前記複数のノードのそれぞれが前記マルチキャストを受信したときに前記データアクセス要請を処理すること、
を含み、
前記複数のノードの各々は他のノードと直接的に通信せず、互いに前記データアクセス要請を送信しない
ことを特徴とするデータ管理方法。

【請求項6】

同一のデータの複製を含む複数のノードと、
データアクセス要請を前記複数のノードに送信するメッセージングチャネルと、
を含み、
前記複数のノードのいずれか１つのノードは、前記メッセージングチャネルから前記データアクセス要請を受信した後、前記データアクセス要請を処理する前に前記データアクセス要請のマルチキャスト要請を前記メッセージングチャネルに送信し、前記メッセージングチャネルは、前記マルチキャスト要請を受信して前記データアクセス要請を前記複数のノードにマルチキャストし、前記複数のノードそれぞれは、前記マルチキャストを受信したときに前記データアクセス要請を処理し、
前記複数のノードの各々は他のノードと直接的に通信せず、互いに前記データアクセス要請を送信しない
ことを特徴とするデータ管理システム。

【請求項7】

前記メッセージングチャネルは、クライアントからデータアクセス要請を受信し、前記複数のノードのいずれか１つのノードを選択して前記データアクセス要請を前記選択されたノードに送信することを特徴とする請求項６に記載のデータ管理システム。

【請求項8】

前記メッセージングチャネルは、ラウンドロビン方式またはロードバランシングに基づいて前記複数のノードのうち前記１つのノードを選択することを特徴とする請求項７に記載のデータ管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データを格納するための装置及び方法に関する。本発明は、マルチマスタモデルに基づいたデータを複製する装置及び方法を開示し、特に、拡張可能な分散インデックスを用いて、１つ以上の格納領域内にデータを分散して格納する装置及び方法を開示する。

【背景技術】

【0002】

データ格納容量を増大させるために、「垂直拡張」及び「水平拡張」が用いられてもよい。垂直拡張は、データを格納するためにより仕様の優れた機器を用いる方法を意味する。水平拡張は、データを格納する機器を追加することによってデータ格納容量の拡大を試みる方法である。垂直拡張は機器が処理できる容量を超過したデータを処理することができない。したがって、一般に、インターネット企業のような大容量のデータを処理しなければならない複数の企業は、水平拡張を用いて大容量のデータを処理する。

【0003】

一般的に、関係型データベース管理システム（Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ；ＲＤＢＭＳ）には原子性（Ａｔｏｍｉｃｉｔｙ）、一貫性（Ｃｏｎｓｉｓｔｅｎｃｙ）、独立性（Ｉｓｏｌａｔｉｏｎ）及び永続性（Ｄｕｒａｂｉｌｉｔｙ）、すなわちＡＣＩＤ特性が要求される。

【0004】

ＲＤＢＭＳが同一のデータに対する複数の複製（ｒｅｐｌｉｃａ）を維持する場合、ＲＤＢＭＳは複製のために複数の複製のうちマスタ及び１つ以上のスレーブを指定してもよい。ＲＤＢＭＳは、一貫性のために同期化された書込み演算を行なってもよい。一般的な同期化された書込み演算過程は、下記のステップ（１）から（６）の通りである。
（１）クライアントがマスタに書込みを要請
（２）マスタが要請された書込みを行う
（３）マスタがスレーブに書込みを要請
（４）スレーブが要請された書込みを行う
（５）マスタがスレーブから書込み要請に対する応答を受信
（６）マスタがクライアントに書込み結果を通知

【0005】

ＲＤＢＭＳにおいて一貫性は極めて重要である。したがって、スレーブは、マスタと完全に同一の情報を有しなければならない。

【0006】

前述されたステップ（１）から（６）のうち、スレーブで障害が発生すると、ＲＤＢＭＳはＲＤＢＭＳのアーキテクチャーにより書込み演算そのものが失敗したものと見なす。

【0007】

ネットワークの発展に伴って、ネットワークを介してアクセスできる多量のデータが発生している。このようなデータを処理するためにクラウドコンピュータのような分散処理システムが導入されているが、従来におけるＲＤＢＭＳは、このような分散処理システムのための拡張性を支援することができないという限界がある。

【0008】

したがって、従来のＲＤＢＭＳが有するＣ（一貫性（Ｃｏｎｓｉｓｔｅｎｃｙ））及び可用性（ａｖａｉｌａｂｉｌｉｔｙ）特性のいずれか１つを放棄し、Ｐ（分割耐性（Ｐａｒｔｉｔｉｏｎ Ｔｏｌｅｒａｎｃｅ））の特性を導入するための様々な試みが行われた。このような試みのうち、代表的なものがＮｏ−ＳＱＬ（Ｎｏｔ ｏｎｌｙ ＳＱＬ）である。

【0009】

Ｎｏ−ＳＱＬは、キー・バリュー（ｋｅｙ−ｖａｌｕｅｄ）データベース（Ｄａｔａｂａｓｅ；ＤＢ）、ドキュメント指向（ｄｏｃｕｍｅｎｔ−ｏｒｉｅｎｔｅｄ）ＤＢ、グラフＤＢ、及び列指向（ｃｏｌｕｍｎ−ｏｒｉｅｎｔｅｄ）ＤＢなどで区分してもよい。

【0010】

そのうち、ドキュメント指向ＤＢの複製方式は、ＲＤＢＭＳの複製方式に類似する。例えば、ドキュメント指向ＤＢの複製は、マスタ及びスレーブに分類されて行われる。ただし、スレーブに書込みを行うとき、ＲＤＢＭＳは一貫性のために同期化された書込み過程を行うものの、ドキュメント指向ＤＢ（例えば、ＭｏｎｇｏＤＢ）は同期化された書込み及び非同期化された書込みを同時に用いることができる。

【0011】

関係型データベース管理システムはその特性上、水平に拡張されることはできない。したがって、ＲＤＢＭＳを大容量のデータのために用いる場合、シャーディング（ｓｈａｒｄｉｎｇ）（または、データ分割）によってＲＤＢＭＳの全体容量が拡張されてもよい。すなわち、同一のスキーマを用いて異なるデータを格納する１つ以上のＲＤＢＭＳ機器を用いてもよい。

【0012】

１つ以上のＲＤＢＭＳ機器を用いる場合、いずれのＲＤＢＭＳ機器があるかを把握しているアプリケーションサーバを用いてもよく、別途のミドルウェア（ｍｉｄｄｌｅｗａｒｅ）によって実際のデータ位置が隠匿されてもよい。

【0013】

シャーディング（または、データ分割）を用いる場合、より大きな容量のデータを処理するためにＲＤＢＭＳ機器が追加されるとき、１つ以上のＲＤＢＭＳ機器の間にデータを再分配しなければならないという問題が発生する。このようなデータの再分配は、ＲＤＢＭＳ機器の運用中に行われることがある。しかし、データの再分配には時間がかかるため、即時性が落ちるという問題がある。データを分散して格納するために、分散キー・バリューＤＢを用いてもよい。分散キー・バリューＤＢは、一貫するハッシュ（ｃｏｎｓｉｓｔｅｎｔ ｈａｓｈｉｎｇ）方式を用いることによってデータを分散して格納してもよい。一貫するハッシュ方式は、データ拡張において構造的な利点を有する。すなわち、一貫するハッシュ方式を用いるデータ格納システムは、サーバを追加することによって処理可能な全体データ量を増加させることができる。しかし、このようなハッシュ方式は、大小の概念を支援しないため、範囲検索に脆弱であり、２次元以上のデータを処理できない。

【0014】

分散キー・バリューＤＢを用いるシステム内のデータは、ハッシュによって分散する。したがって、範囲検索のために順次に検索結果を取得することができず、検索範囲内のキーをそれぞれ照会しなければならない。

【0015】

例えば、Ａというフィールドの値が１から１０の間のデータを探す場合、ＲＤＢＭＳでは範囲検索のために「ｓｅｌｅｃｔ＊ｆｒｏｍ ｆｏｏ ｗｈｅｒｅ Ａ＞＝１ａｎｄＡ＜＝１０」のようなクエリを用いてもよい。一方、キー・バリューＤＢは、１から１０までのデータをそれぞれ照会しなければならない。

【0016】

したがって、ハッシュを用いるキー・バリューＤＢは、２次元以上のデータを処理する空間的インデックスを有することはできない。すなわち、特定の空間内にあるいずれかのデータを処理しなければならない場合、空間内にあるデータはキー・バリューＤＢの様々なノード（すなわち、サーバ）に分散して格納されているため、様々なノードのいずれのノードでも完全なインデックスを取り揃えることができない。

【発明の概要】

【発明が解決しようとする課題】

【0017】

本発明の目的は、メッセージングチャネルを用いて１つ以上のノードがデータアクセス要請を処理する装置及び方法を提供する。

【0018】

本発明の目的は、データアクセス要請を選択されたノードに送信し、選択されたノードの要請に応じてデータアクセス要請を１つ以上のノードにマルチキャストする装置及び方法を提供する。

【0019】

本発明の目的は、ツリー構造で構成された１つ以上の格納領域を用いてデータを格納する装置及び方法を提供する。

【0020】

本発明の目的は、階層的なキーを用いてデータが格納される格納領域を決定する装置及び方法を提供する。

【課題を解決するための手段】

【0021】

本発明の一実施形態によると、１つ以上のノードのうち選択されたノードがデータアクセス要請を受信し、前記選択されたノードが前記データアクセス要請のマルチキャスト要請をメッセージングチャネルに送信し、前記メッセージングチャネルが前記マルチキャスト要請を受信して前記データアクセス要請を前記１つ以上のノードにマルチキャストし、前記１つ以上のノードそれぞれが前記マルチキャストを受信して前記データアクセス要請を処理することを含み、前記１つ以上のノードは、前記データに対する複製を含むことを特徴とするデータ管理方法が提供される。

【0022】

前記データ管理方法は、メッセージングチャネルがクライアントから前記データアクセス要請を受信すること、前記メッセージングチャネルが前記１つ以上のノードのうち前記選択されたノードを決定すること、前記メッセージングチャネルが前記データアクセス要請を前記選択されたノードに送信すること、をさらに含んでもよい。

【0023】

データアクセス要請は、データの読み出し、書込み、挿入、削除、または更新のいずれか１つ以であってもよい。

【0024】

本発明の他の実施形態によると、データアクセス要請に対するマルチキャスト要請を受信し、１つ以上のノードに前記データアクセス要請を送信すること、を含み、前記１つ以上のノードは、前記データアクセス要請が要請するデータに対する複製を含むノードであることを特徴とするデータ管理方法が提供される。

【0025】

前記データ管理方法は、クライアントから前記データアクセス要請を受信すること、前記１つ以上のノードのうち選択されるノードを決定すること、前記データアクセス要請を前記選択されたノードに送信すること、をさらに含んでもよい。

【0026】

前記ノードを決定することは、ラウンドロビン方式またはロードバランシングに基づいて前記１つ以上のノードのうち前記選択されるノードを決定してもよい。

【0027】

本発明の他の実施形態によると、端末がクライアントからデータアクセス要請を処理する方法において、クライアントによって送信されたデータアクセス要請が送信され、前記データアクセス要請のマルチキャスト要請をメッセージングチャネルに送信し、前記メッセージングチャネルからマルチキャストを介して前記データアクセス要請を受信し、データアクセス要請を処理すること、を含むデータ管理方法が提供される。

【0028】

データアクセス要請が送信されることは、メッセージングチャネルからデータアクセス要請を受信することを含んでもよい。

【0029】

本発明の一実施形態によると、同一のデータの複製を含む１つ以上のノードと、データアクセス要請を前記１つ以上のノードに送信するメッセージングチャネルと、を含み、前記１つ以上のノードのいずれか１つのノードは、前記データアクセス要請のマルチキャスト要請を前記メッセージングチャネルに送信し、前記メッセージングチャネルは、前記マルチキャスト要請を受信して前記データアクセス要請を前記１つ以上のノードにマルチキャストし、前記１つ以上のノードそれぞれは、前記マルチキャストによって前記データアクセス要請を処理することを特徴とするデータ管理システムが提供される。

【0030】

前記メッセージングチャネルは、クライアントからデータアクセス要請を受信し、前記１つ以上のノードのいずれか１つのノードを選択して前記データアクセス要請を前記選択されたノードに送信してもよい。

【0031】

前記メッセージングチャネルは、ラウンドロビン方式またはロードバランシングに基づいて前記１つ以上のノードのうち前記１つのノードを選択してもよい。

【0032】

本発明の一実施形態によると、クライアントからデータアクセス要請を受信する受信部と、データ格納装置においてデータの格納領域を有する１つ以上のノードのうち選択されるノードを決定する制御部と、データアクセス要請を前記選択されたノードに送信する送信部と、を備え、前記受信部は、前記選択されたノードから前記データアクセス要請のマルチキャスト要請を受信し、前記送信部は、前記第１要請を前記１つ以上のノードにマルチキャストすることを特徴とするメッセージングチャネルが提供される。

【0033】

本発明の一実施形態によると、ツリー構造で構成された１つ以上の格納領域を含み（各格納領域は前記ツリーにおける１つのノードに対応）、前記１つ以上の格納領域それぞれには０個以上のサブキーを有する階層的なキーが割り当てられ、前記１つ以上の格納領域のうち任意の第１格納領域をルートにするサブツリー内の格納領域は、前記第１格納領域の第１キーに対応するデータを格納し、前記第１キーは、第２キーに１つ以上のサブキーが連鎖されたキーであり、前記第２キーは、第２格納領域のキーであり、前記第２格納領域は、前記第１格納領域の親格納領域であることを特徴とするデータ格納装置が提供される。

【0034】

前記１つ以上の格納領域のそれぞれは、関係型データベース機器であってもよい。前記１つ以上の格納領域のそれぞれは、関係型データベースのインデックス、キー、および命令を理解および処理するミドルウェアを含んでもよい。

【0035】

前記階層的なキーは、英数字及び区分子を組み合わせた文字列であってもよい。

【0036】

第１キーに対応するデータは、データのキーの接頭語のいずれか１つが前記第１キーと同一のデータを意味してもよい。

【0037】

接頭語は、前記データのキーのｎ個のサブキーのうち前のｉ個のサブキーであってもよい。

【0038】

ｉは１以上ｎ以下であってもよい。

【0039】

前記第１格納領域は、前記第１格納領域のキーに対応するデータのうち、前記第１格納領域の子格納領域のキーに対応しないデータを格納してもよい。

【0040】

前記データ格納装置に第３格納領域を追加する場合、前記第３格納領域の第３キーに対応するデータを前記第１格納領域から前記第３格納領域に移動させ、前記第３格納領域は、前記第１格納領域の子格納領域であってもよい。

【0041】

前記第１格納領域の格納量が予め定義された基準に達したとき、前記第３格納領域の追加及び前記データ移動を行ってもよい。

【0042】

前記第１格納領域は、前記第１格納領域の１つ以上の子格納領域に検索範囲に対応するキーを有するデータの第１目録を要請し、前記第１格納領域が格納したデータのうち、前記検索範囲に対応するデータの第２目録を前記要請に応じて返還された前記第１目録に併合して前記検索範囲に対する結果として返還してもよい。

【0043】

本発明の一実施形態によると、１つ以上の格納領域をツリー構造で構成し（各格納領域は前記ツリーにおける１つのノードに対応）、前記１つ以上の格納領域それぞれに０個以上のサブキーを有する階層的なキーを割り当て、前記１つ以上の格納領域のうち、任意の第１格納領域をルートにするサブツリー内の格納領域内に前記第１格納領域の第１キーに対応するデータを格納することを含み、前記第１キーは、第２キーに１つ以上のサブキーが連鎖されたキーであり、前記第２キーは、第２格納領域のキーであり、前記第２格納領域は、前記第１格納領域の親格納領域であることを特徴とするデータ格納方法が提供される。

【0044】

前記格納することは、第１格納領域のキーに対応するデータのうち、第１格納領域の子格納領域のキーに対応しないデータを第１格納領域に格納することを含んでもよい。

【0045】

前記データ格納方法は、第１格納領域の子格納領域として、１つ以上の格納領域に検索範囲に第３格納領域を追加すること、第３格納領域の第３キーに対応するデータを第１格納領域から第３格納領域に移動させること、をさらに含んでもよい。

【0046】

前記第３格納領域を追加することおよび前記データを移動させることは、第１格納領域の格納量が予め定義された基準に達したとき行なわれてもよい。

【0047】

前記データ格納方法は、第１格納領域の１つ以上の子格納領域に検索範囲に対応するキーを有するデータの第１目録を要請しと、１つ以上の子格納領域が第１目録を返還し、第１格納領域が格納したデータのうち、検索範囲に対応するデータの第２目録を返還された第１目録に併合して検索範囲に対する結果として返還すること、をさらに含んでもよい。

【発明の効果】

【0048】

本発明によると、マルチキャストを介して１つ以上のノードが同時にデータ要請を処理することによって、データの一貫性を維持する装置及び方法を提供することができる。

【0049】

本発明によると、１つ以上のノードがメッセージングチャネルとの接続のみを維持することによって、ノードの挿入、削除、または故障を容易に処理できるデータ管理システムを提供することができる。

【0050】

本発明によると、ロードバランシングを考慮して、１つ以上のノードのうちクライアントのデータアクセス要請を処理するノードを選択する装置及び方法を提供することができる。

【0051】

本発明によると、ツリー構造で構成された１つ以上の格納領域を用いてデータを格納する装置及び方法を提供することができる。

【0052】

本発明によると、階層的なキーを用いてデータが格納される格納領域を決定する装置及び方法を提供することができる。

【0053】

本発明によると、データを格納することによって、ツリー構造で格納領域を拡張し、拡張された格納領域にデータを移動する装置及び方法を提供することができる。

【0054】

本発明によると、クエリを子ノードに対応する子格納領域に送信し、子格納領域から返還されたデータ目録をクエリの検索結果として併合して返還する装置及び方法を提供することができる。

【図面の簡単な説明】

【0055】

【図1】マスタ−スレーブ構造における非同期的な書込みを説明するための図である。

【図2】マルチマスタの複製方式を説明するための図である。

【図3】本発明の一例に係るデータ管理システムの構造を示す図である。

【図4】本発明の一実施形態に係るデータ管理方法の信号フローチャートである。

【図5】本発明の一例に係るデータ管理方法の信号フローチャートである。

【図6】本発明の一実施形態に係るメッセージングチャネルのブロック図である。

【図7】本発明の一実施形態に係るデータ格納装置を示す図である。

【図8】本発明の一例に係るデータ格納装置に格納領域を追加する過程を説明するための図である。

【図9】本発明の一例に係るデータ格納装置に対する範囲検索を説明するための図である。

【図10】本発明の一実施形態に係るデータ格納方法のフローチャートである。

【図11】本発明の一実施形態に係るデータ格納装置おける拡張方法のフローチャートである。

【図12】本発明の一例に係るデータ格納装置の範囲検索のフローチャートである。

【発明を実施するための形態】

【0056】

以下、本発明の一実施形態を図面を参照しながら詳細に説明する。しかし、本発明は、以下の実施形態に制限されることはなく、限定されることもない。各図面に示された同一の参照符号は同一の部材を示す。

【0057】

後述する本発明の実施形態は、キー・バリューＤＢを用いる分散処理システムをマルチマスタ方式により実現する方法を提供する。

【0058】

データ管理システムを実現するとき、障害対応（ｆａｕｌｔ ｔｏｌｅｒａｎｃｅ）及びロードバランシング（ｌｏａｄ ｂａｌａｎｃｉｎｇ）などのために、同一のデータを有する複数のノードが構成される必要がある。ノードは、いずれかの作業を処理する１つの単位を意味する。例えば、ノードは、１つの物理的又は論理的なサーバ（または、ＤＢ）であってもよい。

【0059】

本発明においてクラスタは、複数の複製から構成された１つの集合を意味する。クラスタは、１つ以上のノードを含んでもよい。クラスタ内の１つ以上のノードは、クライアントに同一のデータを提供する。

【0060】

図１は、マスタ−スレーブ構造における非同期的な書込みを説明するための図である。

【0061】

前述された一貫性の代わりに、可用性または性能に重点をおく場合、複製のために様々な方式が用いられる。例えば、マスタ−スレーブ構造でも非同期化された書込みが適用されてもよい。Ｎｏ−ＳＱＬでマスタ−スレーブモデルを用いて複製が２つ以上ある場合、複製のいずれか１つ（または、１つ以上）に対しては同期化された書込みが適用されてもよく、残りの複製には非同期化された書込みが適用されてもよい。

【0062】

マスタ−スレーブ構造における非同期的な書込み過程は、下記のステップ（１）からステップ（４）の通りである。
（１）クライアント１１０が書込み要請１５０
（２）マスタ１２０が要請された書込みを行う１６０
（３）マスタ１２０がスレーブ１３０（または、１つ以上のスレーブ１３２、１３４及び１３６）に非同期的な書込みを要請１７０
（４）マスタ１２０がクライアント１１０に書込み結果を通知１８０

【0063】

上記のようなステップで、スレーブ１３０で入出力（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ；ＩＯ）が行われるときは、クライアント１１０が書込み要請の結果を把握するときと重なる。したがって、スレーブ１３０に障害が発生することで書込みが正しく行われない場合、後に一貫性において問題が生じる。

【0064】

図２は、マルチマスタの複製方式を説明する。

【0065】

データの一貫性が重要な（すなわち、複数のデータのいずれもが正しいデータであることが重要な）ＲＤＢＭＳは、マスタ−スレーブモデルを用いるが、Ｎｏ−ＳＱＬを用いるＤＢはマルチ（Ｍｕｌｔｉ）マスタ（または、Ｎｏ−マスタ）の複製方式を用いてもよい。

【0066】

マルチマスタモデルが用いられる場合、複製の数を初期に指定する必要がある。

【0067】

第１ノード２１０、第２ノード２２０、及び第３ノード２３０は、それぞれマルチマスタモデルの複製である。

【0068】

マルチマスタモデルを用いるシステムでは、同一の内容を格納する複製それぞれに異なるクライアントがアクセスして情報を更新することで、一貫性を有さない情報が様々なクライアントに送信されることがある。

【0069】

２つのクライアントがそれぞれ第１ノード２１０及び第３ノード２３０に対して情報Ａの更新を要請すると、次に情報Ａを読込んだクライアントは、いつ、どのノード（例えば、第１ノード２１０または第３ノード２３０）を介して情報Ａにアクセスするかに応じて、異なる値を取得する。情報Ａに対する更新された内容が異なるノードで全て複製される前にクライアントが情報Ａを読込む場合、クライアントはどのノードを介して情報Ａをアクセスしたかに応じて異なる値を取得する。または、第１ノード２１０及び第３ノード２３０でＡに対する更新が互いに異なるように行われた場合、クライアントはどのノードを介して情報Ａにアクセスしたかに応じて異なる値を取得する。

【0070】

前述されたように、明示的なマスタがない状態で、複製関係にある異なる複数のノードそれぞれにほとんど同時に情報更新が要請された場合、どのノードが有する情報が正しいのかを把握する必要がある。

【0071】

したがって、マルチマスタモデルを用いるシステムは、情報を読み出すときに情報に対する補正を行う。このような補正は、読み出し補正（ｒｅａｄ ｒｅｐａｉｒ）であり、読み出し補正はシステムの読み出し性能を低下させる恐れがある。

【0072】

図３は、本発明の一例に係るデータ管理システムの構造を示す図である。

【0073】

データ管理システム３００（以下、システム３００と称する）は、複製を用いてデータを格納するシステムである。システム３００は、メッセージングチャネル３２０及び１つ以上のノード３３０を含む。システム３００は、レベル（Ｌｅｖｅｌ；Ｌ）４スイッチ３２５をさらに含んでもよい。

【0074】

説明の便宜のために、図示された１つ以上のノード３３０は、同一のデータを格納及び提供する複製（クラスタ）を示す。１つ以上のノード３３０は、マルチマスタ方式によって動作されてもよい。図示していないが、システム３００は、他のデータに対する複製を含む複数のノードをさらに含んで構成されてもよい。

【0075】

システム３００は、クライアント３１０からのデータアクセス要請を処理する。データアクセス要請は、システム３００内の特定データに対する読み出し（ｒｅａｄ）、書込み（ｗｒｉｔｅ）、挿入（ｉｎｓｅｒｔ）、削除（ｄｅｌｅｔｅ）、または、更新（ｕｐｄａｔｅ）要請であってもよい。

【0076】

クライアント３１０は複数であってもよい。すなわち、システム３００は、各クライアント３１０からデータアクセス要請を受信してもよく、データアクセス要請を処理してもよい。クライアント３１０は、データの要請を示す要請メッセージを送信することによって、シスム３００にデータを要請する。

【0077】

メッセージングチャネル３２０は、システムでクライアント３１０とデータを格納している１つ以上のノード３３０との間のメッセージを処理するミドルティア（ｍｉｄｄｌｅ−ｔｉｅｒ）の役割を行う。メッセージングチャネル３２０は、ルータの役割を行うメッセージ基盤ミドルウェア（Ｍｅｓｓａｇｅ Ｏｒｉｅｎｔｅｄ Ｍｉｄｄｌｅｗａｒｅ；ＭＯＭ）またはメッセージ基盤ミドルウェアが搭載されたサーバであってもよい。また、メッセージングチャネル３２０は、処理容量を拡張するために、複数のサーバまたはソフトウェアデーモン（ｄａｅｍｏｎ）で構成されてもよい。

【0078】

メッセージングチャネル３２０と接続される１つ以上のノード３３０は、固有のアドレス体系を用いる。メッセージングチャネル３２０で各ノードにメッセージを送信するためにアドレスを指定する方法は、（１）ユニキャスト（ｕｎｉｃａｓｔ）、（２）エニーキャスト（ａｎｙｃａｓｔ）、及び（３）マルチキャスト（または、ブロードキャスト）のいずれか１つ以上であってもよい。アドレスを指定する方法に応じて、メッセージングチャネル３２０が接続されたノードにメッセージを送信する方式が異なる。

【0079】

ユニキャストは、固有アドレスによって指定された１つのノードにのみメッセージングチャネル３２０がメッセージを送信する方式である。エニーキャストは、メッセージングチャネル３２０がいずれかの群（ｄｏｍａｉｎ）の１つのノードにのみメッセージを送信する方式である。メッセージングチャネル３２０は、各ノード３３２、３３４、または３３６とユニキャストまたはエニーキャストでメッセージまたはデータを送受信する。例えば、メッセージングチャネル３２０は、データアクセス要請を処理するために、選択された特定ノードにユニキャストまたはエニーキャスト方式を用いて要請メッセージを送信する。

【0080】

マルチキャストは、いずれもの群の全てのノードにメッセージを送信する方式である。メッセージングチャネル３２０は、同一のデータを有する１つ以上のノード（すなわち、クラスタ）を１つの群として指定し、メッセージをマルチキャストしてもよい。したがって、メッセージングチャネル３２０は、特定のデータアクセス要請をマルチキャストして該当クラスタ内の全てのノードがデータアクセス要請を受信できるようにする。メッセージングチャネル３２０は、群に関する情報を管理する管理部またはこれを管理する別途のサーバをさらに含んで構成してもよく（図示せず）、ノードの追加または除去するときに新しいノードに関する情報をアップデートしてもよい。

【0081】

ここで、各ノード３３２、３３４、または３３６は、メッセージングチャネル３２０にのみ接続されるだけであって、各ノード相互間は通信することができない。この場合、ノードの追加または削除が発生する場合、新しいノードまたは削除されたノードに関する情報は、メッセージングチャネル３２０にのみ送信されてもよい。

【0082】

クライアント３１０がメッセージングチャネル３２０のプロトコルを把握している場合、クライアント３１０は、メッセージングチャネル３２０に直接データアクセス要請を送信してもよい。または、クライアント３１０は、各ノード３３２、３３４または３３６に直接データアクセス要請を送信してもよい。この過程において、アクセス要請は、ネットワーク上に位置するＬ４スイッチ３２５を経由してもよい。Ｌ４スイッチ３２５は、仮想ＩＰ（ｖｉｒｔｕａｌ ＩＰ；ＶＩＰ）によって１つ以上のノード３３０を管理する。クライアント３１０がＶＩＰを用いてデータアクセス要請を送信すると、ＶＩＰを有するＬ４スイッチ３２５は、データアクセス要請を受信した後、受信されたデータアクセス要請を１つ以上のノード３３０で適切に分配する。

【0083】

下記では、メッセージングチャネル３２０を用いて１つ以上のノード３３０の全てが同一のデータを維持及び提供する方法について説明する。また、下記の方法を用いることによってマルチマスタ複製が実現されることができる。

【0084】

図４は、本発明の一実施形態に係るデータ管理方法の信号フローチャートである。

【0085】

本実施形態において、端末（すなわち、第１ノード３３２、第２ノード３３４及び第３ノード３３６）は、クライアント３１０からのデータアクセス要請を処理する。

【0086】

ステップＳ４１０において、クライアント３１０はメッセージングチャネル３２０にデータアクセス要請を行う。データアクセス要請は、特定のデータ（例えば、オブジェクト）の読み出し、書込み、挿入、削除、または更新のいずれか１つ以上であってもよい。メッセージングチャネル３２０は、クライアント３１０からデータアクセス要請を受信する。

【0087】

ステップＳ４２０において、メッセージングチャネル３２０は、データアクセス要請に対して特定データを含むノードで構成されたクラスタから１つのノードを選択する。説明の便宜のために図４に示された１つ以上のノード３３０（すなわち、第１ノード３３２、第２ノード３３４、および第３ノード３３６を含むクラスタ）が、要請されたデータを含むノードの集合という。したがって、メッセージングチャネルは３２０は、１つ以上のノード３３０から１つのノードを選択する。メッセージングチャネル３２０は、ラウンド・ロビン（ｒｏｕｎｄ−ｒｏｂｉｎ）方式などを利用したり、ロードバランシングに基づいて選択されたノードを決定してもよい。本実施形態では、第２ノード３３４が選択された場合について説明する。

【0088】

ステップＳ４３０において、メッセージングチャネル３２０は、選択されたノード（すなわち、第２ノード３３４）にデータアクセス要請を送信する。

【0089】

選択されたノード（すなわち、第２ノード３３４）は、メッセージングチャネル３２０からクライアント３１０によって送信されたデータアクセス要請を受信する。ここで、データアクセス要請を受信した選択されたノード（第２ノード３３４）は、直ちにデータアクセス要請に対する処理（例えば、データの挿入または削除）を行わない場合がある。

【0090】

もし、データアクセス要請がデータに対する読み出し要請である場合、下記のステップＳ４４０、Ｓ４５０、Ｓ４６２、Ｓ４６４、及びＳ４６６を行わなくてもよい。この場合、データは選択されたノード（第２ノード３３４）からメッセージングチャネル３２０を経由してクライアント３１０に送信されてもよく、または、クライアント３１０に直接送信されてもよい。

【0091】

ステップＳ４４０において、選択されたノード（第２ノード３３４）は、データアクセス要請に対するマルチキャスト要請をメッセージングチャネル３２０に送信する。メッセージングチャネル３２０は、選択されたノード（第２ノード３３４）からマルチキャスト要請を受信する。

【0092】

ステップＳ４５０において、メッセージングチャネル３２０は、データアクセス要請を１つ以上のノード３３０にマルチキャストする。マルチキャストの対象は１つ以上のノード３３０（すなわち、選択されたノードの全ての複製）である。マルチキャストを要請する選択されたノード（第２ノード３３４）自体にも、マルチキャストを介してデータアクセス要請が送信される。１つ以上のノード３３０それぞれは、マルチキャストされたデータアクセス要請を受信する。

【0093】

メッセージングチャネル３２０がマルチキャストしたデータアクセス要請は、１つ以上のノード３３０に（論理的に）同時に到着する。また、１つ以上のノード３３０それぞれは、マルチキャストを介してデータアクセス要請を受信したとき、実際にデータアクセス要請を処理してもよい。

【0094】

ステップＳ４６２、Ｓ４６４、及びＳ４６６において、１つ以上のノード３３０それぞれは、マルチキャストされたデータアクセス要請を処理する。例えば、１つ以上のノード３３０それぞれは、受信されたデータアクセス要請に応じてデータの書込み、挿入、削除、または更新作業などを行う。

【0095】

したがって、メッセージングチャネル３２０が複数のデータアクセス要請を順次マルチキャストすることによって、１つ以上のノード３３０は、全て同一の順序で複数のデータアクセス要請を処理することができる。システム３００は、アクセス要請の順序を把握するために、システム３００内の全てのノードを時間同期化してもよく、各要請に対するタイムスタンプを用いてもよい。システム３００は、時間同期化のためにＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を用いてもよい。したがって、１つ以上のノード３３０が、管理するデータの一貫性を維持することができる。

【0096】

図５は、本発明の一例に係るデータ管理方法の信号フローチャートである。

【0097】

ステップＳ５１０において、選択されたノード（すなわち、第２ノード３３４）は、データアクセス要請を受信する。

【0098】

データアクセス要請は、クライアント３１０から直接に送信されたものであってもよい。

【0099】

データアクセス要請は、Ｌ４スイッチ３２５を経由して送信されたものであってもよい。Ｌ４スイッチ３２５は、クライアント３１０からデータアクセス要請を受信する。Ｌ４スイッチ３２５は、１つ以上のノード３３０のうち１つのノードを選択し、データアクセス要請を選択されたノードに送信する。Ｌ４スイッチ３２５は、ラウンド・ロビン方式などを用いたり、ロードバランシングに基づいて選択されたノードを決定してもよい

【0100】

ここで、データアクセス要請を受信した選択されたノード（第２ノード３３４）は、直ちにデータアクセス要請に対する処理を行わない場合がある。

【0101】

ステップＳ５２０において、選択されたノード（第２ノード３３４）は、データアクセス要請に対するマルチキャストをメッセージングチャネル３２０に要請する。すなわち、選択されたノード（第２ノード３３４）は、データアクセス要請のマルチキャスト要請をメッセージングチャネル３２０に送信する。メッセージングチャネル３２０は、選択されたノード（すなわち、第２ノード３３４）からデータアクセス要請に対するマルチキャスト要請を受信する。

【0102】

ステップＳ５４０において、メッセージングチャネル３２０は、データアクセス要請を１つ以上のノード３３０にマルチキャストする。マルチキャストの対象は、１つ以上のノード３３０（すなわち、選択されたノードの全ての複製）である。マルチキャストを要請する選択されたノード（第２ノード３３４）自体にも、マルチキャストを介してデータアクセス要請が送信される。１つ以上のノード３３０それぞれは、マルチキャストされたデータアクセス要請を受信する。

【0103】

ステップＳ５５２、ステップＳ５５４、ステップＳ５５６において、１つ以上のノード３３０それぞれは、マルチキャストを介して受信されたデータアクセス要請を処理する。

【0104】

例えば、１つ以上のノード３３０それぞれは、受信されたデータアクセス要請に応じてデータの挿入、削除、または更新作業を行う。各ノード（例えば、第１ノード３３２、第２ノード３３４、または第３ノード３３６）は、データアクセス要請をマルチキャストを介して受信した後、データアクセス要請を処理する。データアクセス要請をマルチキャストするメッセージングチャネル３２０は、各ノードの立場におけるデータアクセス要請の順序を把握することができる。システム３００はアクセス要請の順序を把握するため、システム３００内の全てのノードを時間同期化してもよく、各要請に対するタイムスタンプを用いてもよい。システム３００は、時間同期化のためにＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を用いてもよい。したがって、メッセージングチャネル３２０は、複数のノードが互いに異なるデータを提供する場合、いずれのデータが正しいデータであるかを常に把握できる。したがって、システム３００は、マルチマスタモデルを使用するにもかかわらず、読み出し補正を行うことなくクライアント３１０にデータを提供することができる。

【0105】

１つ以上のノード３３０のうち、特定ノードに障害が発生したり、１つ以上のノード３３０から特定ノードを削除するとき、または、１つ以上のノード３３０に特定ノードを追加するとき、メッセージングチャネル３２０は、障害、削除、または追加に関する情報を把握することができる。

【0106】

したがって、図４及び図５を参照して前述した方法は、便宜または目的などに応じてクラスタ内に複製（すなわち、ノード）を自由に追加及び削除できる柔軟な拡張性を提供することができる。また、前述した方法は、クラスタ内のいずれのノードでデータ照会を処理しても同一の結果を提供することができる。したがって、ロードバランシングの効果が提供される。

【0107】

図４及び図５を参照して前述した実施形態では、１つ以上のノード３３０それぞれは、他のノードと直接的に通信せず、自身以外にはどのようなノードが存在するかも把握できないまま動作する。

【0108】

したがって、１つ以上のノード３３０に特定ノード（すなわち、複製）が追加または削除される場合、追加または削除の処理は、メッセージングチャネル３２０に対してのみ行われ、他のノードは追加または削除に影響を受けることなく動作することができる。

【0109】

例えば、システム拡張のために１つのノードが追加される場合、該当ノードはメッセージングチャネル３２０に該当ノードに関する情報を送信し、メッセージングチャネル３２０との接続を生成する。その後には、該当ノードが含んでいるデータアクセスの要請を受けてもよい。

【0110】

一方、メッセージングチャネル３２０は、各ノードの状態をチェックしてもよい。例えば、メッセージングチャネル３２０はハートビット（ｈｅａｒｔｂｅａｔ）メッセージを周期的に受信したり、メッセージ送信に対する応答有無に基づいてシステムの障害有無を判別する。または、システム上、必要に応じて特定ノードを除去する場合、メッセージングチャネル３２０に除去されたノードに関する情報が送信されてもよい。もし、１つのノードに障害が発生したと判断されたり、特定ノードが除去される場合、メッセージングチャネル３２０は、該当ノードにこれ以上のメッセージを送信しない。このようにノードがなくなる場合、メッセージングチャネル３２０は、必要に応じて複製数を維持するための移動作業を指示してもよい。

【0111】

このようにシステム３００、はノードの挿入、削除、または故障を容易に処理することができる。

【0112】

図６は、本発明の一実施形態に係るメッセージングチャネル３２０のブロック図である。

【0113】

メッセージングチャネル３２０は、受信部６１０、制御部６２０、及び送信部６３０を備える。

【0114】

受信部６１０は、ネットワークを介してデータを受信する。例えば、ステップＳ４１０及びステップＳ５１０で、受信部６１０はクライアント３１０からデータアクセス要請を受信する。また、ステップＳ４４０及びステップＳ５４０で、受信部６１０は、選択されたノードからデータアクセス要請の１つ以上のノード３３０へのマルチキャスト要請を受信する。

【0115】

制御部６２０は、例えば、ステップＳ４２０において、１つ以上のノード３３０のうち選択されるノードを決定する。制御部６２０はラウンドロビンまたはロードバランシングに基づいて１つ以上のノード３３０のうち選択されるノードを決定してもよい。

【0116】

送信部６３０は、ネットワークを介してデータを送信する。例えば、ステップＳ４３０において、送信部６３０は、選択されたノードにデータアクセス要請を送信する。また、ステップＳ４５０及びステップＳ５４０において、送信部６３０は、データアクセス要請を１つ以上のノード３３０にマルチキャストする。

【0117】

一方、メッセージングチャネル３２０は、ノード情報を管理する管理部（図示せず）をさらに備えてもよい。管理部は、ノードの情報、同一のデータの複製であるクラスタ情報を管理してもよく、メッセージングチャネル３２０がクラスタを１つの群として取り扱ってブロードキャスティングできるようにする。管理部では、ノードの追加または除去時に新しいノードに関する情報をアップデートしてもよい。

【0118】

先に図１から図５を参照して説明された本発明の一実施形態に係る技術的な内容が本実施形態にそのまま適用されてもよい。したがって、本詳細な説明は以下では省略する。

【0119】

図７は、本発明の一実施形態に係るデータ格納装置を示す図である。

【0120】

データ格納装置７００は、１つ以上の格納領域７１０、７２０、７３０、７４０及び７５０を備えてもよい。ここで「格納領域」とは、データを格納する物理的または論理的な空間を意味する。例えば、「格納領域」とは、１つの関係型データベースまたはファイルシステム、あるいは同一のデータに対する複製の集合である分散クラスタであってもよい。

【0121】

データ格納装置７００は、図３から図６を参照して説明した第１ノード３３２、第２ノード３３４及び第３ノード３３６の１つ以上に対応してもよい。

【0122】

各格納領域は、論理的にツリー形態の階層的な構造を有してもよい。言い換えれば、各格納領域は、ツリーにおける１つのノードに対応し、任意の２つの格納領域の間には２つの格納領域に対応するノード間の関係によって親−子関係または兄弟関係などが成り立つ。

【0123】

図７を参照すると、第１格納領域７１０はツリー構造のルートノードに、第２格納領域７２０及び第３格納領域７３０はそれぞれ第１格納領域７１０の右側の子ノード及び左側の子ノードに対応する。第１格納領域７１０は、第２格納領域７２０及び第３格納領域７３０の親格納領域である。第２格納領域７２０は、第１格納領域７１０の（左側）子格納領域である。第２格納領域７２０は、第３格納領域７３０の兄弟格納領域である。第４格納領域７４０及び第５格納領域７５０はそれぞれ第３格納領域７３０の左側の子ノード及び右側の子ノードに対応する。

【0124】

格納領域７１０、７２０、７３０、７４０及び７５０それぞれには、各格納領域を識別するためのキー（ｋｅｙ）が割り当てられてもよい。このキーは、格納領域との間の階層構造を表すことができる形態で構成される。例えば、１つのキーは、１つ以上のサブキー（ｓｕｂ−ｋｅｙ）及びこれを区分する区分子（ｓｅｐａｒａｔｏｒ）を含んで構成されてもよい。ここで、サブキーは、任意のサブツリー内の全てのノードを代表する値になる。図７を参照すると、「ｋｏｒｅａ」は第１格納領域７１０をルートにするサブツリーを代表するキーであり、「ｓｅｏｕｌ」は第３格納領域７３０をルートにするサブツリーを代表するキーある。図７において、「ｋｏｒｅａ」、「ｋｙｅｏｎｇｇｉ」「ｓｅｏｕｌ「ｋａｎｇｂｕｋ」「ｋａｎｇｎａｍ」などはそれぞれ１つのサブキーであり、「．」を区分子として用いて「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ」のような１つのｋｅｙを構成する。

【0125】

下記の数式（１）はこのように階層的なキーを示す正規式の一例である。

【数1】

（１）
ここで、ｋｅｙは階層的なキーを示し、ｋｅｙは英数字（ａｌｐｈａｎｕｍｅｒｉｃ）と区分子「．」で組合わせた文字列（ｓｔｒｉｎｇ）である。

【0126】

一般的な英文字、数字及び区分子「．」を用いる場合、キーは数式（１）のように表わすことができるが、本発明はこれに限定されることなく他の文字を含んだり、または、他の形態の区分子を用いてもよい。また、キーが必ず１つの文字列で構成される必要はなく、例えば、リンクリスト（ｌｉｎｋｅｄ ｌｉｓｔ）のような形態で構成してもよい。以下では区分子などに区分されたサブキーを順に第１サブキー、第２サブキー、．．および第ｎサブキーとする。ルートノードのレベルを１とするとき、レベルｎに位置するノードに対応する格納領域を識別するキーはｎ個のサブキーを含む。

【0127】

一方、ルートノードに対応する格納領域のキーは空白（ｎｕｌｌ）であってもよい。このような場合、ルートノードは０個のサブキーを、レベルｎに位置するノードに対応する格納領域を識別するキーはｎ−１個のサブキーを含んでもよい。例えば、階層的なキーは、数式（１）の正規式によって生成された文字列または空白文字列であってもよい。

【0128】

図７において、第１格納領域７１０に割り当てられたキー７１５は、「ｋｏｒｅａ」である。キー７１５は、第１サブキー「ｋｏｒｅａ」のみを有する。

【0129】

第２格納領域７２０に割り当てられたキー７２５は、「ｋｏｒｅａ．ｇｙｅｏｎｇｇｉ」である。キー７２５は、第１サブキー「ｋｏｒｅａ」及び第２サブキー「ｇｙｅｏｎｇｇｉ」を有する。第３格納領域７３０に割り当てられたキー７３５は、「ｋｏｒｅａ．ｓｅｏｕｌ」である。キー７３５は、第１サブキー「ｋｏｒｅａ」及び第２サブキー「ｓｅｏｕｌ」を有する。第４格納領域７４０に割り当てられたキー７４５は、「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｂｕｋ」である。キー７３５は、第１サブキー「ｋｏｒｅａ」、第２サブキー「ｓｅｏｕｌ」及び第３サブキー「ｋａｎｇｂｕｋ」を有する。第５格納領域７５０に割り当てられたキー７５５は、「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ」である。キー７５５は、第１サブキー「ｋｏｒｅａ」、第２サブキー「ｓｅｏｕｌ」及び第３サブキー「ｋａｎｇｎａｍ」を有する。

【0130】

格納領域に割り当てられたキーは、格納領域の親格納領域のキーに１つ以上のサブキーが連鎖されたキーであってもよい。例えば、第４格納領域７４０に割り当てられたキーは、第４格納領域の親格納領域である第３格納領域７３０のキー「ｋｏｒｅａ．ｓｅｏｕｌ」にサブキー「ｋａｎｇｂｕｋ」が連鎖されたキーである。

【0131】

すなわち、格納領域ｐ及び格納領域ｃが互いに親格納領域及び子格納領域の関係にある場合、親格納領域ｐのキーｋｐが第１サブキーｓｋ１から第ｎサブキーｓｋｎを含むと（ここで、ｎは１以上の整数である）、子格納領域ｃのキーｋｃは第１サブキーｓｋ１から第ｎｓｋｎを含み、第ｎ＋１サブキーｓｋ（ｎ＋１）から第ｍサブキーｓｋｍを含んでもよい。ここで、ｍはｎ＋１以上の整数である。

【0132】

本発明の一実施形態によると、データ格納装置７００は、データを各格納領域のキーに応じて分類して格納する。データはキーを有する。データのキーは、データの分類体系に用いられる識別子である。データのキーは、データの分類体系の上位置を表してもよい。データ格納装置７００内のツリー構造が分類体系を表す場合、データはデータのキー値に応じて特定の格納領域（または、格納領域のキー）に対応する。

【0133】

特定の格納領域を示すノードをルートにしたサブツリーにおいて、サブツリー内の格納領域は特定の格納領域のキーに対応するデータを格納する。

【0134】

例えば、第３格納領域７３０をルートにしたサブツリー７６０において、サブツリー７６０内の格納領域７３０、７４０及び７５０は、第３格納領域７３０のキー７３５「ｋｏｒｅａ．ｓｅｏｕｌ」に対応するデータを格納する。

【0135】

また、第４格納領域７４０をルートにしたサブツリーは、第４格納領域７４０のみを含む。したがって、第４格納領域７４０は、第４格納領域７４０のキー７４５「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｂｕｋ」に対応するデータを格納してもよい。

【0136】

また、第５格納領域７５０をルートにしたサブツリーは、第５格納領域７５０のみを含む。したがって、第５格納領域７５０は、第５格納領域７５０のキー７５５「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ」に対応するデータを格納してもよい。

【0137】

ここで、格納領域のキーに対応するデータは、データのキーの接頭語（ｐｒｅｆｉｘ）のいずれか１つが格納領域のキーと同一のデータを意味する。

【0138】

キーｘの接頭語とは、階層的なキーｘがｎ個のサブキーｘ１、ｘ２、ｘ３、．．．、ｘｎを含むとき、ｘのサブキーのうちのｉ個（ｉは１以上ｎ以下）のサブキーを含むキーを意味する。例えば、階層的なキー「ａ．ｂ．ｃ」の接頭語は「ａ」、「ａ．ｂ」及び「ａ．ｂ．ｃ」であってもよい。

【0139】

例えば、データのキーが「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ」であれば、「ｋｏｒｅａ」、「ｋｏｒｅａ．ｓｅｏｕｌ」は前記キーの接頭語の１つであってもよい。したがって、前記データは、第１格納領域７１０のキー７１５「ｋｏｒｅａ」及び第３格納領域７３０のキー７３５「ｋｏｒｅａ．ｓｅｏｕｌ」に対応して、第４格納領域７４０のキー７４５及び第５格納領域７５０のキー７５５には対応しない。

【0140】

例えば、データのキーが「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ．ｓｈｉｎｓａ」であれば、キーの接頭語は「ｋｏｒｅａ」、「ｋｏｒｅａ．ｓｅｏｕｌ」、「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ」であってもよい。データは、第１格納領域７１０のキー７１５、第３格納領域７３０のキー７３５及び第５格納領域７５０のキー７５５に対応する。

【0141】

データは、自らのキーに応じてデータ格納装置７００の１つ以上の格納領域７１０、７２０、７３０、７４０及び７５０のいずれか１つの格納領域内に格納されてもよい。

【0142】

例えば、格納領域は、（１）格納領域のキーに対応し、（２）格納領域の子格納領域のキーには対応しないデータを格納してもよい。

【0143】

親格納領域ｐに対応するデータは、親格納領域ｐの子格納領域ｃにも対応する。データが格納領域ｐ及び格納領域ｃに対応する場合、データは、格納領域ｐではない格納領域ｃをルートにしたサブツリー内の格納領域のいずれか１つの格納領域内に格納されてもよい。

【0144】

データのキーが「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ．ｓｈｉｎｓａ」または「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ．ｓｈｉｎｓａ．１」であれば、データは、第１格納領域７１０、第３格納領域７３０、及び第５格納領域７５０に対応する。データは第５格納領域７５０内に格納されてもよい。

【0145】

データのキーが「ｋｏｒｅａ．ｇａｎｇｗｏｎ」であれば、データは第１格納領域７１０に対応する。データは第１格納領域７１０内に格納されてもよい。

【0146】

前述のような格納方式が用いられる場合、階層的なキーによって実際のデータが位置する格納領域が検索されてもよい。すなわち、実際のデータが位置する格納領域は、階層的なキー全体またはキーの接頭語によって検索されてもよい。

【0147】

以下では、データのキーが「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ．ｓｈｉｎｓａ」であるデータが検索される場合の例について説明する。ルートノードに対応する第１格納領域７１０のキー７１５がデータのキーと比較される。データのキーの接頭語の１つである「ｋｏｒｅａ」は、第１格納領域７１０のキー７１５と同一である。また、第３格納領域７３０及び第１格納領域７１０は互いに子−親の関係にある。データのキーの接頭語の１つである「ｋｏｒｅａ．ｓｅｏｕｌ」は、第３格納領域７３０のキー７３５と同一である。第５格納領域７５０及び第１格納領域７１０は互いに子−親の関係にある。データのキーの接頭語の１つである「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ」は、第５格納領域７５０のキー７５５と同一である。したがって、キーが「ｋｏｒｅａ．ｓｅｏｕｌ．ｋａｎｇｎａｍ．ｓｈｉｎｓａ」であるデータは、第１格納領域７１０及び第３格納領域７３０を経由して第５格納領域７５０内で検索されてもよい。

【0148】

以下は、データのキーが「ｋｏｒｅａ．ｊｅｊｕｄｏ」であるデータが検索される場合について説明する。データのキーの接頭語の１つである「ｋｏｒｅａ」は、第１格納領域７１０のキー７１５と同一である。データのキーの接頭語である「ｋｏｒｅａ」及び「ｋｏｒｅａ．ｊｅｊｕｄｏ」は、第２格納領域７２０のキー７２５及び第３格納領域７３０のキー７３５とは同一ではない。したがって、キーが「ｋｏｒｅａ．ｊｅｊｕｄｏ」であるデータは第１格納領域７１０内で検索されてもよい。

【0149】

図８は、本発明の一例に係るデータ格納装置に格納領域を追加する過程を説明するための図である。

【0150】

図７を参照して前述したデータ格納装置７００は、格納領域のキーである「ｋｏｒｅａ」に対応するデータを格納するため、格納領域が追加されたと見なすことができる。

【0151】

初期状態８１０において、データ格納装置７００は第１格納領域７１０のみを有する。

【0152】

第１格納領域７１０のキー７１５は「ｋｏｒｅａ」である。したがって、キーが「ｋｏｒｅａ」であるデータ、キーが「ｋｏｒｅａ．ｇｙｅｏｎｇｇｉ」から始まるデータ、及びキーが「ｋｏｒｅａ．ｓｅｏｕｌ」から始まるデータは、全て第１格納領域７１０内に格納される。

【0153】

データ格納装置７００が運用されることによって、特定の接頭語を有する（すなわち、特定の文字列から始まる）キーを有するデータ（例えば、「ｋｏｒｅａ．ｓｅｏｕｌ」）が多くなれば、データ格納装置７００は、特定の接頭語をキーとして有する格納領域を追加してもよい。この追加は、データ格納装置７００のツリー構造が拡張されることを意味する。すなわち、拡張は、データ格納装置７００のツリー構造に新しい格納領域（または、新しい格納領域を示すノード）が追加されることを意味する。

【0154】

データが格納された状態８２０において、第１格納領域７１０は、キー７１５に対応する１つ以上のデータ８６０を格納する。

【0155】

第１格納領域７１０が１つ以上のデータ８６０を全て処理できない場合、新しい格納領域の追加が要求される。例えば、データ格納装置７００は、下記の状態８３０、８４０及び８５０を経由して拡張されてもよい。

【0156】

ノード生成状態８３０で示すように、データ格納装置７００は、第１格納領域７１０の子格納領域である第３格納領域７３０を生成してもよい。

【0157】

すなわち、第３キー７３５に対応するデータ（すなわち、データのキーが「ｋｏｒｅａ．ｓｅｏｕｌ」から始まるデータ）は、第３格納領域７３０に別個に分離されてもよく、分離後第３格納領域７３０によって処理されてもよい。

【0158】

追加通知状態８４０において、新しく生成された第３格納領域７３０は、自らの親格納領域である第１格納領域７１０に自らが処理するキー（すなわち、第３キー７３５）を通知してもよい。この通知は、格納領域の追加を通知するものである。

【0159】

データ移動状態８５０において、通知を受信した第１格納領域７１０は自らが格納したデータのうち通知された第３キー７３５に対応するデータ８７０を第３格納領域７３０に移動させる。例えば、通知を受信した第１格納領域７１０は、自らが格納したデータのうち通知された第３キー７３５に対応するデータ８７０を第３格納領域７３０にコピーしてもよい。コピーが完了すると、第１格納領域７１０は子格納領域（すなわち、第３格納領域７３０）が保有するデータを重複して保有する必要がない。したがって、１格納領域７１０は、自らが格納したデータのうち第３格納領域７３０にコピーされたデータを削除してもよい。削除の後、第１格納領域７１０は、第１キー７１５に対応するデータのうち第３キー７３５に対応しないデータを格納する。

【0160】

第３格納領域の第３キー７３５に対応するデータ８７０を第１格納領域７１０から第３格納領域７３０に移動することによって、第１格納領域７１０の格納量は減少する。

【0161】

データ格納装置７００は、第１格納領域７１０に新しいデータが挿入されることによって第１格納領域７１０の格納量が予め定義された基準に達したとき、前述した第３格納領域７３０の生成及び第３格納領域７３０へのデータ移動を行なってもよい。

【0162】

拡張中に、データ格納装置７００は（部分的または全体的に）中断されなくてもよい。また、拡張によってデータも自動で複製されてもよい。

【0163】

拡張中に、第３キー７３５に対応する新規の流入データは、拡張によって生成された子ノードに対応する第３格納領域７３０に送信される。

【0164】

データ格納装置７００の縮小（すなわち、ツリーノードの削除）は、前述したデータ格納装置７００の拡張の逆順に行なわれてもよい。

【0165】

図９は、本発明の一例に係るデータ格納装置に対する範囲検索を説明するための図である。

【0166】

特定の条件が満たされるデータを照会するためにクエリが用いられてもよい。クエリは、特定の検索範囲に対応するキーを有するデータ目録を質疑する文章であってもよい。

【0167】

データ格納装置７００の格納領域７１０、７２０、７３０、７４０及び７５０の全てまたは一部は、クエリに対してデータを検索してもよい。格納領域７１０、７２０、７３０、７４０及び７５０の全てまたは一部によって検索された結果を併合することで、特定の格納領域７１０、７２０、７３０、７４０または７５０には格納されていないデータも検索されてもよい。

【0168】

クエリ提供状態９１０において、クエリは、任意の格納領域７１０、７２０、７３０、７４０または７５０に提供されてもよい。

【0169】

本発明の一実施形態では、ルートノードに対応する第１格納領域７１０にクエリが提供された場合を説明する。

【0170】

第１格納領域７１０は、送信されたクエリの分析によって自らの第１キー７１５がクエリに対応するか否かを判断する。ここで、第１キー７１５がクエリに対応することは、第１キーに対応するデータのうちクエリの検索範囲に含まれるデータが存在することを意味する。

【0171】

例えば、クエリの検索範囲が「ｕｓａ．ａｒ」から「ｕｓａ．ｃａ」までであれは、第１キー７１５「ｋｏｒｅａ」に対応するデータは検索範囲内には含まれない。したがって、第１キー７１５はクエリに対応しない。

【0172】

もし、クエリに対応するデータがなければ、第１格納領域７１０はクエリに対して空白（ｎｕｌｌ）を返還してもよく、または、これ以上の処理を行なわなくてもよい。

【0173】

クエリ送信状態９２０において、第１格納領域７１０は、自らの子格納領域である第２格納領域７２０及び第３格納領域７３０にクエリを送信してもよい。すなわち、第１格納領域７１０は、１つ以上の子格納領域（すなわち、第２格納領域７２０及び第３格納領域７３０）に検索範囲に対応するキーを有するデータの目録を要請してもよい。

【0174】

第２格納領域７２０及び第３格納領域７３０も自らの子格納領域にクエリを送信してもよい。すなわち、クエリの送信は階層的に行われてもよい。（図示せず）

【0175】

目録返還状態９３０において、第１格納領域７１０の１つ以上の子格納領域（例えば、第２格納領域７２０及び第３格納領域７３０）から検索範囲に対応するキーを有するデータの目録が返還されてもよい。

【0176】

また、クエリの送信が階層的に行われた場合、第２格納領域７２０及び第３格納領域７３０もそれぞれ自らの１つ以上の子格納領域から検索範囲に対応するキーを有するデータの目録が返還されてもよい。

【0177】

目録併合及び検索結果の返還状態９４０において、第１格納領域７１０は、検索語の検索範囲に対する結果として併合されたデータ目録を返還してもよい。

【0178】

第２格納領域７２０及び第３格納領域７３０が返還したデータの目録も併合されたデータ目録であってもよい。すなわち、併合されたデータ目録の返還は階層的に行われてもよい。

【0179】

第１格納領域７１０は、第１格納領域７１０が格納したデータのうち検索範囲に対応するデータの第２目録を返還された第１目録として併合してもよく、併合によって生成して併合された目録を検索語の検索範囲に対する結果として返還してもよい。

【0180】

前述したように、本発明の一例によって、キー・バリューＤＢまたはハッシュを用いることなく、範囲検索及び空間的なインデックスが支援され得る。

【0181】

図１０は、本発明の一実施形態に係るデータ格納方法のフローチャートである。

【0182】

ステップＳ１０１０において、１つ以上の格納領域がツリー構造で構成される。１つ以上の格納領域それぞれ、はＲＤＢＭＳであってもよい。

【0183】

ステップＳ１０２０において、１つ以上の格納領域それぞれに階層的なキーが割り当てられる。階層的なキーは０個以上のサブキーを有してもよい。階層的なキーは、前記の数式（１）の正規式によって生成された文字列であるか、空白文字列であってもよい。

【0184】

ステップＳ１０３０において、１つ以上の格納領域のうち、任意の第１格納領域を示す第１ノードをルートにしたサーバツリー内の格納領域内に第１格納領域の第１キーに対応するデータが格納される。

【0185】

第１キーは、第１ノードの親ノードを示す第２格納領域の第２キーに１つ以上のサブキーが連鎖されたキーである。

【0186】

第１キーに対応するデータは、データのキーの接頭語のうち１つが第１キーと同一であるデータを意味する。

【0187】

データのキーの接頭語のうち１つが格納領域のキーと同一であれば、データは格納領域に対応するものと見なすことができる。

【0188】

第１格納領域に対応するデータのうち、第１ノードの子ノードを示す第３格納領域に対応するデータは第３格納領域に格納され、第３格納領域に対応しないデータは第１格納領域に格納される。したがって、ステップＳ１０３０は、第１格納領域に対応するデータのうち、第１ノードの子ノードを示す格納領域に対応しないデータを第１格納領域に格納するステップを含んでもよい。

【0189】

先に図７から図９を参照して説明した本発明の一実施形態に係る技術的な内容は、本実施形態にもそのまま適用されてもよい。したがって、本詳細な説明は以下では省略する。

【0190】

図１１は、本発明の一実施形態に係るデータ格納装置における拡張方法のフローチャートである。

【0191】

後述するステップＳ１１１０、Ｓ１１２０、Ｓ１１３０、及びＳ１１４０は、前述したステップＳ１０３０に含まれてもよい。

【0192】

ステップＳ１１１０において、第１格納領域の格納量が予め定義された基準に達するか否かを判定する。

【0193】

第１格納領域の格納量が予め定義された基準に達する場合は、ステップＳ１１２０が行われ、そうではない場合は、データの格納を行い終了する。

【0194】

ステップＳ１１２０において、第１格納領域の子格納領域の第３格納領域が生成される。

【0195】

ステップＳ１１３０において、第３格納領域は第１格納領域に自らの第３キーを通知する。

【0196】

ステップＳ１１４０において、第３格納領域の第３キーに対応するデータが第１格納領域から第３格納領域に移動する。

【0197】

ステップＳ１１４０は、（１）第３格納領域の第３キーに対応するデータが第１格納領域から第３格納領域にコピーされるステップ、及び（２）第１格納領域のデータのうち第３格納領域にコピーされたデータが削除されるステップを含んでもよい。

【0198】

先に図７から図１０を参照して説明した本発明の一実施形態に係る技術的な内容は、本実施形態にそのまま適用されてもよい。したがって、本詳細な説明は以下では省略する。

【0199】

図１２は、本発明の一例に係るデータ格納装置の範囲検索のフローチャートである。

【0200】

ステップＳ１２１０において、クエリが第１格納領域に提供される。

【0201】

クエリは、格納領域にクエリ内の検索範囲に対応するキーを有するデータを要請する文章である。

【0202】

ステップＳ１２２０において、クエリが第１格納領域の子格納領域に送信される。すなわち、第１格納領域は、１つ以上の子格納領域に検索範囲に対応するキーを有するデータの第１目録を要請する。

【0203】

ステップＳ１２２０は再帰的に行われてもよい。クエリが送信された第１格納領域の子格納領域は、クエリを自らの１つ以上の子格納領域に再送信してもよい。

【0204】

ステップＳ１２３０において、１つ以上の格納領域が第１目録を返還する。

【0205】

ステップＳ１２４０において、第１格納領域が格納したデータのうち検索範囲に対応するキーを有するデータの第２目録が返還された第１目録に併合されることで併合された目録を生成する。

【0206】

ステップＳ１２３０及びＳ１２４０は再帰的に行われてもよい。第１格納領域の子格納領域は、自らの１つ以上の子格納領域から検索範囲に対応するデータの第３目録が返還されてもよい。第１格納領域の子格納領域は、返還された第３目録を第１目録と併合してもよく、併合された第１目録を第１格納領域に返還してもよい。

【0207】

ステップＳ１２５０において、併合された目録が検索範囲に対する結果として返還される。

【0208】

先に図７から図１１を参照して説明した本発明の一実施形態に係る技術的な内容は、本実施形態にそのまま適用されてもよい。したがって、本詳細な説明は以下では省略する。

【0209】

一実施形態に係る方法は、多様なコンピュータ手段によって行うことができるプログラム命令形態で実現され、コンピュータ読み出し可能媒体に記録されてもよい。記録媒体は、プログラム命令、データファイル、データ構造などを単独または組み合わせたものを含んでもよい。記録媒体及びプログラム命令は、本発明の目的のために特別に設計して構成されたものでもよく、コンピュータソフトウェア分野の技術を有する当業者にとって公知のものであり使用可能なものであってもよい。コンピュータ読取可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク及び磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光記録媒体、フロプティカルディスクのような磁気−光媒体、及びＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を保存して実行するように特別に構成されたハードウェア装置を含んでもよい。プログラム命令の例としては、コンパイラによって生成されるような機械語コードだけでなく、インタプリタなどを用いてコンピュータによって実行され得る高級言語コードを含む。上述のハードウェア装置は、本発明の動作を行うために１つ以上のソフトウェアモジュールとして作動するように構成してもよく、その逆も同様である。

【0210】

上述したように本発明を限定された実施形態と図面によって説明したが、本発明は、上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態から様々に修正及び変形が可能である。

【0211】

したがって、本発明の範囲は、開示された実施形態に限定して定められるものではなく、特許請求の範囲及び特許請求の範囲と均等なものなどによって定められるものである。

【符号の説明】

【0212】

３１０ クライアント
３２０ メッセージングチャネル
３３２ 第１ノード
３３４ 第２ノード
３３６ 第３ノード
７００ データ格納装置
７１０ 第１格納領域
７１５ 第１キー

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】