JP2008537258A - 分散型で非集中型のデータ格納および検索を行うシステムおよび方法 - Google Patents

Abstract

拡張ＳＯＡＰ環境内での分散型で非集中型のデータの格納および検索のためのシステムおよび方法が開示されている。この種のシステムおよび方法は、データ格納および検索に必要な帯域幅だけでなく計算要求も分散化する。したがって、この種のシステムおよび方法は、１つのノードがすべての格納および検索処理を行う必要性を軽減し、単一のノードがすべてのデータを送信するまたは受信するように求められない。

Description

概して、本発明は分散型で非集中型のデータ格納および検索を行うシステムおよび方法に関する。より詳細には、本発明は、例えば、リッチメディア広告、写真およびビデオの共有および格納、ならびにビデオ電子メールなどのピアベースサービスを可能にするために費用効果の高い機構を提供する分散型の格納モデルおよび検索モデルに関する。

いくつかのシナリオがピアベースの分散型格納システムを介して可能とされる。この種のシナリオの例は、ピアベースのテキストおよびリッチメディア広告の格納／キャッシング（ｃａｃｈｉｎｇ）／レプリケーション（ｒｅｐｌｉｃａｔｉｏｎ）、ピアベースのデジタル写真およびビデオの格納および共有、ならびにピアベースのビデオ電子メールを含む。しかし、これらのシナリオは、格納費用がデータセンタでは抑制されなくなる可能性があるのでサービスを集中されると法外な費用がかかる傾向がある。

多くのウェブサイトは、ユーザから以前に学んだ情報に基づいて掲載される高度のターゲット広告を有する純然たる広告ベースモデルに移行している。例えば、大量の人口統計学的データが人々について収集され、たくさんの情報が、ウェブサイトのクリックストリーム（ｃｌｉｃｋｓｔｒｅａｍ）で収集されたデータだけに基づいて推論されることができることはよく知られている。例えば、高度のターゲット広告は、検索キーワードに基づいていてもよい。典型的には、この種のシナリオは多くの記憶装置を要する。

集中型の方法でのこの種の広告の格納は以前に行われていた。しかし、異なる費用構造がローカル装置に対して広告を効率的に格納し、転送し、キャッシュに入れることができるために必要とされうるので、問題が新生市場などのある種の市場に存在する。多くの場合には、概して広告が様々な世界的市場にローカライズされているので、これらの広告を集中化し、データセンタで格納費用を支払うことは法外な費用である。世界中に広告を発送するために帯域幅の費用を支払うことは通常、効率的なまたは安価なモデルではない。

写真共有に関する既存の解決策は、２つの主要なグループに分類される、すなわち集中格納（例えば、ｐｈｏｔｏｓ．ｍｓｎ．ｃｏｍ）または二地点間（「Ｐ２Ｐ」）写真共有（例えば、Ｇｏｏｇｌｅの「Ｐｉｃａｓａ」の現バージョン）。集中格納は明確な制限を有する、すなわちそれが無料で提供される場合、写真格納に利用できる総スペースは厳しく制限されうる。一方、典型的な利用者手数料は、ユーザ自身のディスクを単に購入するためにユーザにかかる費用をはるかに超過する傾向がある。しかし、ユーザがユーザ自身のディスクを購入する場合、ユーザは写真をバックアップすることに関与し、ほとんどのブロードバンド接続がアップロードの速度を落とすので写真を見ることができる人数で厳しく制限されうる。

ＧｒｏｏｖｅまたはＧｏｏｇｌｅのＰｉｃａｓａの現バージョンなどのＰ２Ｐ写真共有の解決策は、ピアグループに関与するすべての装置にわたって写真を全コピーする。これは、上述の格納費用および帯域幅の問題を回避するが、それは異なる問題をもたらす。例えば、多くの人々がグループに関与していない場合、参加者の写真が、それらのローカルコピーが失われた場合に利用できない可能性がある機会がかなりある（様々なピアの使用可能時間に応じて）。さらに、この力づく的解決策はすべてのピアの１００％がすべての写真の１００％を格納する必要がある。これは、全ピアグループにわたって使用される多くの予備の記憶装置をもたらす結果となり、よく評価されない。

電子メールを介して配信されるビデオメッセージは、写真共有に関連して上述の同一の問題の多くを被るが、それらはサイズがさらに大規模である（格納を高価にする）。また配信が、中央のデータセンタからサービスされない限り信頼性のない結果となる。生放送のＰ２Ｐビデオ電話会議は格納問題を有しないが（ビデオが送信されると同時にビデオは取り込まれる）、それは話し手側の同時性と共に品質（帯域幅によって制限される）を中心にしてさらなる制限を有する。

したがって、当技術分野では、例えば、リッチメディア広告、写真／ビデオの共有／格納、およびビデオ電子メールなどのピアベースサービスを可能にするために費用効果の高い機構を提供する分散型の格納モデルの必要性がある。

本発明は、非集中型で分散型のデータ格納および検索のためのシステムおよび方法を提供する。この種のシステムは相互接続されたノードのネットワークを含むことができる。各ノードは、「ローカルキャッシュおよびトランスポート層」、「ストリーム・ストア層」、「チャンク・ストア層」および「フラグメント・ストア層」を形成する１つまたは複数のプロセスの集合体をその上で実行することができる。プロセスの集合体は「ブロック」格納のために提供されてもよい。

