JP2012256324A - データ管理方法、および、複合型データ管理システム - Google Patents

Abstract

【課題】様々なタイプの「巨大データ」を効率よく処理できる複合型データ管理システムを提供する。
【解決手段】複合型データ管理システム１００は、二つ以上のデータ管理システムから構成され、外部のアプリケーションやユーザ１１０は、統一インタフェースを使用して複合型データ管理システムにアクセスする。外来データオブジェクトに対応する生データ１７０は、複数の予め定義された特徴（例えば、サイズやデータ型を含む）に基づいて、接続された複数のデータ管理システムのいずれかの記憶部１３０に保存されるように送られ、一方、外来データオブジェクトに対応するメタデータ１６０は、生データがどこに格納されるかに関係なく、特定のデータ記憶部１２０に格納される。
【選択図】図１Ｂ

Description

本発明は、概してデータ管理システムに関し、特に、大きくて様々なデータセットのより効率的な管理のための複合型データ管理システムに関する。

インターネットの登場によって、いくつかのデータ管理問題が解決された一方で、同時に、いくつかの新たなデータ管理問題が発生している。例えば、多くのインターネットアプリケーション（例えば電子商取引、電子メール、ソーシャルメディアアプリケーション）は、いわゆる「巨大データ」問題を生み出した。「巨大データ」問題は、データの巨大な量に起因している。巨大な量のデータの多くは、とても高速に、かつ、フォーマットや長さを大きく変えながら、生み出されている。一般に、「巨大データ」という用語は、データセットを指す。データセットは、大きくなりすぎて、許容範囲内の時間でデータの保存、管理、処理を行うために通常使用されているデータベース管理手段の能力を超えてしまう。そのようなデータセットでは、１つのデータセット内のすべてが、数十テラバイトから大きなペタバイトまでの範囲で変動しうる。このように、「巨大データ」は、莫大な数の潜在的に不定形のデータオブジェクトから構成される。それらのデータオブジェクトは、毎日生み出され、瞬時にアクセス可能でなければならず、さらに、もしかしたら長期間、高信頼性かつ安価で保存されなければならない。

分散処理型のストレージシステムとして、ＮｏＳＱＬと呼ばれるものや、「巨大データ」データベースが近年現れている。そのようなデータベース管理システムの例としては、ＨＢａｓｅ，Ｃａｓｓａｎｄｒａ，ＭｏｎｇｏＤＢ，Ｈｉｂａｒｉ（登録商標）等がある。そのようなデータベースは、従来のＳＱＬデータベースの高機能を提供しない一方、比較的安価で高信頼性の手法で巨大データの格納や検索を非常に効率よく行う。そのようなＮｏＳＱＬに基づくシステムは、また、容易にサイズ変更可能である。そのようなＮｏＳＱＬに基づくシステムにおいて、異種サーバは、いつでもネットワーク接続されたサーバクラスタに追加されうる。サーバクラスタは、サービスのために壊れることなしで自動的に再バランスと分配が行われるデータによってフォローされる。

しかし、そのような高いパフォーマンスとスケーラビリティを達成するために、これらのＮｏＳＱＬに基づいたシステムは、特定のデータタイプに対して最適化されなければならない。例えば、Ｃａｓｓａｎｄｒａは、多数の小さなデータイテムの高速書き込みを処理するように最適化されるが、多数の大きなデータイテムがそのデータベースに書き込まれるときは逆に相対的に低いパフォーマンスとなる。従来技術の解決手段で、非常に多くの異なるデータタイプに対して最適化するものはなかった。

１つの考えられる解決手段は、異なる複数のデータタイプに対して異なる複数の解決手段を配置することである。例えば、大きなデータをファイルシステムに格納し、一方、小さなデータオブジェクトをＮｏＳＱＬデータベースに保存する。しかし、この手法では不充分である。なぜなら、維持すべきシステムやソフトウェアの数が増えるからである。異なる複数のデータベースにまたがる同時使用は難しい可能性が高い。また、大きなデータと小さなデータを持つことになるユーザに対する使用ポリシー（いくつかのバイト／秒の制限）の実行によって、リアルタイムで２つの異なるシステムの同時使用が必要となる。このアプローチが大きなスケールの「巨大データ」環境で機能するのかも疑わしい。このアプローチでは、また、「Ｎ」が増加するにつれて、Ｎ個のシステムに容易にスケール変更できない。なぜなら、管理や同時使用によるオーバーヘッドが増加するからである。

したがって、様々なタイプの「巨大データ」を効率よく処理できる複合型データ管理システムが望まれている。

本発明について開示および権利請求するのは、複合型データ管理システム、および、複合型データ管理システムによるデータ管理方法である。１つの実施形態において、複合型データ管理システムによるデータ管理方法は、多くのデータ記憶部を有しており、外部装置からの外来データオブジェクトに対する書き込みリクエストを受信したり、外来データオブジェクトが多くの所定の特徴のうちの１つ以上を有しているか否かを判定したりする。したがって、その方法では、多くのデータ記憶部のうちのどれが外来データオブジェクトに対して好ましいデータ記憶部であるのかを、多くの所定の特徴のうちの外来データオブジェクトが持っている１つ以上の特徴に基づいて決定したり、それに対応して、外来データオブジェクトの生データを保存のために特定した好ましいデータ記憶部に送信したりする。最後に、この方法では、外来データオブジェクトに関するメタデータを多くのデータ記憶部のうちの第１データ記憶部に格納するが、その際、多くのデータ記憶部のうちのどれが外来データオブジェクトの生データを持っている好ましいデータ記憶部であるかは関係ない。メタデータは、その好ましいデータ記憶部における対応するデータオブジェクトの生データを有する特定のメタデータ入力とリンクしている対応情報を含んでいる。

