JP6602355B2 - クラウドベースの分散永続性及びキャッシュデータモデル - Google Patents

Description

本発明は、構造化照会言語（ＳＱＬ）アプリケーションインタフェースを備えたクラウドベースの分散永続性及びキャッシュデータモデルを使用して、クラウドコンピューティングの拡張可能性を向上させ待ち時間を低減するためのシステム及び方法を提供する。

クラウドコンピューティング環境は、ウェブ上でネットワークを介して、インフラストラクチャ、アプリケーション、及びソフトウェアを提供することができる。初期のウェブベースのインフラストラクチャは、メインフレーム又はサーバベースの関係データベースモデル及びｎ階層ネットワーククラスタリングアプリケーションサーバに基づいていた。ウェブが成長して対話型プラットフォームになったので、インフラストラクチャは、２つのフロント−データ層とアプリケーション層になった。アプリケーション層に対しては多数のソリューションが存在し、オフザシェルフ・ソリューションを使用することによって直線的な拡張可能性をかなり容易に達成することができ、アプリケーション層が、モデルビューコントローラ（ＭＶＣ）アーキテクチャでビュー及びコントローラを提供する。データ層は本来、ＭＶＣアーキテクチャにおけるモデルを構成する。データ層は、関係データベース、オブジェクト指向データベース、及びキー／値ペアデータベースを含むデータベース管理システムの１つを使用して、アプリケーションに対する非構造化／構造化データを提供する。

関係データベース
関係データベースは、本技術分野で公知である。関係データベースは、構造化照会言語（ＳＱＬ）を使用してアクセスすることができる構造化テーブル内のビット及びバイトの形式で様々なデータ型を格納する構造化データストアある。関係データベースの基点は、関係代数にさかのぼることができる。現在の関係データベース提供物の基本的な前提は、標準化されたインタフェースを介して何らかのハードウエア又はソフトウェアから独立してデータがアクセス可能である必要がある点にある。初期段階では、データ要素は、最小又はゼロ関係属性によって独立している。データベースエンジンがより強力になるにつれて、データ構造及び関係データグラフは、テーブルとデータ要素との間の関係が複雑になるように複雑になる。本来、関係データベースは、データベースにアクセスするアプリケーションのためのＳＱＬインタフェースを備えた行及び列から構成されるテーブルの集まりである。関係データベースは、一般的なデータを管理する場合に、単純性、ロバスト性、融通性、性能、拡張可能性、及び互換性のベストミックスをこれまで提供してきた。データベースを供給するベンダーに関わらず、全ての関係データベースは、例外なくデータの構造化を要求する。関係データベース管理システム（ＲＤＢＭＳ）の欠点は、手動介入及び維持を必要とするパーティショニング及び／又はシャーディングを使用しない限り、動的又は自動的にネットワーク上でシームレスに物理マシン境界全体にわたって分散できないということである。

この手動介入は、単一マシンの物理境界内又は外部データアレイ内に格納することができるデータ量の物理的制限を克服する必要がある。ウェブ２．０及びその大規模なデータスケールが出現する前は、上記のシナリオは、マルチコアコンピュータ処理ユニットを備えた単一マシンの計算能力が大部分の機構のデータ成長よりも速く成長したので絶えず機能することができたが、現在のアプリケーションに対するデータスケールは、毎日、指数的に成長し、上記の前提が当てはまらない。上記の欠点は、極めて高額な使用許諾及びサポート費用に加えて、エクサバイト及びゼッタバイトであるデータスケールを有する現在の及び将来のクラウドベースのアプリケーションに対して関係データベースを不都合なものにする。

関係／オブジェクト関係データベース
関係データベース設計は、１世代又は２世代ずつオブジェクト指向設計パラダイムに先行しているので、複雑なオブジェクトグラフに対する真のサポートが欠如している。情報の複雑性の進歩が、関係データベースに対する別の欠点を引き起こしている。関係データベースは、詳細には、共通の特性によってデータを組織化するために作られる。複雑な画像、数字、設計、及びマルチメディア製品は、簡単なカテゴリー化を不可能にし、最終的には非構造化データに変わる複雑なオブジェクトグラフをもたらし、オブジェクト−関係データベース管理システムと呼ばれるデータベースの新しい形式のための方法をもたらす。現在のシステムは、より複雑なアプリケーションを処理するよう設計されており、クラウドにおける拡張可能及び分散可能である能力を必要とする。オブジェクト関係データベースは、これらが拡張可能又はネットワーク分散可能でないので必要条件を満足させず、従って不適当である。

キー／値データベース
新しいウェブ２．０パラダイムは、ギガバイトとは対照的にテラバイト及びペタバイト単位で測定されるデータを処理する。関係データベースは４０年間機能しているが、これらは、毎日のようにテラバイトの大きさで急成長するデータを処理するのに適切ではない。この欠点に対する主な理由は、関係データベースに対して、拡張可能性が、下層マシン又は分割マシンの計算能力に直接関係付けられるからである。コンピュータ処理のすべてのファセットにソーシャルネットワーキングの態様を追加したウェブ２．０の出現の前は、サーバ設計における進歩によって、データベースは拡張して、スアプリケーションのニーズにサービスを提供するようになっているが、ペタバイト及びより大きな大量データを処理するために、新しい形式のデータベース管理システムが定着しており、非関係データベース管理システム（非ＲＤＢＭＳ）又はスキームレスデータベースとして公知のキー／値ストアを使用している。新しい形式のデータベース管理システムは、一般的にはキー／値ストアを使用する非関係及び／又はＮｏＳＱＬデータベースと呼ばれる。実際には、標準的な名前がまだ存在せず、文書指向、インターネットフェーシング、属性指向、分散データベース（これも関係性とすることができるが）、シャードソートアレイ、分散ハッシュテーブル、又はキー／値データベースと呼ぶことができる。これらの名前の各々は、この新しい方式の特定の特徴を示すが、これらは、発明者らがキー／値データベースと呼ぶ、１つのテーマにおける全てのバリエーションである。以下を含む幾つかの選択肢が、この新しいキー／値方式によって現在の市場で利用可能である。

Ｃａｓｓａｎｄｒａ（カサンドラ）は、オープンソース分散データベース管理システムである。これは、単一障害点がない高可用性サービスを提供すると同時に多くのコモディティサーバ全体に拡散される大量のデータを処理するよう設計されたＡｐａｃｈｅソフトウェア財団のトップレベルプロジェクトである。これは、最初にＦａｃｅｂｏｏｋによって開発されそれらのインボックス検索特徴を強力にするＮｏＳＱＬソリューションである。Ｃａｓｓａｎｄｒａは、Ａｍａｚｏｎ−Ｄｙｎａｍｏのようなインフラストラクチャで実行されるＢｉｇＴａｂｌｅ（ビッグテーブル）データモデルである。

Ｃａｓｓａｎｄｒａは、結果整合性を有する構造化キー−値ストアを提供する。キーは、カラムファミリーにグループ分けされる複数の値にマップされる。カラムファミリーは、Ｃａｓｓａｎｄｒａデータベースが作成された時に固定されるが、いつでもファミリーにカラムを追加することができる。更に、カラムは、指定されたキーだけに追加され、異なるキーは、いずれの所与のファミリーにおいてもカラムの異なる数を有することができる。

各キーに対するカラムファミリーからの値が一緒に格納され、Ｃａｓｓａｎｄｒａをカラム指向のＤＢＭＳと行指向のストアの間のハイブリッドにする。

一般的には、ＣｏｕｃｈＤＢと呼ばれるＡｐａｃｈｅ ＣｏｕｃｈＤＢは、Ｅｒｌａｎｇプログラミング言語で書かれたフリーオープンソース文書指向データベースである。これは、ローカル複製のために設計されたＮｏＳＱＬ製品であり、広範囲のデバイスに沿って垂直に拡張する。ＣｏｕｃｈＤＢは、営利事業ＣｏｕｃｈＯｎｅ ａｎｄ Ｃｌｏｕｄａｎｔによってサポートされる。

ハイパーテーブルは、ＧｏｏｇＬｅのＢｉｇＴａｂｌｅ（ビッグテーブル）の設計での公開に端を発するオープンソースデータベースである。プロジェクトは、大規模データインテンシブタスクを解決したエンジニアの経験に基づく。ハイパーテーブルは、ＡｐａｃｈｅＨａｄｏｏｐＤＦＳ、グラスタＦＳ、又はコスモスファイルシステム（ＫＦＳ）のような分散ファイルシステム（ＤＦＳ）の上部で実行される。これはほとんど全てが、性能を求めてＣ＋＋で書かれている。