ローカルキャッシュおよびトランスポート層は、ストレージサービスと、ルーティングサービスとを含むことができる。ストレージサービスは、任意長のあるビットストリームを格納するための格納要求を受信することができる。ルーティングサービスは、ビットストリームをストリーム・ストア・サービスのうちのいずれかに伝達することができる。ストリーム・ストア・サービスは、その後の検索のためにローカル固定記憶装置(persistent storage)にビットストリームを格納し、ビットストリームを１つまたは複数の「チャンク」に分割することもできる。次いでストリーム・ストア・サービスは、チャンクを各チャンク・ストア・サービスに伝達することができる。チャンク・ストア・サービスは、その後の検索のためにローカル固定記憶装置にチャンクを格納し、チャンクを１つまたは複数の「フラグメント」に分割することもできる。次いでチャンク・ストア・サービスは、フラグメントをチェックブロック（ｃｈｅｃｋ ｂｌｏｃｋ）に符号化し、それらを各フラグメント・ストア・サービスに伝達することができる。フラグメント・ストア・サービスはその後の検索のためにローカル固定記憶装置にフラグメントを格納することができる。したがって、ビットストリームは複数のチェックブロックに分割され、概して各チェックブロックは、この種のノードの広大なネットワーク上で分散された、異なるネットワークノード上に格納されることができる。

この種の非集中型でピアツーピアの分散型格納システムは、例えば広告が見られるべきである実際の地方または都市に存在するクライアントＰＣ内など、デジタル広告をローカルに格納しキャッシュに入れるために使用されることができる。デジタル写真およびビデオの格納および共有に関しては基本的な分散型格納機構が、大量の冗長度を必要とすることなく写真の非常に高い信頼性および可用性を実現するために利用されることができる。ビデオ電子メールに関しては分散型格納モデルが、大規模なビデオメッセージのために調整される信頼性のある電子メール配信システムを構築するために利用されることができる。

〈コンピューティング環境の例〉
図１および下記の説明は、本発明の一例の実施形態が実現される適切なコンピューティング環境の簡単な一般的説明を行うものである。しかし、すべての種類のハンドヘルド機器、携帯機器、および他のコンピューティング機器が、本発明に関連して使用するために企図されることは理解されよう。汎用コンピュータが下記で説明されているが、これは単に一例である。本発明は、ネットワークサーバの相互運用性および対話を有するシンクライアント（ｔｈｉｎ ｃｌｉｅｎｔ）上で動作可能であってもよい。したがって、本発明の一例の実施形態は、ほとんどないクライアントリソースまたは最小のクライアントリソースが含まれているネットワークのホストサービスの環境で実現されることができる（例えば、クライアント機器がワールドワイドウェブに対するブラウザまたはインターフェースとしてだけ働くネットワーク環境）。

要求されていないが、本発明は開発者またはテスタによって使用されるためにアプリケーション・プログラミング・インタフェース（ＡＰＩ）を介して実現される、および／または１つまたは複数のコンピュータ（例えば、クライアントワークステーション、サーバ、または他の装置）によって実行されるプログラムモジュールなどのコンピュータの実行可能な命令の一般的なコンテキストで説明されるネットワーク・ブラウザ・ソフトウェア内に含まれることができる。概して、プログラムモジュールは、特定のタスクを実行するまたは特定の抽象データ型を実行するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。典型的には、プログラムモジュールの機能は、様々な実施形態で望まれるように結合されるまたは分散されることができる。さらに、当業者は、本発明が他のコンピュータシステム構成を用いて実施されることができることを理解することになる。本発明を用いて使用に適しうる他のよく知られたコンピューティングシステム、環境、および／または構成は、パーソナルコンピュータ（ＰＣ）、現金自動預け払い機、サーバコンピュータ、ハンドヘルドまたはラップトップ機器、マルチプロセッサシステム、マイクロプロセッサベースシステム、プログラマブル家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、などを含むが限定されるものではない。本発明の一実施形態は、タスクが、通信ネットワークまたは他のデータ伝送メディアを介して接続される遠隔処理装置によって実行される分散型コンピューティング環境で実施されることもできる。分散型コンピューティング環境ではプログラムモジュールは、メモリ記憶装置を含むローカルコンピューティング格納メディアおよび遠隔コンピュータ格納メディアの両方に配置されることができる。

したがって、図１は、本発明が実現されることができる適切なコンピューティングシステム環境１００の一例を示すが、上記で明確にしたようにコンピューティングシステム環境１００は、適切なコンピューティング環境の一例だけであって、本発明の使用または機能の範囲に関していかなる限定も示唆するものではない。コンピューティング環境１００は、例示の動作環境１００で示される構成要素のうちのいずれか１つまたは組合せに関係するいかなる依存性または要求を有するものとして解釈されるべきでもない。

図１を参照して、本発明を実現する一例のシステムは、コンピュータ１１０の形で汎用コンピューティング装置を含む。コンピュータ１１０の構成要素は、処理ユニット１２０、システムメモリ１３０、およびシステムメモリを含む様々なシステム構成要素を処理ユニット１２０に結合するシステムバス１２１を含むことができるが限定されるものではない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのうちのいずれかを使用するローカルバスを含むいくつかの種類のバス構造のうちのいずれかであってよい。例として（限定されない）、この種のアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子標準協会（ＶＥＳＡ）ローカルバス、周辺装置相互接続（ＰＣＩ）バス（メザニンバス（Ｍｅｚｚａｎｉｎｅ ｂｕｓ）としても知られている）などを含む。