本発明の他の態様、特徴、技術については、以下の本発明の典型的な実施形態の記載を見ることによって当業者に明らかになるであろう。

本発明によれば、様々なタイプの「巨大データ」を効率よく処理できる。

本発明の原理に基づいた、大きくて様々なデータセットを管理するための２つの典型的な複合型データベース管理システムを示す。 本発明の原理に基づいた、大きくて様々なデータセットを管理するための複合型データベース管理システムを実行するための処理を示す。 小さなデータセットと大きなデータセットの両方をより効率的に格納および管理する複合型データベース管理システムを実行するための図２の処理の一例を示す。

＜本発明の概要＞
本発明は、概して、２つ以上の統合型データ管理システムから構成される複合型データ管理／保存システムに関する。メタデータは、少なくとも１つの付加的に接続されたデータ管理システム（例えばＯＳファイルシステムのような大きなデータ記憶部）内のデータを有する第１データ管理システム（例えばＮｏＳＱＬデータベースのような小さなデータ記憶部）内のデータとリンクするために使用される。

前記メタデータのリンクによって、第１データ管理システムは、１つ以上の接続された付加的なデータ管理システムを有する配置されたシステム（例えば、分割、再生、移転（スケールアウトのケースで）、回復（故障からの復旧）、バックアップ等）におけるデータ管理のためのすべてのアルゴリズムを共有できる。したがって、それぞれの利益に影響する。なぜなら、異なるタイプの複数のデータ管理システムがそれぞれのタイプのシステムにおける異なる複数のデータ管理アルゴリズムを使用する複雑さなしで、あるタイプ／サイズのデータにおいて他のタイプ／サイズの場合よりもより効率的に処理するようになるからである。そのために、本発明の他の態様では、外来データオブジェクトの１つ以上の特徴を判定し、また、そのような特徴の存在に基づいて、外来データオブジェクトの元となっている生データを、そのようなデータの保存や管理のために最も適した、または、設計された、接続されたデータベース管理システムの１つに送信する。例えば、あるデータ記憶部は、特定のデータタイプに有効な付加的なインデックス／サーチの機能を含み、したがって、他のデータ記憶部よりも効率的な手法でそのようなデータを格納、管理できる。

外来データオブジェクトの生データが２つ以上のデータ記憶部に同時に格納されることは当然である。例えば、電子メールオブジェクトは、メール記憶や検索のために最適化された記憶部に格納され、同時に、インデックスやサーチのために最適化された他の記憶部に格納される。そのとき、そのようなデータに対応するメタデータは、そのような両方のデータ記憶部へのリンクを示す。

考えられるデータの特徴に関して、そのような特徴はデータオブジェクトのサイズおよび／またはタイプ（テキストデータに対するメディアデータ）を含む。付加的な特徴は、データオブジェクトに対するアクセスのパターンやＱＯＳ（クオリティ・オブ・サービス）に対応するアクセスパターン情報を含む（例えば、データオブジェクトが頻繁な変更に対してまれにアクセスや変更されるという事実や、外来データオブジェクトが異なる料金プランのユーザからのもので、遅い（安い）データ記憶部に格納されているという事実）。付加的なオブジェクトの特徴は、ローカルに対するリモートと同様（アプリケーションはこのデータオブジェクトが少なくとも１つのリモートデータセンタで複製されるべきであることを示す。）、さらに、強いまたは弱いコンシステンシー（すべての複製がアップデートされた後、または、いくつかの複製がアップデートされた後、返信のために書き込む。）を含む。

例えば、制限なしの例として、いくつかのデータベース（例えばＭｏｎｇｏＤＢ）は、特別な構造（例えばＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）を有するドキュメントの記憶部としてよりよく最適化される。そのようなデータベースは、好ましい構造でないデータを格納するとき、低効率なパフォーマンスとなる。そのような場合において、本発明によれば、そのようなデータベースは、データオブジェクトを受信し、それが好ましくない構造であることを認識し、そして、そのデータオブジェクトを、分離され接続されている、受信されたデータオブジェクトのタイプにとってより適したデータベースに送る。

本発明の他の態様によれば、外部ソース（アプリケーションやユーザ）は、単一のデータ記憶部とインタフェース接続できる。この第１データ記憶部または第１データ記憶部は、多くの接続されたデータ管理システムのうちの１つにおけるそのオブジェクトを形成する元となっている生データを選択的に格納している間、すべてのデータオブジェクトに対して同じメタデータ構造を用いる。この方式において、この第１データ記憶部（すべてのメタデータは、第１データ記憶部における記憶のために最も適したデータサイズなので、第１データ記憶部に格納されている）による管理機能は、分離されたそれぞれのデータ記憶部に自身の管理機能を信頼させるよりもむしろ、多くの付加的に接続されたデータ記憶部を管理するために使用される。多くの接続されたデータ記憶部は第１データ記憶部（ユーザ／アプリケーションがインタフェース接続する先の単一のデータ記憶部）の管理機能から外れることができるので、システムの全体的な複雑さは大きく減少する。