ＭｏｎｇｏＤＢは、Ｃ＋＋プログラミング言語で書かれたオープンソース、拡張可能、高性能、スキーマフリー、文書指向データベースである。このデータベースは、ＪＳＯＮのような文書の集まりを管理するので文書指向である。従って、データを複雑な階層にネストすることができ照会可能及び索引可能であるので、多くのアプリケーションがより自然な方法でデータをモデル化することができる。ＭｏｎｇｏＤＢの開発は１０ｇｅｎによって２００７年１０月に始まった。最初の公開は、２００９年２月であった。

ＴｏｋｙｏＣａｂｉｎｅｔは、データベースを管理するためのルーチンのライブラリである。データベースは、各々がキーと値のペアである記録を包含する単純なデータファイルである。すべてのキー及び値は、可変長のシリアルバイトである。バイナリデータと文字列の両方を、キー及び値として使用することができる。データテーブルの概念もデータ型も存在しない。記録は、ハッシュテーブル、Ｂ＋ツリー、又は固定長アレイに組織化される。ＴｏｋｙｏＣａｂｉｎｅｔは、ＧＤＢＭ及びＱＤＢＭの後継者として開発されてきた。

Ｖｏｌｄｅｍｏｒｔは、関係データベースではなく、ＡＣＩＤプロパティを満足させながら属性関係を満足させようと試みることはせず、オブジェクトリファレンスグラフをトランスペアレントにマップしようとするオブジェクトデータベースでもなく、文書指向のような新しいアブストラクションを導入することもない。これは、基本的には大きな分散型の永久耐障害性ハッシュテーブルである。アクティブ記録又はハイバーネイトのようなＯ／Ｒマッパーを使用することができるアプリケーションでは、Ｖｏｌｄｅｍｏｒｔが、水平拡張可能性及びより高い可用性を提供するが、利便性を大いに犠牲にする。インターネットタイプの拡張可能性の圧力下の大きなアプリケーションでは、システムは、幾つかの機能的に区分されたサービス又はアプリケーションプログラミングインタフェースから構成される可能性が高く、これは、水平に区分することができる記憶システムを使用して複数のデータセンタ間で記憶資源を管理することができる。このスペースにおけるアプリケーションでは、データの全てが何らかの単一データベースでは利用できないので、任意のインデータベース結合は既に不可能である。典型的なパターンは、ハッシュテーブル意味論を何らかの方法で要求するキャッシング層を導入することである。

Ｄｒｉｚｚｌｅは、キー／値ストアが解決しようとする問題に対する対抗策と考えることができる。Ｄｒｉｚｚｌｅは、ＭｙＳＱＬ（６．０）関係データベースの派生として始まった。最後の数カ月に渡って、この開発者は、非コア特徴のホスト（ビュー、トリガ、準備された命令文、格納された手順、問合せキャッシュ、ＡＣＬ、及び幾つかのデータ型を含む）を、スリムで単純な高速データベースシステムを作成する目的で取り除いてきた。Ｄｒｉｚｚｌｅは、関係データを格納することができ、目的は、１６コア又はそれ以上を備えたシステムで実行されるウェブ及びクラウドベースのアプリケーションに合った準関係データベースプラットフォームを構築することである。

複雑なオブジェクトグラフを有するアプリケーションに関する前述のような分散型キー／値データベースの最大の欠点は、応答時間における待ち時間及び何らかのオフザシェルフ汎用関係データベースにおいて当然のことと考える機能の欠如である。現在のソーシャルネットワーキングアプリケーションの全てではないが大部分は、極めて複雑なオブジェクトグラフを必要とする。

ＢｉｇＴａｂｌｅは、Ｇｏｏｇｌｅファイルシステム、ＣｈｕｂｂｙＬｏｃｋＳｅｒｖｉｃｅ、ＳＳＴａｂｌｅ、及び幾つかの他のＧｏｏｇｌｅプログラムに構築された、圧縮されて高性能かつ専用のデータベースシステムであり、これは現在ではＧｏｏｇｌｅの外部では分散又は使用されていないが、Ｇｏｏｇｌｅは、Ｇｏｏｇｌｅアプリケーションエンジンの一部としてそれへのアクセスを勧めている。

ＨＢａｓｅは、ＧｏｏｇｌｅのＢｉｇＴａｂｌｅの後でモデル化されたオープンソースの非関係分散データベースであり、Ｊａｖａ（登録商標）で書かれている。これは、Ａｐａｃｈｅソフトウェア財団のＨａｄｏｏｐプロジェクトの一部として開発され、Ｈａｄｏｏｐ分散ファイルシステムのトップで実行され、ＨａｄｏｏｐのためのＢｉｇＴａｂｌｅのような機能を提供する。これは、大量のスパースデータを記憶する耐障害性の方法を提供する。

データベースメモリキャッシュ
動的ウェブの出現により、データアクセス時間の待ち時間がウェブページの性能に影響を与えるようになってきた。読み取り及び書込みの両方に対するデータアクセス時間における待ち時間は、永続的データを保持するハードドライブのアクセス時間に直線的に関係している。情報を得るためにディスクにアクセスする障害を取り除くために、コンピュータ開発者は、同じデータの頻繁な読み取りのためにサーバにメモリの一部分（ＲＡＭ）を確保する方法として、共有メモリ／キャッシュの概念を考え出した。読み取りのためのデータをキャッシュしておくことで、頻繁なディスクアクセスの必要性を無くし、従ってデータ待ち時間が短縮される。時間が進むにつれて、キャッシュはよりエキゾチックに成長する。様々な利用可能な選択肢には、Ｇｏｏｇｌｅ Ｃａｃｈｅ；ＣＳＱＬキャッシュ‐ＭｙＳＱＬ、Ｐｏｓｔｇｒｅｓ及びＯｒａｃｌｅからのキャッシュテーブル；Ｍｅｍｃａｃｈｅｄ‐問合せのキャッシュ結果セット；ＴｉｍｅｓＴｅｎ−キャッシュＯＲＡＣＬＥテーブル；及びＳａｆｅＰｅａｋ−フルデータの正確性のための自動化キャッシュエビクションによるＳＱＬサーバからの問合せ及び手順の結果セットの自動化キャッシングを含む。Ｍｅｍｃａｃｈｅｄは、フリー及びオープンソース、高性能、分散メモリオブジェクトキャッシングシステムであり、性質上汎用的であるが、データベース負荷を軽減することによって動的ウェブアプリケーションをスピードアップする場合に使用することが意図されている。Ｍｅｍｃｈａｃｈｅｄは、データベース呼出し、アプリケーションプログラミングインタフェース呼出し、又はページレンダリングの結果からの任意データ（ストリング、オブジェクト）の小さなチャンクに対するメモリ内キー−値ストアである。

構造化データとアプリケーション（キャッシュと共に）の間のインタラクションに対する全ての３つのメインストリームアプローチは賛否両論である。本発明は、クラウドにおいて完全に機能的に関係的であり完全に分散可能なデータストアを単一のパッケージで提示することによって、新しいクラウドベースのパラダイムに対するソリューションを提供する。

本発明は、クラウドコンピューティングのためのデータベース階層における強化された拡張可能性及び低減された待ち時間のためのシステム及び方法を提供する。これらは、関係、又は非関係（構造化、又は非構造化）データベースフォーマットのいずれかにおいてデータを格納することができるキャッシュアダプタを含むシステムを備え、キャッシュアダプタは、データの永続性のためのデータキャッシュのバックエンドにおける分散ファイルシステム及び分散ファイルシステムからのデータ同期のためのクライアントデータベース（キャッシュ）のフロントエンド上のクライアントキャッシュと通信する。

本発明の更なる理解を可能にするために用いられ本明細書の一部に組み入れられてこれを構成する添付の図面は、本発明の原理を説明するための記述と共に本発明の例示的な実施形態を示す。