典型的には、コンピュータ１１０は様々なコンピュータ可読メディアを含む。コンピュータ可読メディアは、コンピュータ１１０によってアクセスされることができる任意の利用可能メディアであってよく、揮発性および不揮発性、着脱式および固定式メディアの両方を含む。例として（限定されない）、コンピュータ可読メディアは、コンピュータ格納メディアと、通信メディアとを備えることができる。コンピュータ格納メディアは、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータなどの情報を格納するための任意の方法または技術で実現される揮発性および不揮発性、着脱式および固定式のメディアの両方を含む。コンピュータ格納メディアは、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、電気的消去可能プログラマブルリードオンリメモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、コンパクトディスクリードオンリメモリ（ＣＤＲＯＭ）、デジタルバーサタイルディスク（ＤＶＤ）もしくは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または所望の情報を格納するために使用されることができ、コンピュータ１１０によってアクセスされることができる任意の他のメディアを含むが限定されるものではない。典型的には通信メディアは、コンピュータ可読命令、データ構造、プログラムモジュールまたは搬送波または他の搬送機構などの変調されたデータ信号内での他のデータを具現化し、任意の情報配信メディアを含む。用語「変調されたデータ信号」は、信号内で情報を符号化するような方法で設定されるまたは変更されるその特性のうちの１つまたは複数を有する信号を意味する。例として（限定されない）、通信メディアは、有線ネットワークまたは直接配線接続などの有線メディア、ならびに音響、無線周波数（ＲＦ）、赤外線、および他の無線メディアなどの無線メディアを含む。上記のいずれかの組合せもコンピュータ可読メディアの範囲内に含まれるべきである。

システムメモリ１３０は、ＲＯＭ１３１およびＲＡＭ１３２などの揮発性メモリおよび／または不揮発性メモリの形でコンピュータ格納メディアを含む。起動中など、コンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム１３３（ＢＩＯＳ）は、典型的にはＲＯＭ１３１に格納される。典型的にはＲＡＭ１３２は、すぐにアクセス可能でありおよび／または処理ユニット１２０によって現在動作されているデータおよび／またはプログラムモジュールを含む。例として（限定されない）、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。ＲＡＭ１３２は他のデータおよび／またはプログラムモジュールを含むことができる。

コンピュータ１１０は、他の着脱式／固定式、揮発性／不揮発性のコンピュータ格納メディアも含むことができる。単に例として、図１は、固定式で不揮発性の磁気メディアから読み取るまたは固定式で不揮発性の磁気メディアに書き込むハードディスクドライブ１４１、着脱式で不揮発性の磁気ディスク１５２から読み取るまたは着脱式で不揮発性の磁気ディスク１５２に書き込む磁気ディスクドライブ１５１、およびＣＤ ＲＯＭまたは他の光メディアなどの着脱式で不揮発性の光ディスク１５６から読み取るまたは着脱式で不揮発性の光ディスク１５６に書き込む光ディスクドライブ１５５を示す。例の動作環境で使用されることができる他の着脱式／固定式、揮発性／不揮発性のコンピュータ格納メディアは、磁気テープカセット、フラッシュメモリカード、デジタルバーサタイルディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどを含むが限定されることはない。典型的にはハードディスクドライブ１４１は、インターフェース１４０などの固定式バブルメモリインターフェースを介してシステムバス１２１に接続されており、典型的には磁気ディスクドライブ１５１および光ディスクドライブ１５５は、インターフェース１５０などの着脱式メモリインターフェースによってシステムバス１２１に接続されている。

上述の図１に示されるドライブおよびそれらの関連したコンピュータ格納メディアは、コンピュータ１１０に関するコンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの格納を行う。例えば、図１ではハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納することとして示されている。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同一であるまたは異なるもののいずれかであってよいことは留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、少なくともそれらが異なるコピーであることを示すために本明細書では異なる番号を与えられている。ユーザは、キーボード１６２およびマウス、トラックボールまたはタッチパッドと一般に呼ばれるポインティングデバイス１６１などの入力機器を介してコンピュータ１１０に命令および情報を入力することができる。他の入力機器（図示せず）は、マイクロホン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどを含むことができる。これらの入力機器および他の入力機器は、システムバス１２１に結合されているユーザ入力インターフェース１６０を介して処理ユニット１２０ａ〜１２０ｆにしばしば接続されているが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェースおよびバス構造によって接続されていてよい。

モニタ１９１または他の種類の表示装置はまた、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続されている。モニタ１９１に加えてコンピュータは、出力周辺インターフェース１９５を介して接続されることができるスピーカ１９７およびプリンタ１９６などの他の周辺出力機器も含むことができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置または他の一般のネットワークノードであってよく、典型的には、メモリ記憶装置１８１だけが図１に示されているがコンピュータ１１０に対する上述の要素の多くまたはすべてを含む。図１に示される論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが他のネットワークも含むことができる。この種のネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットで一般的である。

ＬＡＮネットワーキング環境で使用されるとき、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続されている。ＷＡＮネットワーキング環境で使用されるとき、典型的にはコンピュータ１１０は、モデム１７２またはインターネットなどのＷＡＮ１７３上で通信を確立する他の手段を含む。内蔵または外付けであってよいモデム１７２は、ユーザ入力インターフェース１６０または他の適切な機構を介してシステムバス１２１に接続されてよい。ネットワーク環境では、コンピュータ１１０に対して説明されるプログラムモジュールまたはその一部は、遠隔メモリ記憶装置に格納されることができる。例として（限定されない）、図１は、メモリ装置１８１上に存在することとしてリモートアプリケーションプログラム１８５を示す。図示されたネットワーク接続は例示であり、コンピュータ間の通信リンクを確立する他の手段が使用されてよい。

当業者は、コンピュータ１１０または他のクライアント装置がコンピュータネットワークの一部として配置されることができることは理解できる。これに関連して本発明は、任意の数のメモリまたは格納ユニットを有するいかなるコンピュータシステムならびに任意の数の格納ユニットまたは容量にわたって生じる任意の数のアプリケーションおよびプロセスに関する。本発明の一実施形態は、遠隔記憶装置またはローカル記憶装置を有してネットワーク環境に配置されるサーバコンピュータおよびクライアントコンピュータを備える環境に適用することができる。本発明は、プログラミング言語機能、変換処理および実行能力を有する独立型のコンピューティング装置に適用されることもできる。