ここに使われているように、（原文において）「ａ」または「ａｎ」は、１または１以上をいう。「多くの」という用語は、２または３以上をいう。「他の」という用語は、２番目または３番目以降をいう。「含む」や「有する」という用語は、オープンエンドである（例えば、「含んでいる」）。「１つの実施形態」、「ある実施形態」、「実施形態」または類似した用語への本明細書を通しての言及は、実施形態に関連して記述される具体的な特徴、構造または特性が本発明の少なくとも１つの実施形態に含まれることを、意味する。このように、この明細書を通じていろいろな箇所におけるそのようなフレーズの現出は、同じ実施形態に必ずしもすべて言及しているわけではない。さらにまた、その具体的な特徴、構造または特性は、限定なしで、１つ以上の実施形態にあらゆる適切な方法で組み込まれてもよい。「または（あるいは）」という用語は、包括的な意味、または、単一あるいはあらゆる組み合わせとして解釈される。したがって、「Ａ、ＢまたはＣ」は、「Ａ」、「Ｂ」、「Ｃ」、「ＡとＢ」、「ＡとＣ」、「ＢとＣ」、「ＡとＢとＣ」のいずれも意味する。要素の組合せ、機能、ステップまたは動作が何らかの方法で本質的に互いに相容れないときだけ、この定義に対する例外が発生する。

コンピュータ・プログラミングの技術に熟達した人の実践に合わせて、本発明は、コンピュータシステムまたは電子システム等によって実行する実施について以下、説明する。そのような実施は、「コンピュータによって実行される」と称される場合もある。象徴的に表現される実施が、他の信号処理と同様、プロセッサ（例えば中央演算処理装置）による記憶箇所（例えばシステム・メモリ）においてのデータ・ビットやデータ・ビットの維持を意味する電気信号の処理を含むことは言うまでもない。データ・ビットが維持される記憶箇所は、データ・ビットに対応する特定の電気特性、磁気特性、光学特性、または有機特性を有する物理的な箇所である。

ソフトウェアで実装されるとき、本発明の要素は、基本的に、必要なタスクを実行するコード部分である。コード部分は、コンピュータ・データ信号によって、プロセッサで読取り可能な媒体に保存されるか、送信される。「プロセッサで読取り可能な媒体」は、情報を格納することができるどんな媒体も含む。プロセッサで読取り可能な媒体の例は、電子回路、半導体メモリデバイス、ＲＯＭ、フラッシュメモリまたは他の不揮発性メモリ、フロッピー（登録商標）・ディスク、ＣＤ−ＲＯＭ、光ディスク、ハードディスク等を含む。

「サーバ」という用語は、電気的構成（例えば、プロセッサ、メモリ、ネットワーク・インタフェースなど）の機能的に関連するグループを意味する。電気的構成は、例えば、ネットワーク環境におけるコンピュータシステムである。ネットワーク環境は、ハードウェア構成とソフトウェア構成の両方を含むか、または、代わりに、実施時に特定の機能を実行するソフトウェア構成だけである。「サーバ」は、１つ以上の関連するデータベースを有する１つ以上のデータベース管理システムとさらに統合されてもよい。

「データベース管理システム」という用語は、プロセッサで読取り可能なメディアに格納されるデータレコード、ファイル、その他のデータオブジェクトの統合した集合体の作成、維持および使用を制御する１つ以上のコンピュータープログラムを意味する。データベース管理システムは、データの保存性や安全性を維持したり、同時発生アクセスを管理したり、データの回復や復旧をしたりするのと同様、格納されたデータにアクセスしたり処理したりするために、外部ソース（例えば、アプリケーション／ユーザ）によって使用できる。

＜典型的なオンライン環境の概要＞
図１Ａは、本発明の１つ以上の態様を実施するように構成された複合型データ管理システム１００の１つの実施形態を表す。図１Ａの例において、システム１００は、第１のデータベース管理システム（第１データ記憶部１２０。例えばＮｏＳＱＬベースのデータベース・システム）にインタフェース接続されるように構成されたアプリケーション／ユーザ１１０の形における外部ソースからアクセス可能な１つ以上のサーバから構成される。さらに、第１データ記憶部１２０は、第２のデータベース管理システム（１３０。大きなデータブロック（例えば、Ｌｉｎｕｘ（登録商標） ｅｘｔ３、Ｌｉｎｕｘ ｅｘｔ４、Ｈａｄｏｏｐ Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍなど）の保管のために最適化されるファイルシステムから構成される。）と通信するように同じように構成される。複合型データ管理システム１００は２つのデータ記憶部のみから構成されているが、Ｎ個の付加的なデータ記憶部が、第１データ記憶部１２０（例えば、図１Ｂを参照して以下に記載される典型的なシステムにおけるケース）に対して同様に接続されていてもよいのは当然である。いかなる場合でも、そのようなファイルシステムは、単純なブロック・データ記憶システム（例えばＣＤＲＯＭ、ＤＶＤ、磁気テープ・システムなど）と同様、配布、複製などのための基本的なデータ管理機能を有する任意のローカル・ファイルシステムである。

第１データ記憶部１２０は、データ分割、自動複製、増分バックアップ、ノード拡大、定数計算などのためのビルトイン機能を提供するように構成されている。第１データ記憶部１２０は、例えば、メモリキャッシュにおける書き込み前方ログを用いる効率的な書き込み／読み出しパスのおかげで、小さなデータサイズに対して高いパフォーマンスを提供できるようなＮｏＳＱＬ型データベースとして実装される。