本発明の実施形態におけるキャッシュアダプタとクライアントとの間のデータの流れを示す図である。 本発明の実施形態におけるキャッシュアダプタを利用する分散ファイルシステムとクライアントとの間のデータの流れ及び同期化を示す図である。 本発明の実施形態におけるキャッシュアダプタを利用する分散ファイルシステムとクライアントとの間のデータの流れ及び同期化を示す図である。 本発明の実施形態を使用して行われるクライアント要求に続くデータの流れを示す流れ図である。 本発明の実施形態を使用してユーザペルソナを設定するためのクライアントログインに続くデータの流れを示す流れ図である。 本発明の実施形態におけるデータセルを示す図である。 本発明の実施形態における１つ又はそれ以上のバーチカルアプリケーションへのユーザ加入を示す図である。 クライアントがデータベースの単一のインスタンスと通信する本発明の特定の実施形態のアーキテクチャを示す図である。 本発明の実施形態によるクライアントマシンデータベースとのデータセルにおけるユーザデータとのバックエンド同期を示す図である。 データベースの複数のインスタンスが並行してクライアントと通信する本発明の特定の実施形態のアーキテクチャを示す図である。 データベースの複数のインスタンスが並行してクライアントと通信し各クライアントがその固有のデータベースインスタンスを有する本発明の特定の実施形態のアーキテクチャを示す図である。 キャッシュアダプタがデータ永続性目的のためにデータベースと対話することができ、次にデータベースが分散ファイルシステムにデータを格納することになる、本発明の特定の実施形態のアーキテクチャを示す図である。

本発明は、本明細書で説明される多様な特定の方法、複合物、材料、製造技術、使用、及び応用に限定されない。本明細書で使用される用語は、特定の実施形態を説明する目的のためだけであり、本発明の範囲を限定するものではない。単数形「ａ」、「ａｎ」及び「ｔｈｅ」は、本文脈が他に明確に指示しない限り複数形の参照を含む。従って、「ある要素」への参照は、１つ又はそれ以上の要素への参照であり、当業者に公知のその等価物を含む。同様に、別の実施例では、「あるステップ」又は「ある手段」への参照は、１つ又はそれ以上のステップ又は手段への参照であり、サブステップ及び従属する手段を含むことができる。使用される全ての接続詞は、可能な限り最も包含的な意味に理解すべきである。従って「又は」という語は、本文脈が他に明確に必要としない限り論理的な「排他的な又は」ではなく論理的な「又は」の定義を有するものとして理解する必要がある。説明される構造は、このような構造の機能的な等価物を示すものと理解すべきである。近似を表現すると解釈できる用語は、本文脈が他の明確に指示しない限りそのように理解すべきである。

他に定義されない限り、本明細書で使用される全ての技術的及び科学的用語は、本発明が属する当業者が一般に理解するのと同じ意味を有する。好ましい方法、技術、デバイス、及び材料が説明されるが、本明細書で説明されるものに類似又は等価の何らかの方法、技術、デバイス、又は材料は、本発明の実施又は検証に使用することができる。本明細書で説明される構造は、このような構造の機能的な等価物を示すものと理解すべきである。

特定される全ての特許及び他の公報は、例えば、本発明に関して使用することができる当該公報で説明される方法論を説明及び開示する目的で、引用により本明細書に組み入れられる。これらの公報は、本出願の出願日の前のその開示のためだけに提供される。ここで、従来の発明又は何らかの他の理由によるそのような開示に対して本発明者が先行しないものであると自認すると解釈されるべきではない。

本明細書で使用する用語「自動的」及びその変形形態は、処理又は動作が実行される場合に有形な人間の入力なしで行われる何らかの処理又は動作を示す。しかしながら、入力が処理又は動作の実行前に受け取られた場合、処理又は動作の実行が有形又は無形な人間の入力を使用したとしても、処理又は動作は自動的とすることができる。このような入力が処理又は動作が実行される方法に影響を与える場合、人間の入力は有形と見なされる。処理又は動作の実行に同意する人間の入力は「有形」と見なされない。

本明細書で使用する用語「コンピュータ可読媒体」は、実行のためにプロセッサに命令を提供することに関係する何らかの有形記憶装置を示す。このような媒体は、限定されるものではないが、不揮発性媒体、揮発性媒体、及び送信媒体を含む多くの形式を取ることができる。不揮発性媒体は、例えば、ＮＶＲＡＭ、又は磁気又は光学ディスクを含む。揮発性媒体は、主メモリのような動的メモリを含む。コンピュータ可読媒体の一般的な形式には、例えば、フロッピーディスク、フレキシブルディスク、ハードディスク、磁気テープ、又は任意の他の磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭ、任意の他の光学媒体、パンチカード、紙テープ、穴のパターンを有する任意の他の物理的媒体、ＲＡＭ、ＰＲＯＭ、及びＥＰＲＯＭ、ＦＬＡＳＨ−ＥＰＲＯＭ、メモリカードのような固体媒体、任意の他のメモリチップ又はカートリッジ、又はコンピュータが読み取ることができる任意の他の媒体が含まれる。コンピュータ可読媒体がデータベースとして構成される場合、データベースは、関係、階層、オブジェクト指向、及び／又は同様のもののような任意の種類のデータベースとすることができることを理解されたい。従って、本発明は、本発明のソフトウェア実施構成が格納される有形記憶媒体及び従来技術で認められている等価物及び後継媒体を含むと考えられる。

本明細書で使用する用語「決定する」、「計算する」、及び「コンピュータ計算する」、及びその変形形態は同義的に使用され、方法論、処理、数学演算、又は技術の任意の種類を含む。

本明細書で使用する用語「モジュール」は、何らかの公知の又は後々に開発されたハードウエア、ソフトウェア、ファームウエア、人工的知性、ファジー論理、又はその要素に関連付けられる機能を実行できるハードウエアとソフトウェアの組み合わせを示す。また、本発明は例示的な実施形態に関して説明されるが、本発明の個々の態様を別々に請求できることを理解されたい。

本明細書で使用する用語「〜と通信する」は、何らかのシステム、ハードウエア、ソフトウェア、プロトコル、又はフォーマットを使用して情報又はデータを交換するために電気信号を使用する何らかの結合、接続、又は対話を示す。

本明細書で使用する用語「仮想」又は「仮想化」は、物理的ディスクドライブのような一部の他の構成要素の論理的表現を示す。換言すると、「仮想」構成要素は、「仮想」構成要素が表わす物理的構成要素とは実際には同じではないが、コンピュータシステムの他の構成要素、ハードウエア、ソフトウェアなどにとっては同じに見える。

本明細書で使用する用語「ディスク」は、コンピュータシステムのためのデータを格納することができる記憶ディスク又は他のメモリを示す。

本明細書で使用する用語「クラウド」又は「クラウドコンピューティング」は、インターネットに基づくコンピューティングを示し、これによって共有される資源、ソフトウェア、及び情報が、公共施設のようにオンデマンドでコンピュータ及び他のデバイスに提供される。

クラウドコンピューティングは、広義では、コンピュータシステムの標準的な構成要素の仮想化である。これは、通常は単一のコンピュータ内に含まれるデータ及びソフトウェアの両方を用い、これら、並びに他の離れた構成要素に広げる。例えば、クライアント又はユーザは、情報が１つの位置に格納され、問合せが別の位置のソフトウェアによって処理され、クライアントが更に他の位置にいる場合に、プログラムを通じて情報を取得するためにサーバ又はデータベースにアクセスすることができる。実際には、ソフトウェアは、複数の本質的に異なる物理的位置にデータ記憶装置を維持しながら単一のサーバとして動作する仮想サーバを作成することができる。データにアクセスするために使用されるソフトウェア機構に関わらず、問合せ処理は、通常は、データ永続性のための分散ファイルシステムと共に関係データベースインスタンスとして動作するキャッシュを含む。キャッシュは、クライアントの要求に応じてより速く分散ファイルシステムにデータを格納し提供できるようにする方式で分散ファイルシステムからのデータを格納又は検索するデータ記憶構成要素である。キャッシュに格納されるデータは、システムのあらゆる場所に格納されたデータの複製とすること、又は前のクライアント要求又は問合せに応じて生成されたデータとすることができる。キャッシュ内のデータの全てが、最終的には分散ファイルシステム及びクライアントキャッシュに同期される。データセルの位置を保持するキャッシュされたデータ記憶装置マップディレクトリが、通常はキャッシュ内のデータセルと通信するための手段として使用される。

本発明の様々な実施形態は、データにアクセス及びこれを格納する場合の速度を向上させ、同時に強化された拡張可能性を提供するよう設計されている。１つの実施形態では、キャッシュアダプタが、関係データベーステーブルフォーマットにデータを格納することができるデータセルを含み、キャッシュアダプタは、分散ファイルシステム及びクライアントキャッシュと通信する。別の実施形態では、キャッシュアダプタが、関係データベーステーブルフォーマットにデータを格納することができる複数のデータベースインスタンスのデータセルを含み、キャッシュアダプタは、分散ファイルシステム及びクライアントキャッシュと通信する。キャッシュアダプタは、キャッシュを組み入れクライアントマシンに存在するフロントエンドクライアントデータベースと共に分散ファイルシステムへのバックエンド接続を維持することができると考えられる。代替えの実施形態では、キャッシュアダプタが、既存のキャッシュと、分散ファイルシステムへの仲介物としての関係データベース又は他の種類のデータベースとの間で通信することができる。キャッシュアダプタは、小さなデータセルから構成することができる。キャッシュアダプタは、キャッシュ内のデータセルと分散ファイルシステムとの間でデータを移動させることができる。