〈分散ネットワーク〉
図２は、複数のネットワークノード１０Ａ〜１０Ｈを備える分散ネットワークの一例を示す。例えば、この種のノードは、パーソナルコンピュータまたは例えばサーバ、ルータ、ネットワークＰＣ、ピア装置など、処理およびデータ格納能力を含む他の任意のネットワーク装置であってよい。例えば、ノード１０Ａ〜１０Ｈは、イントラネットまたはインターネットなどのローカルネットワークまたは広域ネットワーク上で互いに相互接続されているピアであってよい。

各ノード１０Ａ〜１０Ｈは固有のアドレスを割り当てられることができる。アドレスの長さは、各ノードが固有のアドレスを有することを保証するために選択されることができる。ネットワークが数千万個のノードを含むことが予想される一例のインタネットベースシステムでは、１６０ビットのアドレスが使用されることができる。この種のアドレス方式は、ＴＣＰの上部にルーティング・オーバーレイ（ｒｏｕｔｉｎｇ ｏｖｅｒｌａｙ）を形成することができる。

いくつかのノード１０Ａ〜１０Ｈの中に分散されるプロセスは、シンプル・オブジェクト・アクセス・プロトコル（「ＳＯＡＰ」）メッセージを介してネットワーク上で互いに通信することができる。ＳＯＡＰは、よく知られた軽量のＸＭＬベースの分散コンピューティングプロトコルである。ＳＯＡＰメッセージは、ＳＯＡＰエンベロープを含むＸＭＬ文書である。エンベロープは、任意選択のＳＯＡＰヘッダおよび必須のＳＯＡＰボディを含む。ＳＯＡＰメッセージヘッダは、メッセージのメタデータ（ｍｅｔａｄａｔａ）を表し、ＳＯＡＰを拡張するための方法を提供する。ＳＯＡＰメッセージボディは、実際のメッセージのペイロード（ｐａｙｌｏａｄ）である。分散プロセスは、ＳＯＡＰパケットをネットワーク上で動かすことによって互いに通信することができる。

プロセスは、メッセージ発信元（例えば、図示のノード１０Ａ上）、所期のメッセージ受信先（例えば、図示のノード１０Ｇ上）、または中継先（例えば、図示のノード１０Ｃ上）であってよい。メッセージ発信元は、初めからＳＯＡＰメッセージをネットワーク上で動かすプロセスである。所期のメッセージ受信先は、メッセージが最終的に定められたプロセスである。したがって、メッセージ発信元から創出するＳＯＡＰメッセージは、所期のメッセージ受信先に関連したアドレスを含むことができる。

しかし、メッセージ発信元が所期のメッセージ受信先のアドレスを知らないことが、特に大規模ネットワークで可能である。実際にはメッセージ発信元は、所期のメッセージ受信先が存在することすら知らない。したがって、所期の受信先（１０Ｇ上）へメッセージを伝えるために中継先ノード（１０Ｃ）上でのプロセスは、メッセージ（１２Ｃ）を受信し、メッセージを変更および／またはコピーし、メッセージの１つまたは複数のコピー（１２Ｄ〜１２Ｆ）をネットワーク上に戻すことができる。したがって、メッセージは、メッセージ（１２Ｇ）が所期のメッセージ受信先（１０Ｇ上）に結局、ホップ（ｈｏｐ）するまでネットワークの中を「ホップ」することができる。約１千万個のノードを有するネットワークの場合、平均ホップカウントは約３回であり、最大ホップカウントは約５．８回である。

発信元から所期のメッセージ受信先へメッセージを伝えるためにかかるホップ回数を最適化するために、ノードは「ゴシップする（ｇｏｓｓｉｐ）」ことができる。つまり、時々、ノードはネットワーク上にそれら自体についての情報を伝達することができる。例えば、ノードは、その使用可能時間または帯域幅およびその隣接ノードの状態についてゴシップすることができる。ノードはまた、それらの隣接ノードによって伝達されているこの種の情報をリッスン（ｌｉｓｔｅｎ）する。その結果、各ノードは、そのピアのうちのいくつかについて知り、情報を保持する。

この種のゴシッピングによりメッセージ発信元が、所期のメッセージ受信先のアドレスの特定の情報なしに所期のメッセージ受信先へメッセージを伝えることができる。例えば、メッセージ発信元がある装置へメッセージを伝えたい場合、メッセージ発信元はできるだけその装置に近いメッセージ（例えば、所期のメッセージ受信先について何かを知りうる他のノードへのメッセージ、または所期のメッセージ受信先について何かを知りうる他のノードについての何かを対処するなど）を伝えることだけが必要である。所期のメッセージ受信先の隣接ノードは所期のメッセージ受信先の情報を有することになるので、メッセージは結局、所期のメッセージ受信先にホップすることになる。したがって、例えば、メッセージ発信元は所期のメッセージ受信者に直接到達する方法を知らない、または例えば、ファイアウォールなどのために所期のメッセージ受信者に直接到達することができない場所にさえメッセージを配信することができる弾力性のあるネットワークが構築されることができる。

各ノード１０Ａ〜１０Ｈ上のサービスは、１つまたは複数の隣接ノードに代わりにローカル・ルーティング・テーブル１４Ａ〜１４Ｈを維持することもできる。ローカル・ルーティング・テーブルは、下記でより詳細に説明される。

〈分散型データ格納のためのシステムおよび方法〉
図３Ａおよび図３Ｂは、分散型データ格納のための一例のシステムを示す。図示されるようにこの種のシステムは、上述などの相互接続されたノードのネットワーク（例えば、３０Ａ、３０Ｂ〜３０Ｎ）を含むことができる。各ノード３０Ａ〜３０Ｎは、その上で実行する任意の数のプロセスを有することができる。例えば、各ノード３０Ａ〜３０Ｎは、「ローカルキャッシュおよびトランスポート層」２０を形成する１つまたは複数のプロセスの集合体と、「ストリーム・ストア層」３２を形成するプロセスの集合体と、「チャンク・ストア層」３４を形成するプロセスの集合体と、「フラグメント・ストア層」３６を形成するプロセスの集合体とを有することができる。プロセスの集合体（図示せず）が、チェックブロック格納のために含まれていてもよい。