発明の１つの態様は、特定の特徴（例えばデータオブジェクトのサイズまたはタイプ）を有するデータオブジェクトが、異なる種類のデータ記憶部（例えば大きな第２データ記憶部１３０）によってより効率的に保存および管理されるものと認められる。この方法では、本発明は、特定のデータオブジェクト（例えば、小さなデータオブジェクト）を第１データ記憶部１２０（例えば、ＮｏＳＱＬ型データベース）に保管することによって、全体的なパフォーマンスを向上させる複合型データベース・ソリューションを提供する。その一方、本発明は、他のタイプのデータオブジェクト（例えば、大きなデータオブジェクト）の生データを第２データ記憶部１３０（例えば、ファイルシステム）に移す。

考慮対象となっているデータオブジェクトの特徴がオブジェクトのサイズであるとき、小さなデータオブジェクトと大きなデータオブジェクトとを区別する閾値が、少なくとも部分的には、特定のシステムハードウェアとワーク負担に依存していることは当然である。このように、閾値はシステム１００のユーザ定義可能なプロパティである。例えば、ソーシャル・ネットワーキング・データを格納および管理するための典型的なデータベースは、１Ｋ〜１０Ｋの範囲内でデータオブジェクトのために最適化される傾向がある。そのようなシステムについては、１００Ｋより大きいデータオブジェクトは大きいと考えられる。同様に、電子メール・データのために最適化されるデータベースは、通常のケースとしてデータを１Ｋ〜１００Ｋに保管する傾向がある。そのようなデータベースについては、１Ｍを超えるデータオブジェクトは、「大きい」と考えられる（例えば大きなファイル添付を伴う電子メール）。技術が進化するにつれ、これらの範囲は同様に進化すると予測される。しかし、特定のデータベースにおいて異種のデータを格納および管理しようとする問題は、おそらく継続する。

ある実施形態において、第１データ記憶部１２０は、さらに、特定の外来データ（例えば、アプリケーション／ユーザ１１０から）が予定された分配方法においてどのように保存されるのかを決定するように構成される。制限なしの例として、ルーティングレイヤ１４０はまず、所定の閾値と外来データオブジェクトのサイズとの比較に基づいて、外来データオブジェクトが第１データ記憶部１２０に保管されるべきか、あるいは、第２データ記憶部１３０から構成されるファイルシステムに保管されるべきかを特定する。ルーティングレイヤ１４０は、代理レイヤとして実装されるが、決定ロジックの多数の他の形、ソフトウェア、ハードウェアまたはその組合せの形で同様に実装されてもよい。

もし、ルーティングレイヤ１４０が、特定の外来データオブジェクトは１つ以上の特定の特徴であって第１データ記憶部１２０がそれのために望ましく構成されているものを有すると特定するなら（例えば、予め定義された閾値より小さい）、外来オブジェクトはローカルデータオブジェクト１５０とともに保管される。ある実施形態において、ローカルデータオブジェクト１５０のメタデータは、図１Ａで示すように、メタデータ１６０として別々に格納される。一方、ある実施形態において、そのようなメタデータは、ローカルデータオブジェクト１５０のように元となっている生データと共に格納される。そのようなメタデータはローカルオブジェクトメタデータと称される場合がある。なぜなら、情報がローカルに（すなわち、第１データ記憶部に）保管されたオブジェクトと一致するからである。

しかし、もし、ルーティングレイヤ１４０が、特定の外来データオブジェクトは１つ以上の特定の特徴であって第２データ記憶部１３０がそれのためによりよく構成されるものを有すると判定するなら（例えば、予め定義された閾値より大きい）、外来オブジェクトの生データは第２データ記憶部１３０を通過し、生データ１７０として格納される。

その上、それにもかかわらず、生データが第２データ記憶部１３０（生データ１７０として）に格納されているそれぞれの外来データオブジェクトのメタデータは、メタデータ１６０として第１データ記憶部１２０に格納される。そのようなメタデータはリモートオブジェクト・メタデータと称される。なぜなら、情報が遠隔で（すなわち、第２データ記憶部で）保管されているオブジェクトと一致するからである。さらに、そのようなメタデータ１６０は、そのような大きなデータオブジェクトのための記述的情報を含み、さらに、特定のメタデータ入力とそれが関係する対応する生データ１７０を対応づける対応情報を含む。それぞれのメタデータ入力は、例えば、内容のタイプ、アクセス制御リストなどを含む。オブジェクトごとのメタデータのサイズは、好ましくは、例えば数百バイトのオーダ程度に小さくあるべきである。

上記のリモートオブジェクト・メタデータは、プレースホルダオブジェクトと称され、管理やアクセスの処理が第１データ記憶部１２０におけるそのリモートオブジェクト・メタデータを用いて実行されるとき、データ管理システム１００は、どのデータ記憶部に入ったものでも対応する生データにおける対応する処理を自動的に行う。この方法では、第１データ記憶部１２０のデータ管理機能だけが使われる。しかし、第１データ記憶部１２０のデータ管理機能を利用することがパフォーマンスへの予想外の悪影響を生み出してしまう場合がある。例えば、第１データ記憶部１２０がすべてのアップデートをＲＡＭとディスク・キャッシュ内のデータオブジェクトに書き込む場合、多くの大きいデータオブジェクトが書かれることになっているとき、ＲＡＭとディスク・キャッシュはすぐに一杯になるかもしれない。そのような場合、選択的に第１データ記憶部１２０のデータ管理機能を回避して、その代わりに問題の特定のデータ記憶部の対応する機能（すなわち、読み書き）を直接利用することは、本発明のさらなる特徴である。