本発明の実施形態では、キャッシュアダプタが、クラウド分散ファイルシステムの前に存在する。このキャッシュアダプタは、ＣｌｏｕｄＣａｃｈｅを作成し、データベースにアクセスするための全ての外部クライアントのためのインタフェースを提供する。このＣｌｏｕｄＣａｃｈｅは、構成ファイル内に記述される全ての利用可能な指定システム全体に広がる連続スペースである。キャッシュアダプタは、データアクセス要求をクラウド内に格納された適当なデータセルに送る。これらのデータセルは、クラウド分散ファイルシステムに加えてクラウドに分散されたキャッシュ内にデータを永久に存続させることができる。更に、キャッシュアダプタは、必要に応じて、キャッシュを通過することなく直接クラウド分散ファイルシステムに存在するデータへのアクセスを可能にすることができる。これは、大きなバルク負荷又は大きなデータ検索を実現し、単一の要求で複数のデータセルにアクセスする必要性を軽減することができる。クライアントからのデータの要求に応じて、キャッシュアダプタは最初に、データがキャッシュ内で利用可能かどうかチェックし、キャッシュが要求されたデータを本当に有する場合、システムは、キャッシュからデータを提供する。しかし、データがキャッシュ内に存在しない場合、システムは自動的に分散ファイルシステムからデータを検索し、データをクライアントに送信する前にこれをキャッシュし、これによってデータ要求を満足させる。この処理は、図３のデータ流れ図と共に以下に示す。

特定の実施形態では、クラウド分散キャッシュが、このキャッシュアダプタにインタフェース接続するアプリケーションのためのＳＱＬインタフェースを備えた関係データベースとして機能する。例えば図１１に示すように、キャッシュは、データ永続性のためにクラウドにおける完全に分散可能なファイルシステムによってバックエンドでサポートすることができる。このセットアップを使用することで、データベースは、ハードウエアの直線的な関数として成長し、潜在的に無限のスケーリングを提供する。エクサバイトを超える領域では、最終的な閾値を存在させることができる。本発明のキャッシュアダプタは、分散ファイルシステムに統合することができる。このアダプタは、構造化関係データフォーマットでキャッシュからのデータを完全に取り入れることができ、次にリアルタイムでの動的な記憶のためにこれを分散ファイルシステム又は中間データベースに変換し、戻り経路で分散ファイルシステム又は中間データベースからのデータをキャッシュ準拠フォーマットに変換する。

アダプタフレームワーク及びデータフロー
例えば図１に示すように、全ての外部クライアントは、ウェブサーバを介してキャッシュアダプタにインタフェースするが、これによりクライアントのためのゲートウエイは、標準的なセキュアｈｔｔｐｓインタフェースを使用してデータベースと通信することが容易になる。キャッシュアダプタ１００はウェブサーバ１１０と双方向に通信し、ウェブサーバ１１０はクライアントと双方向に通信する。クライアントは、移動デバイス固有のアプリケーションクライアント１２０又はＨＴＭＬ５アプリケーションクライアント１２１とすることができる。プレゼンテーション層１３０、１３１及びクライアントデータベース１４０、１４１はクライアント１２０、１２１内に包含される。

キャッシュアダプタは、標準的なＪａｖａデータベース接続性（ＪＤＢＣ）インタフェースを使用してデータセル及びファイルシステムに内部でインタフェースすることができる。個別のデータセルの各々は、クラウド分散ファイルシステムに永続的にデータを存続させることができる。キャッシュに存在するデータは、関係データベーステーブルフォーマットに類似の構造化形式になる。しかしながら、クラウド分散ファイルシステムに存在するデータは、非構造化フォーマットである。アダプタ処理フレームワークが、機能呼出し、読み取り／書込みの要件に応じて、１つのフォーマットから他のフォーマットにデータを変換するよう要求される。

通例、キャッシュ（代替えとして、複数のマシンにわたる１つの連続ユニットとしてのキャッシュを示す際のＣｌｏｕｄＣａｃｈｅ）は、メモリの確保された部分である。図２に示すように、キャッシュアダプタ２００は、自らの使用のために、連続スペース、ＣｌｏｕｄＣａｃｈｅとしてマシンのネットワーク化クラスタ（物理的及び／又は仮想的）における１つ又はそれ以上のノード２６０、２６１、２６２の個々のＲＡＭの指定された部分を確保する。処理は、さらに２つの接続、つまりＣｌｏｕｄＣａｃｈｅから下の分散ファイルシステムへの１つの接続、及びＣｌｏｕｄＣａｃｈｅから軽量アプリケーションサーバ２５０及びウェブサーバ２１０を介したクラウドへのもう１つの接続を設定する。キャッシュアダプタは、データセルにデータを格納するためにこの指定されたメモリスペースを使用する。各データセルは、そのデータサイズの点でフレキシブルであるが、インフラストラクチャ全体の維持及び一貫した機能を容易にするために、構成ファイルで指定された上限値が存在する。外部アプリケーションは、標準的なＪＤＢＣインタフェース又は標準的なｈｔｔｐｓインタフェースの拡張であるインタフェースを使用して、キャッシュアダプタにインタフェースすることができる。外部アプリケーションは、データセルと直接通信することはできない。データセルは、処理の不可欠の部分である。

キャッシュアダプタは、関係データベーステーブルフォーマットでキャッシュ内のデータセルにデータを格納する。データがキャッシュに存在し分散ファイルシステムを含む標準的なオペレーティングシステムファイルシステムには存在しないという意味で、これは従来の関係データベース管理システム（ＲＤＢＭＳ）とは異なる。キャッシュに存在するデータは永続性であり揮発性ではなく、クラウド分散ファイルシステムは永続性のために使用される。従来のＲＤＢＭＳは、ディスクファイルシステムにデータを格納し、データベースによっては、データのある部分を短待ち時間でキャッシュすることができるが、２つの媒体のいずれも単一のエンティティとしてクラウドに完全に分散されない。シャーディング（区分化）が類似の機能を提供できるが、シームレスではなく、従って大幅なカスタマイゼーションを必要とし他の制限を有する。

データセルは、単一の又は複数のユーザのためのユーザデータを包含する。個別のデータセルの各々は、複数のデータテーブルを包含する。これらのテーブルは単一の又は複数のユーザのためのデータを包含する。キャッシュアダプタは、ユーザのデータスペース要件を自動的に割り出し、ユーザのためのデータを検索するか又はユーザによって入力された新しいデータを格納する。

キャッシュアダプタが外部分散ファイルシステムと通信し、図１及び２に示すようにクライアントキャッシュからのデータを分散ファイルシステムに、分散ファイルシステムからのデータをクライアントデータベースに変換する。

確定的な説明は実施形態のみを提供し、本発明の範囲、可用性、又は構成を制限するものではない。むしろ、確定的な説明は、実施形態を実施するための実施可能な説明を当業者に提供するであろう。様々な変更が請求項の精神及び範囲から逸脱することなく要素の機能及び構成に対して可能であることを理解されたい。例えば、本発明は、ソーシャルネットワーキング、クライアント／顧客管理及びサービス、金融及びビジネスサービス、ヘルスケア記録管理、トランザクション管理、販売、マーケティング、分析、セキュリティ警告、インテリジェンス収集、及びコラボレーションに関する応用分野を見つけるために考えられた。