ローカルキャッシュおよびトランスポート層２０は、ストレージサービス２２とルーティングサービス２４とを含むことができる。ストレージサービス２２およびルーティングサービス２４は、同一のノードまたは異なるノード上に存在することができる。ストレージサービス２２は、ネットワークを介して同一のノードからまたは異なるノードから格納要求（ビットストリーム）を受信することができる。格納要求は、あるビットストリームを格納するための要求を含むことができる。概して、この種のビットストリームはいかなる任意長Ｍを有することができる。ルーティングサービス２４は、ビットストリームを１つまたは複数のストリーム・ストレージサービス３２Ａ〜３２Ｎのうちのいずれかに伝達することができる。ビットストリームを受信するストリーム・ストレージサービスは、ルーティングサービスと同一のノード上または異なるノード上に存在することができる。

受信者ノード（図示の３２Ａ）でのストリーム・ストア・サービスは、ビットストリームを含む１つまたは複数のパケットを受信することができる（例えば、ビットストリームが非常に長いので２つ以上のパケットがビットストリームをストリーム・ストア・サービスに伝達するために必要とされる）。ストリーム・ストア・サービス３２Ａは、その後の検索のためにローカル固定記憶装置内にビットストリームを格納することができる。ストリーム・ストア・サービス３２Ａは、ビットストリームを１つまたは複数の「チャンク」に分割することもできる。各チャンクは長さｍ≦Ｍビットであってよい。一例の実施形態では、各チャンクは約６４Ｋビットの長さを有することができる。次いで、ストリーム・ストア・サービス３２Ａは、１つまたは複数のチャンクのそれぞれを各チャンク・ストア・サービス３４Ａ〜３４Ｎに伝達することができる。チャンクを受信するチャンク・ストア・サービスは、ストリーム・ストア・サービス３２Ａと同一のノード上または異なるノード上に存在することができる。

受信者ノード（図示の３４Ａ）でのチャンク・ストア・サービスは、チャンクを含む１つまたは複数のパケットを受信し、その後の検索のためにローカルの永続性記憶装置内にチャンクを格納することができる。チャンク・ストア・サービス３４Ａは、チャンクを１つまたは複数の「フラグメント」に分割することもできる。各フラグメントは長さｌ≦ｍビットであってよい。一例の実施形態では各フラグメントは、約２Ｋビットの長さを有することができる。次いで、チャンク・ストア・サービス３４Ａは、フラグメントをチェックブロックに符号化し、１つまたは複数のチェックブロックのそれぞれを各フラグメント・ストア・サービス３６Ａ〜３６Ｎに伝達することができる。フラグメントを受信するフラグメント・ストア・サービスは、チャンク・ストア・サービス３４Ａと同一のノード上または異なるノード上に存在することができる。

受信者ノード（図示の３６Ａ）でのフラグメント・ストア・サービスは、フラグメントを含む１つまたは複数のパケットを受信し、その後の検索のためにローカル固定記憶装置内にフラグメントを格納することができる。受信者ノードでのフラグメント・ストア・サービス３６Ａ〜３６Ｎは、各チェックブロックを含む１つまたは複数のパケットを受信することができ、それぞれは、その後の検索のためにローカル固定記憶装置内に各チェックブロックを格納することができる。したがって、Ｍビットのビットストリームは、複数のｋビットのチェックブロックに分割され、概して各ブロックは、この種のノードの広大なネットワーク上に分散された異なるネットワークノード上に格納される。

各チャンクが分割されるチェックブロック数は、多大な自信を持って信頼性のある検索を保証するために十二分であることが好ましい。いくつかの知られたアルゴリズムのいずれかは、元のビットストリームがチェックブロックから再構築されることができることを一定の自信レベルを持って保証するために格納されるべきチェックブロック数を決定するために使用されることができる。この種のアルゴリズムは当業者には知られており、したがって本明細書で詳細に説明される必要はない。

データ検索システム（下記で説明される）がその後、格納されたデータを見いだすことができることを保証するためにアドレス方式が、データを格納すべき場所（すなわち、どのノード上）を決定するために使用されることができる。例えば、ルーティングサービスは、ビットストリームをルーティングすべきノードのアドレスをビットストリーム自体に基づいて計算することができる。例えば、各ノードが固有のアドレスによって識別されることができる上述などのシナリオではハッシュ（ｈａｓｈ）が、ビットストリームに基づいて計算されることができ、ハッシュテーブルは、ハッシュ値に対応するノードアドレスを決定するために調べられることができる。

ビットストリームはビットストリーム識別子を有することができる。例えば、ビットストリームはファイルであってよく、すなわちファイルはファイル名を有する。したがって、ファイル名がビットストリーム識別子と見なされてよい。ユーザ（すなわち、ビットストリームを格納するように求める人）はユーザ識別子を有することができる。例えば、ユーザに関連する公開鍵があってよい。一例の実施形態では、ビットストリーム識別子およびユーザ識別子が連結され、連結されたストリング（ｓｔｒｉｎｇ）のハッシュが計算されることができる。上述のように計算されたハッシュ値は、ビットストリームが格納および後続の格納処理のために送信されるべきノードのアドレスを決定するために使用されることができる。同様に、各ハッシュ値は、ビットストリームが分解されるチャンクごと、フラグメントごとおよびチェックブロックごとに計算されることができる。次いで、チャンク、フラグメント、およびチェックブロックは、計算されたハッシュ値に対応するアドレスを有するノードに送信されることができる。