図１Ｂを参照すると、アプリケーション／ユーザ１１０がインタフェース接続する第１データ記憶部１２０に加えて、多くのデータ記憶部１３０_１−ｎによって構成される複合型データ管理システム１００の他の例が、示されている。図１Ａに関して上記で述べた説明の全ては、ここに取り入れられて、図１Ｂの例に適用できる。

上記の図１Ａの例と同様に、第１データ記憶部１２０は、データ分割、自動複製、増分バックアップ、ノード拡大、定数計算などのためのビルトイン機能を提供するように構成されている。また、第１データ記憶部１２０は、小さなデータサイズに対して高いパフォーマンスを提供できるようなＮｏＳＱＬ型データベースとして実装される。

前記したように、第１データ記憶部１２０は、１つ以上の認識された特徴を有する外来データオブジェクトに基づいて、特定の外来データ（例えば、アプリケーション／ユーザ１１０から）がどのように格納されるべきかを判定するように構成される。そのように、ルーティングレイヤ１４０は、外来データオブジェクトの特定の特徴をまず判定するように構成される。ルーティングレイヤ１４０は、利用できるデータ記憶部のうちのどれが、外来オブジェクトに対する生データを格納するのに用いられるべきかを、特定する。前述のように、この特定は、利用できるデータ記憶部のうちのどれが、１つ以上の判定された特徴を有するデータを格納および管理するために最適な構成になっているかについて特定することに基づいて、なされる。

それに加えて、それから、外来データオブジェクトに対応するメタデータは、第１データ記憶部１２０に好ましく格納される。それは、多くのデータ記憶部（例えば、第１データ記憶部１２０とさらなる多くのデータ記憶部１３０_１−ｎ）のうちのどれが対応する生データを格納するのに過去に用いられたかに関係ない。

図１Ａ、１Ｂは、本発明の原理に基づいた複合型データ管理システムを実施するための２つの典型的なシステム構成を表している。一方、他の既知または明らかなデザイン・バリエーションが等しく想像されて、本発明の範囲内であることは、当然である。

図２を参照すると、本発明の原理に基づいた、大きくて様々なデータセットを管理するための方法の１つの実施形態が示されている。特に、複合型データ管理システム（例えば、図１Ａ、１Ｂのシステム１００）が、外部ソース（例えば、図１Ａ、１Ｂのアプリケーション／ユーザ１１０）から書き込みリクエストを受信したとき（例えば「ＰＵＴ」オブジェクト処理の形で）、プロセス２００はブロック２１０から始まる。そのようなオブジェクト処理がどのようなプロトコル（例えばＳ３またはＨＴＴＰ）においてでも可能であることは当然である。

外来オブジェクトは、１つ以上の所定の特徴を有する。その１つ以上の所定の特徴は、オブジェクトがシステムによって書き込まれて保管される前に、検知または判定されたものである。そのために、プロセス２００のブロック２２０で、外来データオブジェクトがＮ個の可能性のある予め定義された特徴のうちのどれを有するかについての判定が、なされる。ある実施形態において、予め定義された特徴の１つは、特定のサイズ範囲、データ型、アクセス／修正の頻度またはパターン、サービスの品質などである。

所定のＮ個の特徴のうちのどれが外来データに存在するかを判定すると、プロセス２００はブロック２３０に進む。ブロック２３０では、多くの接続されたデータ記憶部（例えば、第１データ記憶部１２０、多くのデータ記憶部１３０_１−ｎなど）のうちのどれが外来データオブジェクトの生データの記憶のために好ましいかについて特定される。ある実施形態において、この特定は、利用できるデータ記憶部のうちのどれがブロック２２０から判定された特徴を示しているデータを格納するためにより好適に構成される（最適化される）かについて特定することに基づいて、なされる。

プロセス２００は引き続いてブロック２４０に進む。ブロック２４０では、外来データオブジェクトの生データが、特定された好ましい利用可能なデータ記憶部に送られる。それから、ブロック２５０では、外来データオブジェクトに対応したメタデータは、第１データ記憶部に格納される。ある実施形態において、外来データオブジェクトの生データが第１データ記憶部、または、他の利用可能なデータ記憶部のいずれかに保管されたかに関わらず、そのようなメタデータは、第１データ記憶部に格納される。そのようなメタデータは、特定のメタデータ入力と対応するデータオブジェクトの生データ（例えば、ＵＲＬ形式の位置情報、パス名、ＩＤなど）を対応づけている対応情報を含む。その上、参照メタデータは、さらに、対応するデータオブジェクトにおけるデータタイプ（サイズ、名前、所有者、最後の変更された時刻、アクセス制御規則、アクセス統計など）の情報を含む。

図２を引き続き参照すると、プロセス２００は引き続いてブロック２６０に進む。ブロック２６０では、以前に第１データ記憶部に格納された対応するメタデータに対する処理が試みられたことを検知すると、プロセスは、Ｎ番目のデータ記憶部に格納されている生データに処理を行う（読む、移動させる、削除する、修正するなど）。この方法では、様々なタイプの「巨大データ」は、より効率的に格納および管理される。