実施例−クラウドベースのソーシャルネットワーキングインフラストラクチャのためのアーキテクチャシステム及び構成要素
本発明の特定の実施形態では、キャッシュアダプタは、性能及び拡張可能性の両方を向上させることによって、既存のソーシャルネットワーキングサイトアーキテクチャを改善する。Ｆａｃｅｂｏｏｋ（登録商標）、Ｔｗｉｔｔｅｒ（登録商標）、ＬｉｎｋｅｄＩｎ（登録商標）等のソーシャルネットワーキングサイトは、コンタクトリレーションシップ管理（ＣＲＭ）スペクトルのサブセットの一部の形式にすぎない。これらのネットワーキングサイトによって、その許可されたユーザ（個人／エンティティ）はパーソナルプロファイルを作成し、そのソーシャルリレーションシップを構築し、互いに対話する際にそれを拡張及び育成することができる。このＣＲＭスペクトルのサブセット内の多くのサイトは、ｎ階層化ウェブインフラストラクチャと対話するクライアントとしてインターネットブラウザを利用する。本発明は、インタラクティブ及びマッシブ拡張可能である堅牢なアーキテクチャによってサポートされる、次世代ソーシャルネットワーキングサイトを提供するために利用することができる。本発明のシステムは、バックエンドインフラストラクチャによってサポートされるクライアントから構成される。

現在の市場に存在する全ての主な提供物は、クライアントが対話するインターネットブラウザを使用する。クライアントは、このインターネットブラウザを介して新しい情報を検索又は提示する。ブラウザは要求をアプリケーションサーバに転送し、アプリケーションサーバがこれらの着信要求を処理する。処理の一部として、アプリケーション層がバックエンドでデータベースと対話する。このような多くのサイトは、バックエンドで関係データベースによってサポートされ、データの流れのボトルネックを生じる。関係データベースアプローチは、（１）アーキテクチャは連続したインターネット接続を必要とする非同期ｈｔｔｐ要求及び応答システムに基づき、インターネット接続なしでは、ブラウザは応答を停止及び中止する（２）応答時間が一般的に遅い（３）追加の特徴は、アプリケーション層及びバックエンドデータベースの両方での同時変更を必要とする場合に困難なタスクである（４）ソフトウェアップグレードリリースサイクルは困難であり時間を消費する、及び（５）インフラストラクチャの維持に費用がかかるという以下の欠点を含む。

本発明は、ワークフロー及びデータフローに関して現在の提供物とは大幅に異なる特徴を提供するバックエンドと共に、現在存在する標準的なブラウザベースのクライアントから構成されるインフラストラクチャを提供することができる。本発明のクライアントは、ＨＴＭＬ５クライアント又は元のオペレーティングシステム、特にＡｐｐｌｅ社のｉＯＳ（登録商標）及びＧｏｏｇｌｅ社のＡｎｄｒｏｉｄ（登録商標）に固有の専用アプリケーションのいずれかとして、プレゼンテーション層のためのアプリケーションコードから構成することができる。クライアントがＰＣ用のＨＴＭＬ５クライアント又はプロプラエタリ移動デバイスＯＳ用の専用アプリケーションか否かに関わらず、クライアントは、常にバックエンドデータベースに直接アクセスすることはない。クライアントは、クライアントマシンに存在するローカルデータベース上のユーザデータの小さなフットプリントにほとんどの時間アクセスする。もし要求された時は、クライアントは、関係データベースとは対照的にクラウドに全てが存在するバックエンドからの付加的なデータをシームレスに検索する。更に、バックエンドは、データをクライアントに送信することに加えて、何らかのクライアントの介入なしにクライアントデータベースをバックエンドからの最新のアップデートデータに同期させ、付加的な又は更なるクライアント対話なしにデータの同期を続ける。

別の差別化は、現在の提供物が、ＭＶＣ（モデルビューコントローラ）オブジェクト設計パターンでサーバ側にコンパイルされたＨＴＭＬページを配信する場合に存在する。ＭＶＣパターンモデルでは、コントローラは、クライアントからの要求の全てを受信して処理するモジュールである。次に、ビューであるプレゼンテーション層はコンパイルされ、次にブラウザにＨＴＭＬストリームを配信し、ＨＴＭＬストリームがクライアントブラウザウェブサーバによって表示される。

バックエンドでは、本発明のシステムは、Ａｐａｃｈｅのようなインターネット／クラウドフェイシング工業規格ウェブサーバを開始する。

アプリケーションサーバ
古いモデルのｎ階層ウェブアーキテクチャでは、中間層は、ＷｅｂＳｐｈｅｒｅ、Ｏｒａｃｌｅ等の専用アプリケーションサーバから構成される。ここで、本発明のアーキテクチャにおける本格的なＪ２ＥＥアプリケーションサーバ構成要素に対する必要性は存在しない。軽量アプリケーションサーバは、コントローラ／ディスパッチャとして作動し、キャッシュアダプタ内に組み込まれる。この主な理由は、本処理の実施形態において、アプリケーションコードが存在する場所にデータを転送するのとは対照的に、データが存在する場所にアプリケーションコードが送られるためである。クライアントは小さなフットプリントデータベースを有し、このデータベースは、バックエンドデータベースに常にそれ自体を同期させる。クライアントは、ユーザにデータを提示するためにローカルデータベースにアクセスする。プレゼンテーション層コードは移動デバイスクライアントのクライアントに存在するが、ＨＴＭＬ５クライアントでは、プレゼンテーション層コードはＨＴＭＬ５にある。

データベースサーバ
図２に示すように、データベース層は、分散ファイルシステム２７０の上部に位置するキャッシュアダプタ２００から構成される。上述したように、別々のアプリケーション及びデータ層を備えた真のｎ階層アーキテクチャとは対照的に、軽量アプリケーションサーバ２５０がキャッシュアダプタ２００の一部として組み入れられるという意味で現在設計されているいずれとも非常に異なる。本発明のシステムには２つのデータキャッシュ構成要素が存在する。すなわち、１つはクライアントマシンに固有のクライアントデータベース（キャッシュ）２４０、２４１としてクライアントに存在し、他のデータキャッシュは、例えば、クラウドに存在するクラスタ化ノードに存在するノード２６０、２６１、２６２から成るＣｌｏｕｄＣａｃｈｅである。ＣｌｏｕｄＣａｃｈｅは、分散ファイルシステム２７０の上部のノード、つまり図２に示すようにクラウドに存在するクラスタ化ノードに位置する。

本発明のシステムは、２つの主な構成要素、すなわち軽量ウェブサーバクラスタ２１０と、本発明によるデータベースサーバとして作動するキャッシュアダプタ２００（軽量アプリケーションサーバ２５０を組み込んだ）とを有することができる。図３はシステムのデータフローを示す。クライアントは、２つの種類の要求をバックエンドに提示することができる。要求は、格納されたデータの検索又は新しいデータの提示（記憶）のいずれかとすることができる。

本発明によるデータ検索要求は簡単である。クライアント３００は、クライアントマシンのローカルデータベースで利用可能である可能性のあるデータ３１０を要求し、利用可能である場合、要求はクライアントマシンを離れず、クライアントマシンの境界内で満たされる。データがクライアントマシンキャッシュに存在しないインスタンスでは、要求がバックエンドに提示される。要求されたデータがクライアントデータベースに存在しない場合、着信要求は、キャッシュアダプタの記憶マップ３２５によってインターセプトされ、要求されたデータの位置を要求に提供する。データ位置は、データがキャッシュにない場合はキャッシュされたデータのポインタであり、次にデータ（アーカイブデータ）が生の非構造化フォーマット３６０で分散ファイルシステムから検索される。分散ファイルシステムからのデータが最初に検索され、次にキャッシュ互換性フォーマット３５５に変換され最後にクライアントキャッシュに送信される。要求されたデータの受信に応じて、クライアントはクライアントのためのデータを表示する。

データ提出要求は、単純なクライアントデータ要求に比べて幾つかの付加的なステップを有する。まず、データは最初にＣａｃｈｅ Ａｄａｐｔｅｒ（固有のＣｌｏｕｄＣａｃｈｅ）に送信され、次にＷｒｉｔｅＣａｃｈｅＡｄａｐｔｅｒ３３０によってバックエンドデータキャッシュフォーマットに変換される。バックエンドデータキャッシュ３４０は常にクライアントアクセスのために最新のデータを格納するが、この段階では、データは一時的でありクライアントは見ることができない。データは更に、分散ファイルフォーマット３５０に変換されセーブされる。ファイルシステム３６０におけるデータの記憶が成功すると、キャッシュ同期アダプタ３７０は格納されたデータを検索してこれをバックエンドキャッシュ３８０に送信する。ビットチェックを行ってデータがキャッシュにセーブされた一時データと一致することを確認し、チェックが成功すると、データロックが解放され、データがクライアントに利用可能になる。

上記に加えて、バックエンドシステムは、定期的に最新のバックエンドデータキャッシュによってクライアントデータキャッシュを常にアップデートする。この持続する双方向同期は、図２の太い点線で示されている。