数百万個のノードを有するネットワーク環境では、各ノードがあらゆるノードに関連する各アドレスを含むハッシュテーブルを格納し維持することは実際的ではない（および望ましくない）。したがって、一例の実施形態では、各ノード１０Ａ〜１０Ｈ上のサービスは、１つまたは複数の隣接ノードの代わりにローカル・ルーティング・テーブル１４Ａ〜１４Ｈを維持することができる（図２参照）。あらゆるノードがアドレス空間（すなわち、いくつかのノードを一意的に識別するために使用されるアドレス方式）について知っているが、各ノードはその隣接ノードのいくつかのためだけにルーティングテーブルを維持することが好ましい。したがって、ハッシュテーブルはいくつかのノードの間に分散されることができる。

分散されたハッシュテーブルを使用することによって各ノードは、全アドレス空間のほんの一部だけを洞察する。しかし、上述のように、メッセージ発信元が所期の受信先のアドレスを知る必要がないことが基本的ファブリック（ｆａｂｒｉｃ）の性質である。メッセージ発信元は格納されるべきビットストリーム（またはチャンクまたはフラグメントまたはブロック）に基づいてハッシュを計算し、そのローカルハッシュテーブルを調べることができる。アドレスが見いだされた場合、メッセージ発信元は所期の受信先にメッセージを直接送信することができる。そうでない場合、メッセージ発信元はメッセージをファブリック上で動かし、メッセージは、それが所期の受信先に達するまで１つまたは複数の中継先を介してホップする。

結局は、上述のようにデータ（例えば、チェックブロック、フラグメント、チャンク、またはビットストリーム）は送信先ノードで永続的である（すなわち、記憶装置に永久的に格納される）。データが永続的であるとき、送信先ノードは、データが永続的であることを発信元ノードに通知するためにファブリック上でメッセージを動かすことができる。発信元ノードが情報メッセージを受信するとき、発信元ノードはデータが永続的であることを受諾する。

例えば、チェックブロックが送信先ノード上で永続的であるとき、フラグメント・ストア・サービスは、チェックブロックが永続的であることをチェックブロックの格納を要求したチャンク・ストア・サービスに通知することができる。同様に、所与のチャンクに関連するすべてのチェックブロックが永続的であるとき、チャンク・ストア・サービスは、チャンクが永続的であることをチャンクの格納を要求したストリーム・ストア・サービスに通知することができる、など。結局は、ローカルキャッシュおよびトランスポート層でのルーティングサービスは、ビットストリームが格納されていることを通知される。

格納が適切に行われたことを確認するために格納を要求するサービスは、データが格納のために送信されるときにタイマを開始することができる。例えば、チャンク・ストア・サービスが格納のためにそのフラグメントを送出するとき、チャンク・ストア・サービスはフラグメント格納確認のタイマを開始することができる。チャンク・ストア・サービスは、特定のフラグメントが、タイマが終了する前に格納されたという確認を受信しない場合、チャンク・ストア・サービスは、フラグメントが格納されなかったと結論を出し、フラグメントを他の場所に格納しようとする。

しかし、上述の分散システムが時間を「変える」能力を有することができることは理解されよう。つまり、各ノードは、絶対システム時間に対してそのノードのために計時するタイムマネジャを有することができる。したがって、時間は、絶対システム時間におよび他のノードのタイムフレームに対して特定ノード上で遅くされる、停止される、または逆行さえされてよい。したがって、格納を要求するノードでの時間が、データが格納されるべきノード（または中継ノード）での時間より速く進みうるので格納を要求するノードでのタイマは、たとえ格納プロセスに何か不具合がなくても（時間が単に遅く進んでいる）データが永続的である前に終了することができる。これに対して対応するために、格納ノードは、たとえ格納がまだ完了されていなくても格納を要求するノードがタイムアウトになるべきでないことを、格納を要求するノードに通知するために格納を要求するノードにメッセージを定期的に送信することができる。

ビットストリーム（または下記に説明されるようにビットストリームの一部）を検索するためにローカルキャッシュおよびトランスポート層２０でのルーティングサービス２４は、データが、それが格納されるノードから検索されるべきことを要求するネットワーク上にメッセージを動かすことができる。データを検索するためにルーティングサービス２４は、データに関連するキーを計算することができる。例えば、上述のように、ルーティングサービスはビットストリーム識別子およびユーザ識別子のハッシュを計算することができる。計算されたハッシュ値は、ビットストリームが格納および後続の格納処理のために送信されるノードのアドレスを決定するために使用されることができる。

次いでルーティングサービスは、ハッシュに関連するアドレス（または最も近い隣接アドレス）を決定するためにローカル・ルーティング・テーブルを調べ、そのアドレスにビットストリームを要求することができる。ビットストリームがそのストリーム・ストア・サービスに関連するローカルキャッシュ内に依然として格納されている場合、ストリーム・ストア・サービスは、１つまたは複数のパケット内のビットストリームを、それを要求したノードに戻す。ビットストリームが、そのストリーム・ストア・サービスに関連するローカルキャッシュ内にまだ格納されていない場合、ストリーム・ストア・サービスは、ビットストリームが分解されたチャンクに関連するハッシュを計算し、それらのチャンクが格納プロセス中に送信されたチャンク・ストア・サービスにそれらのチャンクを要求する。

チャンクが、そのチャンク・ストア・サービスに関連するローカルキャッシュ内に残存する場合、そのチャンクはそれを要求したノードに戻される。そうでない場合、チャンク・ストア・サービスは、そのチャンクに関連するフラグメントに関連するハッシュを計算し、それらのフラグメントが格納されたノードにそれらのフラグメントを要求する。

ビットストリームが再構成され、それを要求したノードビットストリームに戻されるまでこのプロセスが続けられる（フラグメントを再構成するためにチェックブロックを検索すること、チャンクを再構成するためにフラグメントを検索すること、ビットストリームを再構成するためにチャンクを検索すること）。上述のように、基本的なファブリックの性質は、キーにルーティングすることによりメッセージが、データが格納されているノードに送られることである。