図３を参照すると、本発明の原理に基づいた、大きくて様々なデータセットを管理するための方法の特定の実施形態が示されている。具体的には、図３のプロセス３００は、図２のプロセス２００（予め定義された特徴が、小さなデータオブジェクトと大きなデータオブジェクトを機能的に区別するサイズ閾値である場合のプロセス）のより特別な例が示されている。例えば、１つ目の特徴は、０から閾値までのオブジェクトサイズ範囲として示される。一方、２つ目の特徴は、その閾値からシステムで課される最大値までのオブジェクトサイズ範囲として示される。

小さなデータを構成するものと大きなデータを構成するものを区別する概念がシステム固有またはアプリケーション固有であることは当然である。そのように、本発明は特定のデータサイズに基づかない。むしろ、必要なことのすべては、ユーザまたはシステムの定義可能な特徴（例えば、データが大きなデータか小さなデータかを区別するために用いられる閾値）である。

前記したプロセス２００に類似し、プロセス３００はブロック３１０から始まる。ブロック３１０では、複合型データ管理システム（例えば、図１Ａ、１Ｂのシステム１００）が、外部ソース（例えば、図１Ａ、１Ｂのアプリケーション／ユーザ１１０）から「ＰＵＴ」オブジェクト処理の形で書き込みリクエストを受信する。外来オブジェクトは、データベースに書き込まれる予定の外来オブジェクトの全体的なサイズを含む関連する内容長さのヘッダを有している。ルーティングレイヤ（例えば、図１Ａ、１Ｂのルーティングレイヤ１４０）において、例えば、内容長さは、予め決められているユーザ定義可能な閾値と比較される（ブロック３２０）。もし、内容長さが閾値未満である（または同じである）ならば、プロセス３００はブロック３３０に進む。ブロック３３０では、外来データオブジェクトは、小さなデータ記憶部に保管される。ある実施形態において、外来オブジェクトのメタデータは、小さなデータ記憶部に同様に格納される。

他方、もし、ブロック３２０で、内容長さが閾値を実際に上回ると判定されると、ブロック３４０で、より大きな外来ブジェクトのメタデータは、小さなデータ記憶部に格納される。一方、そのオブジェクトの元となっている生データは、大きなデータ記憶部に送られて格納される（ブロック３５０）。ブロック３４０で保存された大きなオブジェクトのメタデータが、元となっている生データが大きなデータ記憶部に実際格納されていることを示している対応情報を更に含んでいることは、さらに当然である。

大きなデータ記憶部への機能呼び出しは、ルーティングレイヤによって用いられる。ルーティングレイヤは、大きなデータ記憶部におけるどのノードに書き込まれるべきかを決定する。ある実施形態において、外来オブジェクトのための生データは、設定されたディレクトリにおける１つのファイルとして、大きなデータ記憶部に書き込まれる。しかし、複合型データベース・システムへのマルチパート・データ・アップロードの場合、各々のデータ部分が別々のファイルとして保存されることは当然である。閾値を変化させることは、新しい外来データオブジェクトリクエストに影響を与えるだけであり、すでに保存されたオブジェクトの位置に影響を与えない。

大きなデータ記憶部に関して、ファイルの数が比較的大きいために、大きなデータオブジェクトを１つのディレクトリに書き込むことを避けることが好ましい場合があるが、もちろん、閾値がどれくらい低く設定されたかに依存する。パフォーマンスを最大にするために、大きなデータ記憶部は、いくつかの定義済みのグループの各々のために１つ以上のグループ−レベル・サブディレクトリを含むトップレベル・ディレクトリで構成される。各々のグループ−レベル・ディレクトリの中で、１つ以上のさらなるユーザレベル・サブディレクトリが、登録ユーザごとに存在してもよい。各々のユーザレベル・サブディレクトリにおいて、間接的レイヤを用いて、各々の保存されたオブジェクトを指定するか、さもなければ特定する。例えば、考慮対象となっているオブジェクトのハッシュ値の２文字のプレフィックスが使われる。

「ＧＥＴ」オブジェクトリクエストが複合型データベース・システムによって受信された場合、プロキシレイヤは、まず、小さなデータ記憶部に格納されているリクエストされたオブジェクトのメタデータを検索して、検索されたメタデータは、リクエストされたオブジェクトが小さなデータ記憶部に実際格納されているか、あるいは、そのサイズが原因で大きなデータ記憶部に格納されているか、を示す。それから、リクエストされたオブジェクトは、特定されたデータ記憶部から読み出される。

「ＤＥＬＥＴＥ」オブジェクトリクエストが複合型データベース・システムによって受信された場合、プロキシレイヤは、まず、小さなデータ記憶部に格納されているリクエストされたオブジェクトのメタデータを検索するようにさらに構成される。また、検索されたメタデータは、オブジェクトが小さなデータ記憶部あるいは大きなデータ記憶部に格納されているか、を示す。それから、特定されたオブジェクトは、特定されたデータ記憶部から削除される。

ノードが追加あるいは削除されたとき、または、そのキー範囲が変わったとき、生データはあるノードから他のノードまで移動されなければならないのは当然である。少なくともいくつかのＮｏＳＱＬ型データベース・システムの場合、移動されるデータは、まず、対応するキー範囲によって確認され、その後、生データはソース・ノードから目的ノードまで送られる。移動される生データが大きなデータ記憶部（例えば、大きなデータ記憶部１３０）によって格納されている場合、小さなデータ記憶部（例えば、小さなデータ記憶部１２０）によって格納されている対応するメタデータは同じように読まれ、移動されたデータの新しい記憶部を反映するために更新される。