関係データベースでは、複数のユーザのためのデータが、データベースの所与のインスタンスの単一の又は区分化された複数のテーブルに並べられる。現在のｎ階層アーキテクチャでは、クライアント要求がウェブサーバに、次にアプリケーションサーバに送信される。アプリケーションサーバは要求を分析し、データベースから特定のデータを要求し、要求を処理し、次に応答をクライアントに送信する。本発明の特定の実施形態のアーキテクチャでは、クライアント要求は、ウェブサーバに、次に軽量アプリケーションサーバ（ＬＡＳ）に送信される。ＬＡＳは要求を分析するが、データベースからデータを要求する代わりに、要求を、データが何らかのアプリケーションコードと一緒に存在するクラスタノードに送信する。

分散ファイルシステムは、永続的データのための主媒体である。全てのバルクデータに関する問合せが具体的に分散ファイルシステムに送られ、キャッシュに触れることはない。本来、キャッシュへの全てのデータに関するユーザ問合せは、クライアントインタフェースからの単一のユーザのためのデータに対してである。データセルのデータは、分散ファイルシステムクラスタ内で発生する全てのデータ処理の最終生成物であり、キャッシュからのデータは、クライアント表示及び対話目的のためにほとんどが使用される。

本発明の特定の実施形態のアーキテクチャの利点は、データを検索しアプリケーションサーバに戻す代わりに、要求がキャッシュアダプタに送られて、適当なデータが存在するクラスタの適切なノードにキャッシュアダプタが要求を送信する。

図７に示すように、単一のデータベースインスタンスにデータを格納しそこから検索することができる。複数のマシンにデータベースを区分することができるが、インスタンスは常に単数であり、要求のフローは、単一の関係データベース管理システムインスタンスを通過しなくてはならない。これは、潜在的な単一障害点である。図９に示すように、本発明の特定の実施形態では、並行してクライアントと通信することができるデータベースの複数のインスタンスを備えたバックエンドインフラストラクチャを存在させることがでる。各クライアントは、スループット及び直線拡張可能性を強化できる固有のデータベースインスタンスを持つことができるように、この設計を拡張することができる。

クライアントの数が増えてデータのサイズが指数的に大きくなり始めると、モデルは、データフロー及びロッキングを管理する単一のマシンの入力／出力制限のために、一部のポイントで維持できなくなる。インスタンスが単一のマシンに存在するので、データベースを収容するマシンのパワーに関わらず、モデルは、非常に大きなデータセットを必要として結果的に著しいコンピュータ処理ユニットチャーンニングパワーを必要とするアプリケーションからの極めて大きなデータ負荷に耐えることができない。シャーディング及びデータアーカイブのような幾つかの革新的なソリューションが存在しているが、そのほとんどすべてが、手動の介入を必要とし依然として単一障害点になる傾向がある。

システム障害の場合、障害回復に利用可能な幾つかの洗練されたソリューションが存在するが、この処理は実施するのに多くの時間がかかり、長期の機能停止に起因して大規模な影響が生じることがある。障害回復時間を短縮するためにデータ複製を使用できるが、これは付加的なコストを伴い、アーカイブテーブルに対してアクティブテーブルに存在するデータを危険にさらす。

図４に示すように、ログインした全てのユーザは、ログイン要求をシステムバックエンドに送信する。システムは、クラスタの最小ビジーノードのＣｌｏｕｄＣａｃｈｅにユーザのための固有ペルソナオブジェクトを作成する。次に、システムは、ユーザが加入している各バーチカルに対するバーティカルオブジェクトグラフの空シェルを更に作成する。ユーザログイン要求の２つの種類、すなわち１つは最初のログイン及びもう１つは次のログインが存在する。

最初のログインは、ユーザプロファイルオブジェクトをインスタンス化する段階及び次に同じものを読み込む段階を必要とする。最初のログイン又は初期ユーザ登録では、ユーザペルソナオブジェクト作成の次に、ユーザが登録の時間に加入することができる各バーチカルに対するデータスキームの空シェルが作成される。次のログインで、ユーザは、付加的なバーチカルに登録する、又は必要であればこれらを切り離すことができる。バーチカルを所与のプロファイルに添付する段階を実現することができる。データセルのデータの全ては、永久記憶のために分散ファイルシステムに存続する。

次のログインに各々では、ログイン要求の受信に応じて、バックエンドは、ユーザペルソナオブジェクトを作成し、ユーザ固有のデータを検索し、ユーザペルソナオブジェクトにユーザオブジェクトに関連付けられる固有のデータを読み込む。更に、バックエンドは、ユーザが加入している全てのバーチカルの空シェルを作成し、次にバーティカルシェルに分散ファイルシステムからのデータを読み込む。

バックエンドは、分散ファイルシステムからＣｌｏｕｄＣａｃｈｅにデータを検索することができる。更に、バックエンドは、データセルからのキャッシュされたデータをクライアントマシンに存在するクライアントデータベースに同期させることができる。

提案されるシステムにおける全てのユーザは、ユーザログインＩＤとの１対１関係を作成する固有のキーによって識別される。固有のキーは、最初にドメイン名を逆にすること（ＧｏｏｇｌｅによるＢｉｇＴａｂｌｅでのキー識別子作成に類似）、及び登録時及び最初のログイン時にユーザが作成した固有のユーザＩＤで終わることによって生成される。

ユーザＩＤを有するユーザ、ＵｓｅｒＩＤ０に関して、キーは、次の、ｃｏｍ：ｃｌｏｕｄｃｏｍｐｏｎｅｎｔｓ：ｄｂｉｎｓｔａｎｃｅ：ｕｓｅｒｉｄ０のように見える。

バックエンドでは、本システムは、全てのユーザのための固有のデータセルを作成する。データセルは、キャッシュアダプタが全てのユーザのために確保するキャッシュの一部分である。各データセルは、ユーザに関連付けられる固有のユーザＩＤによって識別される。

図５は、ユーザのデータセルのグラフ図である。データセル内には、各々が対応するバーチカルに対するユーザデータを保持する埋め込みデータセルのグループがある。これらの埋め込みセルの各セルは、特定の産業バーチカル（industry vertical）に関する特定の固有の構造を有する。

従来の関係データベースでは、データは、データベースの単一のインスタンスのテーブルに並べられる。所与のテーブルは、複数のエンティティに対するデータを包含する。この場合のエンティティの単純な例は、ユーザになる。各ユーザは、固有のユーザＩＤによって識別される。所与のエンティティでは、そのエンティティに関係付けられるデータを、データベースインスタンス全体にわたって複数のテーブルで拡散させることができる。数百のテーブルが存在することがあるが、これは、常にオリジナルエンティティＩＤからキーオフ（ｋｅｙ ｏｆｆ）する。これによって、関係データベースの単一のテーブルは、複数のユーザのためのデータを格納することができる。従来の関係データベースを使用してデータを管理するために、インスタンスが存在し、人間が複数のマシンにおけるデータの単純な区分化及び／又は複数のマシンにおけるデータのシャーディングを使用している。これは手動の介入を必要とし、モデルは、マシンの入力／出力制限、及び地理的に多様なユーザに関する１つの中心位置のデータ位置に起因して、クラウドベース環境において維持することができない。

キャッシュアダプタは、インスタンスを自動的に作成するための能力を有する。キャッシュアダプタは、単一の連続キャッシュ（複数のマシンの確保された部分）としてＣｌｏｕｄＣａｃｈｅを作成することによって始動する。キャッシュアダプタは、構成ファイル内の「最大サイズ」パラメータに基づくそのサイズに関する上限値を有するインスタンスを作成する。インスタンスの作成後、キャッシュアダプタは、アクティブ（ログインした）ユーザデータをインスタンスに読み込む段階を開始する。インスタンスがその最大サイズに達してそれ以上データを格納できない場合、キャッシュアダプタは新しいインスタンスを作成する。キャッシュアダプタが作成できるインスタンスの数に制限値はない。記憶マップは、これらのインスタンスに格納された全てのインスタンス及びユーザＩＤのディレクトリリストを維持する。キャッシュに格納されたデータは、クライアントの消費（クライアントのレポート）に対して準備ができている処理データである。

従来の単一のインスタンスとは対照的に、データベースの複数のインスタンスを作成することによって、本システムは、複数のインスタンス（ノード／マシン）全体に作業負荷を拡散することができる。クライアント要求が適切なデータベースインスタンスに送られると、通信は、クライアント及びインスタンスに限定される。これは、ドメイン：データベースインスタンス：インスタンス内の単純な固有のユーザＩＤとは異なるユーザＩＤから成るユーザＩＤを構築することによって実現される。更に、全てのユーザに対する全てのインスタンス内に、ユーザが登録された全てのバーチカルに関するデータを保持するためのオブジェクトグラフが存在する。