上述のように、ビットストリームが複数の連続的なチェックブロック（フラグメント、チャンク）に分割されることができる。したがって、検索プロセスは全ビットストリームを検索する必要がなく、チェックブロック（フラグメント、チャンク）のサブセットだけを検索することができる。概して、検索プロセスはビットストリーム内の任意のチェックブロック（フラグメント、チャンク）で開始し、他の任意のチェックブロック（フラグメント、チャンク）で終了することができる。ビットストリームの一部だけを検索するために検索サービスは、ビットストリームのその一部を構成するチェックブロック（フラグメント、チャンク）に関連するアドレスを決定し、それらのチェックブロック（フラグメント、チャンク）にビットストリームのその一部の再構成を要求することだけを必要とする。ハッシュプロセスは、以前の層の識別子およびチャンクの序数（すなわち、オフセット）、つまりより低い層内でのチェックブロックをハッシュすることによって動作するのでその部分のいずれかのハッシュ値を見いだすことが可能である。

チェックブロックが永続的であるノードが、データが検索されたときに、もはやネットワーク上にない可能性がある（例えば、データが上書きされた、削除された、または破損された可能性がある、ノードが、データが必要とされるときに利用できない可能性がある、ノードがネットワークから永久に除去されてしまう可能性がある、など）ことが予想される。上述のように各チャンクが分割されるチェックブロック数は、いくつかのチェックブロックが修復できないときでさえ、多大な自信を持って信頼性のある検索を保証するために十二分であることが好ましい。１つまたは複数のノードが、データが格納される時点とデータが検索される時点との間でネットワークに追加されることができることも予想される。キーにより近い新しいノードが導入された場合、基本的ファブリックの性質により以前の既存のノード（データが格納された時点で存在したノード）は新しいノードが導入されたことおよび新しいノードが検索されるように求められるデータにより近いことを理解することになる。したがって、新しいノードは、データが格納されるノードにメッセージをホップするプロセスを続けるために新しいノードへの適切なメッセージを「強いる」ことができる。

本発明の１つの態様により、非集中型でピアツーピアの分散型格納機構は、例えば、広告が見られるべきである実際の地方または都市に存在するクライアントＰＣ内など、ローカルに広告を格納しキャッシュに入れるために使用されることができる。このようにして、テキスト広告およびバナー広告が格納されるだけでなく、特定の地域、近所、または個人に局部化されたリッチメディア（例えば、ステレオ音声に加えてフルモーションビデオ）のテレビ型広告も格納されることができる。

デジタル写真およびビデオの格納および共有に関しては基本的な分散型格納機構は、ＧｏｏｇｌｅのＰｉｃａｓａの現バージョンでなど、この種の多大な量の冗長度を必要とすることなく写真の非常に高い信頼性および可用性を実現するために利用されることができる。具体的にはこのシナリオは、市場に現れる電話ベースカメラの数の増大を考慮すると重要でありうる。それ自体のローカル大容量記憶装置を有する電話ベースカメラの場合でさえ、ユーザは、写真をバックアップしそれらを電子的に共有する問題を依然として有する可能性がある。これは、携帯電話の利用がより迅速な無線インフラストラクチャの増設により急増している新生市場で特に興味がありうる。

ビデオ電子メールに関して、分散型格納モデルは、大規模のビデオメッセージのために調整される信頼性のあるメール配信システムを構築するために利用されることができる。この種のシステムでは品質問題は、システムが送信者または受信者のいずれかの帯域幅制限によってもはや拘束されないので解決されることができる。それによって受信側が、同時に同一の場所で自由にされることもできる。このシナリオは、複雑なスクリプトがキーボード上でテキストメッセージをタイプすることを困難にし、高い率の誤字が任意の種類のテキストメッセージを送信することを困難にする新生市場で重要でありうる。

したがって、拡張ＳＯＡＰ環境でのデータの分散型で非集中型の格納および検索のためのシステムおよび方法が説明されている。この種のシステムおよび方法は、データ格納および検索に必要な帯域幅だけでなく計算要求も分散化することは理解されよう。つまり、この種のシステムおよび方法は、１つのノードがすべての格納および検索処理を行う必要性を軽減し、単一のノードがすべてのデータを送信するまたは受信するように求められない。

本発明は様々な図で示されるある種の好ましい実施形態に関連して説明されているが、他の同様の実施形態が使用されることができ、変更または追加が、それから逸脱することなく本発明を実施するために説明された実施形態になされることができることがさらに理解されよう。例えば、データが格納されているとき、データは暗号化され符合化されるなどができ、それによって検索処理は、実際に検索されたデータが予想されたデータであることを検証することができるようになる。したがって、本発明は任意の単一の実施形態に限定されるべきでなく、特許請求の範囲による幅および範囲で解釈されるべきである。

本発明の態様が実行されるコンピューティング環境の一例を示す構成図である。 分散ネットワークの一例を示す図である。 分散型格納システムの一例を示す図である。 分散型格納システムの一例を示す図である。

Claims (19)

1. ビットストリームを格納するための要求を受信し、前記ビットストリームを含むストリーム・ストア・メッセージをネットワーク上にルーティングするローカルキャッシュおよびトランスポート層と、
   前記ストリーム・ストア・メッセージを受信し、前記ビットストリームを複数のチャンクに分割し、複数のチャンク・ストア・メッセージをネットワーク上に送信するストリーム・ストア層と
   を備え、
   各前記チャンク・ストア・メッセージは、前記複数のチャンクのそれぞれ１つを含み、
   前記チャンクのそれぞれは、第１の複数のネットワークノードのうちのそれぞれ１つ上に格納されることを特徴とする非集中型で分散型のデータ格納のためのネットワークベースシステム。