本発明はいろいろな実施形態に関連して記述されているが、本発明が更なる修正を許容可能であることは当然である。本出願は、一般に、本発明の原理に従い、また、本発明が関係する技術の範囲内で既知や慣習的な実行の範囲内での本発明からの変更を含む本発明のいかなるバリエーション、使用または適用もカバーしている。

１００ システム
１１０ アプリケーション／ユーザ
１２０ 第１データ記憶部
１３０ 第２データ記憶部
１４０ ルーティングレイヤ
１５０ ローカルデータオブジェクト
１６０ メタデータ
１７０ 生データ

Claims (24)

1. 複数のデータ記憶部を有する複合型データ管理システムによるデータ管理方法であって、
   前記複合型データ管理システムは、
   外部ソースから外来データオブジェクトに関する書き込みリクエストを受信し、
   前記外来データオブジェクトが複数の予め定義された特徴のうちの１つ以上の特徴を有しているか否かを判定し、
   前記外来データオブジェクトが有していると判定された１つ以上の予め定義された特徴に基づいて、前記複数のデータ記憶部のうちのいずれが前記外来データオブジェクトにとって好ましいデータ記憶部であるのかを特定し、
   前記外来データオブジェクトの生データを格納するために前記特定した好ましいデータ記憶部に送信し、
   前記複数のデータ記憶部のいずれが前記外来データオブジェクトの生データを有する前記好ましいデータ記憶部であるかに関係なく、前記外来データオブジェクトに関するメタデータを前記複数のデータ記憶部のうちの第１データ記憶部に格納し、
   前記メタデータは、特定のメタデータ入力と前記好ましいデータ記憶部におけるその対応するデータオブジェクトの生データとを対応付ける対応情報を含んでいる
   ことを特徴とするデータ管理方法。
2. 前記複合型データ管理システムは、さらに、
   前記第１データ記憶部に記憶された前記外来データオブジェクトに対応するメタデータによる処理が試みられたことを検知すると、前記好ましいデータ記憶部における前記外来データオブジェクトの生データを処理する
   ことを特徴とする請求項１に記載のデータ管理方法。
3. 前記試みられた処理は、前記外来データオブジェクトの移動、削除、修正および複製のいずれかに合致する
   ことを特徴とする請求項２に記載のデータ管理方法。
4. 前記複合型データ管理システムは、
   前記書き込みリクエストを受信する場合、
   外部のアプリケーションまたはユーザから、前記外来データオブジェクトに関する書き込みリクエストを受信し、
   前記書き込みリクエストは、「ＰＵＴ」オブジェクト処理である
   ことを特徴とする請求項１に記載のデータ管理方法。
5. 前記複数の予め定義された特徴は、予め定義されたデータオブジェクトサイズを含む
   ことを特徴とする請求項１に記載のデータ管理方法。
6. 前記複数の予め定義された特徴は、予め定義されたデータタイプを含む
   ことを特徴とする請求項１に記載のデータ管理方法。
7. 前記対応情報は、前記外来データオブジェクトの生データが格納されている前記好ましいデータ記憶部における位置を示す情報を含んでいる
   ことを特徴とする請求項１に記載のデータ管理方法。
8. 前記複合型データ管理システムは、
   外部のアプリケーションまたはユーザから、以前に格納されたデータオブジェクトに関する読み出しリクエストを受信し、
   前記以前に格納されたデータオブジェクトに対応する前記第１データ記憶部において格納されているメタデータを検索し、その際、当該メタデータは、前記外来データオブジェクトの生データが格納されている前記好ましいデータ記憶部における位置を示しており、
   前記メタデータによって示されている前記位置から前記以前に格納されたデータオブジェクトを読み出す
   ことを特徴とする請求項１に記載のデータ管理方法。
9. 前記複合型データ管理システムは、
   前記好ましいデータ記憶部に格納された前記外来データオブジェクトに対する処理のために前記第１データ記憶部のデータ管理機能を用いる
   ことを特徴とする請求項１に記載のデータ管理方法。
10. 前記複合型データ管理システムは、
    前記第１データ記憶部における特定のデータ管理機能の使用が、前記複合型データ管理システムに対してネガティブなパフォーマンスの影響を有することを判定し、
    それに応じて、前記第１データ記憶部における前記特定のデータ管理機能を回避して、前記ネガティブなパフォーマンスの影響を回避するために前記好ましいデータ記憶部の対応するデータ管理機能を使用する
    ことを特徴とする請求項９に記載のデータ管理方法。
11. 外部ソースを複数のデータ記憶部に接続するために構成される第１データ記憶部を含む前記複数のデータ記憶部と、
    前記複数のデータ記憶部と接続されており、
    前記外部ソースから外来データオブジェクトに関する書き込みリクエストを受信し、
    前記外来データオブジェクトが複数の予め定義された特徴のうちの１つ以上の特徴を有しているか否かを判定し、
    前記外来データオブジェクトが有していると判定された１つ以上の予め定義された特徴に基づいて、前記複数のデータ記憶部のうちのいずれが前記外来データオブジェクトにとって好ましいデータ記憶部であるのかを特定し、
    前記外来データオブジェクトの生データを格納するために前記特定した好ましいデータ記憶部に送信し、
    前記複数のデータ記憶部のいずれが前記外来データオブジェクトの生データを有する前記好ましいデータ記憶部であるかに関係なく、前記外来データオブジェクトに関するメタデータを前記複数のデータ記憶部のうちの前記第１データ記憶部に格納するルーティングレイヤと、を備え、
    前記メタデータは、特定のメタデータ入力と前記好ましいデータ記憶部におけるその対応するデータオブジェクトの生データとを対応付ける対応情報を含んでいる
    ことを特徴とする複合型データ管理システム。