関係データベースでは、同じインスタンス内に全てのテーブルの作成を試みることができるが、テーブルの数及びデータのサイズが大きくなるにつれて、モデルは性能劣化に起因して維持できなくなる。障害の主な理由は、物理的システムの入力／出力制限又はデータベースが区分化される場合の複数のシステムの構成及びコラボレーションの制限である。

本発明の特定の実施形態のアーキテクチャは、データベースの複数のインスタンスを作成することによって入力／出力ボトルネックを取り除く。複数のインスタンスを作成することで、データの一貫性の点で全体としてシステムの複雑さが増すが、これは、ＳｔｏｒａｇｅＭａｐと呼ばれるスマートディレクトリ構造を実施することによって解決される。ＳｔｏｒａｇｅＭａｐは、起動又は停止される全てのインスタンスを追跡する。全てのインスタンスのリストに加えて、ＳｔｏｒａｇｅＭａｐは、各インスタンス内の各ユーザＩＤに基づくデータ分散を追跡する。図７はＳｔｏｒａｇｅＭａｐ及びデータセルコンテンツを示している。

更に、所与のユーザＩＤのためのデータセルは、全てのデータベースインスタンスにわたってそのユーザプロファイルの唯一のインスタンスだけを有する。そのユーザプロファイルに関係付けられる全てのトランザクションが列に並べられ、その単一のインスタンス内で連続して処理される。

登録又は登録後処理の一部として、ユーザは、システムに１つ又はそれ以上の産業バーチカルアプリケーションに加入することができる。各バーチカルは、産業バーチカルセグメントに関係付けられる属性を固有に取り込むデータレイアウトを有する。ユーザによる加入時のこのレイアウトは、固有のユーザプロファイルに添付される。ユーザがそのペルソナに添付できるバーチカルの数に制限はない。

図６は、異なる観点からのインスタンスの断面図を示している。ユーザペルソナは、ユーザのアイデンティティを反映する中心オブジェクトである。様々な産業バーチカル区分を、所与のユーザペルソナに添付することができる。バーチカルは、ソーシャルネットワーキング、医療記録、コンタクト関係管理、個人及び企業媒体記憶装置、個人及び企業文書アーカイブ、金融サービス、電子ゲーム、及びコラボレーションなどの文脈に関するデータを包含することができる。

図８に示すように、バックエンドは、データセルのユーザデータをクライアントマシンデータベースに同期させる。各ログイン時に、ユーザはバックエンドへのクレデンシャルとしてパスワードと共にユーザＩＤを提示する。ユーザＩＤを使用して、バックエンドはファイルシステムからデータを検索して、データセルの形式でそのユーザに対するユーザペルソナオブジェクトに対するキャッシュエントリを作成し、クライアントマシンとのデータ同期リンクを設定する。全てのクライアントマシンが以前にシステムに登録されている限り、ユーザは複数のマシンから同じユーザＩＤでログインすることができる。複数のマシンは、同じユーザＩＤでシステムにアクセスすることができ、これらのマシンがリンクされると、そのデータベースは、データセルからの最新ユーザデータと同期される。

データセルのデータは、バックエンド分散ファイルシステムに永久に存続する。クライアントからの要求を受信すると、バックエンドＳｔｏｒａｇｅＭａｐは、データ要求をそのクライアントのデータを含む適切なデータベースインスタンスに送る。データセルがユーザＩＤに基づいて位置付けられると、接続（通信チャネル）が、その特定のユーザＩＤに対応するデータセルインスタンスに設定される。また、バックエンドは、応答と共にセキュリティトークンを設定して送信する。次の全ての要求には、このセキュリティトークンが添付される。セキュリティトークンが無効であるか（タイムアウト又は他の理由で）又は紛失している場合、次にバックエンドは、システムに再ログインするようクライアントに要求する。

本発明の特定の実施形態のアーキテクチャは、ソーシャルネットワーキングアプリケーション、例えばＦａｃｅｂｏｏｋに適用することができる。２００８年には、サイトがＭｙＳＱＬ専用の１，８００サーバ及びメムキャッシュ専用に８０５サーバを有したと推測される。しかしながら、複数のＭｙＳＱＬがシャードして、メムキャッシュインスタンスは単一のサーバで仮想的に実行することができるので、インフラストラクチャを実行する物理サーバの数が少なくなる。しかし最近では、４０００を超えるＭｙＳＱＬサーバがありメムキャッシュデータ専用の類似の相応の数があるといううわさがある。そのマシンの数は、２００８年からの実質的な増加を表わしており、成長予測が予定通りに進んだ場合、将来的には維持できない数が推定される。

ＭｙＳＱＬ、さらに言えば、あらゆる関係データベースは、クラウドに必要なデータサイズ及びスループットによって設計されていない。あらゆるＲＤＢＭＳの主な欠点も、ＡＣＩＤトランザクションコンプライアンス、バッファプール、又はメモリスワップスペースのロックに関係する過負荷と共に、シングルインスタンスであるということである。複数のインスタンスの作成を試みることができるが、アプリケーションは、インスタンス全体にわたるデータ分配及び複数のインスタンスの間の多相コミットによって設計する必要がある。これは、コミット障害、障害回復などの場合にロールバックのような多数のハードルを生じる。本発明の実施形態は、単一のＲＤＢＭＳコーディネータを介するのではなくクライアントと直接通信することができる複数のインスタンスを含む。

本発明の特定の実施形態のアーキテクチャでは、互いに独立して作用するデータベースの複数のインスタンスが存在する。これは、主データベースの外側でデータ分散及び位置ディレクトリ（ＳｔｏｒａｇｅＭａｐに維持される）を最初に取り、単一のデータセル内に単一のユーザのためのデータを閉じ込めるデータセルを作成することによって実現される。発明者らのソリューションによって、並行して実行される複数のインスタンス全体にわたって作業負荷を分散することができる。前記の実行モードに対する要件は、データが全てのデータ書込みのための専用データセルに送られるよう各単一のユーザに要求することだけである。

ユーザデータを包含する従来の関係データベースの一般テーブルを以下に表す。これは、所与のポイントでのユーザテーブルのスナップショットである。例えば、このテーブルは、テーブルの同じ数の行によって表される５００万を超えるユーザＩＤを包含することができる。
ユーザＩＤ ファーストネーム ラストネーム ジップコード
１ ジョン スミス １０１７０
２ フランク クラーク １００１７
｜
｜
｜
６００００００００ マーク ベイカー ２２１５０

あらゆるユーザが少なくとも５人の友達を有する場合、ユーザ間のこの関係を明示するテーブル、「友情テーブル」が、実施例によって作成される。
ユーザＩＤ 友達＿ユーザ＿ＩＤ
１ ６
１ ５
１ ４
１ ３
１ ２
２ １
２ ９
２ ８
２ ７
２ ６

５００２３２６５７ １

従って、このテーブルは、全てのユーザに対する５人の友達に対応するために５００，０００，０００×５行の最小値を必要とする。

ユーザＩＤが特定のジップコードに移動することを計画しており、訪問中にジップコードのユーザの友達の誰かのカレンダー上で自由時間を有するかどうか見つけたい場合、その種類の問合せは、３つのテーブル間の統合をもたらす必要がある。索引を使用することによって問合せを最適化できるが、これはほんの開始点であり、オブジェクトグラフがより複雑になるにつれて、システムはプログラムするのが難しくなる。

本発明の特定の実施形態のアーキテクチャでは、友情テーブルの実施例より１００倍大きなサイズ又はこれを超える匹敵するテーブルが存在できるが、これらのテーブルは、分散ファイルシステムに存在し、データ処理のためだけに使用される。単一のユーザのための全てのユーザに関係付けられるデータが常に単一のデータセルに存在するので、ユーザ問合せは、これらのテーブルに決して問合せない。ユーザジップコード問合せの実施例では、本発明の特定の実施形態のアーキテクチャにおいて、本出願は、そのユーザのためのデータセルに要求を送信し、ＳｔｏｒａｇｅＭａｐを使用してそのユーザのためのデータセルを位置付ける。データセルにおいて一度、本出願は、友達の数に等しい行の数を有する友情テーブルをスキャンする（５００，０００，０００×５行を備えたテーブルに問い合わせるより処理しやすいスキャン）。データの区分化と組み合わせたインデクシング、ロッキングは、相対的に負荷を軽減できるが、所与のマシンの物理的制限がボトルネックを生じる。このようなモデルは、多くの資源の割り当て（複数のノード／マシン）があっても経済的に耐えられない。要求されるジップコードにおけるユーザに対する友達の行をフィルタ処理すると、本出願は次に、友達（フィルタ処理されたユーザ）のカレンダーオブジェクトと対話することができる。このシナリオは、従来の関係データベースセットアップにおける数十億の行をスキャンするより効率的であり高速である。本発明の特定の実施形態のアーキテクチャは、クライアント要求のために設定される作業データのサイズを低減する。これは、区分にまたがる大きなテーブルの結合を実行する極めて大きな数の行又は問合せを備えたテーブルとは対照的に、単一のデータセルとの着信要求作業を有することによって実現される。