2. 前記チャンク・ストア・メッセージを受信し、各チャンクを各複数のフラグメントに分割し、前記フラグメントをチェックブロックに符号化し、複数のフラグメントストア・メッセージをネットワーク上に送信するチャンク・ストア層をさらに備え、各前記フラグメントストア・メッセージは前記複数のフラグメントのうちのそれぞれ１つを含み、
   前記フラグメントのそれぞれは、第２の複数のネットワークノードのうちのそれぞれ１つ上に格納されることを特徴とする請求項１に記載のネットワークベースシステム。
3. 前記フラグメントストア・メッセージを受信し、前記チェックブロックのそれぞれを第３の複数のネットワークノードにわたって格納されるようにするフラグメント・ストア層
   をさらに備えることを特徴とする請求項２に記載のネットワークベースシステム。
4. 前記ビットストリームは、前記ストリーム・ストア層に関連するネットワークノード上に格納されることを特徴とする請求項３に記載のネットワークベースシステム。
5. 各フラグメントは、所定の程度の自信の範囲内で前記フラグメントの検索を保証するために十分なチェックブロック数に符号化されることを特徴とする請求項２に記載のネットワークベースシステム。
6. 前記ローカルキャッシュおよびトランスポート層は、前記ビットストリームに基づいてハッシュ値を計算し、前記ハッシュ値は、前記ストリーム・ストア・メッセージが送信される予定であるノードに関連するアドレスを決定するために使用されることを特徴とする請求項１に記載のネットワークベースシステム。
7. 前記ローカルキャッシュおよびトランスポート層は、前記ビットストリームが格納されている前記ストリーム・ストア層から確認を受信することを特徴とする請求項１に記載のネットワークベースシステム。
8. 前記ローカルキャッシュおよびトランスポート層は、前記ビットストリームが格納のために送出されるときにタイマを開始し、前記ローカルキャッシュおよびトランスポート層が、前記タイマが終了する前に前記ビットストリームが格納されているという確認を前記ストリーム・ストア層から受信しない場合、前記ローカルキャッシュおよびトランスポート層は前記ビットストリームを異なるノード上に格納しようとすることを特徴とする請求項７に記載のネットワークベースシステム。
9. 各ノードは、絶対システム時間に対してそのノードのために計時するタイムマネジャを有し、前記ストリーム・ストア層は、前記ビットストリームが依然として格納されるプロセス中であるのでタイムアウトしないことを前記ローカルキャッシュおよびトランスポート層に通知することを特徴とする請求項８に記載のネットワークベースシステム。
10. 各ノードは、１つまたは複数の隣接ノードの代わりにローカル・ルーティング・テーブルを維持し、前記ハッシュ値を含む前記ローカル・ルーティング・テーブルのうちの少なくとも１つは、前記ストリーム・ストア・メッセージが送信される予定である前記ノードに関連する前記アドレスを決定するために使用されることを特徴とする請求項６に記載のネットワークベースシステム。
11. 前記チャンク・ストア・メッセージのうちの少なくとも１つは、１つまたは複数の中継ネットワークノードを介してネットワークの中をホップすることによって所期のメッセージ受信先に配信されることを特徴とする請求項１に記載のネットワークベースシステム。
12. デジタル広告の格納のための要求を受信し、前記デジタル広告に関連するビットストリームを含むストリーム・ストア・メッセージをネットワーク上にルーティングするように動作する第１のサービス集合体と、
    前記ストリーム・ストア・メッセージを受信し、前記ビットストリームを複数のチェックブロックに分割し、複数のネットワークノードのうちのそれぞれ１つ上に格納するために前記チェックブロックを配信するように動作する第２のサービス集合体と
    を備えることを特徴とする非集中型でピアツーピアの分散型格納システム。
13. 前記ネットワークノードのうちの少なくとも１つは、前記広告が見られる地理的な位置に存在する記憶装置を含むことを特徴とする請求項１２に記載の分散格納システム。
14. 前記広告は、テキスト広告、バナー広告、ならびにフルモーションビデオおよびステレオ音声を含むリッチメディア広告のうちの少なくとも１つであることを特徴とする請求項１２に記載の分散格納システム。
15. 前記広告は、特定の地理的地域にローカライズされるまたは特定の個人にパーソナライズされることを特徴とする請求項１２に記載の分散格納システム。
16. デジタル写真およびデジタルビデオのうちの少なくとも１つを格納するための要求を受信し、前記デジタル写真またはデジタルビデオに関連するビットストリームを含むストリーム・ストア・メッセージをネットワーク上にルーティングするように動作する第１のサービス集合体と、
    前記ストリーム・ストア・メッセージを受信し、前記ビットストリームを複数のチェックブロックに分割し、複数のネットワークノードのうちのそれぞれ１つ上に格納するために前記チェックブロックを配信するように動作する第２のサービス集合体と
    を備えることを特徴とする非集中型でピアツーピアの分散型格納システム。
17. 前記デジタル写真またはデジタルビデオは電話ベースカメラから創出されたことを特徴とする請求項１６に記載の分散格納システム。
18. 前記電話ベースカメラが無線の電話ベースカメラであることを特徴とする請求項１７に記載の分散格納システム。
19. ビデオ電子メールメッセージを格納するための要求を受信し、前記ビデオ電子メールメッセージに関連するビットストリームを含むストリーム・ストア・メッセージをネットワーク上にルーティングするように動作する第１のサービス集合体と、
    前記ストリーム・ストア・メッセージを受信し、前記ビットストリームを複数のチェックブロックに分割し、複数のネットワークノードのうちのそれぞれ１つ上に格納するために前記チェックブロックを配信するように動作する第２のサービス集合体と
    を備えることを特徴とする非集中型でピアツーピアの分散型格納システム。

Images