12. 前記複合型データ管理システムは、さらに、
    前記第１データ記憶部に記憶された前記外来データオブジェクトに対応するメタデータによる処理が試みられたことを検知すると、前記好ましいデータ記憶部における前記外来データオブジェクトの生データを処理するように構成される
    ことを特徴とする請求項１１に記載の複合型データ管理システム。
13. 前記試みられた処理は、前記外来データオブジェクトの移動、削除、修正および複製のいずれかに合致する
    ことを特徴とする請求項１２に記載の複合型データ管理システム。
14. 前記外来データオブジェクトに関する書き込みリクエストは、「ＰＵＴ」オブジェクト処理である
    ことを特徴とする請求項１１に記載の複合型データ管理システム。
15. 前記複数の予め定義された特徴は、予め定義されたデータオブジェクトサイズを含む
    ことを特徴とする請求項１１に記載の複合型データ管理システム。
16. 前記複数の予め定義された特徴は、予め定義されたデータタイプを含む
    ことを特徴とする請求項１１に記載の複合型データ管理システム。
17. 前記対応情報は、前記外来データオブジェクトの生データが格納されている前記好ましいデータ記憶部における位置を示す情報を含んでいる
    ことを特徴とする請求項１１に記載の複合型データ管理システム。
18. 前記複合型データ管理システムは、さらに、
    外部のアプリケーションまたはユーザから、以前に格納されたデータオブジェクトに関する読み出しリクエストを受信し、
    前記以前に格納されたデータオブジェクトに対応する前記第１データ記憶部において格納されているメタデータを検索し、その際、当該メタデータは、前記外来データオブジェクトの生データが格納されている前記好ましいデータ記憶部における位置を示しており、
    前記メタデータによって示されている前記位置から前記以前に格納されたデータオブジェクトを読み出す
    ことを特徴とする請求項１１に記載の複合型データ管理システム。
19. 前記複合型データ管理システムは、
    前記好ましいデータ記憶部に格納された前記外来データオブジェクトに対する処理のために前記第１データ記憶部のデータ管理機能を用いる
    ことを特徴とする請求項１１に記載の複合型データ管理システム。
20. 前記複合型データ管理システムは、
    前記第１データ記憶部における特定のデータ管理機能の使用が、前記複合型データ管理システムに対してネガティブなパフォーマンスの影響を有することを判定し、
    それに応じて、前記第１データ記憶部における前記特定のデータ管理機能を回避して、前記ネガティブなパフォーマンスの影響を回避するために前記好ましいデータ記憶部の対応するデータ管理機能を使用するように構成されている
    ことを特徴とする請求項１９に記載の複合型データ管理システム。
21. 少なくとも第１データ記憶部と第２データ記憶部とを有する複合型データ管理システムによるデータ管理方法であって、
    前記複合型データ管理システムは、
    外部ソースから外来データオブジェクトに関する書き込みリクエストを受信し、
    前記外来データオブジェクトのオブジェクトサイズを判定し、
    前記オブジェクトサイズが予め定義された閾値未満のとき、前記外来データオブジェクトの生データを前記第１データ記憶部に格納し、その際、前記第１データ記憶部は、前記第２データ記憶部に比べて、小さなデータオブジェクトの格納および管理に適した構成となっており、
    前記オブジェクトサイズが前記予め定義された閾値以上のとき、前記外来データオブジェクトの生データを前記第２データ記憶部に格納し、その際、前記第２データ記憶部は、前記第１データ記憶部に比べて、大きなデータオブジェクトの格納および管理に適した構成となっており、
    前記外来データオブジェクトの生データが前記第１データ記憶部に格納されているか前記第２データ記憶部に格納されているかに関係なく、前記外来データオブジェクトに関するメタデータを前記複数のデータ記憶部のうちの前記第１データ記憶部に格納し、その際、前記メタデータは、特定のメタデータ入力と、前記第１データ記憶部および前記第２データ記憶部のいずれかに格納されているその対応する前記データオブジェクトの生データとを対応付ける対応情報を含んでいる
    ことを特徴とするデータ管理方法。
22. 前記複合型データ管理システムは、
    前記書き込みリクエストを受信する場合、
    外部のアプリケーションまたはユーザから、前記外来データオブジェクトに関する書き込みリクエストを受信し、
    前記書き込みリクエストは、「ＰＵＴ」オブジェクト処理である
    ことを特徴とする請求項２１に記載のデータ管理方法。
23. 前記対応情報は、前記外来データオブジェクトの生データが前記第１データ記憶部または前記第２データ記憶部のいずれに格納されているかを示す情報を含んでいる
    ことを特徴とする請求項２１に記載のデータ管理方法。
24. 前記複合型データ管理システムは、
    外部のアプリケーションまたはユーザから、以前に格納されたデータオブジェクトに関する読み出しリクエストを受信し、
    前記以前に格納されたデータオブジェクトに対応する前記第１データ記憶部において格納されているメタデータを検索し、その際、当該メタデータは、前記以前に格納されたデータオブジェクトの生データが前記第１データ記憶部または前記第２データ記憶部のいずれに格納されているかを示しており、
    前記メタデータによって示されている位置から前記格納されたデータオブジェクトを読み出す
    ことを特徴とする請求項２１に記載のデータ管理方法。

Images