複数のインスタンスが、作業負荷の分散を提供する。データセルが、作業負荷の分岐を更に提供する。適切に設計されたマルチスレッディッドアプリケーションはこの特徴を活用しマルチフォールドスループットを提供することができる。データセルは、データベースコントローラからのいずれの助けもなしにクライアントに同期し、これによってバックエンドと複数のクライアント間のマルチチャネルセキュア通信を同時に可能にする。分散ファイルシステムは、障害回復のための堅牢なバックエンドを提供する。メモリのデータセルを作成及び破壊するためのキャッシュアダプタの能力によって、本システムは短待ち時間で非常に応答性が良いものとなる。

本明細書で説明した本発明の実施形態は、単に例示的なものである。当業者であれば、本開示の範囲内であることが意図される、本明細書に具体的に説明した実施形態の変形例を理解することができる。同様に、本発明は、請求項によってのみ制限される。本発明は、請求項及びその均等物の範囲内に入る場合にこれらの変形例を網羅する。

１００ キャッシュアダプタ
１１０ ウェブサーバ
１２０ 移動デバイス固有のアプリケーションクライアント
１２１ ＨＴＭＬ５アプリケーションクライアント
１３０ プレゼンテーション層
１３１ プレゼンテーション層
１４０ クライアントデータベース
１４１ クライアントデータベース

Claims (20)

1. 分散ファイルシステムを形成するマシンのネットワーク化クラスタの少なくとも１つのノードにメモリの指定された部分を連続スペースとして確保するよう構成されたキャッシュアダプタを備える、分散キャッシュデータシステムであって、
   前記メモリの指定された部分は、キャッシュを形成し、
   前記メモリの指定された部分は、データを格納するよう構成されたデータセルを含み、 前記キャッシュアダプタは、前記データ及び分散ファイルシステムにインタフェースするよう構成され、
   前記キャッシュアダプタは、前記データにアクセスするために外部クライアントのためのインタフェースを提供するよう構成され、
   前記キャッシュアダプタは、ウェブサーバを介してクライアントに通信するよう構成され、
   前記キャッシュアダプタは、データアクセス要求を前記データセルのうちの適当なデータセルに送るよう構成され、
   前記キャッシュアダプタは、前記キャッシュアダプタ内に組み込まれた軽量アプリケーションサーバを介してデータアクセス要求を処理するように構成される、
   分散キャッシュデータシステム。
2. 前記キャッシュアダプタは、前記データを関係データベーステーブルフォーマットで格納するよう構成されている、請求項１に記載のシステム。
3. 前記キャッシュアダプタは、ジャバデータベース接続性インタフェースを使用して前記データ及び前記分散ファイルシステムにインタフェースするよう構成されている、請求項１に記載のシステム。
4. 前記キャッシュアダプタは、必要に応じて、前記キャッシュを通過することなく前記分散ファイルシステムに存在する前記データに直接アクセスするよう構成されている、請求項１に記載のシステム。
5. 前記キャッシュアダプタは、前記クライアントからのデータ要求に応じて、前記データが前記キャッシュ内で利用可能かどうか最初にチェックするよう構成されており、前記キャッシュが前記要求されたデータを有する場合、前記分散キャッシュデータシステムは前記キャッシュから前記データを送出し、
   前記データが前記キャッシュ内に存在しない場合、前記分散キャッシュデータシステムは、前記分散ファイルシステムから前記データを検索し、次に前記要求されたデータを前記クライアントに直接送出するか又は前記データを前記クライアントに送信する前に前記データをキャッシュする、請求項１に記載のシステム。
6. 前記キャッシュアダプタは、構造化関係データフォーマットで前記キャッシュから前記データを取り出し、次に前記データを分散ファイルシステム及び中間データベースの１つに変換するよう構成されており、
   前記アダプタは、分散ファイルシステム、又は前記中間データベースからの前記データをキャッシュ準拠フォーマットに変換するよう更に構成されている、請求項１に記載のシステム。
7. 前記クライアントは、移動マシン固有のアプリケーション及びＨＴＭＬアプリケーションクライアントの１つを含む、請求項１に記載のシステム。
8. 前記クライアントは、プレゼンテーション層、クライアントデータベース、及び前記キャッシュアダプタへの永続ソケット接続を含む、請求項７に記載のシステム。
9. 前記キャッシュは、分散ファイルシステムの上部の少なくとも１つのノードに位置する、請求項１に記載のシステム。
10. 前記キャッシュアダプタは、前記キャッシュアダプタにインタフェースするアプリケーションのためのＳＱＬインタフェースを備えた関係データベースとして機能する、各ユーザのためのキャッシュの固有のインスタンスを作成する、請求項１に記載のシステム。
11. 前記キャッシュアダプタは、前記分散ファイルシステムの前に存在する、請求項１に記載のシステム。
12. 前記キャッシュは、構成ファイル内の連続スペースである、請求項１に記載のシステム。
13. キャッシュデータを分散させるための方法であって、
    キャッシュアダプタを用いて、分散ファイルシステムを形成するマシンのネットワーク化クラスタの少なくとも１つのノードにメモリの指定された部分を連続スペースとして確保する段階と、
    データを格納するよう構成されたデータセルを含む前記メモリの指定された部分を用いてキャッシュを形成する段階と、
    データキャッシュ及び分散ファイルシステムを前記キャッシュアダプタにインタフェースする段階と、
    前記キャッシュアダプタを用いて前記データにアクセスするために外部クライアントにインタフェースする段階と、
    前記キャッシュアダプタを用いてウェブサーバを介してクライアントに通信する段階と、
    前記キャッシュアダプタを用いてアクセス要求を前記データセルのうちの適当なデータセルに送る段階と、
    前記キャッシュアダプタ内に組み込まれた軽量アプリケーションサーバを介してアクセス要求を処理する段階と、
    を含む方法。
14. 関係データベーステーブルフォーマットで前記データを格納する段階を更に含む、請求項１３に記載の方法。
15. ジャバデータベース接続性を使用して前記データ及び前記分散ファイルシステムをインタフェースする段階を更に含む、請求項１３に記載の方法。
16. 必要に応じて、前記キャッシュを通過することなく前記分散ファイルシステムに存在する前記データに直接アクセスする段階を更に含む、請求項１３に記載の方法。
17. キャッシュアダプタを用いて、分散ファイルシステムを形成するマシンのネットワーク化クラスタの少なくとも１つのノードにメモリの指定された部分を連続スペースとして確保するための手段と、
    データを格納するよう構成されたデータセルを含む前記メモリの指定された部分を用いてキャッシュを形成するための手段と、
    データキャッシュ及び分散ファイルシステムを前記キャッシュアダプタにインタフェースするための手段と、
    前記キャッシュアダプタを用いて前記データにアクセスするために外部クライアントにインタフェースするための手段と、
    前記キャッシュアダプタを用いてウェブサーバを介してクライアントに通信するための手段と、
    前記キャッシュアダプタを用いてアクセス要求を前記データセルのうちの適用なデータセルに送るための手段と、
    前記キャッシュアダプタ内に組み込まれた軽量アプリケーションサーバを介してアクセス要求を処理するための手段と、
    を備える、分散キャッシュデータシステム。
18. 前記キャッシュアダプタは、関係データベーステーブルフォーマットで前記データを格納するよう構成されている、請求項１７に記載のシステム。
19. 前記キャッシュアダプタは、ジャバデータベース接続性インタフェースを使用して前記データ及び前記分散ファイルシステムにインタフェースするよう構成されている、請求項１７に記載のシステム。
20. 前記キャッシュアダプタは、必要に応じて、前記キャッシュを通過することなく前記分散ファイルシステムに存在する前記データに直接アクセスするよう構成されている、請求項１７に記載のシステム。